(項目管理)敏捷項目管理

1、1.敏捷項目管理1.1. 敏捷軟件開發(fā)之項目管理1.1.1.軟件開發(fā)之項目管理項目管理是將知識、技能、工具與技術應用于項目活動，以滿足項目的要求。軟件開發(fā)項目的項目管理，是為了確保軟件開發(fā)項目順利進行的各種管理活動的總和。PMBOK ( Project Management Book of Knowledge)中將項目管理分為9大知識領域.整合管理.范圍管理.時間管理.成本管理.質里官理.人力資源管理.溝通管理.風險管理.采購管理至今為止，項目管理往往從這幾個方面制定計劃，在實施中，檢查計劃和實施效果的偏差，監(jiān)控項目的健康狀況。1.1.2.敏捷軟件開發(fā)之項目管理敏捷軟件開發(fā)的項目管理，是指在敏

2、捷軟件開發(fā)中進行的項目管理活動。敏捷軟件開發(fā)，如同第一章所述，是一種積極擁抱變化的開發(fā)模式。敏捷軟件開發(fā)認可并應對不確定性，換句話說，需要面對風險(根據PMBOK的定義，風險就是不確定性)。某種程度上，敏捷開發(fā)過程就是風險管理的過程。敏捷軟件開發(fā)的各種實踐方法(Practice)就是為了應對各種風險而存在。敏捷軟件開發(fā)的項目管理，其本質在于-平衡(Bala nee )為了提升透明度花費的 成本和因為可能發(fā)生變更而帶來 的風險。 敏捷項目管理中，開發(fā)流程的概念輕量且抽象。在日新月異的今天，開發(fā)流程本身的靈活性顯得非常重要。不是用 一個固定的流程來應對變更，而是根據不同環(huán)境不同需要裁剪開發(fā)流程。從

3、這個意義上來說，只定義必不可少的管 理內容的、輕量級的開發(fā)流程是順應時代需要的。如果只在傳統(tǒng)的 Paradigm 下解讀和裁剪敏捷開發(fā)的流程，就很容易忘記敏捷開發(fā)的本來意義，這是造成敏捷開發(fā) 失敗的一個主要原因。 對流程的裁剪， 一定要在正確理解敏捷項目管理的意義、 不抹殺“敏捷” 特性的前提下進行。1.2. 敏捷開發(fā)的可交付成果1.2.1.不事先規(guī)定可交付成果的細節(jié)敏捷軟件開發(fā)中，品質代表軟件與用戶需求的匹配程度。不事先規(guī)定可交付成果的細節(jié)是為了追求更高品質。因為 在開發(fā)過程中，需求可能發(fā)生變更，可交付成果的內容也可能隨之而改變。敏捷軟件開發(fā)的特征不僅僅在于能以較低成本應對變更，而是使軟件盡

4、可能具有應對變更的能力。敏捷項目管理的 假設是，某個項目難以用傳統(tǒng)的流程進行管理。即，Goal會隨著時間的變化而變化。因此，重點在于認識到可能發(fā)生變更的風險，提高應變能力。但是，通常情況下，人們認為如果可交付成果不斷變化，開發(fā)可能無法收尾。因此，敏捷項目管理把開發(fā)期間分解 成幾個短的區(qū)間，把每個短區(qū)間的可交付成果在一定程度上固定下來。在項目進展過程中，一邊聽取客戶反饋，一 邊調整可交付成果。可交付成果的靈活性要保持在多大程度？這個取決于流程的設計，是敏捷項目管理中非常重要的內容。1.2.2.可能發(fā)生變更，風險管理怎么辦1.2.2.1.What s Risk有可能發(fā)生變更的地方，就存在著各種各樣

5、的風險。風險是因為可能發(fā)生變更而造成的，所以無論用不用敏捷項目 管理，風險都是存在的。但是，采用敏捷軟件開發(fā)和采用傳統(tǒng)的瀑布式開發(fā)，客戶和開發(fā)團隊所承擔的風險是不同的。首先，傳統(tǒng)的管理方法是制定計劃，根據執(zhí)行結果和計劃之間的偏差來評估可交付成果?？墒且驗榭赡艽嬖谧兏?， 無法嚴密地定義可交付成果。因此，就出現了以下兩種做法：a）做各種假設，無論如何定義出可交付成果，決定金額和交貨期 b）雖然對可交付成果不是很清楚，但還是決定了金額和交貨期 采用方法a的話，變更帶來的風險由客戶承擔。即，如果假設和實際不相符，可交付成果和實際的業(yè)務需求就不一 致。采用方法b的話，開發(fā)團隊承擔仕樣變更的風險，因為一邊

