敏捷无敌之成长的烦恼(15)

 成长的烦恼(15)

本文摘自《敏捷无敌》一书

这天晚上，阿捷跟美国方面开完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小时，对任务进行细化，结果任务估算增加。