失敗的敏捷專案

作為敏捷專家，我們熱衷於談論在專案上取得的成就，卻很難做到對失敗直言不諱。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/，如需轉載，請註明出處，否則將追究法律責任。