作為敏捷專家,我們熱衷于談論在項目上取得的成就,卻很難做到對失敗直言不諱。Robin Dymond在“一個失敗的敏捷項目”這篇文章中談到了有關失敗的話題。
Robin的文章中談到一個替換內部現有流程的例子,從任何角度看這個項目都應該成功:
實施基于現有的商業(yè)軟件(COTS, Commercial Off The Shelf Software) 產品負責人對現有流程有著深入的了解 團隊成員具有在商業(yè)和敏捷項目實施上的成功經驗 資深敏捷教練曾與該組織有過廣泛的合作 3個大型的咨詢公司為團隊成員提供產品方面的知識 第二個迭代結束時,事情開始變壞。產品負責人懷疑COTS工具能否完成任務。在第三次迭代過程中,業(yè)務用戶試用軟件的反饋普遍都是負面的。因為不具備長遠的眼光,產品負責人被撤銷了。Elizabeth Hendrickson曾說過“在第三次迭代中,如果所有用戶的反饋都是負面的,應該取消這個項目或者重新仔細規(guī)劃!
Rpbin認為,在項目開始之前,這次失敗就已埋下了伏筆:
立項:項目由IT總監(jiān)和運營總監(jiān)一起推動,F有的業(yè)務并沒有成為驅動這個項目的動力,其流程也不需要進行改進。
平臺選擇:選擇新平臺的驅動力在于,大家確信基礎設施需要從原有的定制系統(tǒng)轉向商用軟件!瓚孟到y(tǒng)在項目開始之前就已經選定了,沒有人試過它是否能滿足需求。而且,團隊開始使用這個應用系統(tǒng)時,才發(fā)現它的能力非常有限,業(yè)務用戶們使用起來也非常痛苦。而總監(jiān)拒絕承認這些數據。 Allan Shalloway認為這個項目的問題在于:“沒有真正的用戶認可,只是業(yè)務負責人說要這么做”。在Allan和團隊建議取消這個項目數月之后,他談到這個項目的失敗原因:
根據我的經驗,許多Scrum項目并沒有真正按照Scrum的要求實施。每當我們去幫助或訓練這些團隊時,他們都會說自己已經有多少個月的Scrum實施經驗。一旦問到他們真正在做什么,就會發(fā)現這些并不符合Scrum的要求。 此后Allan指出,他看到很多團隊都對Scrum的原則缺乏清晰的理解:
一次只著眼于一個產品 讓團隊把關注點集中在業(yè)務價值上 擁有強有力的業(yè)務出資人支持 讓團隊的工作針對故事進行 清晰定義“完成”對于團隊的含義 …… 最后Robin描述了他登山的經驗,他談到加拿大的阿爾卑斯俱樂部有一本刊物——《阿爾卑斯意外事故月刊》。這本雜志記錄了登山發(fā)生的意外事故,可以讓其他的登山者們認識到什么地方出了問題,如何擺脫危險,以及事故發(fā)生的經過。Robin認為我們也需要這樣的月刊:“每天都有數十億的資金耗在這上面,跟其它行業(yè)相比,軟件項目存在驚人的高失敗率,難道我們不應該正式地記錄和分析這些失敗嗎?”
此文章共有2頁 1 2 下一頁
文章來源:中國項目管理資源網
|