细节决定成败——动作一定要做到位，才能强身健体

本文源自我在2012 Top100Submit大会的演讲《细节决定成败》，并会收录到麦思博公司将编集的《2012案例年鉴》中。

为期三天的Top100Submit会议中，你能听到来自不同IT领域、不同背景的嘉宾分享他们的故事，总能从中找出一些值得你学习的亮点，可能是你之前有疑惑的问题，也可能是你之前遇到过，但却是不同的应对策略。

在这里，我把自己所遇到的状况，以及应对策略记录下来，与大家分享。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

前言

敏捷软件开发方法在业界广泛受到关注，尤其是其中的SCRUM方法，更是广泛流行，几乎成了“敏捷”的代名词。之所以流行，一个很重要的原因是SCRUM从管理角度出发，易理解，看上到比较容易，所以也比较受管理者的青睐。

然而，SCRUM的创始人之一肯. 施瓦伯（KenSchwaber）在2009年的一篇博文上说：“目前实施SCRUM的软件企业中，有75%企业可能无法得到它们想达到的效果。”这一点也得到了充分的证实，因为随着越来越多的企业采纳该方法，负面的结果与声音也越来越多，尽管也有很多成功的案例在全球分享。

本文并不打算讨论导致这么负面结果的原因，而是讨论在已实施SCRUM一段时间，并且实施效果并不理想的企业中，如何帮助团队发现问题，通过白板的七次改变f过程，反映团队成长和持续改进，最终提前交付了高质量的新特性，并让团队成员真正理解了敏捷开发思想，在团队中重新树立了信心。

一、组织状况与试点团队人员组成

整个企业在2009年开始实施SCRUM，每个团队都在做SCRUM中规定的管理实践，而且建立了持续集成服务器，每天都可以定时构建，运行自动化测试。然而，每个产品在开发完成后，总是需要很长的时间修复缺陷，产品进度的可预期性不高。同时，还能看到肯.施瓦伯在其博文中提到的ScrumBUT症状，比如常常听到下面类似的说法：（1）每天站会开销太大了，我们每周做一次吧；（2）回顾会议太浪费时间了，所以我们不做了吧；（3）两个星期基本上什么也做不完，我们一个月算一次迭代吧；（4）经常来一些临时任务，所以总是完不成Sprint计划。

那么，到底是因为SCRUM不适合这样的组织吗？还是有别的原因呢？加入公司后，本人选择了一个试点团队，希望通过亲自实践，找到答案和改进方法。

最终选择了一个由近百人参与的嵌入式产品开发项目，并在其中选择了一个团队，该团队负责其中一个特性，开发是基于1500万行以上代码的一个遗留系统，编程语言是C++。

团队共有九人，只有TeamLead在该代码基础上工作过两年，其他人员均少于半年，有一个开发人员刚刚入职两个月。

Team Lead：1人

Product Owner：1人

Architect：1人

Developer：5人

Manual Tester：1人

二、团队工作过程中的白板演进

1、“似乎标准”的SCRUM白板

最初团队使用较早的SCRUM白板格式，对用户故事进行任务分解，而分解的依据之一是活动类型。而每个任务的估计使用绝对时间，并在每天早会上更新以时间为单元的燃尽图。而每天早会上，看上去更像是团队成员的工作汇报，每个人都关注于自己做的任务。而且每个用户故事都很大，需要两周或更多才能完成。

2、建立价值流导向的白板

为了更好的发挥早会的作用，并为了更好地跟踪项目进度，交付风险，团队统一了认识，即：任务并不是个人的最终交付物，而用户故事才是团队要交付的内容。每天的早会应该围绕着用户故事及用户故事中所涉及的内容，而不是独立的任务活动。因此，我们在第一个迭代的第一周结束就改变了我们的白板样式，把原来的任务活动变成了独立的栏目，使每个人都关注用户故事在白板上从左到右的流动速度。当然，也对用户故事进行了分拆，使大多数用户故事都可在一周内（不超两周）开发完成。

3、“完成”标准化、明确化

在第一个迭代的回顾会议上，大家发现了一个问题，即：每个人对每个活动的结束标准不一致，有的人认为自己在纸上设计好自己开发的用户故事后，就可以把它放到“编码”栏中了，而有的人则是写好的代码，才把用户故事从“设计”栏直接放到了“测试”栏中。为了能够让团队对协作过程达成一致，并明确每个阶段的完成定义（Definition of Done），团队把这些完成条件写在了各栏目之间，以使每个人在移动用户故事卡时都检查一下。

4、“潜在问题”可视化

