1.1. 敏捷軟體開發之專案管理
1.1.1. 軟體開發之專案管理
專案管理是將知識、技能、工具與技術應用於專案活動，以滿足專案的要求。軟體開發專案的專案管理，是為了確保軟體開發專案順利進行的各種管理活動的總和。pmbok（project management book of knowledge）中將專案管理分為9大知識領域
1. 整合管理
2. 範圍管理
3. 時間管理
4. 成本管理
5. 質量管理
6. 人力資源管理
7. 溝通管理
8. 風險管理
9. 採購管理
至今為止，專案管理往往從這幾個方面制定計畫，在實施中，檢查計畫和實施效果的偏差，監控專案的健康狀況。
1.1.2. 敏捷軟體開發之專案管理
敏捷軟體開發的專案管理，是指在敏捷軟體開發中進行的專案管理活動。敏捷軟體開發，如同第一章所述，是一種積極擁抱變化的開發模式。敏捷軟體開發認可並應對不確定性，換句話說，需要面對風險（根據pmbok的定義，風險就是不確定性）。
某種程度上，敏捷開發過程就是風險管理的過程。敏捷軟體開發的各種實踐方法（practice）就是為了應對各種風險而存在。
敏捷軟體開發的專案管理，其本質在於 - 平衡（balance）為了提公升透明度花費的成本和因為可能發生變更而帶來的風險。
敏捷專案管理中，開發流程的概念輕量且抽象。在日新月異的今天，開發流程本身的靈活性顯得非常重要。不是用乙個固定的流程來應對變更，而是根據不同環境不同需要裁剪開發流程。
從這個意義上來說，只定義必不可少的管理內容的、輕量級的開發流程是順應時代需要的。
如果只在傳統的paradigm下解讀和裁剪敏捷開發的流程，就很容易忘記敏捷開發的本來意義，這是造成敏捷開發失敗的乙個主要原因。對流程的裁剪，一定要在正確理解敏捷專案管理的意義、不抹殺「敏捷」特性的前提下進行。
1.2. 敏捷開發的可交付成果
1.2.1. 不事先規定可交付成果的細節
敏捷軟體開發中，品質代表軟體與使用者需求的匹配程度。不事先規定可交付成果的細節是為了追求更高品質。因為在開發過程中，需求可能發生變更，可交付成果的內容也可能隨之而改變。
敏捷軟體開發的特徵不僅僅在於能以較低成本應對變更，而是使軟體盡可能具有應對變更的能力。敏捷專案管理的假設是，某個專案難以用傳統的流程進行管理。即，goal會隨著時間的變化而變化。
因此，重點在於認識到可能發生變更的風險，提高應變能力。
但是，通常情況下，人們認為如果可交付成果不斷變化，開發可能無法收尾。因此，敏捷專案管理把開發期間分解成幾個短的區間，把每個短區間的可交付成果在一定程度上固定下來。在專案進展過程中，一邊聽取客戶反饋，一邊調整可交付成果。
可交付成果的靈活性要保持在多大程度？這個取決於流程的設計，是敏捷專案管理中非常重要的內容。
1.2.2. 可能發生變更，風險管理怎麼辦
1.2.2.1. what』s risk
有可能發生變更的地方，就存在著各種各樣的風險。風險是因為可能發生變更而造成的，所以無論用不用敏捷專案管理，風險都是存在的。
但是，採用敏捷軟體開發和採用傳統的瀑布式開發，客戶和開發團隊所承擔的風險是不同的。
首先，傳統的管理方法是制定計畫，根據執行結果和計畫之間的偏差來評估可交付成果。可是因為可能存在變更，無法嚴密地定義可交付成果。因此，就出現了以下兩種做法：
a) 做各種假設，無論如何定義出可交付成果，決定金額和交貨期
b) 雖然對可交付成果不是很清楚，但還是決定了金額和交貨期
採用方法a的話，變更帶來的風險由客戶承擔。即，如果假設和實際不相符，可交付成果和實際的業務需求就不一致。採用方法b的話，開發團隊承擔仕樣變更的風險，因為一邊要遵守金額和交貨期的約定，一邊還要完成可交付成果的變更。
一般來說，很難讓某一方承擔全部風險。通常的做法是採用折衷案。即，暫不考慮誰是誰非，客戶和開發團隊共同承擔上述風險進行專案活動。
敏捷軟體開發中，客戶和開發團隊要一起承擔變更可能性帶來的風險。客戶有責任解釋說明並排序選擇軟體需求。可是，如果客戶不能從開發團隊得到有關專案進度的反饋，就無法做合適的判斷。
這就是溝通上的風險。
另外，事先沒有約定可交付成果的細節，因此，專案能夠在預算和進度要求內完成的保證就沒有了。開發團隊也要充分了解這一風險，並作出應對。
外包公司可能會盡可能降低成本，既滿足事先決定的交付期和可交付成果，又使計畫和執行之間的gap轉向有利於開發商一方，從而實現利益最大化。但是，敏捷軟體開發中，沒有事先約定可交付成果的細節，所以，很可能不存在如上所述的提高利潤的空間。
開發商如果採用敏捷軟體開發，就要認識到這樣的風險，同時最大限度地滿足客戶需求。
1.2.2.2. 怎麼降低風險
因為可能存在變更，所以無論採用哪種專案管理方法，都必須承擔變更可能性帶來的風險。
那麼，敏捷專案管理的優點在**呢？
就在於敏捷專案管理能夠應對更多的、可能發生的變更。因為敏捷軟體開發本來就假設軟體開發專案中有可能發生變更。因此，越是深刻理解敏捷軟體開發的本質，正確實踐，就越能以較少的成本應對可能發生的變更。
與此相對的，瀑布式專案管理沒有做這種假設。
從這一點來看，熟練使用敏捷軟體開發，可以更迅速更安全地應對變更可能性帶來的風險。
更重要的是，當使用敏捷專案管理時，顧客和開發團隊之間的風險平衡（risk balance）是win-win的合作關係。即，適應變更，擁抱變更的開發使客戶得到想要的功能，另一方面，開發團隊因客戶滿意而獲得更大收益。
與此相對，瀑布式專案管理在制定計畫時，顧客和開發團隊之間就形成了一種風險的交易（tradeoff）。一旦發生變更，顧客和開發團隊在誰承擔風險上很容易形成對立關係。這種對立關係潛在地增加了專案管理的難度。
變更越可能發生，專案管理就越難做。
敏捷專案管理的point在於顧客和開發團隊一起向乙個目標奮鬥，即提供更能滿足使用者需要的可交付成果。消解了對立關係，構築了一種積極應對變更的合作關係。這一點，相對於傳統的專案管理來說，無論在合同方式，還是在顧客和開發團隊間的角色扮演（責任分擔）上，都是一種激變吧！
1.3. 敏捷專案管理之估算
敏捷專案管理中，計畫（planning）非常重要。計畫之前，開發團隊要估算出任務的大小（size）。
這和傳統的瀑布式專案管理究竟有何不同呢？敏捷軟體開發中，估算有兩個特徵：一是以顧客能夠管理的需求為單位進行估算，另乙個是只需估算出需求的相對大小。
關於這兩個特徵，解說如下。
1.3.1. 以客戶能夠管理的需求為單位進行估算
第乙個特徵是要義客戶能夠管理的需求為單位進行估算。雖然這並非是敏捷專案管理固有的東西，但對於敏捷專案管理來說，至關重要。因為採用這樣的管理方法，顧客可以自主排序選擇需求。
首先，敏捷軟體開發前，客戶有責任準備需求列表。當然啦，大多數情況下，由開發團隊幫客戶製作需求列表。但開發團隊要認識到需求列表的製作和管理是顧客的責任。
關於這種需求列表，每種開發方式都有自己的叫法，其中需求的粒度和表現形式也不同。例如，xp中，有story。scrum中有product backlog。
無論哪種，都是利害關係者期待的軟體功能（feature）。
以客戶能夠管理的需求為單位進行估算，其本質在於使客戶能夠判斷功能的優先度，以決定每次交付時，軟體需要具有什麼功能。
1.3.2. 只需估算出需求的相對大小
這裡的估算並不是專案所需時間（人月）的估算。因為估算出來的累計時間，很可能因為人力資源等限制，會與實際需要的時間大相徑庭。
第二點，需求的相對大小是由經驗和感覺得來的，客戶比較容易理解，也比較容易操作。
敏捷專案管理的前提是專案的不可**性。因此，精細估算得來的計畫和概算估算得來的計畫，其精度差別不大 -都是不確實的計畫。因此，與其在估算上花費成本，倒不如把側重點放在體制的整備上，以應對意外事態。
敏捷專案管理中，以需求的相對大小為單位進行估算。這個單位在xp中稱作story point。
1.3.3. 也有不能對應的不確定性
敏捷專案管理接受不確定性，需要時，可以調整估算值。但是，有時，估算階段的前提條件中，也有一些不得不確定的要素。
這些要素一旦變更，其變更成本往往不可接受。比較極端的例子，比如，一旦選定某種開發語言，就幾乎不可能再變了。還有，架構的再構也是這樣。
因此，事先必須詳細調查這些不可更改的因素。例如，多數情況下，開發團隊根據經驗定義非功能需求，整理出架構的優缺點，明確其適用範圍和潛在風險。
1.4. 敏捷專案管理之流程設計
1.4.1. 迭代（iteration）
敏捷專案管理的要點在於能夠設計出乙個流程以平衡為獲取反饋所花費的成本和獲得反饋給專案帶來的好處。客戶從開發人員那兒得到關於可交付成果的報告，並進行決策。該決策作為仕樣反饋給開發人員。
然後，開發人員基於該仕樣改進開發，並繼續向客戶報告結果。如此這般，客戶和開發人員一邊切磋琢磨，一邊做出更好的軟體。
敏捷軟體開發採用迭代（iteration）管理開發專案工作。乙個迭代，一般持續一周或乙個月。迭代是分配任務和製作可交付成果的管理單位。
迭代的長度一旦決定了，就不再更改。即，迭代的長度是固定的，不是由分配的任務大小決定的。scrum使用rugby中的術語，每個迭代被稱作乙個sprint。
1.4.2. time-box
time-box被稱作迭代背後的手。重視人與人之間互動的流程，往往會有規則不夠用的缺陷。這是因為，這種流程的重點在於協調以完成實際的工作，而不是遵守嚴密的規章制度。
這種流程更接近於管理的本質，但是更難掌控。
激發創造力的交流是必不可少的，但有時候，用於調整的時間無限膨脹，甚至壓縮了做實際工作的時間。例如，長時間的會議和辯論。的確，各種session會給參加者帶來一定的滿足感，但也容易流於為會議而會議的形式主義，或者帶來「開會就是完成工作」的虛假的成就感。
更壞的情況時，如果掌控不好，會造成進度遲延、品質低下、以及成本和回報的不平衡。那麼，該如何解決這些問題呢？
有一種方法，對各項活動設定了時間，並要求嚴守結束時間。即，終了時間必須結束，即使會議的預期可交付成果還處於in progress的狀態，也要結束，這個預期的可交付成果會成為下一道工序的輸入。這種時間管理方法就叫做time-box。
time-box的point在於並不倉促得出可交付成果。而是按時間進入下一道工序，得到客戶反饋，再返回來，更好地完成可交付成果（由此可見，專案真的是一種目標導向、結果導向的東西）。
專案的敏捷開發與敏捷測試
敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...
華為公司實際的敏捷專案管理經驗
關於華為敏捷專案管理 ipd 整合產品開發，華為花重金從ibm購買的一套產品整合開發流程，業界有一本書，pace講的就是這一套ipd流程，而ipd並不去講你的開發要怎麼做，ipd做的就是 投資決策 市場驅動 更多的是決定做不做這個事情，做這個事情對於投資人員是不是受控的，所以在ipd裡面會有dcp點...
敏捷開發與敏捷測試
敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...