LOFTER for ipad —— 让兴趣,更有趣

点击下载 关闭

LOFTER-网易轻博

Scrum

1894浏览    46参与
榜单数据更新于2018-06-02 15:31
蓓蓓—PM的修炼

雌雄同体 | 互联网时代的阴性领导力(深度好文)

3.8女神节,马不停蹄赶到上海,参加u.lab中国2017年在上海浦东创展的开年活动。从个体进化到组织进化,与来自创新创业、教育等不同领域的女性先行者面对面交流。这次上海之行收获颇丰,让我对下一代领导力,有了全新的理解。

本篇共计3490字,预计阅读时间10分钟。


下一代领导力的未来


奥托·夏莫在达沃斯世界经济论坛的演讲中提到,下一代的领导力将会表现出更多的阴性特质。在这个颠覆性变革丛生的互联网时代,伴随人工智能的兴起,依赖数据计算和逻辑处理的工作,将会越来越多被替代,而从心出发,具备高感受力、高反思力、高感知力的阴性领导力,代表着下一代领导力的未来...

3.8女神节,马不停蹄赶到上海,参加u.lab中国2017年在上海浦东创展的开年活动。从个体进化到组织进化,与来自创新创业、教育等不同领域的女性先行者面对面交流。这次上海之行收获颇丰,让我对下一代领导力,有了全新的理解。

本篇共计3490字,预计阅读时间10分钟。


下一代领导力的未来


奥托·夏莫在达沃斯世界经济论坛的演讲中提到,下一代的领导力将会表现出更多的阴性特质。在这个颠覆性变革丛生的互联网时代,伴随人工智能的兴起,依赖数据计算和逻辑处理的工作,将会越来越多被替代,而从心出发,具备高感受力、高反思力、高感知力的阴性领导力,代表着下一代领导力的未来。


不管是在企业还是现今的社会中,主流的领导方式呈现出非常强烈的阳性特征,大都是强势的,说一不二的,在结果导向的互联网企业中尤甚,习惯用简单粗暴的方式来解决问题,眼睛一刻不停的盯着数字,手脚一刻不停的向前狂奔。说实话我很欣赏这样的leadership所带来的那种,扑面而来的,执!行!力!(微笑脸)。他们想了就说,说了就做,要做就100%做透,死磕自己,做到极致。


然而,在这个个体价值越来越凸显的互联网时代,命令控制型的领导模式,越来越显示出它的局限性。在这种强势领导者的周围,却遍布着各种看不见的淤堵情绪,要不就如同火山,过段时间集中爆发一次;要不就彻底转化为深深的压抑,随之而来的是循规蹈矩和创造力的缺位。


《道德经》中说,“知其雄,守其雌,为天下溪”。即便对于一个男性领导者来说, 守雌都是相当重要的修为。虽心有猛虎,少了细嗅蔷薇的细腻与敏感,恐怕也会丢失了一分沉静与笃定。


那么,我们该如何修炼自己的阴性领导力呢?


阴性领导力的三个重要特征


在我看来,所谓的阴性领导力,大约可以归纳为以下三力模型,高感受力+高反思力+高感知力。而阴性领导力的修炼,则可以从身、心、意三个层面出发,增强对自我的觉察和锻炼。



高感受力


在之前报道的Julia的工作坊中,我们提到一个ME-US-IT框架,大意是说如果一个leader在IT(事务性工作)中持续投入猛抓业务,ME和US做的一般(很少关注自己和他人的状态)的话,那么任这个leader不辞辛劳,殚精竭虑,长期下来作为一个团队,其效能提升的空间也只有50%。而与此相反,如果一个leader能够在ME和US上都做的很好,那么长期下来这个团队效能提升的空间,竟然可以达到390%!!!




我曾经看到一些阴性气质凸显的leader们,有很多甚至是男性领导者,他们真的可以做到“雌雄同体”(咳咳)。


  • 开会的时候TA敏锐地留意每个人细微的状态变化,当大家因为意见不合而僵持不下时,TA一句玩笑举重若轻,转而把大家带到全新的思考维度上面去;

  • 交待了几次的事情迟迟没有启动,TA会说“这件事情似乎不在你的兴奋点上,对吗?”,然后仔细听你的诉说,同时思考如何能够让你在做事的同时找到自己的发展;

  • 一件事情遇到困难,持续的努力都没有起色,你知道TA第一个会问的问题,一定是你需要什么帮助?然后一起去找新的可能解法,而不是责问你为什么没有做好。你知道,TA是真的相信,你,已经尽力了。


这样一种有温度的leader,会更多关注冰山下每个人细微的感受、感觉和感情,而不只是硬邦邦的逻辑、推理和结果。

这样一种有温度的leader,懂得“用”和“养”的关系,不只是“取现”式的拿来就用,只要结果,而是关注产出的同时,也时不时地“存钱”,让这个人在做事的同时也能有所成长。

这样一种有温度的leader,能够最大程度激活个体的能量,通过组织的力量而非个人的力量,让团队完成远大的目标。


高反思力


阴性领导力的特征之二,就是要具备高反思能力。不再一味强势坚守自己的观点:“我是对的!你是错的!”而是,时常反观自省,“我可能想错了,原来还可以这样!”


教育自媒体人沈祖芸,把高反思能力分为三个阶段:

  • 处在第一层次的人,反思通常发生在遭遇巨大变化之时,特别是面对巨大的打击和挫折,人会因此被迫产生一种自我回观,对之前的行为作出调整。

  • 处在第二层次的人,反思已经变成了一项周期性进行的活动,每走过一个阶段,就会触发自觉地总结回顾,为后一个阶段积蓄一些改变的动力。

  • 处在第三层次的人,主动反思的意识已经融入了血液,进行中一旦意识到问题,就会马上响应做出改进。响应速度之快,哪怕在事情发生的前后5分钟,其思维模式和行为模式都在不断进化。


具备高反思能力的人,在心态、思维和意志上,都是非常开放的。我曾经跟一个处于第三层次的leader聊天,他说他现在对于任何人或事物,都已经不会再有那么僵化的、非零即一的看法,而是变得非常非常灵活,就好像回到一种混沌的状态。变化的原因是他开始认识到,不管是对哪个人或哪件事,都有正反两面性。虽然现状可能是9:1,造成你对这个人或事有如此这般的认知,可从变化的眼光来看,这两面都有无限的可能性。在这样的认知下,他对人对事的看法,不得不经常松动,甚至发生阴阳的转化。不理解的人会觉得他过于善变,可当你深入了解之后,从另一个角度来看,或许有一种可能,就是他进化的速度实在太快了。。。


与此相反,低反思能力的人,头脑中往往有着极为坚固的封闭体系,对周围人或事形成了很多固有的看法和判断。当环境发生变化并释放出信号时,TA们如鸵鸟般视而不见,继续死撑着试图用自成一套的体系来解释。直到哪天猛烈的大地震来临,整个系统发生崩溃,TA们将会陷入到极大的恐慌,不得不去重建一套新的封闭体系,以支撑起脆弱的自我,也因此开启新一次的轮回。


一个人如果具备高反思能力,越是环境剧烈变化,越是会锻炼出极强的反脆弱能力,对变化耐受甚至能从变化中获益。一个人如果具备高反思能力,就能不断超越自己,保持一个超高速的成长,赢在各个时代里。


进而,一个组织如果具备高反思能力,也才能够在剧烈的时代变迁中,依然做到基业长青。


高感知力


阴性领导力的特征之三,就是具备高感知力,向内看,与初心连接。


馒头商学院的王欣院长,在分享帮助传统企业做互联网转型的诀窍时说到:

  • 很多企业把自己遇到的问题归因于环境的变化、竞争对手的威胁。后来她跟企业一起去分析所面临的现状,她发现困住他们的不是环境,也不是竞争对手,而是他们走了一段路之后,忘了自己为什么出发。当初究竟为什么要创办这家企业?

  • 当我们能够与初心合一,我们才能找到自己的力量所在。


这个世界从来不缺乏向外看的眼光,在U.lab的Mooc中,有一段非常有意思视频,讲的是1968年阿波罗朝着月球前进的过程中,有个宇航员在跟地面连线时,随口说到,“嘿,我要把镜头掉转过来,让大家看看地球”。那是人类第一次看到了自己的星球,而这一刻注定意义非凡!


在此之前,人们全部的注意力都放在我们要去太空,满脑子都是月球上会是什么样的景象。刹那间,当我们猛然回头,看到黑色的虚空中悬挂着的地球时,一种全新的自我觉察升起了。


我身边的很多人,包括我自己,从小努力学习,是为了考个好大学;长大后殚精竭虑,是为了找个好工作;然后我们兢兢业业经营自己的事业和人生,是为了得到他人的认可。我们给自己设定了一个又一个的目标,在人生的路上不断狂奔,却渐渐忘了自己为什么要出发。终有一日,某个新的挑战,某件事,某个触动,会让我们停下来,开始调转镜头,看向自己。


在经历了亲人离世的悲痛之后,我越发忍不住问自己,既然人生终究一场空,我为什么要做这些事?我究竟在寻求什么?我最想要的到底是什么?这个从未有过的视角,促使我开始越来越多的自我回观。


每个人都会有找到自己的方式,但在我看来,唯有用心去做事,用心去经历,让自己全身心投入这个世界,尽情地撒欢。然后,在某个时刻,当头脑中那些嗡嗡作响的杂音和杂念平静下来,用你的心去感受,自己最最enjoy的那个我,到底是什么。


具备这样一种高感知力的人,TA们在践行的同时,自带超敏锐的感知传感器,一边做一边感知一边调整,迭代反馈都在瞬间同步发生,我想这才是真正的“知行合一”吧!


结束语


最后在此一并感谢在本篇中现身的那些leader们,TA们给过我很多启发,并且依然在深深地影响着我。然而,总结归纳容易,全然做到实属不易。写下来的好处,分享的同时,也在于可以时常反观提醒自己,走在知行合一的路上,与君共勉!


好文推荐

给新手leader的5个忠告

给新手PM的5个忠告

项目经理的核心竞争力


蓓蓓—PM的修炼

互联网企业下的阴阳平衡

[导读]在业务发展的高压之下,我们渐渐习惯用最最简单粗暴的方式来解决问题。“发展才是硬道理”,渐渐演变成“发展才是唯一道理”。如何从对立中找到统一,帮助产品和团队健康快速的成长,是项目经理们必备的技能。引文也从阴阳的角度分析了如何将对立的二者进行统一,打造健康的团队。

“业务导向”Vs“可持续发展”

文/雷蓓蓓


去年的Scrum Gathering会上,在IBM及GE等公司分享的敏捷转型经验中,都会提到两个典型角色的构建,PO(Product owner)与SM(Scrum master)。其中,PO是业务目标导向,为业务目标负责,关心商业回报及投入产出比ROI,决定哪些事...

[导读]在业务发展的高压之下,我们渐渐习惯用最最简单粗暴的方式来解决问题。“发展才是硬道理”,渐渐演变成“发展才是唯一道理”。如何从对立中找到统一,帮助产品和团队健康快速的成长,是项目经理们必备的技能。引文也从阴阳的角度分析了如何将对立的二者进行统一,打造健康的团队。

“业务导向”Vs“可持续发展”

