我们的项目采用Scrum敏捷失败了

作者：蓝白云

首先告诉大家一个好消息，我们的项目采用敏捷Scrum进行X项目开发宣告失败，中途不得不转向传统过程。
为什么是好消息？我认为：失败是成功之母。没有失败就发现不到所隐含的实际问题，将实际问题解决才是成功的必经之路。如果第一次成功反而不正常，所以这次的失败是个好消息。
下面我将结合敏捷Scrum在该项目中应用失败的经验与大家分享。

引出实际的问题（也是现象）

1. 整个团队没有掌握敏捷Scrum。
2. 团队成员不知如何更好地划分User Stories。
3. 在需求分析阶段我们更多的是在争吵需求。
4. 我们对现有的持续集成工具了解甚少。
5. 我们没有用（自动）测试来驱动开发（TDD）的动力。
6. 开发过程中其他团队的人需要我们的帮助。
7. 领导们仍然在等待团队的开发进展汇报。
8. 缺乏有实践经验的Scrum Master的指导。

整个团队没有掌握敏捷Scrum

整个团队对敏捷思想还没有基本的了解，甚至还有很多人认为敏捷就是“裸奔”。有些误认为仅有状态墙就是敏捷了。
在X项目敏捷过程中，A同事问我Sprint是什么，Backlog又是什么，等等。
当然这是因为当时缺少敏捷培训所致。
我个人理解：敏捷就是在合理的时间内高质量迭代式地完成客户所需软件的开发过程，去掉多余的无实际意义的工件。而Scrum是敏捷过程的其中之一，它有一定的过程规范要求。

团队成员不知如何更好地划分User Stories

X项目团队成员缺乏搜寻User Story的能力。
由于接触敏捷时间不长，加上Scrum的Story又是项目中的重中之重。而如何搜寻User Story？一时也不知所措。
Story Point更加是雾里看花，越看越花。X项目1.2版本的Story Point基本上是拍脑袋拍出来的，对Scrum的Story Point理解不深没有掌握，所以拍出来的都缺乏实际意义。具有讽刺意味的是状态墙上的燃尽图走的是楼梯形。
推荐大家看《User Stories Applied》，目前只有英文版。

在需求分析阶段我们更多的是在争吵需求

在讨论需求时，我们开发人员一直都是在没有客户在场的情况下进行需求分析和争吵的。
A、B、C都是开发者。A认为x需求应该加入该版本，B认为y需求也应该加入该版本。C发言了，他提出z需求，而且他还情不自禁地说出了z需求如何实现的。C又认为A的x需求不合理，B认为C的z需求不合理。争吵中……
需求分析时，不是只听某个人的也不是只听领导的（领导有时也犯错），而应该是更多地听取客户（或者客户代表、产品代表）的声音。之所以敏捷Scrum中也把客户纳到软件开发团队中来的目的。

我们对现有的持续集成工具了解甚少

在X项目敏捷时误以为暂时没有持续集成工具我们也可以做到敏捷，然而结果就是失败。
持续集成就是每天晚上（充分利用工作以外的时间）自动编译连接和测试运行所有的模块，尽早地暴露出问题。
在X项目敏捷中都是手动地测试，每次要一起测试时都要重新搭建环境。测试验证效率低。
我了解到现有的CC.NET为免费的，但听说配置比较复杂。
不管工具怎样不方便，我们仍需要加快熟悉持续集成工具。

我们没有用（自动）测试来驱动开发（TDD）的动力

X项目敏捷时的误区：我们编写代码都是先编写好后再来手动地进行测试，没有真正用上TDD。
最大的原因就是大家都不知如何开始TDD，心存疑虑。
在X项目敏捷失败后，我初试一下TDD开发X项目命令行联想模块。现正在开发当中就已经感觉到TDD的好处。其中TDD步骤如下：
1、写一个测试程序。考虑一下你希望实现的操作（功能）要如何使用代码来体现。
2、尽快地让测试程序可运行。如果明显存在一个整洁、简单的解决方案（例如伪实现），那么就将其键入。如果这个方案需要耗费一分钟的时间，再仔细想想怎样才能几秒钟内就能运行通过。
3、编写合格的代码。将第2步的简单方案优化，消除先前引入的重复设计，使测试尽快通过。

开发过程中其他团队的人需要我们的帮助

A同事在进行X项目开发的同时又要支持M产品。B同事更加是忙不开，因为他比较热心，其他团队的人有问题就找他。
我们正在开每日15分钟例会，其他团队的某同事要求A帮忙定位一个问题。
正在开发中，一个电话过来需要参加一个会议。
同样正在开发中，一个使用X项目的用户打电话过来说，strstr函数是如何用的。-_-!
像这种被很多事情干扰的例子数不胜数，开发效率必受到影响，敏捷也许就是空谈。

领导们仍然在等待团队的开发进展汇报

我记得在X项目 V1R2的第1个Sprint中，同事A坚持认为要向领导们每周汇报开发进展。
他打心里上说不汇报，领导们不知道我们在做什么，做到什么程度了。当时我也当心领导们不知道如何看我们的状态墙而没有反对。
同事A在汇集进展时要向每个人问一问，而且还征求团队每个人的同意。这一搞下来1个小时时间整理不到10行的进展汇报。
建议领导们也应该参加敏捷培训。

缺乏有实践经验的Scrum Master的指导

在X项目敏捷过程中缺少这个角色。
假设对敏捷Scrum有着基本的认识和了解，也必须要有经验的Scrum Master来引导。因为他可以：
引导实践过程出现问题时如何解决。
引导我们什么时候该计划Sprint和如何计划。
引导我们什么时候该回顾Sprint和如何回顾。
引导我们如何找到真正的Story。
引导我们如何玩转敏捷Scrum。
引导我们不会走老路。