太多的敏捷開發項目失敗。這很難甚至精確地測量這么多的軟件開發項目失敗的次數，因為最終“完成”和發布，即便：

• 他們花了足夠長的時間來構建
• 構建的質量很差
• 構建的產品不是客戶所期望的的
• 構建的成本大大超出預期

多年來，我在多個不同的敏捷開發團隊工作過，同時也為一些敏捷開發提供咨詢和培訓。在這期間，我發現5個共同的問題，如果這些問題不被解決，就很可能會導致項目失敗。

1. 不是產品所有者

所有的事情，都可能會導致一個敏捷軟件項目的失敗，而不是一個正在開發的產品  的最終的決策者的人，是確保其（產品）消亡最快的方式。

如果你追隨Scrum的，沒關系，只管做你自己的Kanban style project 項目或者別的事;如果你想你的項目能取得成功，你需要能一個能多所開發的產品設定方向和做決定的人。

想想要改造一個廚房。如果你聘請了一堆的承建商進來，做各種各樣的工作，如：管道，木工，地板等，但你沒有一個人來決定實際完成的廚房看起來應該像什么樣，最終你將會得到一個亂七八糟的廚房。

[[72880]] 

少有的幾個承建商可能會足夠的聰明的，能找到正確的人以詢問應該做什么，但設計一個廚房需要的不僅僅是隨意的決定櫥柜放哪兒，而是需要更多。你需要的是有人能真正的提出符合實際的設計和愿景，并隨著工程的不斷推進能對愿景進行糾正，以避免問題的發生。

話費大量錢財重建你的廚房，看起來相當瘋狂，但不想在設計成品或者雇傭人員上投資任何時間和努力，已完成該項工程。

當然，日復一日，我在軟件項目中的確看到很多這樣的行為。我看見很多公司在敏捷開發上花費了大量的金錢，但并不會委任任何人成為正在建設的項目的真正的主人，并為它設置愿景。

2.沒有迭代

迭代是敏捷開發給軟件開發世界帶來的關鍵價值之一。

但什么是迭代呢？

你可能會認為，這意味著將你的項目分成兩個短周期或者迭代周期。雖然這樣做可以促進迭代開發，這并不意味著你是在使用迭代。

感到困惑了吧？下面就讓我們揭秘吧：

迭代的關鍵是在時間范圍內，一點點的開發一個產品。這將準確的，作為一個產品的演進來描述迭代過程中的商品。

無論你是否相信宏觀進化，微進化，或適應性是否是一個成熟的概念。進化背后的想法是事情隨著時間的推移逐漸被改變。由量變到質變。

試想一下，如果進化論是最“敏捷”軟件內置的方式工作，這將是多么的愚蠢。

試想一下，如果你是一條在大洋中游動的魚，并有一些自己的在出生時就有功能健全的腿的魚寶寶。然后，那些有腿的魚寶寶長大了，然后又有翅膀的魚寶寶。

[[72881]]

也許腿和翅膀并不會讓魚能活的更好，也沒有被恰當的設計，因為腿和翅膀的出現，不是隨著時間的推移因適應所做的改變，而是突然出現。

產品功能不應該以單一的短周期或迭代來建立。好比在單一的一代魚的身上出現退一樣愚蠢。

反之，功能應該隨著時間的推移和進化。某種功能不應被放入到某種單一的短周期或迭代，然后去實現。一種功能應該從小規模開始，并隨著時間的推移進行進化和開發收到反饋，客戶或者產品所有者試圖將其開發出來。

太多的時候，我看到敏捷開發的項目進行了錯誤迭代和迭代開發產品。

不要試圖發送一次完成的功能，而是讓它隨著時間的推移來完成。

當你訂一塊牛排的時候，服務生問你的第一件事是什么？

顯而易見，他們問你你想如何完成它。

如果廚師不知道你想要完成的牛排的制作標準，廚師就必須決定他或她的制作標準是什么。

[[72882]] 

你可會得到一個完美的牛排，或者一個讓你難以置信的牛排，或者介于兩者之間，完全取決于為你烤制牛排的人。

這不是一個烤制牛排的好方式，同樣也不是制作軟件的好方式。

在大多數軟件項目中，我經常遭遇到大量的在烤制時沒有定義的牛排。積壓工作當時間耗盡的時候，經常被“做”。

對于一個敏捷開發團隊，做任何積壓工作有一個明確的標準是相當重要的。

這意味著，產品所有者應該定義一些可接受性測試。測試是手動測試還是全自動測試沒有關系，與團隊指定的標準是否能達到其測試目標有關。

缺乏標準，好比父母對孩子所提的問題“我應該吃多少豆子？”時所做的回答：“吃飽就行”一樣。

沒有制定標準會導致負面情緒，并為什么在手指指向的方向沒有做正確的事。

我發現，如果你詳細的告訴某人你對他的期望是什么以及評判的標準是什么，你將會比僅僅分配給他們任務得到更好的結果，牽著他們的鼻子說，“好好干。”

5.不要為了團隊而建立團隊

團隊是一個奇怪的組織，特別是敏捷團隊。

有很多的變數，會影響到團隊的行為和交互。有太多的方式組建一個健康的團隊，亦有很多方式創建很爛的團隊。

一個健康積極的團隊具有協同作用，一個不健康的消極團隊比其團隊成員各干各的好不了多少。

關鍵是有一個健康的團隊，能讓每個團隊成員都變得很自主。無論你的政見如何，你也許會同意以下觀點，當一個國家入侵另一個國家，并建立了一個并非由公民選舉的政府來管理人民，肯定有問題的。

同樣的問題發生在敏捷開發過程中。

我并不是說團隊不應該有責任制。但如果你想以敏捷的方式管理一個軟件項目，你必須讓團隊在達成共識的基礎上自我組織以及自我管理。

當團隊老大總是監督和干擾的話，團隊互動變得非常困難。

自然而然的，團隊時常有他們自己的開發節奏，領導力和角色（稱之為準則）。

然而，當外部力量直接干擾團隊工作時，他們沒有權力決定他們自己的命運，團隊成員就會開始意識到他們需要好自為之。

額外的敏捷開發資源

我發現在這些議題中發現好的資源是相當困難的，但這里有一些書，我發現了一些和我上面描述的有用的期刊的地址。

• Succeeding with Agile: Software Development Using Scrum-這本書專注于Scrum 但它同樣適用于不同種類的敏捷項目。 Mike Cohn和我時常在大部分敏捷主題上達成一致。
• Agile Retrospectives-我發現這本書對于團隊回顧能得到啟發，這些想法將真正有助于打破障礙，幫助團隊解決他們自身遇到的問題。
   
• Scrumban 和 Kanban and Scrum - 兩本書都提供了豐富的信息，關于combining Scrum and Kanban以及對于解決上述提到的問題，提供了好的解決方案。

你認為如何？我錯過了任何的敏捷項目真兇？與他們打交道的任何有用的提示？

讓我們從下面的評論中尋找答案。

英文原文：5 Things That Will Make Your Agile Development Project FAIL