6、要遵守金額和交貨期的約定，一邊還要完成可交付 成果的變更。一般來說，很難讓某一方承擔全部風險。通常的做法是采用折衷案。即，暫不考慮誰是誰非，客戶和開發(fā)團隊共同 承擔上述風險進行項目活動。敏捷軟件開發(fā)中，客戶和開發(fā)團隊要一起承擔變更可能性帶來的風險?？蛻粲胸熑谓忉屨f明并排序選擇軟件需求?？墒?，如果客戶不能從開發(fā)團隊得到有關項目進度的反饋，就無法做合適的判斷。這就是溝通上的風險。另外，事先沒有約定可交付成果的細節(jié)，因此，項目能夠在預算和進度要求內完成的保證就沒有了。開發(fā)團隊也要 充分了解這一風險，并作出應對。外包公司可能會盡可能降低成本，既滿足事先決定的交付期和可交付成果，又使計劃和執(zhí)行之間的Ga

7、p轉向有利于開發(fā)商一方，從而實現利益最大化。但是，敏捷軟件開發(fā)中，沒有事先約定可交付成果的細節(jié)，所以，很可能不 存在如上所述的提高利潤的空間。開發(fā)商如果采用敏捷軟件開發(fā)，就要認識到這樣的風險，同時最大限度地滿足客戶需求。1222 怎么降低風險因為可能存在變更，所以無論采用哪種項目管理方法，都必須承擔變更可能性帶來的風險。那么，敏捷項目管理的優(yōu)點在哪里呢？就在于敏捷項目管理能夠應對更多的、可能發(fā)生的變更。因為敏捷軟件開發(fā)本來就假設 軟件開發(fā)項目中有可能發(fā)生變更。因此，越是深刻理解敏捷軟件開發(fā)的本質，正確實踐，就越能以較少的成本應對可能發(fā)生的變更。與此相對的，瀑布式項目管理沒有做這種假設。從這一點

8、來看，熟練使用敏捷軟件開發(fā)，可以更迅速更安全地應對變更可能性帶來的風險。 更重要的是， 當使用敏捷項目管理時， 顧客和開發(fā)團隊之間的風險平衡 (Risk Balance )是 Win-Win 的合作關系。即，適應變更，擁抱變更的開發(fā)使客戶得到想要的功能，另一方面，開發(fā)團隊因客戶滿意而獲得更大收益。 與此相對，瀑布式項目管理在制定計劃時，顧客和開發(fā)團隊之間就形成了一種風險的交易( Tradeoff )。一旦發(fā)生 變更，顧客和開發(fā)團隊在誰承擔風險上很容易形成對立關系。這種對立關系潛在地增加了項目管理的難度。變更越 可能發(fā)生，項目管理就越難做。敏捷項目管理的 Point 在于顧客和開發(fā)團隊一起向一個

9、目標奮斗，即提供更能滿足用戶需要的可交付成果。消解了 對立關系，構筑了一種積極應對變更的合作關系。這一點，相對于傳統(tǒng)的項目管理來說，無論在合同方式，還是在 顧客和開發(fā)團隊間的角色扮演(責任分擔)上，都是一種激變吧！1.3.敏捷項目管理之估算敏捷項目管理中，計劃( Planning )非常重要。計劃之前，開發(fā)團隊要估算出任務的大小(size )。這和傳統(tǒng)的瀑布式項目管理究竟有何不同呢？敏捷軟件開發(fā)中，估算有兩個特征：一是以顧客能夠管理的需求為單 位進行估算，另一個是只需估算出需求的相對大小。關于這兩個特征，解說如下。1.3.1.以客戶能夠管理的需求為單位進行估算 第一個特征是要義客戶能夠管理的需

10、求為單位進行估算。雖然這并非是敏捷項目管理固有的東西，但對于敏捷項目 管理來說，至關重要。因為采用這樣的管理方法，顧客可以自主排序選擇需求。首先，敏捷軟件開發(fā)前，客戶有責任準備需求列表。當然啦，大多數情況下，由開發(fā)團隊幫客戶制作需求列表。但 開發(fā)團隊要認識到需求列表的制作和管理是顧客的責任。關于這種需求列表，每種開發(fā)方式都有自己的叫法，其中需求的粒度和表現形式也不同。例如， XP 中，有 Story 。 Scrum 中有 Product Backlog 。無論哪種，都是利害關系者期待的軟件功能( Feature )。以客戶能夠管理的需求為單位進行估算，其本質在于使客戶能夠判斷功能的優(yōu)先度，以決

