太多的敏捷开发项目失败。这很难甚至精确地测量这么多的软件开发项目失败的次数，因为最终“完成”和发布，即便：

他们花了足够长的时间来构建

构建的质量很差

构建的产品不是客户所期望的的

构建的成本大大超出预期

多年来，我在多个不同的敏捷开发团队工作过，同时也为一些敏捷开发提供咨询和培训。在这期间，我发现5个共同的问题，如果这些问题不被解决，就很可能会导致项目失败。

1. 不是产品所有者

所有的事情，都可能会导致一个敏捷软件项目的失败，而不是一个正在开发的产品 的最终的决策者的人，是确保其(产品)消亡最快的方式。

如果你追随Scrum的，没关系，只管做你自己的Kanban style project 项目或者别的事;如果你想你的项目能取得成功，你需要能一个能多所开发的产品设定方向和做决定的人。

想想要改造一个厨房。如果你聘请了一堆的承建商进来，做各种各样的工作，如：管道，木工，地板等，但你没有一个人来决定实际完成的厨房看起来应该像什么样，最终你将会得到一个乱七八糟的厨房。

少有的几个承建商可能会足够的聪明的，能找到正确的人以询问应该做什么，但设计一个厨房需要的不仅仅是随意的决定橱柜放哪儿，而是需要更多。你需要的是有人能真正的提出符合实际的设计和愿景，并随着工程的不断推进能对愿景进行纠正，以避免问题的发生。

话费大量钱财重建你的厨房，看起来相当疯狂，但不想在设计成品或者雇佣人员上投资任何时间和努力，已完成该项工程。

当然，日复一日，我在软件项目中的确看到很多这样的行为。我看见很多公司在敏捷开发上花费了大量的金钱，但并不会委任任何人成为正在建设的项目的真正的主人，并为它设置愿景。

2.没有迭代

迭代是敏捷开发给软件开发世界带来的关键价值之一。

但什么是迭代呢？

你可能会认为，这意味着将你的项目分成两个短周期或者迭代周期。虽然这样做可以促进迭代开发，这并不意味着你是在使用迭代。

感到困惑了吧？下面就让我们揭秘吧：

迭代的关键是在时间范围内，一点点的开发一个产品。这将准确的，作为一个产品的演进来描述迭代过程中的商品。

无论你是否相信宏观进化，微进化，或适应性是否是一个成熟的概念。进化背后的想法是事情随着时间的推移逐渐被改变。由量变到质变。

试想一下，如果进化论是最“敏捷”软件内置的方式工作，这将是多么的愚蠢。

试想一下，如果你是一条在大洋中游动的鱼，并有一些自己的在出生时就有功能健全的腿的鱼宝宝。然后，那些有腿的鱼宝宝长大了，然后又有翅膀的鱼宝宝。

也许腿和翅膀并不会让鱼能活的更好，也没有被恰当的设计，因为腿和翅膀的出现，不是随着时间的推移因适应所做的改变，而是突然出现。

产品功能不应该以单一的短周期或迭代来建立。好比在单一的一代鱼的身上出现退一样愚蠢。

反之，功能应该随着时间的推移和进化。某种功能不应被放入到某种单一的短周期或迭代，然后去实现。一种功能应该从小规模开始，并随着时间的推移进行进化和开发收到反馈，客户或者产品所有者试图将其开发出来。

太多的时候，我看到敏捷开发的项目进行了错误迭代和迭代开发产品。

不要试图发送一次完成的功能，而是让它随着时间的推移来完成。

3.没有将事物分解的足够小

对于将事物分解成小的、易接受的块，我是坚定支持者。

为什么如此重要的一个主要原因，是这样做可以避免延期。

延期经常发生在当我们对大型的可能困难的任务感到畏惧的时候，或者我们不知道接下来该做什么的时候。

如果你能将大项目分成很多小块，这将使项目看起来很容易完成，并有一个明确进展步骤。