文/雷蓓蓓


去年的Scrum Gathering会上,在IBM及GE等公司分享的敏捷转型经验中,都会提到两个典型角色的构建,PO(Product owner)与SM(Scrum master)。其中,PO是业务目标导向,为业务目标负责,关心商业回报及投入产出比ROI,决定哪些事情最应该优先去做;而SM则更多是凝聚团队更好地达成目标,关心长期发展过程中的团队人员成长,及系统的可持续发展。PO与SM可以说是Scrum当中最为经典的角色设计,彼此互为补充,确保团队健康的前提下,达成业务目标。他们就好比一对搭档,互相制约互相平衡,失去了哪一方的视角,都会带来严重的后果。



而在实际项目当中,在业务发展的高压之下,许多长期效应的工作却被一再选择性忽略,我们没有时间做架构优化,我们没有时间做团队回顾及凝聚,因为单单是拼业务就已经够忙了。于是,我们开始习惯用最最简单粗暴的方式来解决问题,目的就是让这台“机器”可以继续快速运转下去。业务目标导向,慢慢地整个团队被绑架,把“发展才是硬道理”,变成了“发展才是唯一道理”。我们没那闲功夫磨刀,直接上去一通砍柴,直到这把刀在一次又一次的蹂躏中断掉了,系统或团队遇到大麻烦了,这才幡然醒悟。


可是,这样的醒悟对于任何一个局中人来说,都无疑是异常艰难的。拿我自己的例子,当我切切实实背着业务压力之时,我发现自己也在不自觉地忽略一些事情,虽然心里也明明知道这不是最好的解法,可还是下意识地给自己的简单粗暴找各种理由。现在看来,我很庆幸自己能有这样一段经历,可以让我真正站在另外一个视角,切身体会到业务压力下的种种难处,才不至于站着说话不腰疼。


项目经理是个多面手,多个角色上的历练和体验,才能拥有更加广阔的视角,及更加成熟的心态。在经历了无数内心斗争之后,我逐渐意识到,业务导向和可持续发展,想在一个人身上完美兼顾两种职责,是有多么困难!我见过一些非常有经验的业务负责人,哪怕是深知其中利害要理,在实际压力之下,也很难真正长久做到兼顾。


一开始,这些对于可持续发展的忽略,在短期内不会出现任何问题,就好比当产品和团队还年轻时,还有大把的青春可以挥霍,连续的加班熬夜,稍作休息、打个鸡血立马就能恢复如初。可随着时间的推移,两年、三年以后,几乎无可避免的,各种亚健康状况开始凸显。表现在产品和团队上,产品新功能交付的速度越来越慢,核心模块的代码已经越来越少的人能看懂,线上各种故障频发,尽管再三强调似乎始终找不到治本的方法。冰冻三尺,非一日之寒,此时想要逆转实属不易。


这也是为什么,在Scrum框架的设计上,设置两个互相制衡的角色会如此重要!罗辑思维有一期节目中曾经说道,在搭建一级组织、配备一个团队的时候,一定要有人扮演那个聚拢人心,发展队伍的角色!在当前的组织架构中,对应于业务负责人,我们的项目经理就需要承担起这个角色,与业务负责人互相搭对,平衡补益,有坚守,有变通,才能共同把事业做大做长久。


最后,关于Scrum中两个角色的设计,再给大家推荐一篇好文,作者王宇从阴阳消长的角度,带我们领略了Scrum框架中隐藏的东方智慧。


以下为转载文章,来自思维发条,作者王宇:


“阴阳者,天地之道也,万物之纲纪,变化之父母,生杀之本始,神明之府也。治病必求于本。”——《黄帝内经》


大家都知道在Scrum中,有三个角色。Team,ScrumMaster,ProductOwner。团队一般就是干活的,“自组织”、“跨职能”,咱们先不说这个角色。先说说PO和SM,PO在团队面前代表业务,在业务方代表团队。他维护了一个产品待办列单(Product Backlog)。但说是他维护,其实是团队一起维护,关键的时候听他的就是了。SM的话,导入过程,激发转变。他站在团队一方和并宣扬敏捷价值观。就像下面的图一样:




这也就是说,有的时候SM和PO的利益是冲突的,但对立且统一。使这种艺术得以实现的就是因为有中间的团队存在。




咱们暂时不说,到底哪个是阴,哪个是阳。由这样的配合形成了一个矛盾的统一体,如果不是矛盾的话就有问题了。比如SM很强悍,PO很弱,团队就像快乐的没头苍蝇一样。比如PO很强悍,SM很弱,团队就像被压迫的奴隶一般。


对于PO所在的黑色区域会形成两种工件,一个就是Product Backlog,再有一个就是离团队更近一些的Sprint Backlog。




这张图感觉不平衡了吧,上面缺少了一些东西。没错,Scrum框架缺少了一部分的内容。把缺失的一部分补充完毕之后就应该是这个样子的。




Sustainable Backlog进入每一个迭代就会分解成为Leadership Action。Sustainable Backlog 如何产生?方向是什么?一般在回顾会议上产生。它持续更新,持续跟进,如同Product Backlog Scrum Master通过教练的方式引导团队产生。方向有两个:


纪律指标

团队是否拥有纪律公约,每个人的执行效果如何?衡量方式可以是匿名打分:5分就是钢铁一般的纪律,我了解并100%执行;1分就是我根本就不知道什么是团队纪律。


快乐指标

团队是否愿意工作,积极参与,愿意贡献每一分力量。衡量方式也可以使匿名打分:5分就是早上起床一想到要上班都安奈不住心中激动的心情;1分就是早上起床想到上班就想死到床上。


这两个指标螺旋上升成为团队的浮现式目的。(对于孩子来说,外部目的是让家长快乐,要不然不会生他;内部目的是要活下去并繁衍下去;浮现式目的就是我要成为一名科学家或是赛车手)这又是一个小的阴阳螺旋。

  • 每一个Sustainable Backlog都是一幅未来的图像。

  • 每一个Sustainable Backlog都是让我们团队更为凝聚的一次动力。

  • 每一个Sustainable Backlog一旦完成,你想要在这个团队永远待下去的想法就会强化一次。

  • 每一个Sustainable Backlog与收入无关。可以简称SB


Leadership Action就是Sustainable Backlog的分解,它有以下特点:

  • 符合SMART原则(不知道的自己查去)

  • 都是改变或转变的行动(跟之前的做法不一样)

  • 不是需要别人告知,而是团队自行分解出来的(我们都是成年人)

  • 每完成一个就可以调整Leadership Action或者Sustainable Backlog

  • 可以在回顾会议上讨论,也可以线下随时跟进与调整。


有时Leadership Action和Sustainable Backlog分界线不明显,就如同Product Backlog 不一定再次分解成为Sprint Backlog一样。那么就会成为Sustainable Leadership Action。简称为SLA,但Sustainable Backlog有一个和Product Backlog明显的区别。就是推动的方向不一样。见下图:




PO的动作是推,而SM的动作是拉。黄色箭头为"Holding for Team"的标志,说白了不管是Product Backlog还是Sustainable Backlog都是大家的。只不过这个角色为整个团队代表某种力量。其实这两个黄色箭头可以与两个会议相关联。如下图:




最终SM会把团队拉到自己的位置,然后逐渐消灭自己。


中国的阳明文化讲究知行合一,知其实就是SM所代表的就是改进状态和团队的敏捷状态,而行则是PO所代表的交付价值导向。一般来讲先知而后行,也就是说SM要导入这种状态,PO才开始工作。但现实中的敏捷推进恰恰大家都太过于强调“行”了,而忽略了“知”的重要性。就如同某人不停呼气一样,他能坚持多久我不知道,可能这也就是为什么敏捷推进在基层团队看来就是另一种压迫团队的手段而已。


不多说了,希望真正的Scrum Master能够坚持敏捷所倡导的价值观,把团队真正的拉到太极之中,打造团队的神奇……

Andy

Scrum晨会那些事

Daily Scrum Meeting,在腾讯这里有多种叫法:站立会、早会、每日例会、晨会。由于会议一般都是在早上开的,因此我们都习惯把该日常会议统一叫“晨会”。在团队内实行了2年的晨会,在此分享一下积累的经验。

1 参与角色

    在大多数的项目里面,会根据特性的不同,我们会划分成为多个虚拟团队,每个团队有比较固定的成员,包括:产品经理(PDM),开发(DE), 测试(TE),项目经理(PM)。

    在虚拟团队中,PM作为一个管理者,保证该团队的正常运作。

    注意:在腾讯的某...

    

Daily Scrum Meeting,在腾讯这里有多种叫法:站立会、早会、每日例会、晨会。由于会议一般都是在早上开的,因此我们都习惯把该日常会议统一叫“晨会”。在团队内实行了2年的晨会,在此分享一下积累的经验。

1 参与角色

    在大多数的项目里面,会根据特性的不同,我们会划分成为多个虚拟团队,每个团队有比较固定的成员,包括:产品经理(PDM),开发(DE), 测试(TE),项目经理(PM)。

    在虚拟团队中,PM作为一个管理者,保证该团队的正常运作。

    注意:在腾讯的某些部门,PM只是负责完成管理工作,因此产品的成功与否跟PM无关,与产品负责人(PDMO)紧密相关,有PDMO和运营直接承担KPI。

    虚拟团队的架构如下图,最终向PDMO汇报



    相关名词解析:

    产品经理(PDM):Product Development Manager

    产品负责人(PDMO):Product Development Manager Owner

    开发:Development Engineer

    测试:Test Engineer

    项目经理:Project Manager

2 设定主持人

    虚拟团队成立初期,PM必须作为主持人,负责维持晨会的正常运作。等到团队经过一段时间的磨合期之后,可以进行主持人轮换。

    2年时间里,每个虚拟团队的晨会方式都不一样,这里总结了主持人需要做的工作:

    1)准时召集开会。会议时间可以设定在9:30-10:00之间,这样能明确大家当天的工作安排。

    2)监督参与成员。PM、PDM、DE、TE都需要参与,保证信息同步的一致性和实时性。

    3)监督发言。确保了每个人的发言都包括了“昨天做了什么”,“今天要做什么”,“遇到什么困难”。

    4)解决困难。对于遇到困难的童鞋,需要落实解决办法。主持人可以发言:“这个问题,谁帮忙看下?”或者“A同学,你能协助B同学看看这个问题么?”。具体方案在晨会后单独把相关人拉起讨论,切勿在晨会上展开讨论。

    5)控制时间。确保每人发言时间1分钟左右,晨会15分钟以内。避免在晨会上对细节问题进行讨论。

    6)明确当日目标。轮流发言完毕之后,主持人需要简单总结当日的目标,明天主持人根据前日的目标进行验收,避免进度延期。


    以上几项是主持人的基本职责,只要做到就可以很好地主持晨会。在过去的团队里面,有些很出色的主持人

    1)冷笑话。在会议前说一个冷笑话,活跃气氛。

    2)个人分享。在会议前用5分钟进行分享,适用7人以下的小团队。分享内容可以由主持人自由发挥。这个环节非常有效,在极短时间内提高了团队凝聚力,团队成员关系也很好。很有趣的事情就是每个人的兴趣不同,因此个人分享逐渐延伸出很多个专辑。例如:个人励志故事、易经那些事、侦探小说、生活百科、国学舞蹈等等。在分享的过程中,提升了大家讲故事的能力,促进感情交流,非常棒。

    3)RTX或邮件输出晨会内容。

    4)实时更新进度墙


