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

　　每位項目經理都可以成功地將敏捷融合到瀑布式環境中，這樣可以提高項目的可預測性、提高成本效益，并促使項目最終獲得成功。

　　曾經項目管理人員認為敏捷只是一種時尚。敏捷宣言發表10年來，這種方法已經漸趨成熟：它已經從邊緣方法逐漸成為核心方法，并且從只應用于小型軟件公司，發展到已應用于大多數的企業組織。敏捷不是銀彈，它也需要適應復雜多變的企業環境。本文的目的正是要說明在企業環境里，項目經理怎樣才能成功地在項目中應用敏捷。

　　我認為敏捷方法最好用于管理產品，不過用于管理項目也很有效。只是項目經理必須理解三條關鍵原則，那樣才能充分發揮敏捷的力量，從而改善項目的交付成果。在本文中，我將討論并破除關于人們通常認為“項目不是敏捷模式就是瀑布模式”的兩個神話，再與大家回顧四種增量敏捷模型，并說明項目經理和其他特定的敏捷團隊負責人如何使用這些模型。最后，我會推薦一個三層嵌套的“信封”模型，講解在瀑布環境中，利用你對項目管理和產品管理的理解、結合你精心選取的管理方法，如何使用信封模型來管理敏捷項目。項目經理大可放心，在敏捷項目里他們的作用非常重要，不僅如此，對于大型項目的成功，他們也是必不可少的。

　　介紹

　　今年人們慶祝了敏捷宣言發布10周年。在這十年間，敏捷從項目管理界中的無名小卒發展成了主流的方法。2009年，在Version One的敏捷調查中，有84%(Version One，2009)的調查對象表示，他們在某種程度上使用了敏捷。2010年，這個數據躍至90%(Version One，2010)。然而，對許多企業高管、總監和經理來說，敏捷仍然讓他們感到困惑、模糊并且不可信。

　　理解以下三條關鍵原則，每位項目經理就都可以在瀑布環境中成功地融合敏捷的價值準則和實踐，從而提升項目的可預測性，促使項目最終獲得成功：

　　敏捷不是用于PMI所指的那類項目的

　　敏捷中的計劃工作，是一系列連續的步驟，沒有明確的界限劃分

　　混合使用敏捷方法和瀑布方法

　　在繼續講解前，我先介紹一下本文內容所基于的情境。我定義了兩種企業類型：軟件公司(獨立軟件供應商)和“其他公司”。由于敏捷方法能較容易地適用于“軟件公司”，本文的重點放在如何在“其他公司”中使用敏捷方法。

　　軟件公司的主要產品是軟件，或者其產品的主要交付渠道是軟件。按照這個定義，微軟和Adobe公司是軟件公司，亞馬遜和易趣也是軟件公司。我們之所以認為亞馬遜和易趣是軟件公司，是因為軟件是他們交付產品或服務的主要渠道。與這種軟件公司相對的是麥當勞和宜家?？梢钥隙?，麥當勞和宜家也使用軟件，但軟件并不是它們的主要產品，也不是它們產品或服務的主要交付渠道。當然，它們確有自己的網站，但麥當勞并不通過互聯網賣漢堡包。同樣，雖然你可以通過網站訂購宜家的產品，但是商店才是他們的主要售貨渠道。

　　有一種處于灰色地帶的第三類公司我也需要說明一下。這類公司在哪里都有一席之地。美國的銀行和保險公司大都是此類灰色地帶的公司。銀行和保險公司既可以算是軟件公司，也可以算是“其他公司”，這取決于他們的組織構成。如果企業按照產品或服務的業務線以水平形式構成，并且(或者)公司組織結構是由產品驅動的，軟件是其產品或服務的主要交付渠道，那它就是軟件公司。相反，如果組織結構基于工作職能劃分，以垂直形式構成，例如分為市場營銷、IT、和產品部門，那它就不是軟件公司。這聽起來很復雜，但在實踐中，用這個定義，簡單地確認公司中幾個特定角色和他們的權力范圍，就能較容易地判斷出這家公司是不是軟件公司。例如，如果公司有負責特定產品或服務的產品負責人，確認他的權力范圍，看他能否為產品做所有的決策：市場營銷決策、IT決策、網站用戶體驗決策等。如果產品負責人擁有對產品的所有控制權，并且能夠做出從概念到客戶的所有決策，那它就是軟件公司，在這種企業環境中，推行敏捷方法會很容易。要不然，它就是非軟件公司，想在這類非軟件公司成功實施敏捷就需要做很多工作了。本文的重點就在于如何在這類“非軟件公司”中實施敏捷。

　　敏捷不是用于PMI所指的那類項目的

　　根據美國項目管理協會(PMI)的定義：

　　項目是為了創造獨特的產品、服務或成果所做的臨時性工作。

　　2001年2月在美國Snowbird Utah舉行的軟件開發者大會上，人們第一次提出“敏捷”一詞。早期，敏捷只是指一些輕量級過程的集合，是針對那時更廣泛使用的“重量級的”(笨重的)方法的回應(Hunt 2010)。與會者制定并發布了敏捷宣言(Beck et al.，2001)，這成為為敏捷運動開始的里程碑。參加這次會議的所有人都是軟件開發人員。他們的關注點在于創建軟件產品，而不是項目管理過程。通過我的個人訪談(van Bennekum，Hunt，Cunningham，Schwaber， & Cockburn, 2010，2011)，我發現他們關注的是：重量級的過程無法適應網絡公司快速變化的特性，這種情況該如何應對。為軟件公司做開發工作時，人們永遠不會有軟件即將開發完成的想法。軟件項目經常會被改進、增強或以其他形式變更，而不像建筑項目或設計洗碗機這類項目。建筑物一旦建成，或者洗碗機一旦被設計出來并交付生產，項目工作就完成了。有可能你再去做內部改進(Interior Improvement，TT)項目或再設計新型的洗碗機，但是原來的項目仍然是完成了，要做的新工作是新的獨立的項目。

　　這與現行的產品管理的本質形成了鮮明的對比：

　　產品管理是控制產品從概念到推向市場或向客戶交付成果和服務的規程和業務流程，用以產生最大可能的商業價值。(Ebert，2009)

　　產品管理關心的是產品的整個生命周期：從概念、發展，直到廢棄。項目是關于創造事物的，當事物創造完成，項目也就結束了。項目不關心產品在整個產品生命周期的發展和改進。管理產品是敏捷能最有效地發揮作用的地方?；c兒時間思考一下敏捷的術語：產品負責人、產品需求列表、產品愿景、產品路線圖，所有這些詞語都關注于產品。敏捷實踐能適用于需求變化的情況，也同樣完全能夠適用于產品管理。當你得知你將有第二個、第三個甚至第二十個發布時，它也只是簡單地增加產品需求列表的范圍，你知道，通過這樣做，假以時日就能實現這些特性。而項目管理卻不同，項目需要嚴密地管理范圍、進度和預算，因為它們是結束項目的決定因素。

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