我经常看到，没有给之前的软件项目考虑足够的工作，人为的创造了积压工作或工作项目。

我创造了一个长期的积压类型：fatlogs。Fatlogs积压没有分解成足够小，并且经常对于要完成什么非常模糊。

当试着理解和解释他们的时候，Fatlogs是出了名的难以估算和浪费时间。关键是fatlogs被分解成更小的可操作的积压工作给敏捷开发团队或大量的时间将被浪费。

很多时候，我发现fatlog 的创造者可以很容易的将工作分成小的易于解释和理解的积压工作，即使对于软件开发知之甚少。

我时常建议敏捷开发团队，他们应该彻底拒绝fatlogs 并将其送回到某条链上。

如果你不能花足够的时间来清楚地说明你想要什么，那么它就没那么重要。

但这也不足以豁免开发团队。 开发团队应该将他们得到的任何积压工作分解成小块任务。

4.没有设置标准

当你订一块牛排的时候，服务生问你的第一件事是什么？

显而易见，他们问你你想如何完成它。

如果厨师不知道你想要完成的牛排的制作标准，厨师就必须决定他或她的制作标准是什么。

你可会得到一个完美的牛排，或者一个让你难以置信的牛排，或者介于两者之间，完全取决于为你烤制牛排的人。

这不是一个烤制牛排的好方式，同样也不是制作软件的好方式。

在大多数软件项目中，我经常遭遇到大量的在烤制时没有定义的牛排。积压工作当时间耗尽的时候，经常被“做”。

对于一个敏捷开发团队，做任何积压工作有一个明确的标准是相当重要的。

这意味着，产品所有者应该定义一些可接受性测试。测试是手动测试还是全自动测试没有关系，与团队指定的标准是否能达到其测试目标有关。

缺乏标准，好比父母对孩子所提的问题“我应该吃多少豆子？”时所做的回答：“吃饱就行”一样。

没有制定标准会导致负面情绪，并为什么在手指指向的方向没有做正确的事。

我发现，如果你详细的告诉某人你对他的期望是什么以及评判的标准是什么，你将会比仅仅分配给他们任务得到更好的结果，牵着他们的鼻子说，“好好干。”

5.不要为了团队而建立团队

团队是一个奇怪的组织，特别是敏捷团队。

有很多的变数，会影响到团队的行为和交互。有太多的方式组建一个健康的团队，亦有很多方式创建很烂的团队。

一个健康积极的团队具有协同作用，一个不健康的消极团队比其团队成员各干各的好不了多少。

关键是有一个健康的团队，能让每个团队成员都变得很自主。无论你的政见如何，你也许会同意以下观点，当一个国家入侵另一个国家，并建立了一个并非由公民选举的政府来管理人民，肯定有问题的。

同样的问题发生在敏捷开发过程中。

我并不是说团队不应该有责任制。但如果你想以敏捷的方式管理一个软件项目，你必须让团队在达成共识的基础上自我组织以及自我管理。

当团队老大总是监督和干扰的话，团队互动变得非常困难。

自然而然的，团队时常有他们自己的开发节奏，领导力和角色(称之为准则)。

然而，当外部力量直接干扰团队工作时，他们没有权力决定他们自己的命运，团队成员就会开始意识到他们需要好自为之。

额外的敏捷开发资源

我发现在这些议题中发现好的资源是相当困难的，但这里有一些书，我发现了一些和我上面描述的有用的期刊的地址。

Succeeding with Agile: Software Development Using Scrum-这本书专注于Scrum 但它同样适用于不同种类的敏捷项目。 Mike Cohn和我时常在大部分敏捷主题上达成一致。

Agile Retrospectives-我发现这本书对于团队回顾能得到启发，这些想法将真正有助于打破障碍，帮助团队解决他们自身遇到的问题。

Scrumban 和 Kanban and Scrum - 两本书都提供了丰富的信息，关于combining Scrum and Kanban以及对于解决上述提到的问题，提供了好的解决方案。