3 Token发言令牌

    在早起的晨会中,每个人是轮流发言的,这是一种常规的方式。在这种方式下会存在几个问题:

    1)发言很形式化

    2)后发言的同学容易开小差,不集中精神

    3)发言过的童鞋会开小会


    后续对晨会进行了优化,增加Token发言令牌。

    准备:一个小巧的公仔,我们这里用的是企鹅公仔

    规则:只有手持公仔的人才能发言。如果想要发言,需要举手示意接到公仔后才能发言。发言完毕,可以随便把公仔抛向未发言的童鞋。

    例子:A手持公仔,发言完毕后抛给B。在B发言过程中,C需要帮助B解决困难。待B发言完毕,C示意需要发言,B把公仔抛给C,C开始发言。

    注意:一定要随意抛出公仔,作用有二:一是不确定性让大家集中精力准备发言,二是增加了晨会的趣味性,特别在早上有提神的效果。


4 设定人数

    晨会人数应控制在15以下,最好在10人左右。这是因为如果人数过多,即使有主持人,也很难保证晨会效果。

    如果团队确实很大,建议采用分层晨会的方法,例如将团队分为几个小组,A、B、C小组分别开晨会,然后A、B、C各派一名代表,再开一个晨会,交流一下小组的工作。

    分层晨会的方式很多,刚才说的是其中一种,大家也可以根据自己的实际情况来组织。

5 进度墙

    试想一下,假如10个人都说完“我昨天做了什么”,“今天要做什么”,“遇到什么困难”,晨会上估计没人会记住。与发言人没直接相关的童鞋更不清楚他做了什么。单纯的口头语言描述,会让信息的传递大打折扣。因此我们需要结合进度墙进行会议。目前我们采用的是Scrum的进度墙方式。(之前试过采用丰田的精益看板方案,发现过于复杂,维护起来不方便,最后舍去了)



    以上是团队2年来总结出的一些经验,希望对读者有帮助,欢迎随时交流。


麻辣土豆片

敏捷方法XP和Scrum有什么区别

最近忽然看起了敏捷方法,在网上瞎逛,发现了一些不错的文章,收藏之。 

查看原文点击 这里,翻译在 这里

作者总结的大致区别如下: 

区别之一:  迭代长度的不同。 
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。 

区别之二: 在迭代中, 是否允许修改需求。 
XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需...
最近忽然看起了敏捷方法,在网上瞎逛,发现了一些不错的文章,收藏之。 

查看原文点击 这里,翻译在 这里

作者总结的大致区别如下: 

区别之一:  迭代长度的不同。 
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。 

区别之二: 在迭代中, 是否允许修改需求。 
XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换,  替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum  Master严格把关,不允许开发团队收到干扰。 

区别之三: 在迭代中,User Story是否严格按照优先级别来实现。 
XP是务必要遵守优先级别的。但Scrum在这点做得很灵活,可以不按照优先级别来做,Scrum这样处理的理由是:  如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story  #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10。 

区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量。 
Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD,  自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾,  因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”。 

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束 

作者建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP。(start with Scrum and then invent your own version of XP.)


同步自网易博客 (查看原文)

黎明传说
通俗易懂学Scrum敏捷开发

通俗易懂学Scrum敏捷开发

通俗易懂学Scrum敏捷开发

秒大刀

读《30天软件开发——告别瀑布拥抱敏捷》

正文之前

  1. 软件开发是复杂的,其结果有时会令人诧异;工作是由人来完成的,人们的创造力和生产效率在小团队协作时最高

  2. 利用短周期循环,在每个循环结束时检视成果来控制复杂度,由此控制风险。短周期循环还能让所有的浪费都变得可见并能够逐步被移除

  3. 发挥主观能动性,充分利用自下而上的智慧

  4. Scrum的核心是其价值观:做正确事情的勇气、竭尽所能地承诺、对当前问题的专注、对团队成员和相关干系人的坦诚,以及对自己和他人的尊重

  5. 组织导入敏捷的过程中,循序渐进是基本的原则之一,剧烈的变革给组织带来的问题永远比效益更多。领导者的参与和推动是组织实施Scrum过程的前提

  6. Scrum很...


正文之前

  1. 软件开发是复杂的,其结果有时会令人诧异;工作是由人来完成的,人们的创造力和生产效率在小团队协作时最高

  2. 利用短周期循环,在每个循环结束时检视成果来控制复杂度,由此控制风险。短周期循环还能让所有的浪费都变得可见并能够逐步被移除

  3. 发挥主观能动性,充分利用自下而上的智慧

  4. Scrum的核心是其价值观:做正确事情的勇气、竭尽所能地承诺、对当前问题的专注、对团队成员和相关干系人的坦诚,以及对自己和他人的尊重

  5. 组织导入敏捷的过程中,循序渐进是基本的原则之一,剧烈的变革给组织带来的问题永远比效益更多。领导者的参与和推动是组织实施Scrum过程的前提

  6. Scrum很难在组织内作为一个特例单独存活,必须让整个组织融入Scrum,实施自内而外的变革,才能让敏捷扎根于组织

  7. 管理者需要给员工创造透明且安全的成长环境

  8. 敏捷转型是一场变革,如果没有高层的支持,项目组只能小打小闹,结果是要么停滞不前,要么中途夭折。它需要自上而下和自下而上的双向支持


第一部分 为什么说每家公司都能在30天内开发出软件

  1. 软件行业正在经历巨变并日臻完善。过去软件开发具有很高的不确定性,风险大,浪费严重,这些司空见惯的情况现在已有所改观


第1章 软件危机:错误的流程导致错误的结果

  1. 采用传统开发流程(瀑布式)的项目中只有14%成功了,而采用敏捷流程的项目成功率则有42%。敏捷项目的成功率是三倍

  2. 在典型的软件项目中,35%以上的需求都会变更

  3. 预测性流程适合制造业的原因是一个流程会制造出大量的产品。而这恰恰是它不适用于软件行业的原因,因为软件开发的一个流程只会产生出一个产品

  4. 软件开发在过去非常容易失败,其根本原因就是使用了预测性流程来做复杂的工作


第2章 Scurm:正确的流程产生正确的结果

  1. 信息是通过观察而不是预测获取的

  2. 我们必须经常检视当前的进度,这样才能够调整下一步的计划,从而得到最好的结果

  3. 高频率的迭代通过持续检查进度来有效控制浪费、降低风险。频率的范围最好在一个星期以上,一个月以内

  4. 增量必须是完全完成并可用的,不能有任何工作落下。未完成的工作或原型都不具有透明性

  5. 每次迭代都会产生潜在可用的软件增量。每个软件增量必须是没有任何遗漏的完整功能

  6. 一旦发现产品的价值已经达到最大,尤其是发现软件里过半的功能很少被使用的时候,就可以停止迭代

  7. 可以在到达交付期限或者预算上限的时候,停止迭代并发布软件

  8. 我们只会开发并积累有价值的增量

  9. 只为即将开始的迭代做详细的计划,这被称为“适时计划”

  10. 打造出有出色创造力、质量、工作效率和士气的高效团队:通过调整团队结构、提供工程实践能力和建立规范来塑造团队特质,提高团队的生产率、质量、创造力和持续改进的能力

  11. 如果要让员工对自己的工作拥有自豪感以及参与感,必须营造一个充满鼓励和尊重的工作环境

  12. 当团队展现出自我管理、自我超越、相互学习这三方面能力的时候,就证明他们已经成为了真正的自组织团队了

  13. 管理层只提供指引、资金和支持,而不会对团队进行过多的干预。管理层扮演的更像是风险投资人的角色,只提供金钱的支援而不会对团队指手画脚

  14. 既要让团队有足够的空间自我管理,又要设定足够的检查点,防止不稳定、不明确以及紧张因素带来混乱。同伴的无形压力以及“关爱和控制”的方法是微管理的基础

  15. 来之不易的知识应该在整个公司范围内积极分享

  16. 敏捷性是在一定风险下把握机会的能力或者说是勇于面对挑战的能力


第3章 你也来试一试:创建试点项目

  1. 团队成员必须是全职的

  2. 所有人都应该在正常的工作时间内工作

  3. 在正常的工作时间结束后让团队成员回家,能够激发他们的潜意识,从而想出新方法,找出错误

  4. 即使在经济衰退的时候,优秀的工程师也会找到别的工作机会

  5. 关于某些重要事情,带有强烈感情的讨论,只有在每个人都感觉安全的情况下才能够进行。每个人都应该感觉到自己受到尊重,能够尽情的讨论和反对,能够为寻求最佳方法而畅所欲言

  6. 有时不显眼的几次打扰,都有可能使团队的效率下降50%以上

  7. 由于当前的方法不可行,因此冒着可控的风险进行变革是值得的

  8. 技术水平最高的团队成员通常会在其他成员的支持下站出来带领大家

  9. 当所有软件工程师都专注在一个问题上的时候,他们能够找到最好的解决方案


第4章 我要做些什么

  1. 决定终止其实也是一种成功,因为你成功的避免了浪费更多的金钱

  2. 人们只有在感觉安全的时候才会进行关键的对话,敞开心扉畅所欲言,不带伤害和报复的互相协作

  3. 经理最重要的职责就是创造安全的工作环境

  4. 在团队中集思广益而不仅仅依赖于经理个人想法的管理方式,能让团队的所有成员尽其所能

  5. 经理的任务是设定目标、帮助团队和扫除障碍,团队成员被授予了充分的自主性

  6. 经验型软件开发流程在组织里能有多成功,很大程度上取决于组织的管理层,以及在面对以上这些变革时的领导力和影响力


第二部分 如果在30天内开发出软件

第5章 初试Scrum

  1. 开发人员需要懂得如何将大的需求分解成在Sprint中可执行的精细的开发事项

  2. 每个人都需要知道在接下来的Sprint中要开发的是什么

  3. Sprint的目标必须同时得到开发人员和产品负责人的认同

  4. 产品负责人则需要同意在Sprint进行期间不会变更开发人员正在开发的需求,任何在计划之外的事情都会等到下一个Sprint再讨论

  5. 完成的软件增量必须是完整可用的软件模块。没有彻底完成的产品待办列表项将会重新进入产品待办列表,成为“待办”条目

  6. 团队是否拥有足以完成工作的技能和设施?


第6章 在项目中应用Scrum

  1. 50%的软件功能很少甚至从未被使用

  2. 为了优化价值,产品负责人必须决定何时停止后续Sprint,以保证交付的功能都是高价值的

  3. 要探索新的机会,要么创造全新的方法,要么改进老的方法

  4. 复杂问题的定义是:未知的比已知的事情多

  5. 周期较长的Sprint通常用于变化较少的环境,而周期较短的Sprint则更适用于具有机会性或挑战性的环境

  6. 周期较长的Sprint适合风险较低,变更不频繁或者确定性较高的情况

  7. 使用较短周期的Sprint的代价就是要花费更多时间在计划和回顾会议上

  8. Scrum团队有时需要长达一年的时间才能完成磨合,成为熟练的团队,或者根本无法变得熟练

  9. 当Sprint的长度短于一周时,团队通常无法将需求转化为可用的功能。在如此短的时间内要开发出可用的功能或者提供管理方面的信息是非常困难的

  10. 当Sprint的长度超出30天时,会失去对项目的专注,甚至忘记了项目的相关内容。随着需求数量的增加,项目的整体复杂度就会以超过线性的方式增加。团队也很难查看并吸收本次Sprint如此大量的信息,并因此作出决定。

  11. 软件开发团队在保持一定速率的时候表现最好,因此他们形成了自己的节奏