与此同时，我们还在每个用户故事上记录了它在每个阶段停留的时间。经过一段时间，我们发现，即使不太复杂且比较小的用户故事在设计阶段的停留时间也显得有些长，但不知道到底是什么原因。于是，我就跟踪了其中的一个。结果发现，根据团队的规则，每个用户故事的设计完成条件是：设计好后需要发邮件，让团队review，review后根据反馈意见进行文档修改，之后才能放到编码阶段中。看上去还挺正常，但出问题的做事的方式。首先，每个开发人员在自行设计时都会使用电子工具来画图，在画图中每个人都很想把各种框的位置放好看一点，这上面花了较多的时间。其次，反馈意见来以后，还要有意见确认，有的意见还不一致，要再召集讨论，然后再画图。其中的浪费非常明显。于是，我们决定：在设计阶段，当开发人员自己想好以后，可召集大家直接在白板前画草图讨论，讨论一致后，再根据一致意见，更新一下设计文档即算完成设计。这样就大大节省了在每个用户故事上不必要的浪费时间。

5、应用约束理论，发现瓶颈

根据原定流程，团队有一个code review的环节，这个环节被放在了“编码”阶段。这也导致用户故事在编码栏的时间过长，表现就是这一栏中经常会出来两个故事卡片上有同一个人的名字。于是团队决定把codereview单独放在一列中。紧接着发现，codereview这一栏目中总会堆积卡片。经过分析发现，开发人员一般在完成整个用户故事的开发以后才会做codereview，这导致一次review的代码过多，review困难，时间过长，反馈太慢。另外，由于大家都有开发任务在身，所以总是以自己的开发任务为高优先级。为了根本解决这个问题，团队制定了两条新的规则：(1)原则上每天都需要提交一次codereview，而不是等整个用户故事写好后再做。(2)code review的优先级原则上高于之前的步骤（编码和设计）。因为codereview更接近价值流的出口。这样一来，用户故事在codereview上基本不会停滞，所以，这一栏就又被从白板上擦掉了。

6、减少不必要的任务切换

随着开发的进行，功能越来越多。我们发现，测试环节中发现的问题也多了起来。然而我们采用测试用例先行的开发方式不应该引起这么多问题（即在写实现代码之前，对用户故事及相关功能的测试用例已经完成，并经过团队的review）。在回顾会议中，测试人员提到这一点时，说有时候明确的用例都无法测试通过。根据大家的意见，在白板上增加一栏，叫做“开发测试”，就是开发人员编码结束后，根据已写好的测试用例，要做明确地自测后，才能放到“测试”一栏。从这之后，一些很低级的缺陷就不会流到“测试”这个环节了，开发人员减少了不必要的任务中途切换。

7、拉响警报，限制“在制品”数量

当功能点开发过半以后，测试人员在回顾会议上提出，测试任务就越来越重。此时出现的现象就是在测试一栏中会堆积很多用户故事，等待被测试。而没有被测试验证通过，就不能算是完成。因此，即使开发工作进行得再快，也无法说“完成”。根据团队的讨论，采用了精益中“限制在制品”的概念，但并没有直接设定在测试栏中用户故事的数量，而是使用另一种方法，来达到类似的效果，即：每天早会上，大家会问测试人员是否能在当天测试完当前待测试的用户故事。如果完不成，则可以根据情况采用两个措施：（1）是否能找到外部资源，帮助完成测试；（2）如果不能，根据任务多少，停止部分开发活动，由开发人员帮助测试人员进行测试，条件是：开发人员不能测试自己开发的用户故事。

三、白板的演进只是冰山的一角

在白板的演进过程中，我们使用了一系列工具，包括价值流分析、“看板”工具、系统思考、“五个why”分析以及精益思想中的限制“在制品”等等。然而，并不是说，我们放弃了SCRUM中的那些实践（如迭代计划会议、站会、迭代演示、迭代回顾会议）。恰恰相反，对于白板的很多改进正是在这些活动中讨论并决定的，尤其是站会和回顾会议。

另外，团队还应用了很多其它实践，包括用户故事的细粒度拆分、相对估算方法、基于RAID的敏捷迭代计划、编写单元测试、从分支开发切换为主干开发、严肃的代码规范（如圈复杂度不得超过10，每个方法的代码不超过50行）、每日提交代码、测试先行方法、使用GIT版本控制工具提高效率等等。

四、收益

比原定计划完成了更多的功能点；该特性无需缺陷修复阶段，且产品测试没有发现缺陷；团队各角色合作顺畅，团队幸福感提升。

五、小结

老子云：“天下大事必作于细，天下难事必作于易”。SCRUM方法是一个简单易懂的软件开发框架，而“把简单的事做好”并不是一件容易的事情。只有理解了敏捷的价值观与原则，才能真正发挥作用，而“照猫画虎”，只能反受其累。同时，大型企业采纳敏捷方法时，也需要充分考虑“跨越鸿沟”时带来的风险，做好准备工作，否则可能会令员工士气低落。