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

　　前言

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

　　然而，SCRUM的创始人之一肯. 施瓦伯(Ken Schwaber)在2009年的一篇博文上说：

　　“目前实施SCRUM的软件企业中，有75%企业可能无法得到它们想达到的效果。(I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.)”

　　这一点也得到了充分的 证实，因为随着越来越多的企业采纳该方法，负面的结果与声音也越来越多，尽管也有很多成功的案例在全球分享。

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

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

　　整个企业在2009年开始实施SCRUM，每个团队都在做SCRUM中规定的管理实践，而且建立了持续集成服务器，每天都可以定时构建，运行自动化测试。然而，每个产品在开发完成后，总是需要很长的时间修复缺陷，产品进度的可预期性不高。同时，还能看到肯.施瓦伯在其博文中提到的ScrumBUT症状，比如常常听到下面类似的说法：

　　每天站会开销太大了，我们每周做一次吧;

　　回顾会议太浪费时间了，所以我们不做了吧;

　　两个星期基本上什么也做不完，我们一个月算一次迭代吧;

　　经常来一些临时任务，所以总是完不成Sprint计划。

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

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

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

　　Team Lead：1人

　　Product Owner：1人

　　Architect：1人

　　Developer：5人

　　Manual Tester：1人

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

　　“似乎标准”的SCRUM白板

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

　　建立价值流导向的白板

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

　　“完成”标准化、明确化

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

　　“潜在问题”可视化

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

　　应用约束理论，发现瓶颈

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

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