失败的敏捷项目

作为敏捷专家，我们热衷于谈论在项目上取得的成就，却很难做到对失败直言不讳。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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14639675/viewspace-400065/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-400065/