7.1 匯入敏捷專案管理的步驟
1.匯入敏捷的步驟
(1).培訓
(2).教練與引導
(3).內化
2.敏捷混合型模式
7.2 專案啟動與敏捷合同
1.敏捷專案啟動
2.敏捷簽約模式
在傳統專案管理框架下的委外專案要採用敏捷，必須要將專案進行方式和所要採用的敏捷過程與實踐，列入合同與建議邀請書中。原則如下：
(1).使用標準的固定成本且時間和材料可變更的合同。
(2).使範圍有彈性，在每個迭代邊界時，適應改變。
(3).如果整體投入沒有改變，成本就不需要改變。
(4).以買方價值優先順序來交付系統系統功能。
(5).使用迭代發布增量成果，作為合同的里程碑。
(6).使用回顧會議來改進簽約過程。
3.傳統合同改為敏捷合同的重點
(1).修改合同。
(2).修改專案預定進度。
(3).明確每次發布的增量成果。
(4).修改專案組織及職責。
(5).修改承包廠商資格。
(6).修改工作內容。
(7).修改需求說明的交付專案。
(8).修改需求的專案規劃。
(9).可於招標公告上加入創意與優選規定。
4.傳統專案章程改為敏捷專案章程的重點
7.3 專案規劃
1.敏捷專案管理五種層級的規劃
(1).在專案立項時，做最高層的規劃，也就是專案願景規劃。
(2).在專案啟動時，做產品地圖的規劃。
(3).在發布迴圈時，每次發布一開始進行發布規劃。
(4).在迭代迴圈時，每次迭代一開始進行迭代規劃。
(5).在每日立會時，進行規劃，動態調整每天的工作。
2.敏捷初學者規劃時常見的錯誤
(1).開發團隊進行規劃時，往往跳過製作角色卡，直接撰寫使用者故事。
(2).團隊未充分理解使用者故事及未具備撰寫使用者的能力。
(3).團隊未具備將使用者故事分級為工作的能力。
(4).產品負責人對使用者故事優先順序排序的能力不足。
(5).敏捷應該有全職的內部教練，才更能保證專案成功。
7.4 專案執行、監控及收尾
1.敏捷專案團隊在專案執行時是自我組織的團隊
2.甲方在專案執行與監控時可採用的敏捷工具
(1).產品地圖
(2).停車場圖
(3).燃盡圖
(4).使用者故事看板
3.專案收尾
第7章 什麼是敏捷設計
7.1 軟體出了什麼錯 在軟體開發過程中，我們經常發現 越來越難以維護。需求變化時，很難去修改 修改後很容易引起意想不到的bug。在開發初期，程式設計師尚能清楚地掌握 能輕鬆的進行維護。隨著專案地進行，設計越來越複雜，越來越混亂，程式設計師自己也不清楚修改某處 是否會引起別的問題。7.2 設計的臭味...
敏捷專案管理
敏捷專案管理 apm 由jim highsmith所著的一書敏捷專案管理，試圖擴大敏捷技術為乙個整體。敏捷專案管理 引入敏捷專案管理步驟同pmi所採用的專案管理步驟結合 調整傳統鐵三角強調價值和質量，建立敏捷三角。傳統鐵三角 範圍 成本 進度 敏捷三角 價值 質量 制約因素 成本 進度 範圍 敏捷鐵...
敏捷專案管理
敏捷開發遵循軟體客觀規律，不斷的進行迭代增量開發，最終交付復合客戶價值的產品。敏捷宣言 敏捷開發原則 敏捷包括三個層次 精益七大浪費 技術債務 變化無法一次性 一開始製作大而全的計畫易造成浪費 應根據迭代積累的經驗和需求變化的情況對計畫不斷調整和細化 多層次反饋 敏捷軟體開發是以短週期迭代為核心，包...