在Scrum实施效果并不理想的企业推进敏捷实施(2)

　　减少不必要的任务切换

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

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

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

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

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

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

　　收益

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

　　小结

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

原文转自：http://letagilefly.com/post/2013/01/what-if-scrum-fails-10070.html