失败的敏捷项目

作为敏捷专家，我们热衷于谈论在项目上取得的成就，却很难做到对失败直言不讳。Robin Dymond 在“一个失败的敏捷项目”这篇文章中谈到了有关失败的话题。

Robin 的文章中谈到一个替换内部现有流程的例子，从任何角度看这个项目都应该成功：

• 实施基于现有的商业软件（COTS， Commercial Off The Shelf Software）
• 产品负责人对现有流程有着深入的了解
• 团队成员具有在商业和敏捷项目实施上的成功经验
• 资深敏捷教练曾与该组织有过广泛的合作
• 3 个大型的咨询公司为团队成员提供产品方面的知识

第二个迭代结束时，事情开始变坏。产品负责人怀疑 COTS 工具能否完成任务。在第三次迭代过程中，业务用户试用软件的反馈普遍都是负面的。因为不具备长远的眼光，产品负责人被撤销了。 Elizabeth Hendrickson 曾说过“在第三次迭代中，如果所有用户的反馈都是负面的，应该取消这个项目或者重新仔细规划。”

Rpbin 认为，在项目开始之前，这次失败就已埋下了伏笔：

立项: 项目由 IT 总监和运营总监一起推动。现有的业务并没有成为驱动这个项目的动力，其流程也不需要进行改进。平台选择: 选择新平台的驱动力在于，大家确信基础设施需要从原有的定制系统转向商用软件。……应用系统在项目开始之前就已经选定了，没有人试过它是否能满足需求。而且，团队开始使用这个应用系统时，才发现它的能力非常有限，业务用户们使用起来也非常痛苦。而总监拒绝承认这些数据。

Allan Shalloway 认为这个项目的问题在于：“没有真正的用户认可，只是业务负责人说要这么做”。在 Allan 和团队建议取消这个项目数月之后，他谈到这个项目的失败原因：

根据我的经验，许多 Scrum 项目并没有真正按照 Scrum 的要求实施。每当我们去帮助或训练这些团队时，他们都会说自己已经有多少个月的 Scrum 实施经验。一旦问到他们真正在做什么，就会发现这些并不符合 Scrum 的要求。

此后 Allan 指出，他看到很多团队都对 Scrum 的原则缺乏清晰的理解：

• 一次只着眼于一个产品
• 让团队把关注点集中在业务价值上
• 拥有强有力的业务出资人支持
• 让团队的工作针对故事进行
• 清晰定义“完成”对于团队的含义
• ……

最后 Robin 描述了他登山的经验，他谈到加拿大的阿尔卑斯俱乐部有一本刊物——《阿尔卑斯意外事故月刊》。这本杂志记录了登山发生的意外事故，可以让其他的登山者们认识到什么地方出了问题，如何摆脱危险，以及事故发生的经过。Robin 认为我们也需要这样的月刊：“每天都有数十亿的资金耗在这上面，跟其它行业相比，软件项目存在惊人的高失败率，难道我们不应该正式地记录和分析这些失败吗？”

查看英文原文： Failures in Agile Develoment

InfoQ 的读者 Joakim Holmbäck 在评论中认为：

识别项目中的失败之处并从中吸取教训，是改进流程的关键。我也同意我们应该（更多地）讨论失败的敏捷项目，但是文中的例子并不恰当。 文中的敏捷过程显然起到了作用。在第一个迭代中，COTS 软件就被证明是不合格的了，产品负责人被替换也证明了这一点。项目失败的唯一原因，是管理层不能听从项目团队的建议。

不管使用什么样的项目管理技术，发生类似的事情总是会失败的。

读者 Julian Browne 提到：

在深水潜水社区中，有一个常用的时间：任何发生的小事故都会被公布出来，防止再度发生。British Sub Aqua Club 会发布年度报告，供大家认真研读。 不考虑故事中的敏捷因素，我觉得其中缺少了解决问题——而不是实施解决方案——的上佳实践，记录并共享失败项目的教训就是其中之一。

不幸的是，很多（绝大多数）失败的信息都被限制在商业组织之内，而且这样的信息很少能被泄露出来。我们只能自己进行项目实施后的复查，这个主意不错，但是通常都执行不好。

针对文末的问题，Mark Levison 公布说他开始准备收集整理《敏捷与 Scrum 失败月刊》，并希望大家提供素材，网址是： http://www.notesfromatooluser.com/2008/07/journal-of-agilescrum-failure.html。针对 Joakim 的说法，他认为：

还能有什么其他失败的原因么？Jerry Weinberg 说过：“总是人的问题。”我想所有失败的项目到最后都能归结到人和沟通的问题上去。我倒想看看有没有能够证明我错误的例子。

针对 Julian 的问题，Mark 认为，既然现在市场上有如此多的教练和培训师，从他们那里一定能够得到很多失败的例子。

而 InfoQ 资深编辑 Deborah Hartmann 对 Mark 的做法表示赞赏，同时她也向读者征求失败的案例，供未来的“理解”练习和研究使用，其网址为 http://www.m3p.co.uk/blog/2008/04/14/what-is-going-on-out-there-a-narrative-inquiry-project/。

面对 Mark 的质疑，读者 Joakim 这样回应：

虽然总是可以归结到人的问题上，Scrum 项目的任务失败还是会有 N 多种原因。上文中提到的失败，主要是由于管理问题：产品负责人被去掉了，而且团队的看法也没有人注意。（一个敏捷项目具备成功的所有要素，还是会失败；这看起来还是挺有意思的。） Scrum 团队失败的其他原因：

- 依赖其他 Scrum 团队（scrum 构成的 scrum 不能正常运作，每个 scrum 的日程不同）

-“完成”的定义没有正确使用
- 故事太大太长
- 团队不具备完成手上任务的技术能力
- 团队的故事组织有问题，每个成员处理自己的故事，但是故事之间互相依赖
- 团队不愿意做正确的回顾活动，因此很难进行改进