11、定每次交付時，軟件需要 具有什么功能。1.3.2.只需估算出需求的相對大小 這里的估算并不是項目所需時間(人月)的估算。因為估算出來的累計時間，很可能因為人力資源等限制，會與實 際需要的時間大相徑庭。第二點，需求的相對大小是由經驗和感覺得來的，客戶比較容易理解，也比較容易操作。敏捷項目管理的前提是項目的不可預測性。因此，精細估算得來的計劃和概算估算得來的計劃，其精度差別不大 都是不確實的計劃。因此，與其在估算上花費成本，倒不如把側重點放在體制的整備上，以應對意外事態(tài)。敏捷項目管理中，以需求的相對大小為單位進行估算。這個單位在XP中稱作Story Point 。1.3.3.也有不能對應的不確定性

12、敏捷項目管理接受不確定性，需要時，可以調整估算值。但是，有時，估算階段的前提條件中，也有一些不得不確 定的要素。這些要素一旦變更，其變更成本往往不可接受。比較極端的例子，比如，一旦選定某種開發(fā)語言，就幾乎不可能再 變了。還有，架構的再構也是這樣。因此，事先必須詳細調查這些不可更改的因素。例如，多數情況下，開發(fā)團隊根據經驗定義非功能需求，整理出架 構的優(yōu)缺點，明確其適用范圍和潛在風險。1.4.敏捷項目管理之流程設計1.4.1.迭代( Iteration ) 敏捷項目管理的要點在于能夠設計出一個流程以平衡為獲取反饋所花費的 成本和獲得反饋給項目帶來的 好處 ?？蛻?從開發(fā)人員那兒得到關于可交付成果

13、的報告，并進行決策。該決策作為仕樣反饋給開發(fā)人員。然后，開發(fā)人員基于 該仕樣改進開發(fā)，并繼續(xù)向客戶報告結果。如此這般，客戶和開發(fā)人員一邊切磋琢磨，一邊做出更好的軟件。 敏捷軟件開發(fā)采用迭代( Iteration )管理開發(fā)項目工作。一個迭代，一般持續(xù)一周或一個月。迭代是分配任務和制 作可交付成果的管理單位。迭代的長度一旦決定了， 就不再更改。 即，迭代的長度是固定的， 不是由分配的任務大小決定的。 Scrum 使用 Rugby 中的術語，每個迭代被稱作一個 Sprint 。1.4.2.Time-boxTime-box 被稱作迭代背后的手。重視人與人之間互動的流程，往往會有規(guī)則不夠用的缺陷。這是

14、因為，這種流程 的重點在于協(xié)調以完成實際的工作，而不是遵守嚴密的規(guī)章制度。這種流程更接近于管理的本質，但是更難掌控。 激發(fā)創(chuàng)造力的交流是必不可少的，但有時候，用于調整的時間無限膨脹，甚至壓縮了做實際工作的時間。例如，長 時間的會議和辯論。的確，各種 Session 會給參加者帶來一定的滿足感，但也容易流于為會議而會議的形式主義， 或者帶來“開會就是完成工作”的虛假的成就感。更壞的情況時，如果掌控不好，會造成進度遲延、品質低下、以 及成本和回報的不平衡。那么，該如何解決這些問題呢？ 有一種方法，對各項活動設定了時間，并要求嚴守結束時間。即，終了時間必須結束，即使會議的預期可交付成果 還處于 In

15、 progress 的狀態(tài)，也要結束，這個預期的可交付成果會成為下一道工序的輸入。這種時間管理方法就叫 做 Time-box 。Time-box 的 Point 在于并不倉促得出可交付成果。而是按時間進入下一道工序，得到客戶反饋，再返回來，更好 地完成可交付成果(由此可見，項目真的是一種目標導向、結果導向的東西) 。重視客戶反饋的敏捷項目管理就采用了 Time-box ，按照定義好的時間，進入下個 Step 。1.4.3.任務管理1.4.3.1.把需求分配到各個迭代 需求是在迭代中實現的。在哪個迭代中分配哪些需求，一般是按照客戶設定的優(yōu)先度，從高到低地實施。 實際操作時，因為需求的大小不同，而

16、迭代的長度是固定的，所以無法完全按照優(yōu)先級實施。另外，客戶也不一定 會主動設置需求的優(yōu)先級。開發(fā)團隊要在每個迭代開始前，與客戶密切交流，讓客戶發(fā)揮主動性選擇需求。1.4.3.2.需求分解成作業(yè)項目 敏捷軟件開發(fā)中，將開發(fā)工作細分為任務，每個人自發(fā)地選擇任務，一項任務完成后，自己再給自己分配下一項任 務。把工作分解到可以分配給個人的程度，叫任務（Task ）。迭代中， 要把需求進一步分解為任務， 并制成一覽表。 然后，通過管理任務的分配， 每個人所做的工作都明了可見。 雖然任務需要分配給 Team 中的某一人，但 Team 全體對任務負有管理責任。不依賴于個人能力。 而是通過 Team 一起管理

