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

• 他們花了足夠長的時間來構(gòu)建
• 構(gòu)建的質(zhì)量很差
• 構(gòu)建的產(chǎn)品不是客戶所期望的的
• 構(gòu)建的成本大大超出預(yù)期

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

1. 不是產(chǎn)品所有者

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

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

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

[[72880]] 

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

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

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

2.沒有迭代

迭代是敏捷開發(fā)給軟件開發(fā)世界帶來的關(guān)鍵價值之一。

但什么是迭代呢？

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

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

迭代的關(guān)鍵是在時間范圍內(nèi)，一點點的開發(fā)一個產(chǎn)品。這將準確的，作為一個產(chǎn)品的演進來描述迭代過程中的商品。

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

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

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

[[72881]]

也許腿和翅膀并不會讓魚能活的更好，也沒有被恰當(dāng)?shù)脑O(shè)計，因為腿和翅膀的出現(xiàn)，不是隨著時間的推移因適應(yīng)所做的改變，而是突然出現(xiàn)。

產(chǎn)品功能不應(yīng)該以單一的短周期或迭代來建立。好比在單一的一代魚的身上出現(xiàn)退一樣愚蠢。

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

太多的時候，我看到敏捷開發(fā)的項目進行了錯誤迭代和迭代開發(fā)產(chǎn)品。

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

當(dāng)你訂一塊牛排的時候，服務(wù)生問你的第一件事是什么？

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

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

[[72882]] 

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

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

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

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

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

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

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

我發(fā)現(xiàn)，如果你詳細的告訴某人你對他的期望是什么以及評判的標準是什么，你將會比僅僅分配給他們?nèi)蝿?wù)得到更好的結(jié)果，牽著他們的鼻子說，“好好干。”

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

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

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

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

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

同樣的問題發(fā)生在敏捷開發(fā)過程中。

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

當(dāng)團隊老大總是監(jiān)督和干擾的話，團隊互動變得非常困難。

自然而然的，團隊時常有他們自己的開發(fā)節(jié)奏，領(lǐng)導(dǎo)力和角色（稱之為準則）。

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

額外的敏捷開發(fā)資源

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

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

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

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

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