動起來再調整 - 向項目經理推薦敏捷

作者: 大衛張  來源: 博客園  發布時間: 2011-07-03 10:55  閱讀: 2229 次  推薦: 0   原文鏈接   [收藏]  
摘要:敏捷開發在中國很火熱,但大家怎么用好敏捷開發?今天的新手軟件項目經理應該了解敏捷如何用好。

  要成為一個好的項目經理需要學會逆水行舟。雖然順水推舟有時也能到達目的地,但學會逆水行舟,你才能到達任何地方。

  “雖然很有道理,但我認為現實不允許,很多項目都有規定的期限。中途還有給客戶演示效果,往往實際項目中都是按最后上線日期來進行項目規劃管理的。”

  “寫得不錯,但是有些建議過于理想化了。畢竟說得很有道理,但實際中具體做起來又不是那么一回事了。”

  這是兩位網友對《軟件項目經理新手上路》的評論。這話很有道理,也是在現實生活中碰釘子碰出來的。在項目中確實存在很多限制,我們應該順應限制,順水推舟,否則會很難看。但如果這些限制間存在矛盾的話,如何能夠做到順水推舟呢?例如,項目資源限制與最后期限限制的矛盾。

  1. 向項目經理推薦迭代

  例1:項目經理張三到了一個新公司帶一個項目。客戶、產品、團隊、流程、制度、環境、領導,一切的一切對于張三都是全新的。

  例2:開發人員張三因為優異的工作表現被提拔成項目經理。雖然張三對于項目中的業務、技術、產品和團隊成員都比較熟悉。但是項目經理是一個全新的視角,張三需要從一個全新的角度去看待和處理問題。

  公司領導找到張三談話,明確提出了項目的最后期限,希望張三能夠給出一個計劃。張三應該怎么辦呢?

  雖然上述兩個案例比較極端一點,但是在接手項目的時候存在幾種未知情況是很常見的事情。在前面的建議中我們談到了項目經理要承認有所不知,同時盡可能在公司內尋找一位項目經理導師。但這還不夠,在應對項目的實際情況時,推薦采用迭代。

  迭代的時間一般是一到三周比較好。即使你的項目只有兩周,也推薦分為一周的兩個迭代。應該在項目經理導師的指導下,將需求劃分到迭代中。每個迭代都應該像一個真實的項目,包含從需求到測試再到發布的全過程。

  2. 迭代的優點和注意事項

  麻雀雖小,五臟俱全,子項目也是一個完整的項目。以半年的項目為例,三周一次迭代,就能變成八個子項目,兩周一次迭代,就是十二個子項目。

  無論你是新手項目經理,還是對項目本身情況不夠了解的項目經理,你都可以從迭代中獲得如下好處。

  2.1 好處:咱輸得起

  分成迭代的第一大好處就是咱輸得起。如果一個項目只有一次實施機會,如果完成的不好,就只有完蛋。而換成迭代后,一個迭代完成的不好,咱輸得起,下個迭代想辦法追回來。

  2.2 好處:先動起來

  相比以前漫長的計劃協調、需求調研、可行性分析等等過程,迭代讓你能夠快速啟動項目。專注于第一個迭代的目標,從而很快就能有產出。

  2.3 好處:暴露問題

  對一個項目而言,其實很難完全預測問題會出現在哪里。是團隊人際關系、設計開發能力、刁鉆的客戶、資源不足,還是其他問題?要預測全部問題并給出完美的答案解決是幾乎不可能的。而迭代能夠幫助暴露這些問題,不需要老是拍腦袋,投入資源去處理可能根本就不會發生的風險。

  咱輸得起,畢竟只是一個迭代嘛。項目的大問題就這樣變成了迭代中的小問題,而項目經理經常處理這些小問題,經驗就積累起來了三。

  2.4 好處:快速積累經驗

  相比以前漫長的項目周期,迭代可以幫助你快速積累項目管理經驗。除了通過解決問題積累經驗外,還可以多做嘗試。既然咱輸得起,咱就敢在合適的情況下不斷嘗試項目管理的想法和做法,而不像以前必須對公司的標準做法生搬硬套,以便在項目失敗后少被挑刺。

  2.5 好處:輔助溝通

  領導愿意在有產出的項目上繼續投入,卻不愿在項目早期花太多時間給你磨嘴皮討價還價。第一個迭代的產出可以幫你大忙。領導你看,我們的產出是這些,但是還有些困難,是不是幫解決下呢?這個時候領導也會變得好說話些。客戶也一樣。人皆如此,要創造錦上添花的機會,別老是叫別人雪中送炭,很辛苦的說。(至于給領導的計劃,就告訴他在用敏捷,然后給一個分迭代的計劃就好。)

  2.6 好處:持續成長

  每一個迭代都會有收獲、有產出,而下一個迭代會建立在上一個迭代的基礎上。在這個過程中,你、團隊、技術、業務、流程等都可以持續成長。

  2.7 注意事項

  全講好處了,你心動了沒?要使用迭代還是有些注意事項的。迭代需要改變一次性完成的設計和開發方式,并且在后期回歸測試的工作量會明顯增加。需要在項目經理導師的指導下,引入對應的實踐逐步解決。(話說不用迭代,采用老方法,一樣有注意事項。)

  3. 繼續演化

  在確定了使用迭代后,需要從原有的整體需求中取出一塊作為迭代的需求;需要在迭代前召開會議,和團隊一起了解迭代需求,并制定迭代的開發計劃;每天早上和項目團隊一起開個會了解下有沒有問題,進展是否順利;在迭代結束時需要檢查迭代需求是否切實完成(通過測試并發布);在迭代結束后,舉行回顧會議,和團隊一起鞏固做得比較好的部分,對發現的問題需提出改進方案。

  也需要自己進行一下回顧,看下自己在這個迭代中哪些地方做得好,哪些地方還可以提高;哪些方法有用,哪些方法效果不佳,下次迭代采用什么方法;項目中還有什么問題,領導和客戶的反饋怎么樣;需要采取哪些措施,需要進行哪些溝通。

  這么一步步來,好像敏捷就不遠了。這不,除了角色和燃盡圖外,Scrum的其它要素就齊了。C項目就是這么一步步走過來的,雖然由于組織原因,C項目的敏捷實施并不完美。

  你是不是也想試試呢?(嘗試有風險,請在你的導師指導下進行,呵呵。)

0
0
 
 
 

文章列表

全站熱搜
創作者介紹
創作者 大師兄 的頭像
大師兄

IT工程師數位筆記本

大師兄 發表在 痞客邦 留言(0) 人氣()