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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

验证程序效能上没有问题

……

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

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

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

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

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

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

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

对于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多人挤在会议室里搞DailyScrum，一叹!)

在结尾时，邹欣提出：

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