微软邹欣分析Scrum开发流程的问题和经验

　　邹欣是工作于微软亚洲研究院的研发经理，同时也是《编程之美》和《移山之道》的作者。前不久，他在博客上总结了自己使用scrum开发流程的经验。

　　在对Scrum的基本概念和流程做了简单介绍之后，邹欣提出几个在实践中会遇到的问题：

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

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

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

　　每日立会流于形式怎么办?

　　针对这些问题，邹欣提出几个改进方法：

　　定义好任务究竟是什么? 任务的完成 (done) 到底意味着什么? 每个人的任务必须是明确定义的

　　要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要， 但是不是关键 (那是沉没成本)，关键是要看我们离最后目标有多远。

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

　　邹欣接下来对于“任务完成”这件事又提出问题：

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

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

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

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

　　验证程序效能上没有问题

　　……

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

　　对于测试人员的职责问题，邹欣提出：

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

　　上面这两个问题，邹欣并没有给出明确的答案。

　　邹欣认为：ScrumMaster是Scrum实施是否能够成功的关键。

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

　　不过邹欣认为Scrum也没有那么特别，它和质量控制理论的模型，比如经典的戴明环PDCA没什么区别，在6西格玛理论中也可以看到相似的流程——DMAIC(Define， Measure， Analyze， Improve， Control)，与渐进交付的流程(Evolutionary Delivery)也很类似。

　　对于Scrum团队，邹欣指出：自我管理、自组织、跨职能，这三点要求看似简单，实际上很难做到。

　　自我管理：

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

　　自组织：

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

　　跨职能：

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

　　他强调：

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

　　最后，邹欣总结了一些实践者的经验教训：

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

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

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

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

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

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

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

原文转自：http://www.ltesting.net