如何把敏捷思想融入到瀑布式開發環境中(3)

　　神話1：敏捷關注人/傳統的項目管理是命令和控制式的。

　　從事越來越復雜的咨詢和系統設計項目工作6年后，我發現自己管理別人做技術工作的時間多于我自己做設計網絡工作的時間。2000年，Cisco公司的一位銷售代表告訴我，我在做的事情實際上應該算是項目管理。我在2001年通過了PMP考試，現在成了“正式的”項目經理。

　　在接下來的幾年里，我使用順序式的方法，管理了大大小小很多個項目。正如古語所說，“當你只有錘子時，你就會看什么都像是釘子”。幸運的是，我這些項目都很適合順序式的模型。我經常負責在華盛頓西雅圖的Fred Hutchinson腫瘤研究中心新建筑項目中的IT工作。這些建筑物不僅要安裝重要的網絡基礎設施和服務器，也要安裝高度敏捷的技術醫療設備，在設備安裝時往往并不需要我的幫助。這些項目工作是由建筑物的施工進度驅動的，是一個非常有序的過程。

　　在2005年，建筑項目放緩了，我開始做更多的軟件項目。與建筑項目不同，軟件基本上是無形的。傳統的項目管理有一個未闡明的假設，它假設你一直可以看到一些東西，如地面上的大坑挖好了、地基打好了、鋼筋也鋪好了。軟件項目卻不是這樣。如果按順序的方法管理，軟件項目直到項目結束才能看到東西。當項目結束時，你指望所有的事情都做好了軟件就能運行。但是你用這種方式管理過軟件項目的話，你就知道這是行不通的。

　　經歷過一次特別沮喪的項目失敗后，我對軟件項目的發展趨勢作了廣泛的研究，我覺得Scrum Master課程對我會有比較大的幫助。碰巧Ken Schwaber(Schwaber，Scrum.org，2010)當時在西雅圖授課。在Scrum Master課程中，我學到了與結構化的軟件項目完全不同的管理方式，這種方式使人們能接受變更，并能隨時清楚地顯示項目進展，即使像軟件這種無形的產品也不例外。并且我發現，它潛在的哲學更有趣。

　　圖 3

　　我一直采用服務型領導的方式管理項目。我是技術人員，但我也知道，致力于具體的數據庫、網絡、程序語言的研發人員，對技術領域的了解遠勝過我，他們知道怎樣才能把工作做好。作為項目經理，我的工作是幫他們把工作需要的知識組織起來，使之可管理并能匯報給老板和管理層，消除障礙，識別可能發生的風險，讓他們能消除或減輕風險。我總是竭盡所能來幫助項目中的技術人員，讓他們可以自由地去做自己最擅長的事情，而不用被雖有必要但卻會打擾工作的項目預算、報告項目狀態等其他事情干擾。Scrum也分享了這個觀點。像“雞”和“豬”(Schwaber & Sutherland，2010)，由被激勵的個體來建設團隊，并相信他們可以做好工作、可以自組織、以平衡的速率工作，這些都表明了對人的持續的關注。

　　神話2：項目不是敏捷模式就是瀑布模式，沒有中間地帶。

　　既然我們已經解開了管理風格和交付方式的謎團，接下來我們再講一下關于二元決策方法的神話。Robert K. Wysocki定義了項目交付物的五種離散的模型(Wysocki，2009)。Chri Ward和Leonardo Legorreta對Wysocki的模型進行了改進(Legorreta，2009)。

　　Wysocki和Legorreta定義的項目管理的五種類型是：

　　瀑布式

　　迭代式

　　增量式

　　自適應式

　　探索式

　　根據我的經驗，自適應式和探索式的方法大致相同。大多自適應的方法都允許范圍變更(隨時可以向backlog增加故事卡片)，區別僅僅是理論在現實生活中的一些不同。所以在此次討論里，我把這兩個模型合為一個，稱為敏捷。

　　順序式——順序式模型是用于中小型項目交付物的傳統方法。項目工作可以按此順序進行：明確項目目標、確定項目范圍、做總體的項目計劃、開發、測試、部署。這個模型適用于：小型或中型的、工作成果可以一次性有效地交付、需求非常清楚、不產生變更(如來自政府或行業法規要求的需求)的項目。

　　增量式——增量式模型是一種特殊的順序式模型，只是它能夠按階段或者以迭加的方式交付成果。就像順序式模型，增量式模型先確定了項目范圍并提前做好計劃，因此它最適合需求明確而且不易發生變更的項目。在每個增量中，團隊可以選擇怎樣工作來滿足交付要求，但不會討論“做什么”和“為什么做”。

　　迭代式——迭代式模型與“提前做好計劃”的順序式模型、增量式模型相反。大多迭代模型實際上是迭代和增量。在迭代式模型中，隨著項目的進展，項目計劃也按迭代逐步細化。項目初期會為整個項目做高層次的計劃，但是計劃的粒度比較粗且常會變更。人們只對即將要做的工作做詳細的計劃。通常只對1周到1月內的短期工作做詳細計劃，其它的工作以后才會做詳細計劃。迭代式模型采用了增量式模型中延期規劃的方法，并且從精益概念中借用了盡快交付的概念：盡可能晚做決定、根據流程工作(Womak & Jones，1996)。在增量式敏捷的工作中，團隊從項目發起人和/或客戶那里獲取工作內容。在每次迭代中，團隊既可以選擇如何工作來滿足交付需求，也會詢問發起人或者客戶要做什么事情。我們可以根據發起人和/或客戶的輸入來調整工作的優先級，完成更重要的功能特性，滿足客戶的交付要求。不過所有要求的特性(由于監管或遵從)最終都將被交付。

　　敏捷式——敏捷式模型允許在每次迭代開始時添加或移除工作范圍。在敏捷項目中，需要客戶經常反饋，以確保功能特性是按照對客戶具有最高價值、對客戶最有益的順序交付的。此外，來自產品負責人或客戶的任何新的想法都可以加入到backlog中。經常展示可運行的軟件，其作用就如同 Heisenberg的“測不準原理”——測量的結果會影響測量(Cassidy，2002)，所以，看到的可運行的軟件也會影響客戶的需求，讓客戶產生新的更好的想法(Barry Boehm有一個首字母縮略詞：IKIWISI-雖然我不知道我要什么，但是“當我看到了我就知道了”)。有的項目問題很復雜，甚至早期對問題都還沒完全理解，這時去理解解決方案就更難了，因此對這類項目需要采用敏捷靈活的流程。

原文轉自：http://www.kjueaiud.com