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

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

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

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

前言

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

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

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

整个企业在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白板

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

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

?

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

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

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

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

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

四、收益

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

五、小结

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