时间过得很快,两个礼拜一晃就过去了。阿捷他们的第一次快跑Sprint也结束了,但大家感觉并不怎么好。
在Sprint计划会议上,大家按照阿捷准备的一个Product Backlog,从中选择了一些用户需求,进行开发。虽然阿捷事先对这个Product Backlog条目做了一定的细化,并设定了一定的优先级,但在选择的时候,大家并没有按照优先级来选,只是找了几个刚好可以在两个礼拜内做完的东西。在会议上,大家大致讨论了一下,阿捷就按照先前的惯例,根据每个人过去的经验,对每个模块的熟悉程度,基本上是直接指定一个人做哪个任务了。对于每个任务,没有做详细的估算和任务划分,因为以前就一直是把任务交给一个人后,由这个人一直负责,自己做估算、做设计、实现,然后交给测试人员测试,测出Bug再返工,直到做完为止。这个过程基本上就是一个黑盒,如果负责这个任务的人不说,别人也不知道具体做得如何,当前是什么状态。
Sprint计划会议的第二天上午10:30,阿捷召集所有的人在“光明顶”举行了第一次站立会议,因为这是首次举行站立会议,大家相互看着对方,觉得很好玩,兴致都很高。阿捷首先把自己负责的任务讲了一下。包括自己将会如何设计、对不同的实现方式进行了比较,然后给出估算,觉得应该可以在一周内做完,然后交给测试人员进行测试。大民、小宝基本上都是同样的模式,也把自己的任务讲了一遍。小宝觉得自己那块有些复杂,可能要花上8个工作日才行,估计剩不了多少时间留给测试了。阿朱和阿紫因为要等着开发人员做完后,才能进行测试,所以也没开始具体做什么事情,讲起来自然很简单,两个人总共花的时间还没有大民、阿捷一个人用的时间一半多。但即使如此,不知不觉地时间就到了11:40,大家差不多站了一个多小时,腿都酸了,刚好都到了吃饭时间,大家一哄而散,下楼去吃饭。
在接下来的日子里,如果有会议室,大家就到会议室里开站立会议;如果没有,大家就聚到阿捷的格子间凑合一下。有时候是上午10:00开,有时候是10:30,还有一次因为阿捷上午要开部门的Dashboard会议,大家的Daily Scrum站立会议是在下午3:00开的。有时候大家会对一个技术问题展开激烈的讨论,有时候不知怎么的,大家就会扯到姚明、NBA、奥运会北京限行措施、抢购奥运门票的事情上去,偶尔还会聊聊公司的公积金政策、部门的人事变动等,反正每次的会议都挺长。有时候谁累了,就坐在椅子上或桌子上,听别人讲。当然还少不了阿紫、小宝这样的短信狂人,收到短信时所带来的噪音。有时候,阿捷也觉得这么做真的有点浪费时间,相信其他人也有同感,但即使如此,大家还是把站立会议坚持了下来,毕竟Scrum很重要的一点就是强调Daily Standup Meeting的!
大民、阿捷所负责的任务基本上都按期完成了,阿朱、阿紫分别进行了测试,虽然发现了一些小问题,但大民、阿捷还是在Sprint结束前就修正完了。但小宝所负责的任务,就像他自己第一天所说的,真的遇到了麻烦。一个模块总是出现Core Dump,无法运行,小宝换了好几种方法,甚至做了Debug版本,进行单步跟踪,还是找不到问题。甚至在开站立会议时,大家等了他好几次,他才不情愿地从座位上站起来,参加站立会议。在会议中间,还跑回去几次看看运行结果。因为小宝自己没有主动提出需要帮忙,所以阿捷、大民也没好意思帮他看到底问题出在哪里。直到Sprint结束前一天,小宝才兴奋地告诉大家,问题终于解决了。可留给阿朱的测试时间只有一天多,虽然阿朱早已准备好了测试用例,但对于这样一个复杂的特性,这点儿时间还是不够的。于是,在这个Sprint中,小宝负责的模块没有完成最终测试。这让阿朱很沮丧,因为感觉好像是她的工作没有做完。同时阿朱也很委屈,毕竟在这次快跑中,自己的工作前松后紧,自己也想努力完成最初计划的事情,可是小宝的工作一直没完成,自己也只能是干着急,毫无办法。
对于这种现状,阿捷更着急。不仅仅是因为这个Sprint的原始计划没有完成,更重要的是自己团队的第一次快跑就这么搞砸了。在Sprint结束后,阿捷组织大家进行了一次简单的回顾,谈谈大家对第一次快跑的感受。在会上,阿捷虽然想了点Ice Breaker,试图活跃一下气氛,但因为第一次快跑的过程与结果都不令人满意,气氛还是很压抑。大家谈得不多,基本上觉得每天的状态报告会花了太多时间,其实应该把这个时间更好地用到项目本身才对;另外,因为Scrum本身只是一个框架,没有定义具体的编程实践,不如一些XP实践更具有可操作性,关键的还是大家基本上都没看到这个Scrum流程的价值,这次快跑让大家感觉有点泄气。小宝和阿朱甚至说,干脆别搞Scrum了,似乎带来的问题更多。阿捷好说歹说,才使大家平静下来,最终达成的一致意见是暂时停下来,重新审视一下,看看是不是可以改善一下,在找到真正可行的办法或者操作实践后,再继续搞Scrum,再试验下一次快跑。
阿捷这几天一直很苦恼,再加上7月的北京已经开始变得炎热起来,阿捷就有点着急上火,不仅仅睡觉不踏实,连嘴边都起了大泡。从感觉上讲,Scrum应该是一个很好的项目管理模式,不然敏捷圣贤也不会推荐给自己,而且要不然像Google、Microsoft等大公司也早就放弃了。可能只是自己实践的方式不对吧,但却又不知道到底该怎么去改善,看来只能靠敏捷圣贤的帮助了。阿捷每天都上网,并待到很晚才下去,希望能碰到敏捷圣贤。
这天晚上,阿捷跟美国方面开完Conference Call后,正准备去洗脸刷牙,却意外地发现敏捷圣贤上线了!阿捷高兴得跳了起来!
阿捷:你好!
敏捷圣贤:你好啊!
阿捷:现在有时间吗?我们遇到了麻烦。
敏捷圣贤:呵呵,我果然猜对了!我是专门上来找你的!我想你们的第一次快跑结束了吧?
阿捷:是的!我们遇到一些问题,大家的意见开始出现分歧了,有人甚至认为Scrum带来了更多的麻烦!
敏捷圣贤:这可不是一个好兆头。说说你的问题,让我看看,怎么解决,我想多数是你们使用的方法有偏差。
阿捷:我也觉得Scrum是一个很好的流程。
敏捷圣贤:对!只做了一个Sprint,不要就下结论说Scrum适合或不适合。Scrum可以让你从另外一个角度来思考如何进行项目管理。找到窍门总是需要花些时间的。我建议你们小组坚持这个流程,至少做完3个Sprint,然后再决定是否继续。第一次快跑肯定会遇到问题的,你们可以回顾总结一下,把一些能操作的反馈加入到第2个Sprint中,逐步做出改善。这样,经过3个Sprint,你们才会真正地了解Scrum。
阿捷:好!我会劝说大家继续跑完Sprint 2和Sprint 3的。
敏捷圣贤:先给我讲一下你们是怎么做的?
阿捷:大概是这样做的。我事先花时间完成了产品的Backlog,然后大家跟大家做了一个执行计划。之后就是每天早上开“站立会议”,这个非常花时间,每次大概40~50分钟。在Sprint结束的时候,每个人做了几分钟的总结,并进行了回顾,会上大家意见纷纭,觉得Scrum问题不少。
敏捷圣贤:哦,你们的产品Backlog是怎么组织的?
阿捷:作为一个Scrum Master,我用Excel做了个列表,把我们下几周需要做的东西放进去,还按照优先级排了一下序。
敏捷圣贤:等一下!你说,你做了一个Product Backlog?
阿捷:是啊!有什么问题吗?
敏捷圣贤:也就是说,你们没有定义一个Product Owner这个角色?没有让这个人去完成并维持Product Backlog?
阿捷:恩,我们没有。
阿捷心想敏捷圣贤的脸色一定很难看,估计这个问题很严重!
敏捷圣贤:如果你们真的想实行Scrum,那么就一定要遵循Nokia的敏捷标准,遵循Nokia制定的“Scrum规则”,这是Nokia用了几年时间,对上百个Scrum团队进行了回顾后,才总结出来的很简单的建议,这可以帮助他们判断一个团队是否在真正实施Scrum。
阿捷:那Nokia怎么知道一个团队是否真的在实施Scrum呢?
敏捷圣贤:首先,他们要看是否采取了迭代开发的方式。多年来,业界一直使用迭代式的、增量式的开发,这似乎已经成为所有敏捷过程的基础元素了。
阿捷:这个应该比较好判断。那为什么团队是否“进行迭代开发”这么重要呢?
敏捷圣贤:因为如果不这样做,甚至都不能称为敏捷的软件开发过程。这是因为敏捷希望整个软件开发流程中的所有人都可以一起工作,大家都要对产品非常了解:无论是构建产品的人,测试产品的人,还是将会使用产品的用户。
阿捷:嗯,大家是应该一起工作。
敏捷圣贤:对,如果把过程分隔成“这里的这些人编写需求说明和规范,然后他们把文档交给负责构建软件的人,软件构建者再将软件转给测试人员,最后测试人员把软件提供给客户”,客户就会说那不是他们真正需要的东西。然后就要回到开头,再来一次。如果如此反复三遍的话,客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。
阿捷:嗯,那在Nokia,还要接着问什么问题?
敏捷圣贤:他们会接着问“你们有固定的迭代周期吗?你们的迭代是否以某个特定的时间开始并以某个固定的时间结束?”
阿捷:是不是迭代周期也应该有限制?
敏捷圣贤:对!在Nokia,迭代周期必须少于6周。如果不是这样做的,那么就没有进行迭代开发。
阿捷:如果人们的回答是肯定的呢?
敏捷圣贤:那他们接下来会问“那好,在每个迭代结束的时候,你们有可以工作的软件么?”这个问题会把很多人排除在外,因为如果不能给出可以工作的软件的话,那也就是没有进行迭代式开发。
阿捷:嗯,如果回答还是肯定的呢?
敏捷圣贤:接下来他们会说“好,你希望在结束时拥有可工作的软件,那么在可以开始迭代之前,你们的团队是不是必须要有一个有完整细节的需求说明?”如果需要的话,那就不是迭代式开发。
阿捷:哦,我有些明白你的意思了。接着呢?
敏捷圣贤:最后他们会说“要在迭代结束时拥有可以工作的软件,将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗?”,这个问题有可能将一半左右的Scrum团队排除在外,这时甚至还没有谈到有关Scrum的话题呢。
阿捷:是啊!我明白了,那他们的“Scrum规则”是什么?
敏捷圣贤:嗯,对于应用Scrum,他们有四个附加的规则。团队被询问的第一个问题是“你们是否有Product Owner?是不是有人可以代表客户与你们一起工作?”
阿捷暗想,自己团队的Scrum还真没有啊,于是问道:Product Owner的作用是什么?
敏捷圣贤:很简单,当团队在决定应该构建什么样的产品时,这个人就是他们要询问的对象,这个人代表着客户的需求与利益。
阿捷:如果对这个问题回答“是”呢?
敏捷圣贤:Nokia会询问的第二个问题是“如果有Product Owner的话,他们是否拥有一个待开发功能的Product Backlog?此Backlog是否根据业务价值排定了优先级?是否已经估算过开发这些功能需要多少时间?”。
阿捷:哦。
敏捷圣贤:这是一个Product Owner为一次版本发布构建路线图所需要的依据。如果得到了肯定的回答,他们会继续询问“团队在开发过程中,有没有使用 Burndown图,来展示当前迭代中随着时间的推进,剩余工作量的变化,以跟踪进度?并且能否基于Burndown图来推算团队的速度?”
阿捷:这个问题的意义在哪里呢?
敏捷圣贤:首先,Product Owner可以根据它来构建发布规划;同时团队可以根据它来真正改进流程。只有知道自己的速度如何,这有助于一个团队进行更好的估算,同时帮助他们在继续后续工作时提升速度。
阿捷:嗯,这已经有三个规则了,最后一个是什么?
敏捷圣贤:Scrum团队依赖自组织的过程,这就意味着团队负责挑选工作、职责分配,并要找出最快交付工作的途径。所以,Nokia的最后一条规则是:在迭代中,项目经理不能干涉团队工作,因为这会停止自组织的过程,并且得到解决方案的过程将不再是最优化的了。
阿捷再次想起了Product Owner的问题,赶紧问:为什么非得要专门的Product Owner?我代替不可以吗?
敏捷圣贤:首先,产品Backlog是Scrum的核心,从根本上说,它是一个需求或故事或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语言进行描述。产品的Backlog应该仅仅由那些产品相关的较大的任务(ticket)组成,有关在产品开发中完成某项工作时候涉及的东西,太细了就不适合。
敏捷圣贤:其次,在维护产品Backlog的时候,Product Owner(就是那个能替最终客户发言的人)必须参加,由他排列优先级。Product Owner必须是离客户最近的人,你作为研发项目管理人员,不可能是离客户最近的人。如果没有这个角色,你们怎么知道哪个重要哪个不重要?和Product所有人交流,你们才可以做出来一个有优先顺序的列表,把最重要的功能放在列表的前面。
阿捷:我知道了,看来我得找Product Manager来担任这个角色才行。那这个Backlog条目除了优先级外,还有其他什么要求?
敏捷圣贤:嗯,每一个条目应该有估计完成时间,这个并不需要很准确。我们只需要有一个大概的估算即可,这样才能够决定把多少工作放到一个Sprint里。
敏捷圣贤:另外,在你开sprint规划会议之前,你的产品Backlog应该保持一种合适的格式。你可以是把它们都放在一个Excel中,也可以是一个Word文档,或者是某种Scrum工具中……采用哪种形式都可以,只要你们自己觉得方便就行。
阿捷:嗯,我用了Excel。
敏捷圣贤:Sprint计划会议除了你的团队成员和Product Owner外,还可以邀请更多的人参加。
阿捷:我还以为我一个人规划Sprint就可以了呢。
敏捷圣贤:那是旧的管理模式。在Scrum框架下,没有“个人”的概念,Scrum依靠的是团队的力量。尽管Scrum Master在这个框架下的作用很重要,但这个人不是独裁者。做Sprint计划时,一定要让整个团队参加。
阿捷:那具体怎么做呢?大家一起做计划,岂不是很乱?
敏捷圣贤:首先,你们要先定下来Sprint的目标,即作为一个团队,你们要完成什么,然后再决定完成多少。
阿捷:我们当前没有任何历史参考数据,怎么知道完成多少呢?
敏捷圣贤:事先计算出在一个Sprint内,团队的可能工作时间。譬如,在未来三周内,一个5人小组,每人每周工作40小时,那么总的工作时间=5×40×3=600小时。
阿捷:理想情况是这样的,但肯定会有人休假的。
敏捷圣贤:对,所以你要将总的工作时间扣除任何预期的非工作时间。譬如,有一个人要休一个礼拜的年假,还有人要看牙,需要占用3天,这样算起来是600-5x8-3x8=536小时。
阿捷:还有,即使每人每天工作8小时,但也不是会真的有8小时工作在项目上,还要参加各种Tea Talk、培训、Team Building等活动。
敏捷圣贤:如果每天8小时,你们大概会有几小时工作在项目上?
阿捷:平均差不多6小时吧。
敏捷圣贤:你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。
阿捷:那估计5小时。
敏捷圣贤:我们把它用百分比表示,5/8,那么就是60%左右,然后用这个“负荷指标”(Load Factor)乘以总的工作时间小时数,你就得到了536×0.6=322小时。
阿捷:嗯,这种估算很实际。
敏捷圣贤:然后从产品Backlog中,按照优先级从高到低,选择出你们认为能在322小时内完成的条目,作为你们当前Sprint的Backlog。注意:选择的Sprint Backlog Item一定要强内聚、松耦合,这样你们才能不受或者少受外界的干扰,目标明确。
阿捷:那个“负荷指标” 60%应该是变动吧?我们刚做一个项目,跟项目做了一段时间相比,肯定是不一样的。再譬如我有新员工加入时,他的效率肯定是要比老员工低的。
敏捷圣贤:对。你已经很好地理解了负荷指标,你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时,要试着找出根本原因,这会使你门的Sprint更有效率。
阿捷:下一步是不是该做任务细化?进行估算?
敏捷圣贤:不完全对,任务细化之外,还有一个非常重要的部分:对于每个细化后的任务,都需要一个非常明确“完成”(Done)的定义。这一点非常重要,必须保证每一个人的理解是正确的、一致的。
阿捷:嗯,否则每个人的估算就会千差万别。
敏捷圣贤:对!估算时,可以用“计划扑克牌”来估算完成时间。你知道怎么用计划扑克牌吗?
阿捷:不知道,我想我可以去查一下。
敏捷圣贤:嗯,你们应该尝试一下这个东西。
阿捷:还有什么值得注意的?
敏捷圣贤:做Sprint任务细化时,一个最佳实践就是把每个任务控制在2~16 小时之间。任务太细,会涉及更多的微观管理,太粗,估算就会不准确。
阿捷:OK!在这一点上,Scrum跟其他项目规划方法是一样的。
敏捷圣贤:下一步,就是让大家自己认领任务,而不是指派!这一点非常关键,一定要记住啊?
阿捷:为什么要认领?指派会更有效率,而且还能根据每个人的特长,让每个人做他擅长的事情。
敏捷圣贤:首先,每个人认领任务后,实际上就是对整个团队有了一个承诺,更能保证按计划完成。其次,让每个人选择自己愿意做的事情,这样才会更有主动性,毕竟“做自己有兴趣的事情,才会真的做好”。这样,不仅满足了个人发展的需要,还可以达到快速的知识共享、团队技能的整体提高。
阿捷:不错,以前是只对项目经理一个人承诺,这样认领后,就成了对所有人的承诺。
敏捷圣贤:此外,跟任何其他会议一样,对于跨度一天的计划会议,确定好会议日程非常重要。因为Sprint计划会议一定要基于Time-Boxed,在规定的时间内,一定要结束,就像一个Sprint一样,同样要有紧迫感。
阿捷:嗯,我会仔细计划的。
敏捷圣贤:还有,Sprint计划会议必须在一个完整天内开完。
阿捷:为什么?
敏捷圣贤:Sprint计划会议开始的那一天,也就是Sprint开始的一天。如果Sprint计划会议要跨越两天,可不是什么好玩儿的事情,你的Burndown Chart就会像我们的这样很难看。你会看到Sprint才一开始,似乎我们的工作量只有150,怎么第二天时工作量就快到了190,出现了一个凸起。如果不了解内情的话,一定还以为Sprint出了问题呢。而实际上是因为我们曾经在前一天的下午开了4小时,第二天上午又开了3小时,对任务进行细化,结果任务估算增加。
阿捷:嗯,还有其他的吗?
敏捷圣贤:有!采用Delphi方法进行任务工作量的估算。当进行任务细化的时候,每个人的估算是不一样的,如果最高估算值跟最低估算值相差一半以上,二者就要沟通一下,看看为什么二者的理解相差这么多。沟通明白后,再重新估算。即使这样,还是会有分歧的,此时采用Delphi估算方法,简单讲就是进行一次加权平均。
阿捷:嗯,我们以前也用过Delphi方法。
敏捷圣贤:为了提高任务细化的效率,可以将团队分成两个小组分别进行。
阿捷:为什么还要分组?不是让大家一起做细化、做估算的吗?
敏捷圣贤:是这样的,我曾经带过一个Team,有10个人。最初,我都是打开投影仪,把Product Backlog投到屏幕上去,大家一边说,我一边敲,我是挺忙活的,但是大家却不一定都能集中注意力。现在回头看看,这种方法真是有点蠢!当Team成员少的时候,在最初的几个Sprint,大家在兴趣还比较高的时候,这种方法还行。当Team成员超过6个的时候,问题出现了,首先是当讨论某一个问题的时候,总会有人问,刚才你们说什么来着?很显然,他走神了。另外,人多的时候,对同一个任务的细化,即使采用Delphi方法,沟通成本也很高,很费时间。
阿捷:那你们具体怎么做的?
敏捷圣贤:后来我就把Team分成两个小组,分别对任务进行细化。细化时,不再用投影仪,而是把Sprint Backlog中的内容按大块张贴在墙上,大家站在墙前,拿着记事帖直接进行细化和估算。当两个小组都进行完后,互相检查对方对任务的细化,解决争议,澄清模糊的地方。这样一来,就把大家的积极性调动起来,参与程度非常高,效率也高。
阿捷:虽然我们团队现在只有5个人,估计还用不上,但这个经验真的值得推广。
敏捷圣贤:产品负责人(Product Owner)一定要参加。实在不能参加的话,也要指定一个人授权代理。否则,就不要开Sprint计划会议。
阿捷:嗯,我一定会把他叫过来参加这个会议的。
敏捷圣贤:最后一点,虽然我们采用了Scrum,但即使不再采用Gatt图,但是传统的Risk/Dependency分析还是不要丢弃。在Sprint计划会议结束前,进行Risk/Dependency的分析,还是会帮助我们发现一些问题的,然后再稍微重新调整任务的优先级,更能保证Sprint的成功。
阿捷:好的!有了这些指导原则,我相信我们的第二个Sprint会走得更好的。
敏捷圣贤发过来一个不断眨眼的笑脸,似乎提醒阿捷不要过于乐观。
阿捷:还有一个问题就是,我感觉这个Scrum好像只定义了一个项目管理框架,没有给出具体的编程实践指导,是你还没告诉我吗?
敏捷圣贤:嗯,不是的。Scrum依靠的是经验管理,所以他没有定义出很细的工程实践。这样才能很好地跟组织原来的工程实践融合起来,譬如跟CMM、ISO 9000、RUP,甚至XP等都能很好地工作在一起。因为Scrum主要是想解决项目管理和组织实践范畴的东西,更多的是关注在敏捷团队建设上,它的终极目标就是自我管理自我组织的高效团队。作为一个敏捷框架,具体的编程实践,可以靠XP去补充。但我还是建议你们,最初先努力适应这个框架,待成熟后再考虑引入其他敏捷实践。
阿捷:好的!这次我不会冒进的。J
敏捷圣贤:那就好!凡事预则立,不预则废。对形势做出良好的判断并提前做好准备还是非常有必要的。我要下了,有事咱们再联系吧。
阿捷:多谢。886。
敏捷圣贤:886。
在Sprint计划会议上,大家按照阿捷准备的一个Product Backlog,从中选择了一些用户需求,进行开发。虽然阿捷事先对这个Product Backlog条目做了一定的细化,并设定了一定的优先级,但在选择的时候,大家并没有按照优先级来选,只是找了几个刚好可以在两个礼拜内做完的东西。在会议上,大家大致讨论了一下,阿捷就按照先前的惯例,根据每个人过去的经验,对每个模块的熟悉程度,基本上是直接指定一个人做哪个任务了。对于每个任务,没有做详细的估算和任务划分,因为以前就一直是把任务交给一个人后,由这个人一直负责,自己做估算、做设计、实现,然后交给测试人员测试,测出Bug再返工,直到做完为止。这个过程基本上就是一个黑盒,如果负责这个任务的人不说,别人也不知道具体做得如何,当前是什么状态。
Sprint计划会议的第二天上午10:30,阿捷召集所有的人在“光明顶”举行了第一次站立会议,因为这是首次举行站立会议,大家相互看着对方,觉得很好玩,兴致都很高。阿捷首先把自己负责的任务讲了一下。包括自己将会如何设计、对不同的实现方式进行了比较,然后给出估算,觉得应该可以在一周内做完,然后交给测试人员进行测试。大民、小宝基本上都是同样的模式,也把自己的任务讲了一遍。小宝觉得自己那块有些复杂,可能要花上8个工作日才行,估计剩不了多少时间留给测试了。阿朱和阿紫因为要等着开发人员做完后,才能进行测试,所以也没开始具体做什么事情,讲起来自然很简单,两个人总共花的时间还没有大民、阿捷一个人用的时间一半多。但即使如此,不知不觉地时间就到了11:40,大家差不多站了一个多小时,腿都酸了,刚好都到了吃饭时间,大家一哄而散,下楼去吃饭。
在接下来的日子里,如果有会议室,大家就到会议室里开站立会议;如果没有,大家就聚到阿捷的格子间凑合一下。有时候是上午10:00开,有时候是10:30,还有一次因为阿捷上午要开部门的Dashboard会议,大家的Daily Scrum站立会议是在下午3:00开的。有时候大家会对一个技术问题展开激烈的讨论,有时候不知怎么的,大家就会扯到姚明、NBA、奥运会北京限行措施、抢购奥运门票的事情上去,偶尔还会聊聊公司的公积金政策、部门的人事变动等,反正每次的会议都挺长。有时候谁累了,就坐在椅子上或桌子上,听别人讲。当然还少不了阿紫、小宝这样的短信狂人,收到短信时所带来的噪音。有时候,阿捷也觉得这么做真的有点浪费时间,相信其他人也有同感,但即使如此,大家还是把站立会议坚持了下来,毕竟Scrum很重要的一点就是强调Daily Standup Meeting的!
大民、阿捷所负责的任务基本上都按期完成了,阿朱、阿紫分别进行了测试,虽然发现了一些小问题,但大民、阿捷还是在Sprint结束前就修正完了。但小宝所负责的任务,就像他自己第一天所说的,真的遇到了麻烦。一个模块总是出现Core Dump,无法运行,小宝换了好几种方法,甚至做了Debug版本,进行单步跟踪,还是找不到问题。甚至在开站立会议时,大家等了他好几次,他才不情愿地从座位上站起来,参加站立会议。在会议中间,还跑回去几次看看运行结果。因为小宝自己没有主动提出需要帮忙,所以阿捷、大民也没好意思帮他看到底问题出在哪里。直到Sprint结束前一天,小宝才兴奋地告诉大家,问题终于解决了。可留给阿朱的测试时间只有一天多,虽然阿朱早已准备好了测试用例,但对于这样一个复杂的特性,这点儿时间还是不够的。于是,在这个Sprint中,小宝负责的模块没有完成最终测试。这让阿朱很沮丧,因为感觉好像是她的工作没有做完。同时阿朱也很委屈,毕竟在这次快跑中,自己的工作前松后紧,自己也想努力完成最初计划的事情,可是小宝的工作一直没完成,自己也只能是干着急,毫无办法。
对于这种现状,阿捷更着急。不仅仅是因为这个Sprint的原始计划没有完成,更重要的是自己团队的第一次快跑就这么搞砸了。在Sprint结束后,阿捷组织大家进行了一次简单的回顾,谈谈大家对第一次快跑的感受。在会上,阿捷虽然想了点Ice Breaker,试图活跃一下气氛,但因为第一次快跑的过程与结果都不令人满意,气氛还是很压抑。大家谈得不多,基本上觉得每天的状态报告会花了太多时间,其实应该把这个时间更好地用到项目本身才对;另外,因为Scrum本身只是一个框架,没有定义具体的编程实践,不如一些XP实践更具有可操作性,关键的还是大家基本上都没看到这个Scrum流程的价值,这次快跑让大家感觉有点泄气。小宝和阿朱甚至说,干脆别搞Scrum了,似乎带来的问题更多。阿捷好说歹说,才使大家平静下来,最终达成的一致意见是暂时停下来,重新审视一下,看看是不是可以改善一下,在找到真正可行的办法或者操作实践后,再继续搞Scrum,再试验下一次快跑。
阿捷这几天一直很苦恼,再加上7月的北京已经开始变得炎热起来,阿捷就有点着急上火,不仅仅睡觉不踏实,连嘴边都起了大泡。从感觉上讲,Scrum应该是一个很好的项目管理模式,不然敏捷圣贤也不会推荐给自己,而且要不然像Google、Microsoft等大公司也早就放弃了。可能只是自己实践的方式不对吧,但却又不知道到底该怎么去改善,看来只能靠敏捷圣贤的帮助了。阿捷每天都上网,并待到很晚才下去,希望能碰到敏捷圣贤。
这天晚上,阿捷跟美国方面开完Conference Call后,正准备去洗脸刷牙,却意外地发现敏捷圣贤上线了!阿捷高兴得跳了起来!
阿捷:你好!
敏捷圣贤:你好啊!
阿捷:现在有时间吗?我们遇到了麻烦。
敏捷圣贤:呵呵,我果然猜对了!我是专门上来找你的!我想你们的第一次快跑结束了吧?
阿捷:是的!我们遇到一些问题,大家的意见开始出现分歧了,有人甚至认为Scrum带来了更多的麻烦!
敏捷圣贤:这可不是一个好兆头。说说你的问题,让我看看,怎么解决,我想多数是你们使用的方法有偏差。
阿捷:我也觉得Scrum是一个很好的流程。
敏捷圣贤:对!只做了一个Sprint,不要就下结论说Scrum适合或不适合。Scrum可以让你从另外一个角度来思考如何进行项目管理。找到窍门总是需要花些时间的。我建议你们小组坚持这个流程,至少做完3个Sprint,然后再决定是否继续。第一次快跑肯定会遇到问题的,你们可以回顾总结一下,把一些能操作的反馈加入到第2个Sprint中,逐步做出改善。这样,经过3个Sprint,你们才会真正地了解Scrum。
阿捷:好!我会劝说大家继续跑完Sprint 2和Sprint 3的。
敏捷圣贤:先给我讲一下你们是怎么做的?
阿捷:大概是这样做的。我事先花时间完成了产品的Backlog,然后大家跟大家做了一个执行计划。之后就是每天早上开“站立会议”,这个非常花时间,每次大概40~50分钟。在Sprint结束的时候,每个人做了几分钟的总结,并进行了回顾,会上大家意见纷纭,觉得Scrum问题不少。
敏捷圣贤:哦,你们的产品Backlog是怎么组织的?
阿捷:作为一个Scrum Master,我用Excel做了个列表,把我们下几周需要做的东西放进去,还按照优先级排了一下序。
敏捷圣贤:等一下!你说,你做了一个Product Backlog?
阿捷:是啊!有什么问题吗?
敏捷圣贤:也就是说,你们没有定义一个Product Owner这个角色?没有让这个人去完成并维持Product Backlog?
阿捷:恩,我们没有。
阿捷心想敏捷圣贤的脸色一定很难看,估计这个问题很严重!
敏捷圣贤:如果你们真的想实行Scrum,那么就一定要遵循Nokia的敏捷标准,遵循Nokia制定的“Scrum规则”,这是Nokia用了几年时间,对上百个Scrum团队进行了回顾后,才总结出来的很简单的建议,这可以帮助他们判断一个团队是否在真正实施Scrum。
阿捷:那Nokia怎么知道一个团队是否真的在实施Scrum呢?
敏捷圣贤:首先,他们要看是否采取了迭代开发的方式。多年来,业界一直使用迭代式的、增量式的开发,这似乎已经成为所有敏捷过程的基础元素了。
阿捷:这个应该比较好判断。那为什么团队是否“进行迭代开发”这么重要呢?
敏捷圣贤:因为如果不这样做,甚至都不能称为敏捷的软件开发过程。这是因为敏捷希望整个软件开发流程中的所有人都可以一起工作,大家都要对产品非常了解:无论是构建产品的人,测试产品的人,还是将会使用产品的用户。
阿捷:嗯,大家是应该一起工作。
敏捷圣贤:对,如果把过程分隔成“这里的这些人编写需求说明和规范,然后他们把文档交给负责构建软件的人,软件构建者再将软件转给测试人员,最后测试人员把软件提供给客户”,客户就会说那不是他们真正需要的东西。然后就要回到开头,再来一次。如果如此反复三遍的话,客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。
阿捷:嗯,那在Nokia,还要接着问什么问题?
敏捷圣贤:他们会接着问“你们有固定的迭代周期吗?你们的迭代是否以某个特定的时间开始并以某个固定的时间结束?”
阿捷:是不是迭代周期也应该有限制?
敏捷圣贤:对!在Nokia,迭代周期必须少于6周。如果不是这样做的,那么就没有进行迭代开发。
阿捷:如果人们的回答是肯定的呢?
敏捷圣贤:那他们接下来会问“那好,在每个迭代结束的时候,你们有可以工作的软件么?”这个问题会把很多人排除在外,因为如果不能给出可以工作的软件的话,那也就是没有进行迭代式开发。
阿捷:嗯,如果回答还是肯定的呢?
敏捷圣贤:接下来他们会说“好,你希望在结束时拥有可工作的软件,那么在可以开始迭代之前,你们的团队是不是必须要有一个有完整细节的需求说明?”如果需要的话,那就不是迭代式开发。
阿捷:哦,我有些明白你的意思了。接着呢?
敏捷圣贤:最后他们会说“要在迭代结束时拥有可以工作的软件,将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗?”,这个问题有可能将一半左右的Scrum团队排除在外,这时甚至还没有谈到有关Scrum的话题呢。
阿捷:是啊!我明白了,那他们的“Scrum规则”是什么?
敏捷圣贤:嗯,对于应用Scrum,他们有四个附加的规则。团队被询问的第一个问题是“你们是否有Product Owner?是不是有人可以代表客户与你们一起工作?”
阿捷暗想,自己团队的Scrum还真没有啊,于是问道:Product Owner的作用是什么?
敏捷圣贤:很简单,当团队在决定应该构建什么样的产品时,这个人就是他们要询问的对象,这个人代表着客户的需求与利益。
阿捷:如果对这个问题回答“是”呢?
敏捷圣贤:Nokia会询问的第二个问题是“如果有Product Owner的话,他们是否拥有一个待开发功能的Product Backlog?此Backlog是否根据业务价值排定了优先级?是否已经估算过开发这些功能需要多少时间?”。
阿捷:哦。
敏捷圣贤:这是一个Product Owner为一次版本发布构建路线图所需要的依据。如果得到了肯定的回答,他们会继续询问“团队在开发过程中,有没有使用 Burndown图,来展示当前迭代中随着时间的推进,剩余工作量的变化,以跟踪进度?并且能否基于Burndown图来推算团队的速度?”
阿捷:这个问题的意义在哪里呢?
敏捷圣贤:首先,Product Owner可以根据它来构建发布规划;同时团队可以根据它来真正改进流程。只有知道自己的速度如何,这有助于一个团队进行更好的估算,同时帮助他们在继续后续工作时提升速度。
阿捷:嗯,这已经有三个规则了,最后一个是什么?
敏捷圣贤:Scrum团队依赖自组织的过程,这就意味着团队负责挑选工作、职责分配,并要找出最快交付工作的途径。所以,Nokia的最后一条规则是:在迭代中,项目经理不能干涉团队工作,因为这会停止自组织的过程,并且得到解决方案的过程将不再是最优化的了。
阿捷再次想起了Product Owner的问题,赶紧问:为什么非得要专门的Product Owner?我代替不可以吗?
敏捷圣贤:首先,产品Backlog是Scrum的核心,从根本上说,它是一个需求或故事或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语言进行描述。产品的Backlog应该仅仅由那些产品相关的较大的任务(ticket)组成,有关在产品开发中完成某项工作时候涉及的东西,太细了就不适合。
敏捷圣贤:其次,在维护产品Backlog的时候,Product Owner(就是那个能替最终客户发言的人)必须参加,由他排列优先级。Product Owner必须是离客户最近的人,你作为研发项目管理人员,不可能是离客户最近的人。如果没有这个角色,你们怎么知道哪个重要哪个不重要?和Product所有人交流,你们才可以做出来一个有优先顺序的列表,把最重要的功能放在列表的前面。
阿捷:我知道了,看来我得找Product Manager来担任这个角色才行。那这个Backlog条目除了优先级外,还有其他什么要求?
敏捷圣贤:嗯,每一个条目应该有估计完成时间,这个并不需要很准确。我们只需要有一个大概的估算即可,这样才能够决定把多少工作放到一个Sprint里。
敏捷圣贤:另外,在你开sprint规划会议之前,你的产品Backlog应该保持一种合适的格式。你可以是把它们都放在一个Excel中,也可以是一个Word文档,或者是某种Scrum工具中……采用哪种形式都可以,只要你们自己觉得方便就行。
阿捷:嗯,我用了Excel。
敏捷圣贤:Sprint计划会议除了你的团队成员和Product Owner外,还可以邀请更多的人参加。
阿捷:我还以为我一个人规划Sprint就可以了呢。
敏捷圣贤:那是旧的管理模式。在Scrum框架下,没有“个人”的概念,Scrum依靠的是团队的力量。尽管Scrum Master在这个框架下的作用很重要,但这个人不是独裁者。做Sprint计划时,一定要让整个团队参加。
阿捷:那具体怎么做呢?大家一起做计划,岂不是很乱?
敏捷圣贤:首先,你们要先定下来Sprint的目标,即作为一个团队,你们要完成什么,然后再决定完成多少。
阿捷:我们当前没有任何历史参考数据,怎么知道完成多少呢?
敏捷圣贤:事先计算出在一个Sprint内,团队的可能工作时间。譬如,在未来三周内,一个5人小组,每人每周工作40小时,那么总的工作时间=5×40×3=600小时。
阿捷:理想情况是这样的,但肯定会有人休假的。
敏捷圣贤:对,所以你要将总的工作时间扣除任何预期的非工作时间。譬如,有一个人要休一个礼拜的年假,还有人要看牙,需要占用3天,这样算起来是600-5x8-3x8=536小时。
阿捷:还有,即使每人每天工作8小时,但也不是会真的有8小时工作在项目上,还要参加各种Tea Talk、培训、Team Building等活动。
敏捷圣贤:如果每天8小时,你们大概会有几小时工作在项目上?
阿捷:平均差不多6小时吧。
敏捷圣贤:你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。
阿捷:那估计5小时。
敏捷圣贤:我们把它用百分比表示,5/8,那么就是60%左右,然后用这个“负荷指标”(Load Factor)乘以总的工作时间小时数,你就得到了536×0.6=322小时。
阿捷:嗯,这种估算很实际。
敏捷圣贤:然后从产品Backlog中,按照优先级从高到低,选择出你们认为能在322小时内完成的条目,作为你们当前Sprint的Backlog。注意:选择的Sprint Backlog Item一定要强内聚、松耦合,这样你们才能不受或者少受外界的干扰,目标明确。
阿捷:那个“负荷指标” 60%应该是变动吧?我们刚做一个项目,跟项目做了一段时间相比,肯定是不一样的。再譬如我有新员工加入时,他的效率肯定是要比老员工低的。
敏捷圣贤:对。你已经很好地理解了负荷指标,你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时,要试着找出根本原因,这会使你门的Sprint更有效率。
阿捷:下一步是不是该做任务细化?进行估算?
敏捷圣贤:不完全对,任务细化之外,还有一个非常重要的部分:对于每个细化后的任务,都需要一个非常明确“完成”(Done)的定义。这一点非常重要,必须保证每一个人的理解是正确的、一致的。
阿捷:嗯,否则每个人的估算就会千差万别。
敏捷圣贤:对!估算时,可以用“计划扑克牌”来估算完成时间。你知道怎么用计划扑克牌吗?
阿捷:不知道,我想我可以去查一下。
敏捷圣贤:嗯,你们应该尝试一下这个东西。
阿捷:还有什么值得注意的?
敏捷圣贤:做Sprint任务细化时,一个最佳实践就是把每个任务控制在2~16 小时之间。任务太细,会涉及更多的微观管理,太粗,估算就会不准确。
阿捷:OK!在这一点上,Scrum跟其他项目规划方法是一样的。
敏捷圣贤:下一步,就是让大家自己认领任务,而不是指派!这一点非常关键,一定要记住啊?
阿捷:为什么要认领?指派会更有效率,而且还能根据每个人的特长,让每个人做他擅长的事情。
敏捷圣贤:首先,每个人认领任务后,实际上就是对整个团队有了一个承诺,更能保证按计划完成。其次,让每个人选择自己愿意做的事情,这样才会更有主动性,毕竟“做自己有兴趣的事情,才会真的做好”。这样,不仅满足了个人发展的需要,还可以达到快速的知识共享、团队技能的整体提高。
阿捷:不错,以前是只对项目经理一个人承诺,这样认领后,就成了对所有人的承诺。
敏捷圣贤:此外,跟任何其他会议一样,对于跨度一天的计划会议,确定好会议日程非常重要。因为Sprint计划会议一定要基于Time-Boxed,在规定的时间内,一定要结束,就像一个Sprint一样,同样要有紧迫感。
阿捷:嗯,我会仔细计划的。
敏捷圣贤:还有,Sprint计划会议必须在一个完整天内开完。
阿捷:为什么?
敏捷圣贤:Sprint计划会议开始的那一天,也就是Sprint开始的一天。如果Sprint计划会议要跨越两天,可不是什么好玩儿的事情,你的Burndown Chart就会像我们的这样很难看。你会看到Sprint才一开始,似乎我们的工作量只有150,怎么第二天时工作量就快到了190,出现了一个凸起。如果不了解内情的话,一定还以为Sprint出了问题呢。而实际上是因为我们曾经在前一天的下午开了4小时,第二天上午又开了3小时,对任务进行细化,结果任务估算增加。
阿捷:嗯,还有其他的吗?
敏捷圣贤:有!采用Delphi方法进行任务工作量的估算。当进行任务细化的时候,每个人的估算是不一样的,如果最高估算值跟最低估算值相差一半以上,二者就要沟通一下,看看为什么二者的理解相差这么多。沟通明白后,再重新估算。即使这样,还是会有分歧的,此时采用Delphi估算方法,简单讲就是进行一次加权平均。
阿捷:嗯,我们以前也用过Delphi方法。
敏捷圣贤:为了提高任务细化的效率,可以将团队分成两个小组分别进行。
阿捷:为什么还要分组?不是让大家一起做细化、做估算的吗?
敏捷圣贤:是这样的,我曾经带过一个Team,有10个人。最初,我都是打开投影仪,把Product Backlog投到屏幕上去,大家一边说,我一边敲,我是挺忙活的,但是大家却不一定都能集中注意力。现在回头看看,这种方法真是有点蠢!当Team成员少的时候,在最初的几个Sprint,大家在兴趣还比较高的时候,这种方法还行。当Team成员超过6个的时候,问题出现了,首先是当讨论某一个问题的时候,总会有人问,刚才你们说什么来着?很显然,他走神了。另外,人多的时候,对同一个任务的细化,即使采用Delphi方法,沟通成本也很高,很费时间。
阿捷:那你们具体怎么做的?
敏捷圣贤:后来我就把Team分成两个小组,分别对任务进行细化。细化时,不再用投影仪,而是把Sprint Backlog中的内容按大块张贴在墙上,大家站在墙前,拿着记事帖直接进行细化和估算。当两个小组都进行完后,互相检查对方对任务的细化,解决争议,澄清模糊的地方。这样一来,就把大家的积极性调动起来,参与程度非常高,效率也高。
阿捷:虽然我们团队现在只有5个人,估计还用不上,但这个经验真的值得推广。
敏捷圣贤:产品负责人(Product Owner)一定要参加。实在不能参加的话,也要指定一个人授权代理。否则,就不要开Sprint计划会议。
阿捷:嗯,我一定会把他叫过来参加这个会议的。
敏捷圣贤:最后一点,虽然我们采用了Scrum,但即使不再采用Gatt图,但是传统的Risk/Dependency分析还是不要丢弃。在Sprint计划会议结束前,进行Risk/Dependency的分析,还是会帮助我们发现一些问题的,然后再稍微重新调整任务的优先级,更能保证Sprint的成功。
阿捷:好的!有了这些指导原则,我相信我们的第二个Sprint会走得更好的。
敏捷圣贤发过来一个不断眨眼的笑脸,似乎提醒阿捷不要过于乐观。
阿捷:还有一个问题就是,我感觉这个Scrum好像只定义了一个项目管理框架,没有给出具体的编程实践指导,是你还没告诉我吗?
敏捷圣贤:嗯,不是的。Scrum依靠的是经验管理,所以他没有定义出很细的工程实践。这样才能很好地跟组织原来的工程实践融合起来,譬如跟CMM、ISO 9000、RUP,甚至XP等都能很好地工作在一起。因为Scrum主要是想解决项目管理和组织实践范畴的东西,更多的是关注在敏捷团队建设上,它的终极目标就是自我管理自我组织的高效团队。作为一个敏捷框架,具体的编程实践,可以靠XP去补充。但我还是建议你们,最初先努力适应这个框架,待成熟后再考虑引入其他敏捷实践。
阿捷:好的!这次我不会冒进的。J
敏捷圣贤:那就好!凡事预则立,不预则废。对形势做出良好的判断并提前做好准备还是非常有必要的。我要下了,有事咱们再联系吧。
阿捷:多谢。886。
敏捷圣贤:886。