第7章 创建Scrum工作室

  1. Scrum工作室——一个长期运营的,可以让Scrum软件项目快速启动的机构。Scrum工作室是组织内的一个全新的、独立的机构。在工作室中使用Scrum解决了在企业里全面推广Scrum时可能遇到的潜在困难和问题

  2. 多数采用Scrum的企业都需要好几年才能完全的获得最大益处

  3. 以团队而不是个人为单位进行奖励,注意绩效考核的方式

  4. 每个增量都要符合Scrum“透明”和“完成”的定义

  5. 工作设施:Scrum团队能够享受更有利于团队合作的开放式设施。Scrum团队成员所拥有的空间足够让他们在开发软件的过程中自由互动,每个人的位置都能够容纳两位或者三位开发人员一起工作。工作室座椅必须舒适,而桌子则能够自由活动。互联网、局域网和开发服务器都应该准备就绪。会议区的投影仪/电子书出设备(大屏幕电视),以及足够的白板。工作室内还需要为到访的客人和临时的工作人员准备充足的空间。如果需要的话还可能根据实际需要重新调整工作空间

  6. Scrum团队必须拥有完全自动化的开发环境,这样一旦有新的软件或者变更,就能马上进行测试

  7. 采用精益质量的管理方法,质量控制需要伴随着整个开发过程,而不是在功能开发完成后再进行测试

  8. Scrum工作室内的团队需要改变企业文化来实现经验主义和自管理组织。这并不简单

  9. 软件缺陷个数:从团队将功能单位的大小报告给产品负责人直到产品交付客户使用3个月后,期间出现的所有缺陷都会被计入其中

  10. 很少使用的功能仍然需要在整个软件系统的生命周期内维护,这样会增加运营成本

  11. 在软件开发过程中的软件质量直接影响到系统的维护成本以及后续系统增强的成本。低质量的软件比高质量的软件更难增强,还会给组织带来成本的提高

  12. 软件的可维持性和可维护性都会影响软件的生命周期和使用。很多组织的产品代码根基质量很差,那么一旦编写这些代码的员工离职,使用Scrum也无法挽回损失

  13. 一个完成、完整的增量必须是可以正式投入使用的。如果一个增量无法正常工作,无法马上部署使用,就不要接收它。让开发人员重新估算实际完成增量所需的时间,并把它放回产品待办列表中

  14. 在没有完成的工作上面添加新的工作,会使原来的工作更难以完成

  15. 当一个项目被认定为“完成”时,应该没有任何剩余的工作

  16. 在安装水管的时候正确的安装和错误的安装所需要的成本其实差别不大

  17. 技术债务阻碍了透明性,也会导致决策出错。我们通过对比完整可用的软件功能模块和剩余需要完成的功能模块来度量进度。没有完成的工作并不在进度的计算范围之内

  18. 你可以投资于开发人员,直到他们都能够熟练的进行开发,也可以选择其他拥有足够技能的开发人员为你效力

  19. Scrum工作室是企业中的一个独立部门。建立工作室并不是要改变整个组织现有的软件开发流程,而是让那些想用Scrum进行软件开发的人有一个独立的工作空间


第8章 在企业中应用Scrum

  1. 企业转型Scrum的成功与否取决于发起转型的高管

  2. 当讨论企业转型的时候,如果员工是会议的主角,那么转型的成功率会比较高;否则就不太可能会成功

  3. 管理的第一件事情就是要度量,然后再根据度量的结果采取行动

  4. Scrum并不是侵入式的流程。如果公司原来就拥有非常出色的开发能力和流程,就可以继续保持原有的流程。只需要简单的结合Scrum模型,提供用于度量和预测的信息就足够了

  5. Scrum为员工创造了可以发挥创造力,找到最佳工作方式的环境。Scrum还提供了可供度量的信息,让员工能够专注在最困难的工作,追求最好的结果。在Scrum中,所有人都明白问题所在,然后齐心协力解决问题

  6. Scrum不是可以被随意修改以迎合现有企业文化的流程。相反,企业的文化应该进行调整来适应Scrum

  7. 不要认为企业转型是件容易的事。开始策划一件有价值的事情的时候,目标明确、身体力行以及建立氛围都是非常重要的。一旦开始使用Scrum,就能更容易地找到最主要的障碍。过度计划和过度思考是很多企业中常见的问题。Scrum所需要的是实际行动、测试、评估、学习、移除障碍,然后用更多行动来为大家创造有价值的东西


第9章 企业级转型:深化并固化改革

  1. 从启动企业转型工程到实现完全转型的道路是非常漫长的,要通过各种努力,经历长达五六年的时间,才能让深入而牢固的变革在企业里扎根。主要的改变很快就会显现出来。转型的第一年里,你就能看到它带来的好处。转型后的两年内,主要的竞争优势就会得到体现。就算转型已经完成,也要持续改进,这是成功的关键

  2. 在开始转型之前,应该先评估实施Scrum所带来的价值是否大于企业变革所需要的成本。应该召集所有需要在转型中与你密切合作的关键人物进行讨论,让彼此都清晰地了解变革的利弊

  3. 消除焦虑和抵触情绪,创建并执行沟通策略

  4. 制定用于度量敏捷度及其价值的关键效能指标。项目的愿景、目标、策略和战略都需要进行策划,同时还要指定项目预算以及发展路线图

  5. 转型的迫切性来自于组织对提供具有竞争力的服务和产品的渴望。那些认为转型迫切的人,必须举出有足够说服力的例子

  6. 用于展现转型迫切性的案例就是为这个团队招兵买马的宣传手段

  7. 我们的一些竞争对手已经在使用Scrum了。他们现在能够以更低的成本更快的开发出高质量的产品。他们正在侵吞我们的市场份额。如果再不向他们学习并超越他们,我们就有麻烦了。我们的利润会下降,客户会转向竞争对手,员工将会离开。因此我们必须对组织进行转型

  8. 支持转型的最高层管理者负责启动全新的转型工程

  9. 有一群居住在冰山上的企鹅,这些企鹅将这座冰山当作深爱的故乡。尽管必须迁徙,但是它们却把这座冰山看作自己赖以生存的地方。他们需要树立新的愿景,了解迁徙的必要性。需要知道现在所居住的冰山只是当前的家,而它们的种群比家更重要。就算冰山融化,整个种群仍然在一起,只是居住的冰山不一样罢了。这样的愿景让企鹅们有了新的信念和做出改变的动力。新目标就是拯救种群,而迁徙就是拯救种群的方法。

  10. 焦虑情绪是针对转型本身而不是针对转型后的未来

  11. 我们的组织将从市场中各种机会和挑战中获益。通过汇聚每个人的智慧和创造力,我们能重复创造新的、有价值的创新服务和产品。我们可能会犯一些错误,但是能够从错误中学习。我们会是一个开放和透明的组织,彻底地公开我们所有的强项、弱点、处境和机会。我们是一个由员工组成并服务员工的组织。我们重视坦诚的对话和冲突,从中获得真相和机会。

  12. 每个项目就是一个Sprint,而每个Sprint的产出就是组织变革的增量

  13. 沟通永远不会嫌多。有很多不可思议的事情由于沟通不够充分而被信以为真。如果人们不知道自己应该做什么或者怎么做,通常意味着沟通不够有效

  14. 不充分的沟通会导致目标不明确、理解偏差以及漫天的谣言

  15. 谣言是非常不利的,因为谣言总是匿名的,所以人们会肆无忌惮的把自己的意见和恐惧都参杂其中。谣言会阻碍变革的进行,因此要进行有意义的变革就必须把谣言驱散

  16. 如果人们不清楚未来的愿景和自身在其中的位置,无论这个愿景有多么美好,他们都会抵触它。所有员工必须清楚的了解未来的变革对他们本身、他们的工作以及家庭的稳固有什么影响。当人们对转型不了解或者感到不安时,很多人会本能的试图阻碍或者弱化转型。如果不理解变革对于自己的意义,无论是现在还是在将来,他们都会一直抵触它

  17. 抵触的形式多种多样,其中最致命的就数消极抵抗了。这些消极抵抗的人不会反对,也不会表达自己的意见。他们不想被当成转型的阻碍,但是也不想进行转型

  18. 要让大家知道可以通过哪些途径可以对转型进行讨论

  19. 员工应该知道如何在组织上下进行沟通交流

  20. 鼓励任何能够帮助组织前进的事情。确保员工的主动性受到鼓励,从失败中吸取教训是流程的一部分。鼓励每个人都从自己和别人的错误中学习,确保大家都知道自己不会因为失败而受罚

  21. Scrum的核心是“检视和调整”

  22. Scrum推广工作应该以项目的方式进行,每个项目的独特性都将为转型作出贡献

  23. 要巩固转型就意味着要使变革在组织里扎根,产生新的企业文化

  24. 任何不合理的东西都会被更合理的东西取代。这使得组织成为知识创造型和学习型的组织

  25. 转型项目的愿景需要在组织内从上到下的贯彻,并进行持续有效的沟通。转型的目标就是将组织变为一个可以持续更新和改进的学习型组织,而转型的回报则是成就卓越


第10章 用Scrum的方式实施Scrum

  1. 人们通常会在他们真正需要时才投入Scrum的怀抱。如果他们原来的工作方式是可行的,他们就不会改变。改变是困难、痛苦、有风险的。只有那些已经绝望或者有远见的人才会勇于改变

  2. 管理层的任务是引导而不是指挥

  3. 在每个Sprint中都必须完成特定的列表项。一旦有些工作没有完成,整个管理团队就会一起找出原因

  4. 如果将高管的个人成就看得比团队成功更重要,那么转型就会失败。没有合作和团队精神就无法实现改变

  5. 转型的策划团队会在每个Sprint开始之前评估接下来要从转型待办列表中挑选的任务,同时根据任务的类型确认执行团队的成员。每个团队成员都是根据接下来的Sprint的需要而挑选的

  6. 如果执行团队没有任何东西可以展示,这就意味着执行团队的成员是错误的人选,或者他们没有在转型上花足够的时间,也可能是要解决的问题太难,无法如期望中那样解决或在当前的条件下解决

  7. Scrum是用于管理复杂工作的流程

  8. 世界上没有任何一项工作比改变一个组织的工作方式更复杂了


术语

  1. 产品待办列表是一个包含了所有可能加入到产品中的特性或者功能的有序列表,也是所有对产品进行改动的需求的唯一来源。产品负责人负责维护产品待办列表,包括维护其内容、可用性和列表项的顺序

  2. 生产效率:在一定资金下可以完成的业务功能的单位个数

  3. 速率:在一定时间或者资金内对创造出的业务功能数量的度量

  4. 无论产品负责人决定何时发布产品,增量都必须随时准备就绪

  5. 质量:从功能单元交到负责人手中开始,直到该功能单元交付给客户使用的前三个月为止总共发现的缺陷个数