17、剩余的任務， 以判斷迭代內是否能完成計劃的可交付成果。 兩一方面， 通過觀察剩余的任務，可以早點發(fā)現異常。設計流程時，一貫的指導思想是：提高作業(yè)透明度，早期發(fā)現異常，縮短迭代期間，早期得到反饋。早期發(fā)現問題，早期做出調整，在設計流程的過程中，要時時關注這一機制。1.5. 敏捷項目的交付1.5.1.多次交付 交付是指在軟件開發(fā)中，核實可交付成果的行為。交付是指軟件可以開始提供商業(yè)服務，或可在公司內部使用，或 可開始作為 Package 產品生產 / 銷售。對外包公司來說，交付一般就是合同期滿的時候，通常只有一次。但是，如果采用敏捷項目管理，假設軟件會隨著 環(huán)境變化和用戶需求的變化而發(fā)生變化，將會

18、有多次交付。1.5.2.每個迭代做交付 敏捷項目管理中，我們何時交付軟件呢？你已經知道，我們是以迭代為單位進行軟件開發(fā)的。我們需要在每個迭代 結束前，準備可以交付的軟件。敏捷軟件開發(fā)中，每個迭代的交付是必不可少的 Practice 。因為，我們要和客戶確 認每個迭代的可交付成果，獲得客戶的反饋，確保項目在正確的方向上運行。反過來說，正因為敏捷軟件開發(fā)需要頻繁地獲取客戶反饋，所以要求迭代的時間不能太長。有時候，一個星期就是 一個迭代，這時，我們需要每周交付一次。普通的開發(fā)人員會認為這是不可能的。因為，交付一般伴隨著繁雜的手續(xù)，例如，壓力測試，審計團隊的檢查，文 檔的整備等。一般認為不滿足公司內部

19、的流程，或者不完全滿足合同上的要求，就沒有達到可以交付的品質。敏捷項目管理中，每個迭代的交付，會讓人想到交付所花費的時間和人力，因此感覺有點不實用。其實，這只是表 達的問題。敏捷項目管理中“每個迭代的交付”是指使軟件達到“可交付的狀態(tài)” （而不是真正就一次性交付了）1.5.3.每個迭代做的簡易交付 交付有兩種。一種是每個迭代結束時的簡易交付，另一種是作為項目的一個里程碑，即End User 可以開始使用的正式交付。1.5.4.簡易交付的要求 正式交付的流程和手續(xù)由合同和公司規(guī)定。敏捷項目管理中，關鍵是要定義簡易交付的交付條件。即，正式交付中 的要求，有哪些在簡易交付中必須滿足。 例如：單元測試

20、在簡易交付中必須滿足（如果你使用測試驅動開發(fā)，必然會有自動化測試） 。 那么，結合測試，和性能測試之類怎么辦呢？每個項目的性質不同，團隊的自動化工具的使用情況也不同，有必要 對每個項目具體問題具體分析具體判斷：需要把結合測試和性能測試放到簡易交付中嗎？ 另外，簡易交付的交付條件和迭代的長度也息息相關。在設計流程時，需要重點討論簡易交付的交付條件。1.5.5.敏捷軟件的文檔1.5.5.1.文檔最少化 敏捷軟件開發(fā)極力排除文檔工作。因為充分交流和代碼共享本身可以是項目團隊用最少的文檔實現仕樣傳達 （ Transfer ）和共享（ Share ）。簡單說來，就是不需要，所以不做。還有其他理由，例如文

21、檔的修改成本，例如文檔有損圓滑的溝通之類。那么，敏捷軟件開發(fā)中，真的不需要文檔嗎？如果我們正確實踐各種Practice ，和利益相關者（包括客戶）溝通順利，那么最大可能減少文檔也沒什么關系。但是，項目結束時， 和利益相關者在默契基礎上進行溝通的環(huán)境也沒有了。 為了和其他項目或者運營團隊 Transfer ， 有必要把信息書面化。除此之外，為了遵守現有的開發(fā)流程和公司內部規(guī)定，有時候并不特別在意文檔自身到底有 沒有用，也必須把文檔準備好。 （用 PMBOK 里的說法：更新組織過程資產）1.5.5.2.在正式交付的迭代準備文檔 那么，如何準備文檔呢？項目里，有一個迭代做正式交付，一般就在那個迭代整理文檔。在正式交付的迭代，團隊 的工作就是測試、準備文檔和交付