敏捷項(xiàng)目管理

1. 敏捷項(xiàng)目管理1.1. 敏捷軟件開發(fā)之項(xiàng)目管理1.1.1. 軟件開發(fā)之項(xiàng)目管理項(xiàng)目管理是將知識、技能、工具與技術(shù)應(yīng)用于項(xiàng)目活動，以滿足項(xiàng)目的要求。軟件開發(fā)項(xiàng)目的項(xiàng)目管理，是為了確保軟件開發(fā)項(xiàng)目順利進(jìn)行的各種管理活動的總和。PMBOK（Project Management Book of Knowledge）中將項(xiàng)目管理分為9大知識領(lǐng)域. 整合管理. 范圍管理. 時間管理. 成本管理. 質(zhì)量管理. 人力資源管理. 溝通管理. 風(fēng)險管理. 采購管理至今為止，項(xiàng)目管理往往從這幾個方面制定計劃，在實(shí)施中，檢查計劃和實(shí)施效果的偏差，監(jiān)控項(xiàng)目的健康狀況。1.1.2. 敏捷軟件開發(fā)之項(xiàng)目管理敏捷軟件開發(fā)的項(xiàng)目管理，是指在敏捷軟件開發(fā)中進(jìn)行的項(xiàng)目管理活動。敏捷軟件開發(fā)，如同第一章所述，是一種積極擁抱變化的開發(fā)模式。敏捷軟件開發(fā)認(rèn)可并應(yīng)對不確定性，換句話說，需要面對風(fēng)險（根據(jù)PMBOK的定義，風(fēng)險就是不確定性）。某種程度上，敏捷開發(fā)過程就是風(fēng)險管理的過程。敏捷軟件開發(fā)的各種實(shí)踐方法（Practice）就是為了應(yīng)對各種風(fēng)險而存在。敏捷軟件開發(fā)的項(xiàng)目管理，其本質(zhì)在于 - 平衡（Balance）為了提升透明度花費(fèi)的成本和因?yàn)榭赡馨l(fā)生變更而帶來的風(fēng)險。敏捷項(xiàng)目管理中，開發(fā)流程的概念輕量且抽象。在日新月異的今天，開發(fā)流程本身的靈活性顯得非常重要。不是用一個固定的流程來應(yīng)對變更，而是根據(jù)不同環(huán)境不同需要裁剪開發(fā)流程。從這個意義上來說，只定義必不可少的管理內(nèi)容的、輕量級的開發(fā)流程是順應(yīng)時代需要的。如果只在傳統(tǒng)的Paradigm下解讀和裁剪敏捷開發(fā)的流程，就很容易忘記敏捷開發(fā)的本來意義，這是造成敏捷開發(fā)失敗的一個主要原因。對流程的裁剪，一定要在正確理解敏捷項(xiàng)目管理的意義、不抹殺“敏捷”特性的前提下進(jìn)行。1.2. 敏捷開發(fā)的可交付成果1.2.1. 不事先規(guī)定可交付成果的細(xì)節(jié)敏捷軟件開發(fā)中，品質(zhì)代表軟件與用戶需求的匹配程度。不事先規(guī)定可交付成果的細(xì)節(jié)是為了追求更高品質(zhì)。因?yàn)樵陂_發(fā)過程中，需求可能發(fā)生變更，可交付成果的內(nèi)容也可能隨之而改變。敏捷軟件開發(fā)的特征不僅僅在于能以較低成本應(yīng)對變更，而是使軟件盡可能具有應(yīng)對變更的能力。敏捷項(xiàng)目管理的假設(shè)是，某個項(xiàng)目難以用傳統(tǒng)的流程進(jìn)行管理。即，Goal會隨著時間的變化而變化。因此，重點(diǎn)在于認(rèn)識到可能發(fā)生變更的風(fēng)險，提高應(yīng)變能力。但是，通常情況下，人們認(rèn)為如果可交付成果不斷變化，開發(fā)可能無法收尾。因此，敏捷項(xiàng)目管理把開發(fā)期間分解成幾個短的區(qū)間，把每個短區(qū)間的可交付成果在一定程度上固定下來。在項(xiàng)目進(jìn)展過程中，一邊聽取客戶反饋，一邊調(diào)整可交付成果?？山桓冻晒撵`活性要保持在多大程度？這個取決于流程的設(shè)計，是敏捷項(xiàng)目管理中非常重要的內(nèi)容。1.2.2. 可能發(fā)生變更，風(fēng)險管理怎么辦1.2.2.1. Whats Risk有可能發(fā)生變更的地方，就存在著各種各樣的風(fēng)險。風(fēng)險是因?yàn)榭赡馨l(fā)生變更而造成的，所以無論用不用敏捷項(xiàng)目管理，風(fēng)險都是存在的。但是，采用敏捷軟件開發(fā)和采用傳統(tǒng)的瀑布式開發(fā)，客戶和開發(fā)團(tuán)隊(duì)所承擔(dān)的風(fēng)險是不同的。首先，傳統(tǒng)的管理方法是制定計劃，根據(jù)執(zhí)行結(jié)果和計劃之間的偏差來評估可交付成果?？墒且?yàn)榭赡艽嬖谧兏?，無法嚴(yán)密地定義可交付成果。因此，就出現(xiàn)了以下兩種做法：a) 做各種假設(shè)，無論如何定義出可交付成果，決定金額和交貨期b) 雖然對可交付成果不是很清楚，但還是決定了金額和交貨期采用方法a的話，變更帶來的風(fēng)險由客戶承擔(dān)。即，如果假設(shè)和實(shí)際不相符，可交付成果和實(shí)際的業(yè)務(wù)需求就不一致。采用方法b的話，開發(fā)團(tuán)隊(duì)承擔(dān)仕樣變更的風(fēng)險，因?yàn)橐贿呉袷亟痤~和交貨期的約定，一邊還要完成可交付成果的變更。一般來說，很難讓某一方承擔(dān)全部風(fēng)險。通常的做法是采用折衷案。即，暫不考慮誰是誰非，客戶和開發(fā)團(tuán)隊(duì)共同承擔(dān)上述風(fēng)險進(jìn)行項(xiàng)目活動。敏捷軟件開發(fā)中，客戶和開發(fā)團(tuán)隊(duì)要一起承擔(dān)變更可能性帶來的風(fēng)險?？蛻粲胸?zé)任解釋說明并排序選擇軟件需求?？墒牵绻蛻舨荒軓拈_發(fā)團(tuán)隊(duì)得到有關(guān)項(xiàng)目進(jìn)度的反饋，就無法做合適的判斷。這就是溝通上的風(fēng)險。另外，事先沒有約定可交付成果的細(xì)節(jié)，因此，項(xiàng)目能夠在預(yù)算和進(jìn)度要求內(nèi)完成的保證就沒有了。開發(fā)團(tuán)隊(duì)也要充分了解這一風(fēng)險，并作出應(yīng)對。外包公司可能會盡可能降低成本，既滿足事先決定的交付期和可交付成果，又使計劃和執(zhí)行之間的Gap轉(zhuǎn)向有利于開發(fā)商一方，從而實(shí)現(xiàn)利益最大化。但是，敏捷軟件開發(fā)中，沒有事先約定可交付成果的細(xì)節(jié)，所以，很可能不存在如上所述的提高利潤的空間。開發(fā)商如果采用敏捷軟件開發(fā)，就要認(rèn)識到這樣的風(fēng)險，同時最大限度地滿足客戶需求。1.2.2.2. 怎么降低風(fēng)險因?yàn)榭赡艽嬖谧兏?，所以無論采用哪種項(xiàng)目管理方法，都必須承擔(dān)變更可能性帶來的風(fēng)險。那么，敏捷項(xiàng)目管理的優(yōu)點(diǎn)在哪里呢？就在于敏捷項(xiàng)目管理能夠應(yīng)對更多的、可能發(fā)生的變更。因?yàn)槊艚蒈浖_發(fā)本來就假設(shè)軟件開發(fā)項(xiàng)目中有可能發(fā)生變更。因此，越是深刻理解敏捷軟件開發(fā)的本質(zhì)，正確實(shí)踐，就越能以較少的成本應(yīng)對可能發(fā)生的變更。與此相對的，瀑布式項(xiàng)目管理沒有做這種假設(shè)。從這一點(diǎn)來看，熟練使用敏捷軟件開發(fā)，可以更迅速更安全地應(yīng)對變更可能性帶來的風(fēng)險。更重要的是，當(dāng)使用敏捷項(xiàng)目管理時，顧客和開發(fā)團(tuán)隊(duì)之間的風(fēng)險平衡（Risk Balance）是Win-Win的合作關(guān)系。即，適應(yīng)變更，擁抱變更的開發(fā)使客戶得到想要的功能，另一方面，開發(fā)團(tuán)隊(duì)因客戶滿意而獲得更大收益。與此相對，瀑布式項(xiàng)目管理在制定計劃時，顧客和開發(fā)團(tuán)隊(duì)之間就形成了一種風(fēng)險的交易（Tradeoff）。一旦發(fā)生變更，顧客和開發(fā)團(tuán)隊(duì)在誰承擔(dān)風(fēng)險上很容易形成對立關(guān)系。這種對立關(guān)系潛在地增加了項(xiàng)目管理的難度。變更越可能發(fā)生，項(xiàng)目管理就越難做。敏捷項(xiàng)目管理的Point在于顧客和開發(fā)團(tuán)隊(duì)一起向一個目標(biāo)奮斗，即提供更能滿足用戶需要的可交付成果。消解了對立關(guān)系，構(gòu)筑了一種積極應(yīng)對變更的合作關(guān)系。這一點(diǎn)，相對于傳統(tǒng)的項(xiàng)目管理來說，無論在合同方式，還是在顧客和開發(fā)團(tuán)隊(duì)間的角色扮演（責(zé)任分擔(dān)）上，都是一種激變吧！1.3. 敏捷項(xiàng)目管理之估算敏捷項(xiàng)目管理中，計劃（Planning）非常重要。計劃之前，開發(fā)團(tuán)隊(duì)要估算出任務(wù)的大?。╯ize）。這和傳統(tǒng)的瀑布式項(xiàng)目管理究竟有何不同呢？敏捷軟件開發(fā)中，估算有兩個特征：一是以顧客能夠管理的需求為單位進(jìn)行估算，另一個是只需估算出需求的相對大小。關(guān)于這兩個特征，解說如下。1.3.1. 以客戶能夠管理的需求為單位進(jìn)行估算第一個特征是要義客戶能夠管理的需求為單位進(jìn)行估算。雖然這并非是敏捷項(xiàng)目管理固有的東西，但對于敏捷項(xiàng)目管理來說，至關(guān)重要。因?yàn)椴捎眠@樣的管理方法，顧客可以自主排序選擇需求。首先，敏捷軟件開發(fā)前，客戶有責(zé)任準(zhǔn)備需求列表。當(dāng)然啦，大多數(shù)情況下，由開發(fā)團(tuán)隊(duì)幫客戶制作需求列表。但開發(fā)團(tuán)隊(duì)要認(rèn)識到需求列表的制作和管理是顧客的責(zé)任。關(guān)于這種需求列表，每種開發(fā)方式都有自己的叫法，其中需求的粒度和表現(xiàn)形式也不同。例如，XP中，有Story。Scrum中有Product Backlog。無論哪種，都是利害關(guān)系者期待的軟件功能（Feature）。以客戶能夠管理的需求為單位進(jìn)行估算，其本質(zhì)在于使客戶能夠判斷功能的優(yōu)先度，以決定每次交付時，軟件需要具有什么功能。1.3.2. 只需估算出需求的相對大小這里的估算并不是項(xiàng)目所需時間（人月）的估算。因?yàn)楣浪愠鰜淼睦塾嫊r間，很可能因?yàn)槿肆Y源等限制，會與實(shí)際需要的時間大相徑庭。第二點(diǎn)，需求的相對大小是由經(jīng)驗(yàn)和感覺得來的，客戶比較容易理解，也比較容易操作。敏捷項(xiàng)目管理的前提是項(xiàng)目的不可預(yù)測性。因此，精細(xì)估算得來的計劃和概算估算得來的計劃，其精度差別不大 -都是不確實(shí)的計劃。因此，與其在估算上花費(fèi)成本，倒不如把側(cè)重點(diǎn)放在體制的整備上，以應(yīng)對意外事態(tài)。敏捷項(xiàng)目管理中，以需求的相對大小為單位進(jìn)行估算。這個單位在XP中稱作Story Point。1.3.3. 也有不能對應(yīng)的不確定性敏捷項(xiàng)目管理接受不確定性，需要時，可以調(diào)整估算值。但是，有時，估算階段的前提條件中，也有一些不得不確定的要素。這些要素一旦變更，其變更成本往往不可接受。比較極端的例子，比如，一旦選定某種開發(fā)語言，就幾乎不可能再變了。還有，架構(gòu)的再構(gòu)也是這樣。因此，事先必須詳細(xì)調(diào)查這些不可更改的因素。例如，多數(shù)情況下，開發(fā)團(tuán)隊(duì)根據(jù)經(jīng)驗(yàn)定義非功能需求，整理出架構(gòu)的優(yōu)缺點(diǎn)，明確其適用范圍和潛在風(fēng)險。1.4. 敏捷項(xiàng)目管理之流程設(shè)計1.4.1. 迭代（Iteration）敏捷項(xiàng)目管理的要點(diǎn)在于能夠設(shè)計出一個流程以平衡為獲取反饋所花費(fèi)的成本和獲得反饋給項(xiàng)目帶來的好處。客戶從開發(fā)人員那兒得到關(guān)于可交付成果的報告，并進(jìn)行決策。該決策作為仕樣反饋給開發(fā)人員。然后，開發(fā)人員基于該仕樣改進(jìn)開發(fā)，并繼續(xù)向客戶報告結(jié)果。如此這般，客戶和開發(fā)人員一邊切磋琢磨，一邊做出更好的軟件。敏捷軟件開發(fā)采用迭代（Iteration）管理開發(fā)項(xiàng)目工作。一個迭代，一般持續(xù)一周或一個月。迭代是分配任務(wù)和制作可交付成果的管理單位。迭代的長度一旦決定了，就不再更改。即，迭代的長度是固定的，不是由分配的任務(wù)大小決定的。Scrum使用Rugby中的術(shù)語，每個迭代被稱作一個Sprint。1.4.2. Time-boxTime-box被稱作迭代背后的手。重視人與人之間互動的流程，往往會有規(guī)則不夠用的缺陷。這是因?yàn)?，這種流程的重點(diǎn)在于協(xié)調(diào)以完成實(shí)際的工作，而不是遵守嚴(yán)密的規(guī)章制度。這種流程更接近于管理的本質(zhì)，但是更難掌控。激發(fā)創(chuàng)造力的交流是必不可少的，但有時候，用于調(diào)整的時間無限膨脹，甚至壓縮了做實(shí)際工作的時間。例如，長時間的會議和辯論。的確，各種Session會給參加者帶來一定的滿足感，但也容易流于為會議而會議的形式主義，或者帶來“開會就是完成工作”的虛假的成就感。更壞的情況時，如果掌控不好，會造成進(jìn)度遲延、品質(zhì)低下、以及成本和回報的不平衡。那么，該如何解決這些問題呢？有一種方法，對各項(xiàng)活動設(shè)定了時間，并要求嚴(yán)守結(jié)束時間。即，終了時間必須結(jié)束，即使會議的預(yù)期可交付成果還處于In progress的狀態(tài)，也要結(jié)束，這個預(yù)期的可交付成果會成為下一道工序的輸入。這種時間管理方法就叫做Time-box。Time-box的Point在于并不倉促得出可交付成果。而是按時間進(jìn)入下一道工序，得到客戶反饋，再返回來，更好地完成可交付成果（由此可見，項(xiàng)目真的是一種目標(biāo)導(dǎo)向、結(jié)果導(dǎo)向的東西）。重視客戶反饋的敏捷項(xiàng)目管理就采用了Time-box，按照定義好的時間，進(jìn)入下個Step。1.4.3. 任務(wù)管理1.4.3.1. 把需求分配到各個迭代需求是在迭代中實(shí)現(xiàn)的。在哪個迭代中分配哪些需求，一般是按照客戶設(shè)定的優(yōu)先度，從高到低地實(shí)施。實(shí)際操作時，因?yàn)樾枨蟮拇笮〔煌?，而迭代的長度是固定的，所以無法完全按照優(yōu)先級實(shí)施。另外，客戶也不一定會主動設(shè)置需求的優(yōu)先級。開發(fā)團(tuán)隊(duì)要在每個迭代開始前，與客戶密切交流，讓客戶發(fā)揮主動性選擇需求。1.4.3.2. 需求分解成作業(yè)項(xiàng)目敏捷軟件開發(fā)中，將開發(fā)工作細(xì)分為任務(wù)，每個人自發(fā)地選擇任務(wù)，一項(xiàng)任務(wù)完成后，自己再給自己分配下一項(xiàng)任務(wù)。把工作分解到可以分配給個人的程度，叫任務(wù)（Task）。迭代中，要把需求進(jìn)一步分解為任務(wù)，并制成一覽表。然后，通過管理任務(wù)的分配，每個人所做的工作都明了可見。雖然任務(wù)需要分配給Team中的某一人，但Team全體對任務(wù)負(fù)有管理責(zé)任。不依賴于個人能力。而是通過Team一起管理剩余的任務(wù)，以判斷迭代內(nèi)是否能完成計劃的可交付成果。兩一方面，通過觀察剩余的任務(wù)，可以早點(diǎn)發(fā)現(xiàn)異常。設(shè)計流程時，一貫的指導(dǎo)思想是：提高作業(yè)透明度，早期發(fā)現(xiàn)異常，縮短迭代期間，早期得到反饋。早期發(fā)現(xiàn)問題，早期做出調(diào)整，在設(shè)計流程的過程中，要時時關(guān)注這一機(jī)制。1.5. 敏捷項(xiàng)目的交付1.5.1. 多次交付交付是指在軟件開發(fā)中，核實(shí)可交付成果的行為。交付是指軟件可以開始提供商業(yè)服務(wù)，或可在公司內(nèi)部使用，或可開始作為Package產(chǎn)品生產(chǎn)/銷售。對外包公司來說，交付一般就是合同期滿的時候，通常只有一次。但是，如果采用敏捷項(xiàng)目管理，假設(shè)軟件會隨著環(huán)境變化和用戶需求的變化而發(fā)生變化，將會有多次交付。1.5.2. 每個迭代做交付敏捷項(xiàng)目管理中，我們何時交付軟件呢？你已經(jīng)知道，我們是以迭代為單位進(jìn)行軟件開發(fā)的。我們需要在每個迭代結(jié)束前，準(zhǔn)備可以交付的軟件。敏捷軟件開發(fā)中，每個迭代的交付是必不可少的Practice。因?yàn)?，我們要和客戶確認(rèn)每個迭代的可交付成果，獲得客戶的反饋，確保項(xiàng)目在正確的方向上運(yùn)行。反過來說，正因?yàn)槊艚蒈浖_發(fā)需要頻繁地獲取客戶反饋，所以要求迭代的時間不能太長。有時候，一個星期就是一個迭代，這時，我們需要每周交付一次。普通的開發(fā)人員會認(rèn)為這是不可能的。因?yàn)椋桓兑话惆殡S著繁雜的手續(xù)，例如，壓力測試，審計團(tuán)隊(duì)的檢查，文檔的整備等。一般認(rèn)為不滿足公司內(nèi)部的流程，或者不完全滿足合同上的要求，就沒有達(dá)到可以交付的品質(zhì)。敏捷項(xiàng)目管理中，每個迭代的交付，會讓人想到交付所花費(fèi)的時間和人力，因此感覺有點(diǎn)不實(shí)用。其實(shí)，這只是表達(dá)的問題。敏捷項(xiàng)目管理中“每個迭代的交付”是指使軟件達(dá)到“可交付的狀態(tài)”（而不是真正就一次性交付了）。1.5.3. 每個迭代做的簡易交付交付有兩種。一種是每個迭代結(jié)束時的簡易交付，另一種是作為項(xiàng)目的一個里程碑，即End User可以開始使用的正式交付。1.5.4. 簡易交付的要求正式交付的流程和手續(xù)由合同和公司規(guī)定。敏捷項(xiàng)目管理中，關(guān)鍵是要定義簡易交付的交付條件。即，正式交付中的要求，有哪些在簡易交付中必須滿足。例如：單元測試在簡易交付中必須滿足（如果你使用測試驅(qū)動開發(fā)，必然會有自動化測試）。那么，結(jié)合測試，和性能測試之類怎么辦呢？每個項(xiàng)目的性質(zhì)不同，團(tuán)隊(duì)的自動化工具的使用情況也不同，有必要對每個項(xiàng)目具體問題具體分析具體判斷：需要把結(jié)合測試和性能測試放到簡易交付中嗎？ 另外，簡易交付的交付條件和迭代的長度也息息相關(guān)。在設(shè)計流程時，需要重點(diǎn)討論簡易交付的交付條件。1.5.5. 敏捷軟件的文檔1.5.5.1. 文檔最少化敏捷軟件開發(fā)極力排除文檔工作。因?yàn)槌浞纸涣骱痛a共享本身可以是項(xiàng)目團(tuán)隊(duì)用最少的文檔實(shí)現(xiàn)仕樣傳達(dá)（Transfer）和共享（Share）。簡單說來，就是不需要，所以不做。還有其他理由，例如文檔的修改成本，例如文檔有損圓滑的溝通之類。那么，敏捷軟件開發(fā)中，真的不需要文檔嗎？如果我們正確實(shí)踐各種Practice，和利益相關(guān)者（包括客戶）溝通順利，那么最大可能減少文檔也沒什么關(guān)系。但是，項(xiàng)目結(jié)束時，和利益相關(guān)者在默契基礎(chǔ)上進(jìn)行溝通的環(huán)境也沒有了。為了和其他項(xiàng)目或者運(yùn)營團(tuán)隊(duì)Transfer，有必要把信息書面化。除此之外，為了遵守現(xiàn)有的開發(fā)流程和公司內(nèi)部規(guī)定，有時候并不特別在意文檔自身到底有沒有用，也必須把文檔準(zhǔn)備好。（用PMBOK里的說法：更新組織過程資產(chǎn)）1.5.5.2. 在正式交付的迭代準(zhǔn)備文檔那么，如何準(zhǔn)備文檔呢？項(xiàng)目里，有一個迭代做正式交付，一般就在那個迭代整理文檔。在正式交付的迭代，團(tuán)隊(duì)的工作就是測試、準(zhǔn)備文檔和交付（not code correction）。1.5.5.3. 正式交付的迭代要做的工作正式交付的迭代中，團(tuán)隊(duì)實(shí)施本應(yīng)在每次