Scrum指南

  1. Scrum团队是跨职能的自组织团队。自组织团队自己选择如何最有效的完成工作,而不是由团队外的人指导。跨职能团队拥有完成工作所需要的全部技能,不需要依赖团队以外的人。这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率

  2. 产品负责人负责最大化产品以及开发团队工作的价值。产品负责人是管理产品待办列表的唯一责任人

  3. Sprint产出的是“完成的”、可用的、潜在可发布的产品增量

  4. Sprint计划是由整个Scrum团队共同协作完成的

  5. 只有开发团队本身可以评估接下来的Sprint可以完成什么工作

  6. Sprint评审会议的结果是一份修订的产品待办列表

  7. Scrum中的工件就是为了最大化关键信息的透明性,这样每个人对工件都有相同的理解

  8. 开发团队负责所有的估算工作

  9. 在Sprint期间只有开发团队可以修改Sprint待办列表


企业级敏捷攻略

  1. 现今的IT组织必须将过时应用程序重构成更灵活的、面向服务的架构,同时有效的协调全球分布式软件开发团队

  2. Scrum的核心在于它以迭代增量式的流程开发产品或者管理工作。在每个迭代结束时,开发出潜在可交付的功能集。Scrum具有以下这些属性:

    1. Scrum是可以用于获得敏捷性的工具

    2. Scrum是管理和控制开发工作的一种敏捷流程

    3. Scrum是对现有工程实践的一种包装

    4. Scrum是在需求快速变化的条件下以团队为基础的系统开发流程

    5. Scrum能够控制由利益和需求间的冲突引起的混乱

    6. Scrum能够改善沟通并且最大程度的促进合作

    7. Scrum能够发现并移除在产品开发和交付过程中出现的任何障碍

    8. Scrum能够最大程度的提高生产力

    9. Scrum既适用于某个独立的项目也适用于整个组织,能够管理多个互相影响的,组织人数超过一千人的产品和项目开发

    10. Scrum能够让每个人都对自己的工作和自己做出的贡献感到高兴,而且每个人都认识到自己已经竭尽全力

  3. Scrum认识到应用程序开发是一个不可预测并且异常复杂的过程

  4. 管理层的使命是帮助团队消除障碍;而团队的使命就是完成他们承诺需要完成的Sprint待办列表项

  5. 敏捷软件开发宣言

  6. 要实施Scrum组织必须要完成两项工作:首先,必须指引开发团队适用Scrum进行软件开发;其次,为团队消除优化创新和软件交付的障碍。第一项工作能够改进软件交付过程;第二项工作则能消除第一项工作中遇到的提高投资回报率和生产效率的障碍

  7. Scrum Master确保团队不会过多的承担他们在一个Sprint内无法完成的工作量来保护他们,同时还不断的消除妨碍团队达成Sprint目标的障碍

  8. 变革是一项困难的工作,同时也没有捷径可走

  9. 要成为世界级的竞争者就必须通过艰苦的奋斗

  10. Scrum和敏捷给业务带来的好处通常是通过同一地点工作的跨职能团队达成的。最理想的团队由不多于11个人组成(包括产品负责人、Scrum Master和开发团队)。每个Scrum团队都能够在没有外界的帮助下独立完成一个特定产品或者应用程序的设计、开发、测试和交付

  11. 组建分布式团队和过大团队应该要仔细权衡



路过

Scrum/Sprint

Advanced Software Engineering, Development Process, Scrum/Sprint


软件开发的流程有很多 (看 各种方法论概述), 我也写过一篇博客 (酒后的敏捷) 谈了谈最近比较时髦的开发流程。 今天我们不喝酒, 正襟危坐地说说敏捷这一路 Scrum/Sprint 开发方法.

从理论上看, 这个方法真是妙得紧:

[图片来源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]

微软 MSDN 也有类似的流程介绍,看起来...

Advanced Software Engineering, Development Process, Scrum/Sprint

 

软件开发的流程有很多 (看 各种方法论概述), 我也写过一篇博客 (酒后的敏捷) 谈了谈最近比较时髦的开发流程。 今天我们不喝酒, 正襟危坐地说说敏捷这一路 Scrum/Sprint 开发方法.

从理论上看, 这个方法真是妙得紧:

[图片来源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]

微软 MSDN 也有类似的流程介绍,看起来真是太容易了:  

 

 

第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以。

产品负责人主导大家对于这个Backlog 进行 增/删/改 的工作。每一项的时间估计的单位为 “天”.

 

第二步: 决定当前的冲刺需要解决的事情 – Sprint Backlog.

任务被进一步细化了,被分解为以小时为单位。如果一个任务的估计时间太长 (例如 超过16个小时),那么它就应该被进一步分解。 冲刺订单上的任务不会被分派,而是由团队成员签名认领他们喜爱的任务。  团队成员能主导任务的估计和分配, 他们的能动性得到较大的发挥。

 

第三步: 冲刺 (Sprint).  在冲刺阶段, 外部人士不能直接打扰团队成员。  一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改变都留待冲刺结束后再讨论。

冲刺期间, 每天要开一个每日例会 (SCRUM Meeting), 团队成员大多站着开会, 所以又称每日立会. 大家依次报告:

我昨天做了啥

我今天要做啥

我碰到了哪些问题

每日立会强迫每个人向同伴报告进度, 迫使大家把问题摆在明面上。同时启动每日构建, 让大家每天都能看到一个逐渐完善的版本。

用简明的图表展现整个项目的进度, 这个图最好放在大家工作的环境中, 或者每天传达给各个成员:

图表可以是燃尽图 Burn Down Chart (想象我们把一堆 Backlog 的木头给烧光)。

 

 

也可以是简单的看板图 Kanban: (把一堆任务从最初的 “待定”推动到“工作中”等各个状态, 直至“完成”)

 

这里有几个 现代软件工程 学生小组的 daily scrum 的过程:

2010 年学生2011年学生项目2012年学生项目

冲刺阶段是时间驱动的 (time-boxed), 时间一到,就结束。这个特点看似不起眼, 其实它有效地给各种延期的想法断了后路,很高明。

 

 

第四步: 得到软件的一个增量版本,然后在此基础上又进一步计划增量的新功能和改进。

 

 

美妙的理论在实践中都会碰到这样那样的问题, 下面是一些例子:

第一步:

各个需求和任务之间是有种种复杂的依赖关系的,除了优先级之外, 我们还要考虑相互的依赖关系。怎样在计划中表现依赖关系呢?

第二步:

如果团队成员对某个任务不感兴趣, 都不认领这个任务怎么办?

有些成员的认领的任务很多, 有些成员认领的任务很少, 忙闲不均, 怎么办?

第三步:

每日例会 (SCRUM Meeting)看起来很爽:

   我昨天做了啥

   我今天要做啥

   我碰到了哪些问题

爽了之后, 也许会流于形式。 我们想象一帮狗熊开Scrum 会议的时候, 大家的发言是:

   我昨天掰棒子

   我今天继续掰棒子

   我没碰到困难

 

这样的会议有用么? 也许昨天掰的棒子没处理, 今天就掰另一个棒子去了, 明天又来一个新棒子…

一群狗熊级的程序员会这么说:

   我昨天写代码

   我今天继续写

   我没碰到困难

每天这么写代码, 我们离完冲刺的终点线到底是更近了, 还是更远了?  如果流于形式, 无论多么敏捷的Scrum 每日立会也会被忽悠, 请看学生们的一个忽悠例子.

一个改进是, 定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的, 狗熊们不能笼统地说, 我在掰棒子, 而是要说明标号为123 的棒子现在是什么状态, 你做好之后交给谁了。

另一个改进是, 要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要, 但是不是关键 (那是沉没成本),关键是要看我们离最后目标有多远。 就像某部门展览“反腐成果”, 给群众看 “已经抓出来N 个腐败分子”固然解恨, 但关键还是 ”还剩多少在台上“,这个问题不说明, 再抓20个, 30个都不解决问题。

 

冲刺到一半的时候, 产品负责人突然发现要做马上重要的改动! 或者某个大佬要看某个不在计划中的功能的演示, 怎么办?  这种情况非常考验 SCRUM MASTER.  如果一个运动员在跑一百米冲刺, 但是跑到一半的时候,领导突然想看一百一十米栏的比赛, 前面马上会摆起栏架, 大家要准备8步上栏!  怎么办?

一个有正常头脑的运动员和教练员会说: 去你的, 要改主意, 也要等到老子冲刺完了再说啊!

 

关于每日立会 - 如果团队成员不在同一个地方, 怎么开会呢?  我听到一些敏捷的专家说, 一个团队的成员必须面对面开会, 才有效果。

Ken Schwaber 说:  I also recommended eliminating all of the development artifacts – like design documents… Scrum relies on high-bandwidth, face-to-face communication and teamwork; cubicles and unneeded artifacts promote isolation and misunderstandings.   [Agile Project Management With Scrum, Page 103]

 

如果项目的所有人都坐在一起, 连工位的矮墙都没有, 那的确很爽, 但是在很多公司中那是不可能的,有些团队成员甚至在不同的时区工作,怎么办? 他们就不能敏捷了?这时候我们的确需要文档和其它辅助手段来沟通。

 

燃尽图,  有些燃尽图只是列出了任务的数目, 这种图无法展现项目的拖延, 一个任务有大有小, 它们在图表中都是一个点, 一个16小时的任务需要3 天完成, 一个2小时的任务处于种种原因也花了3天时间, 他们在图表中的表现是一样的。 在实践中, 我个人认为以时间为度量的燃尽图更有效果.

下面是一个实际项目的燃尽图, 有三个每天跟踪的时间值:

   实际剩余时间/remaining hour: 每个团队成员所有任务的 remaining hour 的总和

   预估剩余时间/projected remaining hour: 根据每个人每天的理论进度推算的剩余时间

   实际花费时间/completed hour:

 

(Sprint 进行中)

 

(sprint 最后)

 

注解1: sprint 从8/22 到 9/28, 中间9/15 - 9/18 整个团队外出开整个部门的年会。

注解2: 开始预计所有工作量为340 小时, 每个工作日能减少 (burn) 17 小时。

注解3: 开发人员有 5.5 名, 绝大多数第一次接触正式商业项目和 SCRUM的团队开发模式。  最终完成的工作量为524 小时, 是预计的 1.5 倍。(这暴露了什么问题呢?

注解4: 有 0.5  名UX 设计人员,  0.5 名PM, 和 2 名测试人员。

注解5: sprint 结束后, 各个任务宣告完成, 并且没有P1 (最严重的) bug,但是P2 及以下的bug 有80 多个, 加上前一个版本遗留下来的70个bug, 总共还有150 个bug 要解决, 才能发布。

注解6: sprint 结束后, 有两个原来的设计发现很有问题,  团队决定在sprint 结束之后进行重新设计,或者叫 Design Change Request (DCR)。

第三步半:

做过项目的人都知道, 当你说“任务都完成了”的时候, 那只是说, 开发人员认为该写的代码都写完了, 还有很多事情没做完. 例如写一个Windows 客户端的功能, 显示一个新闻图片加上和与它相匹配的文字 (假设这些图片/文字都可以从互联网上拿到) , 做完之后, 还有下面的事情:

验证这个功能显示在WinXP, vista, win7, win2008 server R2, win2012 server 都显示正确。 (开发人员表示自己的机器是win2008 server, UI 看起来不错, 其它平台想必也不错!)

验证这个功能的显示布局和字体在100% 到150% 的DPI 上都显示正确, 在各种色彩配置中都显示正确。

验证文字无论是中文, 英文, 阿拉伯文都能正确显示 (联合国五种工作语言我们得支持吧? )

验证程序效能上没有问题

验证程序在长期使用, 没有内存和资源泄露

验证这个功能和其它功能有较好的集成

谁来做这第三步半呢?  程序员写完功能的时候, 我们感觉好像项目完成了 80%, 殊不知后面的20% 往往要花费80% 的时间, Sprint/Scrum 没有明确表明到底 何人/何时/何种优先级 来完成这个20% 的任务。

长期任务: 软件项目中常常有一些比较艰难和底层的任务, 完成这些任务需要超过sprint 所计划的时间, 这时候我们怎么安排呢?  在我的经验中, 这些任务往往在短周期的迭代中得不到应有的重视, 一直拖着。

软件团队中还有一个重要的角色 - 测试。 测试人员在一个冲刺中怎么工作呢? 有敏捷专家建议测试人员可以担负起 Product Owner 的部分责任,同时掌握 Acceptance Test 流程, 对产品的最终质量负责。  但是测试人员的开发技术能力在团队中并不占优 (在有些中国公司中甚至是最弱的一环),他们在大家都要 “烧光”所有任务的压力下,能担当起 Product Owner 这一责任么?

这一篇博客讲了 第三步半要做什么事情,  它的流程图可以作为Scrum/Sprint 的补充:

 

第四步:

得到了一个增量的软件发布, 当然好, 但是谁来验证这个增量满足了事先的计划呢?  如果程序员们在冲刺的过程中发现了新问题, 改进了原来的计划, 这是好事呢还是坏事?

每一次冲刺结束后, 大家要放松一下, 总结上一次的经验教训,争取下一次做得更好。 这个博客记录了微软学术搜索项目组 10 次冲刺的过程

 

软件开发流程有好多种, 我们怎么衡量一个开发流程是否对当前的项目/团队合适? 我觉得Scrum/Sprint 能成功实施的关键在于 ScrumMaster。我听到有些团队也实施Scrum, 但是他们随机挑一个成员来做 ScrumMaster, 好像 ScrumMaster就是招呼大家开开会, 记录每个人的进度而已。这种方法失败的可能性很大。 一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境,描述实现细节的技术语境) 自如地翻译和切换,事实上是一个强有力的PM,如果团队还要求她做全职的开发工作,这样的人就更难找了。

Scrum 很特别么?

我个人认为它和质量控制理论的模型, 例如 经典的戴明环  PDCA Plan-Do-Check-Act/Adjust 没什么太大区别.  正如 Ken Schwaber 在描述Scrum 的核心特点的时候说:

在迭代开始时, 团队审视摆在他们面前的任务,选择他们认为可以在迭代期间完成的那些 (Plan)。然后团队独立地尽最大努力完成这些任务 (Do)。在迭代结束时, 团队给利益关系人展示他们的成果 (Check),并对开发流程进行调整 (Act/Adjust).

 

在 6西格玛理论中 ( Six Sigma) ,我们也可以看到相似的流程, 只不过它变成了 "Define, Measure, Analyze, Improve, Control" (DMAIC). 此模型不强调迭代的重要性。

 

Scrum 和 渐进交付的流程 (Evolutionary Delivery) 也很相似:

图片来源: Rapid Development (1996), Chapter 7, “Lifecycle Planning” (p. 133)

 

Scrum 的团队

Scrum对团队的要求很简单:self-managing, self-organizing, cross-functional, 但是这很难做到。软件项目的团队各式各样 (各种团队类型的介绍), 假设一个团队做得还不错,现在要变成 Scrum 流程, 那团队要做下么的改变:

  1. Self-managing: 以前领导布置了任务,我们实现就可以了,现在要自己挑选任务;每次sprint 结束之后,还要总结不足,提出改进,并且自己要实施这些改进。“自我管理”不等于“没有管理”。

  2. Self-organizing: 以前做好自己的事情就好了,安心下班。现在每个人要联合起来对项目负责,有人工作落后了还要帮助他改进,项目缺少某类资源还要自己顶上去。

  3. cross-functional: 以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责,自己搞定spec, 和别人沟通, 同时自己搞定测试。

如果你的团队很弱, 那么强行把Scrum (或者其它高级方法)套在上面也没有用, 也许还会适得其反,往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 (self-managing, self-organizing, cross-functional)的一帮人, 那么用不用Scrum 都能写好软件!

 

经验:

这里有一些实践者的经验教训:

  1. ScrumMaster 不是一个官,而是一个没有行政权力的沟通者,就像微软的PM 那样。她同时还要在团队中做具体的工作。直接把原来的 “经理”变成 ScrumMaster 大多行不通。

  2. 在一些公司中,不少项目需要很多暗箱操作和政治角力才能搞定, Scrum 会把这些矛盾都摆到明处。这有好处,也有风险。

  3. 在复杂的项目里,要让一线团队成员做决定。

  4. 创业公司的团队其实经常是运行在 Scrum 的模式中 (只不过大家太忙,没功夫论证到底多么Scrum)。

  5. 在Scrum 计划阶段的估计不是一个“合同”, 领导们不要把它当成一个合同。估计总是不准的。 坚持短期的Sprint,即使不准的估计也不会有大的损害。

  6. 不要和管理层谈 “流程”, 他们只关心 “结果”。

  7. 在大型团队,复杂项目中,Scrum 并没有非常完美的答案,Scrum 的创始人也承认这一点。 (我曾看到30多人挤在会议室里搞 Daily Scrum,一叹! )

总结:

Sprint/Scrum 对项目的众多需求采取分而治之的办法,  能让相关人员集中精力, 在一定期限内解决部分问题。

它强调短时间的迭代 (iteration), 在多次迭代中不断总结, 改进团队的流程和产品功能。

它明确地指出不同人在一个项目中的投入和责任的不同 (猪和鸡), 并坚持让全身心投入的“猪”来主导项目。

它通过 daily scrum, ScrumMaster 等方法和角色,鼓励团队内部交流并优化团队和其他人员的交流方式。

它对团队成员提出了很高的要求, self-managing, self-organizing, cross-functional。 一般人不能马上做到这一点。

它不是 “银弹”,不能解决软件开发的所有问题,至于具体项目进度如何跟踪, 如何管理测试工作, 如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招,想出合适的办法。


SCRUM 视频: Scrum 看似容易, 门道挺多, 这里是一个视频系列,大家可以观赏:  http://blogs.collab.net/agile/scrum-training-series  

思考题:

在一个冲刺中, 团队预计每天的进度为 30 小时。当项目完成了一半的工作量的时候, 大家发现实际的进度为15小时/天,  问: 在余下的时间中, 团队的进度要到多少, 才能在项目结束时让整个项目的平均进度恢复到每天30 小时?

蓓蓓—PM的修炼

“小鱼儿”学沟通系列之五—走出困境

这一集,经历了几番历练的小鱼儿,到了一个完全陌生的环境——公司里大名鼎鼎的“笑傲江湖”项目组。这不刚进来才没几天,小鱼儿便开始觉得不太对劲,到底是什么情况呢?


小鱼儿:成长中的项目经理

郭靖:小鱼儿的直线经理&师傅

任我行:“笑傲”项目的核心开发

方证:任我行的直线经理,“笑傲”项目的开发负责人

风清扬:大部门总监,“笑傲江湖”项目组的总负责人


新的征程

部门老大风清扬,为人沉稳谦和,虽说之前有过几面之缘,但并无太多交集。在小鱼儿首次拜访中,风清扬只是简单说了几点期望和想法,“站会、白板、度量...”尽管指示非常明确,但小鱼儿听下来却始终如雾里看花,似...

这一集,经历了几番历练的小鱼儿,到了一个完全陌生的环境——公司里大名鼎鼎的“笑傲江湖”项目组。这不刚进来才没几天,小鱼儿便开始觉得不太对劲,到底是什么情况呢?


小鱼儿:成长中的项目经理

郭靖:小鱼儿的直线经理&师傅

任我行:“笑傲”项目的核心开发

方证:任我行的直线经理,“笑傲”项目的开发负责人

风清扬:大部门总监,“笑傲江湖”项目组的总负责人

 

新的征程

部门老大风清扬,为人沉稳谦和,虽说之前有过几面之缘,但并无太多交集。在小鱼儿首次拜访中,风清扬只是简单说了几点期望和想法,“站会、白板、度量...”尽管指示非常明确,但小鱼儿听下来却始终如雾里看花,似乎隔着一层什么,本想继续深挖几个“为什么”,无奈相互了解甚少且时机未到,只得匆匆收关。

“笑傲”项目是风清扬选择的第一个试点,在风清扬那里没有解开心中的疑问,小鱼儿只好去找负责人方证。方证跟小鱼儿聊了很多,不过小鱼儿隐隐觉得方证的话,听来总带着些许无奈。一番了解之后,发现原来这“笑傲”项目在这个项目组里,优先级是最低的,也正是因为此,各种资源经常跟不上,项目周期经常被拖得特别长,等待已成为常态,久而久之大家也都习惯了。不知不觉聊了半个多小时,方证见小鱼儿仍旧是摆出一副不依不饶要继续探究的劲头,他兀自叹了口气,眼神越过小鱼儿,怔怔得看着远方,一字一句地吐出“坦白跟你讲,我觉得你也改变不了什么。”

在之后的日子里,这句话就像幽灵一样,不时地回荡在小鱼儿的脑袋里,“改变不了什么…改变不了什么…”,时而让他失落绝望,时而又让他斗志昂扬!小鱼儿就是在这样的情境下,踏上了全新的项目旅程。

 

艰难开局

这天是开发内部的周会,小鱼儿被叫过去旁听,一进门就被那扑面而来的“霸气”给震住了。这是他第一次看到会议上的任我行,只见他以极快的语速问着每个人的开发进度,并飞快地做出指示“XXXX,这个你去跟进一下”、“XXXX,做得时候一定要注意性能,不要到最后得不偿失”!被点名的人低声应和着,一路没有多余的话。

会议很快结束了,全程下来似乎只有任我行一人在说,其他人都低着头,间或随意翻翻手机,每当他停下来的时候,气氛会显得异常安静。结尾的时候,任我行的目光停在小鱼儿身上,似乎在等待什么。于是小鱼儿连忙抓住机会,跟大家做了个自我介绍,并且简单说明了下自己的来意及管理层对于试点的期望。话还没说完,就听任我行开腔了,“站会我们之前在XX项目开过的,没什么用!”虽然之前早已见惯了各种质疑,但如此直接且丝毫不容置疑的口吻,让刚刚开场的小鱼儿颇有点下不来台。

这次的经历过后,小鱼儿开始转向做“地下工作”,在筹备试点启动会前,几位核心人物都被他找遍了,找他们讨论试点需要做哪些改变,然后一一回应每个人心中的疑问和困惑。原来这“笑傲”项目,动辄三四个月的发布周期,在大家看来却稀松平常,因为优先级低,发布日期很少有人关注,一遇到什么情况就延期,之前并无人在意。

小鱼儿知道,周期这么长,且中间没有任何验证,各种问题和风险无疑都会在后期被放大,站会、白板虽然可以加快信息流动,但很多根本问题却被掩盖掉,无法在过程中暴露并得到解决,风险只会随着时间日积月累,愈发的不可控。可想要说服大家同意缩短周期,又谈何容易!各种阻力都来了,就拿方证的话来说,“你要清楚老大让你做的是什么...”虽然话没有继续说下去,小鱼儿却立刻明白了这言下之意,这根本不是你该要关心的范畴嘛。面对这些阻力,小鱼儿几乎使出了浑身解数,产品、设计、开发、测试一个接一个地游说,才勉强让大家同意了在下个版本的计划中加入一个中间提测的点。

“呼…”,全部办妥之后,小鱼儿长出一口气,想到经理郭靖跟自己开玩笑的话,“你这是一朝打回解放前啊!”,禁不住一丝苦笑。由于提前做了充足的准备工作,试点启动会上,小鱼儿没有遇到什么麻烦,一片风平浪静,站会、白板等得以顺利的推行。可令小鱼儿不安的是,那气氛仍然安静地让人不大舒服,即便小鱼儿卖力地想和大家有些互动,仍然仿佛一潭死水,激不起半点波澜。

 

冲突爆发

随着项目往前推进,提测的日子总算到了,积累了两三个月的开发成果,一下子呈现在了大家面前,提测、走查,大伙儿各种忙碌。让小鱼儿没想到的是,一场冲突也正在酝酿,一触即发!

设计走查之后,一个长长的清单连夜出炉了,上面密密麻麻写满了各种问题。第二天,走查沟通会还没说上几句,任我行发飙了:“写就好好写嘛,不要打那么多叹号好不好!知道有多影响程序员的情绪吗!害的我一晚上都没睡好觉!”设计MM顿感冤屈,“走查时发现这么多问题,你知道多影响我的情绪吗?我交互稿里分明都是有的…”

“这个当时说过的,你是不是没搞清楚这个机制啊!”“…那算我错乱了行不,谁也不可能保证一开始就是对的吧,开发有bug,设计也会有后期发现设计不合理的地方。这个很正常吧!”“不正常…”

整个会议就在各方漫长的推推嚷嚷中艰难地推进着,小鱼儿在一旁看得心急如焚,“这样一来,我们不是又要延期了?!”“延期呗,还能怎么办?”,方证的话无奈中又有些习以为常,众人沉默,脸上分明写着“不关我的事”!后来,“笑傲”足足推迟了一个周才得以最后发布,但似乎并没有人关心这些。

 

走出困境

在试点项目陷入困境的同时,小鱼儿的内心也在经历着前所未有的波澜。小鱼儿时常觉得自己像是骑着一匹瘦马,妄想挑战大风车的堂吉诃德,而他拼命想要战胜的,却是飘在空中,落在人们心底的那些细细碎碎的声音:“我觉得你也改变不了什么”、“延期呗,还能怎么办?”…那些声音背后深深的无力和绝望,连同那些异样安静的氛围,像是从四周细小的缝隙里涌过来的冰冷潮水,一点点淹没了他,小鱼儿开始愈发喘不过气来。

虽然几番尝试去澄清去确认,但那些漠然的神情和言语,始终刺痛着他。“或许他们根本就不想要改变!”,小鱼儿失落极了,他已感受不到一丝一毫地被需要,举目四周却又孤立无援。就这样在坐了两三个月的冷板凳之后,小鱼儿觉得自己正在逼近那个极限,而周围似乎一切仍然照旧,于是,他,崩溃了!

在那些低落的日子里,郭靖给了小鱼儿很多安慰和鼓励,这些诉说让他得以宣泄,但那些让他困扰的缘由,仍然像乌云一般笼罩着,迟迟无法散去。

直到有一天夜里,小鱼儿被吵醒之后就再也睡不着了,他打开朋友圈,注意到一篇文章。文章讲的是“胡萝卜、鸡蛋和咖啡豆”的故事,曾经有一个女儿遇到了人生中的挫折,他的爸爸给她看胡萝卜、鸡蛋、咖啡豆遇到沸水后的变化,胡萝卜本来是硬的,变软了;鸡蛋里面本来是软的,变硬了;而咖啡豆呢?它融于了水,然后彻底改变了水质!

那一瞬间,小鱼儿“噌”的一声,从床上蹦了起来,心中只有一个强烈的念头,“我要做咖啡豆!我要做咖啡豆!”。那一瞬间,小鱼儿清晰地认识到,自己已经在被这个环境所改变,这个充满压抑和无力的环境,正在让自己也变得无比沮丧,似乎做什么都无法使它改变分毫,可当真就这样任由环境改变自己吗?他打开灯,开始奋笔疾书,像是怕它们会溜走一样,小心翼翼地记录下此刻的想法和心情,一番折腾之后,才满意地睡去了。

 

重新振作

那天之后,虽然外面的世界仍然一切照旧,可小鱼儿却坚定的相信“一切都会好起来的!”。小鱼儿暗自打定主意,不管遇到什么样的回应,始终保持自己的正能量!哪怕没有一个人在意这些,哪怕面对“老大有问过你进度吗?没有把。。”这样怀疑的声音,小鱼儿依然坦然从容,带着那份简单的相信,尽自己最大的努力,去准备好自己可以做的一切,每一次站会、每一项跟进、白板上的每个便签、燃尽图上的每一个点…就这样陀螺一般忙碌着。

世界果真就是这么奇妙,当小鱼儿的心境变化之后,每一点一滴的努力,真的如他想象的那样,在一点一滴地改变着周围的环境,然后聚沙成塔,汇流成河!

在版本结束后精心设计的回顾会上,一个换位思考的游戏让大家抛开了日常惯有的角色思维定势,并由此开始深入讨论研发过程中的角色间协作模式,效果显然超出了小鱼儿的预期。体验了一把策划的研发人员,突然发觉自己也会有那么多的“想当然、自以为”,尝试做了一把研发的策划和设计人员,则体会到了拿到需求时的那种“茫然、困惑”。通过一个简单的游戏,大家设身处地地理解了对方,明白出现理解的偏差是正常的,而我们要做的,就是如何更好地协作来改善这种情况。

正是这个讨论,让团队终于自己得出了,那个让小鱼儿一直心心念念想要的结论,不是对上游更加变本加厉的要求,不是拒绝变更或筑起高墙,不是出现问题后互相之间的指责和惩罚!我们应该缩短发布周期,更快的迭代-验证-反馈,过程中增强中间版本的实时沟通和反复调整,从而避免版本后期的各种不可控…

回顾会上的热烈讨论,那一双双眼睛里闪耀和流转着的光芒,直到现在小鱼儿回想起来也倍感欣慰,因为他知道,自己终于做到了!

 

走出困境

困境永远源于内心!

正如《楚门的世界》中“上帝”一般的制片人克里斯多夫,在面对公众对他的质疑时极为平静地断言,“如果他下定决心要出去,没有人可以拦得住他!”真正的牢笼始终都只在他的内心,从来都只在每一个人的内心!这也是为什么,当人们看到楚门克服心中的恐惧,挣脱了那个伴随了他一生的谎言时,会如此欢欣雀跃,就仿佛从困境中挣脱的正是他们自己!

相比外界你所面临的种种困境,更为可怕的是内心的绝望和恐惧。当你把眼光放在环境的各种局限和不如意上,你会不断受挫,在困境中来回打转。只有当你把眼光放在自己身上时,才会真正明白,走出困境的钥匙,从来都在自己手中。

改变自己,真的能够改变世界!也只有改变自己,才可能改变世界!

当你下定决心要走出困境的时候,没有任何人能够拦得住。


扩展阅读

“小鱼儿”学沟通系列之一-性格色彩

“小鱼儿”学沟通系列之二-引入变化

“小鱼儿”学沟通系列之三-透过现象看本质

“小鱼儿”学沟通系列之四-向上管理

你对了,世界就对了 (如何改变自己,个人心得)

本白

Scrum敏捷项目管理学习

在软件工程领域,随着人们对变化的认识,以及编码这种思维活动的模糊性带来的诸多弊端,敏捷开发成为人们对待IT项目的主流过程。

 敏捷有很多种,Scrum便是其中之一,非常适合小型团队。Scrum其实更像一个框架,简单地说明了一些项目开发过程中必备的活动和工件,帮助团队去理解和实施。

 以一张图来说明便是:

 

 

3个工件 3个角色 5个活动 没了。所谓大道至简,简单明了的规则才利于推广和实施。

 

下面简单说明下以上三个内容。

 

3个工件:

产品订单:产品的功能需求列表,给予优先级。产品订单是变化的,迭代的。

冲刺订单:一个冲刺要完成的用户故事,须细分为...

在软件工程领域,随着人们对变化的认识,以及编码这种思维活动的模糊性带来的诸多弊端,敏捷开发成为人们对待IT项目的主流过程。

 敏捷有很多种,Scrum便是其中之一,非常适合小型团队。Scrum其实更像一个框架,简单地说明了一些项目开发过程中必备的活动和工件,帮助团队去理解和实施。

 以一张图来说明便是:

 

 

3个工件 3个角色 5个活动 没了。所谓大道至简,简单明了的规则才利于推广和实施。

 

下面简单说明下以上三个内容。

 

3个工件:

产品订单:产品的功能需求列表,给予优先级。产品订单是变化的,迭代的。

冲刺订单:一个冲刺要完成的用户故事,须细分为任务,为团队认领,并给出预期工时。冲刺订单需确定,冻结的。

任务墙:包括各项任务(未开始,进行中,已完成)以及燃尽图(项目工时跟踪)

 

3个角色:

产品负责人:产品经理,维护产品订单,制定优先级。

Scrum负责人:相当于项目经理,负责推进Scrum实施。

团队:5-9人,跨职能的团队,即包括UI,开发,测试。

 

5个活动:

冲刺:2-4周的开发时间,需交付经过测试的开发结果。

冲刺计划会议:全员参与,输出冲刺订单,确定工作分解。

每日例会:15分钟内的站立会议,3个问题:昨日做了什么,今日准备做什么,有什么困难。更新任务墙。

冲刺评审会议:展示开发结果,产品负责人评估结果。

冲刺回顾会议:总结和改善scrum实施过程,使团队持续成长。

 

总结:将开发分割为一个个冲刺,以便拥抱变化,并每日更新状态,保证最大化的透明度,使整个团队以更好的效率配合,前进,交付有质量的结果。

 

注意:冲刺并不是加班,敏捷开发不提倡加班。计划协调不周会导致加班,有加班,必然会存在减班现象,从而导致团队疲惫,影响士气,弊大于利。

参考书目《轻松scrum之旅》

Binge

敏捷开发之Scrum扫盲篇(转载)

原文:http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html


现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...


为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。


什么是敏捷开发...

原文:http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html

 

现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...

 

为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

 

什么是敏捷开发?

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

 

为什么说是以人为核心?

我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

 

什么是迭代?

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

 

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

 

什么是Scrum?

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

 

【Scrum开发流程中的三大角色】

产品负责人(Product Owner)

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

 

流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

 

开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

 

Scrum流程图

 

 

//------------------------

下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

什么是Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

 

如何进行Scrum开发?

1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

 

下面是运用Scrum开发流程中的一些场景图:

 

上图是一个 Product Backlog 的示例。

 

 

上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。



 

任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


 

每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

 

 

上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...

 

敏捷开发的4句宣言

个体与交互 胜过 过程与工具

可以工作的软件 胜过 面面俱到的文挡

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

 

软件测试

扩展阅读:Agile方法的12个原则

  1. 在快速不断地交付用户可运行软件的过程中,将使用户满意放在第一位。

  2. 以积极的态度对待需求的变化(不管该变化出现在开发早期还是后期)。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。

  3.  以几周到几个月为周期,尽快、不断地交付可运行的软件供用户使用。

  4. 在项目过程中,业务人员和开发人员最好能一起工作。

  5. 以积极向上的员工为中心建立项目组,给予他们所需的环境和支持,对他们的工作予以充分的信任。

  6. 在项目组中,最有用、最有效的信息沟通手段是面对面的交谈。

  7. 项目进度度量的首要依据是可运行的软件。

  8. Agile过程高度重视可持续开发。项目发起者、开发者和用户...

  1. 在快速不断地交付用户可运行软件的过程中,将使用户满意放在第一位。

  2. 以积极的态度对待需求的变化(不管该变化出现在开发早期还是后期)。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。

  3.  以几周到几个月为周期,尽快、不断地交付可运行的软件供用户使用。

  4. 在项目过程中,业务人员和开发人员最好能一起工作。

  5. 以积极向上的员工为中心建立项目组,给予他们所需的环境和支持,对他们的工作予以充分的信任。

  6. 在项目组中,最有用、最有效的信息沟通手段是面对面的交谈。

  7. 项目进度度量的首要依据是可运行的软件。

  8. Agile过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。

  9. 应时刻关注技术上的精益求精和设计的合理,这样能提高软件的快速应变力。

  10. 简单化(尽可能减少不必要工作的艺术)是基本原则。

  11. 最好的框架结构、需求和设计产生于自组织的项目组。

  12. 项目组要定期对其运作方面进行反思,提出改进意见,并相应进行细调。


米茶

scrum 敏捷开发

定义Scrum是一个迭代性、增量性的流程,适用于任何的产品开发以及工作管理。 在每个迭代结束后,Scrum都会产生一套可以交付的功能性产品。

宣言个体与交互 胜过过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划

Scrum的特点是:Scrum是一个敏捷的流程,可用于管理和控制研发工作。
Scrum是现有设计流程的总结。
Scrum以团队为基础,是一种在要求迅速变化情况下迭代地、增量地开发系统和产品的方法。
Scrum是一个控制由利益和需求冲突导致的混乱的流程。
Scrum是改善交流并最优化合作的方式。
Scrum是一种检测...
定义Scrum是一个迭代性、增量性的流程,适用于任何的产品开发以及工作管理。 在每个迭代结束后,Scrum都会产生一套可以交付的功能性产品。

Edit

宣言个体与交互 胜过过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划

Edit

Scrum的特点是:Scrum是一个敏捷的流程,可用于管理和控制研发工作。
Scrum是现有设计流程的总结。
Scrum以团队为基础,是一种在要求迅速变化情况下迭代地、增量地开发系统和产品的方法。
Scrum是一个控制由利益和需求冲突导致的混乱的流程。
Scrum是改善交流并最优化合作的方式。
Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
Scrum是最大化生产率的一种方法。
Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
Scrum能让每个参与者都对自己的工作以及自己做出的贡献感到满意,并让他们感觉自己的工作已经达到最佳的水平。

Edit

角色:一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意,那你准备给餐馆起什么名字呢?”,
鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样?”,“我不这么认为”,猪说, “我全身投入,而你只是参与而已”

Edit

产品负责人

利用产品backlog,督促团队优先开发具有价值的功能,并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级,以便将最具价值的功能安排在下一个迭代中完成。

Edit

开发团队

开发软件功能,他们是自组织团队,团队 所有成员对每一次迭代和整个项目共同负责,不单做考核。

Edit

Scrum Master

则需要对Scrum过程负责,向所有项目参与者讲授Scrum方法,负责实施Scrum,确保它既符合企业文化,又能交付预期利益,还需督促 全体成员遵从Scrum规则和实践。

Edit

鸡类人员

站立会议中鸡类人员不得讲话、评论、扮鬼脸等

在Scrum团队中,ScrumOwner(产品经理)、ScrumMaster(项目经理)、Developer、需求分析师为猪类角色,而管理者、测试工程师、UI工程师、QA、客户等为鸡类角色。
软件测试

软件测试概述——扩展阅读之Agile方法

常见的Agile 敏捷方法有XP(Extreme Programming)、SCRUM、FDD(Feature Driven Development)等。以下是2012年时使用Agile方法的比例:

常见的Agile 敏捷方法有XP(Extreme Programming)、SCRUM、FDD(Feature Driven Development)等。以下是2012年时使用Agile方法的比例:



秒大刀

实际软件项目中的开发方式?

    从事软件开发已7年有余,回头看亲历过的和周围的项目,有几个问题值得思考:

  1. 是不是因为教科书上对瀑布诟病太多了,然后大家就连瀑也不布了?

  2. 实际中的项目往往既不是瀑布,也不是敏捷,那到底属于那种开发方式呢?姑且称之为“自然开发方式”吧

  3. 没有文档就不是瀑布?摇身一变就敏捷?或者是什么?

  4. 如果我们通常采用的开发方式属于“自然开发方式”,很难说是否还处于瀑布模型之前还是之后?效能上和瀑布孰高孰低呢?

  5. 小团队往往会采用更“自然”一点的开发方式,大型团队流程上也许会相对正规一点,那这种“更贴近自然”的开发方式和“更正规化一点”的开发方式...

    从事软件开发已7年有余,回头看亲历过的和周围的项目,有几个问题值得思考:

  1. 是不是因为教科书上对瀑布诟病太多了,然后大家就连瀑也不布了?

  2. 实际中的项目往往既不是瀑布,也不是敏捷,那到底属于那种开发方式呢?姑且称之为“自然开发方式”吧

  3. 没有文档就不是瀑布?摇身一变就敏捷?或者是什么?

  4. 如果我们通常采用的开发方式属于“自然开发方式”,很难说是否还处于瀑布模型之前还是之后?效能上和瀑布孰高孰低呢?

  5. 小团队往往会采用更“自然”一点的开发方式,大型团队流程上也许会相对正规一点,那这种“更贴近自然”的开发方式和“更正规化一点”的开发方式孰高孰低呢?

  6. 如何界定混乱与灵活性?

  7. 我们如何改进现有状况?

IT168文库

大型金融组织的scrum实践

 

大型金融组织的scrum实践


来自某大型金融服务集团在过去一年中敏捷转型的酸甜苦辣。记录了一个数百人规模的离岸研发团队如何从传统的瀑布开发模式向敏捷开发模式转化,在公司全球研发团队中找到适合自己的高效自组织scrum团队的发展之路。


详细解读 和小伙伴们一起来吐槽

大型金融组织的scrum实践 - 332566262 - 拟声的主扬

 

大型金融组织的scrum实践


来自某大型金融服务集团在过去一年中敏捷转型的酸甜苦辣。记录了一个数百人规模的离岸研发团队如何从传统的瀑布开发模式向敏捷开发模式转化,在公司全球研发团队中找到适合自己的高效自组织scrum团队的发展之路。


详细解读 和小伙伴们一起来吐槽

秒大刀

Scrum的由来—由瀑布等传统开发模型的弊端提出敏捷开发方法

瀑布模型是由Royce在1970年提出的,他把大型软件的开发分为分析与编程. 
瀑布模型的弊端: 
    1). 强调文档性:导致了往往要到开发的后期,才能看到软件的模样.为软件的开发极大的增加了风险性. 
    2). 没有迭代与反馈:导致了无法应对客户的需求变化. 
        而在当今ERP盛行的软件市场里面,由于市场带动的软件需求变化和软件初期客户对需求描述的不清楚,都...

瀑布模型是由Royce在1970年提出的,他把大型软件的开发分为分析与编程. 
瀑布模型的弊端: 
    1). 强调文档性:导致了往往要到开发的后期,才能看到软件的模样.为软件的开发极大的增加了风险性. 
    2). 没有迭代与反馈:导致了无法应对客户的需求变化. 
        而在当今ERP盛行的软件市场里面,由于市场带动的软件需求变化和软件初期客户对需求描述的不清楚,都为瀑布模型的使用带来了困难. 
    3). 采用瀑布模型开发的软件,极大的带来了更改的成本 

    结果:我们需要一种能够针对需求变化作出快速有效反馈并且能够让客户在短期内看到软件模型,减少风险的开发方法——Agile{Scrum
 
敏捷开发方法的前身是轻量级开发方法(Lightweight methods)—针对传统的重型开发方法(传统的瀑布开发方法) 
Scrum开发方法是由Jeff Sutherland在1993年创立 
Scrum的骨架和核心:Scrum的所有实践都围绕一个迭代,增量的过程骨架展开 
Scrum是遵循敏捷方法的一个软件开发框架。在SCRUM框架中,融入敏捷开发的精神和思想,就被称作SCRUM开发方法。Scrum是一个 什么样的开发框架呢?简单说,它由三个角色(Role),三种会议(Meeting),三项工件(Artifact)组成 
 
Scrum中基本概念
 
三个基本角色(Role) 

  • 产品主管(Product Owner)

  • Scrum师傅(Scrum Master)

  • 团队成员(Scrum Team)

三种会议(Meeting) 

  • 迭代计划会议(Sprint Planning Meeting)

  • 每日晨会(Daily Scrum Meeting) 

  • 迭代回顾会议(Sprint Review Meeting) 

三项工件(Artifact) 

  • 待开发任务列表(The Sprint Backlog) 

  • 待修复缺陷列表(The defect backlog) 

  • 进度图(BrunDown Chart) 

 

 

from: http://blog.csdn.net/xoyojank/archive/2008/09/02/2864542.aspx

扩展阅读:

Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述
Scrum框架及其背后的原则(下)——框架背后的原则及实施过程不良症状分析

2011-7-22

    我们团队在推行Scrum过程中受到外界各种各样的压力。目前能被允许采用的有限的几种实践也经过了各种折中,甚至都不敢光明正大的承认采用的是Scrum!

    老廖找到一组文章,正好是“吐槽”Scrum的,共同娱乐。

    从两篇中文和另外一篇英文文章后面的评论明显可以看出咱们深奥了。师长经常教导我们“先做人,再做事”,精辟啊!
    尊重科学!

2011-10-13

微软的一些资料:

2012-6-25

    敏捷,是灵丹妙药还是又一个忽悠?

LOFTER

让兴趣,更有趣

简单随性的记录
丰富多彩的内容
让生活更加充实

下载移动端
关注最新消息