- 看板是一個及時的庫存控制調度系統(tǒng)障涯。產品流程只有在收到命令信號時才執(zhí)行较店。
- 所有任務都必須經過測試或驗證流程雷客，來確保質量已介入開發(fā)流程中。完成的任務通常移動到“準備測試”目錄下娄昆，然后由測試者和客戶執(zhí)行測試佩微。任務板上部分任務沒有詳細的驗證或測試標準，這些任務不會移入”準備測試“下萌焰，但仍要進行驗證哺眯，并通常移至”準備驗證“目錄下
- ”項目章程“是重要的管理文件，需要所有干系人參與扒俯∧套浚”項目章程“包含三個重要信息：前景一疯、任務、成功標準
優(yōu)先級技術：
- MoSCow Must Should Could Won't
- Kanon模型 基本需求（必須）夺姑，性能需求（越多越好）墩邀，愉悅需要
- 相對量級 基于成本、風險和處罰后能提供最大益處的特征應用擁有最高優(yōu)先級
XP極限編程強調以下原則：
- 結對編程
- 可持續(xù)速度
- 不斷自動測試
- 有效溝通
- 簡單性
- 反饋
- 勇氣
- 集體所有權
- 持續(xù)整合
- 激勵工作
- 共享工作空間
- 現(xiàn)場客戶代表
- 使用隱喻說明概念
- 產品待辦事項是一列所有需要在迭代中開發(fā)的產品特性綜合清單盏浙，它是不斷變化的眉睹，以適應客戶需求。
- 產品負責人的主要職責之一是：return on investment 投資回報率
常見的敏捷架構/方法論包括：
- scrum
- xp極限編程
- 精益軟件開發(fā)
- 水晶
- 特性驅動開發(fā) fdd
- 動態(tài)系統(tǒng)開發(fā)方法 dsdm
- 敏捷統(tǒng)一過程 aup
- 敏捷中废膘，故事地圖本質上等同于項目計劃竹海，它將用戶故事/產品特性按邏輯主題排列，作為開發(fā)的計劃丐黄。
計劃撲克是基于寬帶德爾菲估算技能斋配、也是以共識為基礎的工作量估算技能。也稱scrum撲克灌闺。運行步驟：
- 一名調停人主持會議艰争，不參與估算
- 產品負責人/管理人員對用戶故事做概述，并回答開發(fā)者提出的澄清問題桂对，往往產品負責人不參與投票
- 每一位估算師抽取一張卡片來估算工作量
- 每人抽取一張卡片后甩卓，同時將他們的卡片翻轉
- 持高和低估算的估算師各有一個機會做立場辯護
- 達成共識前不斷重復以上流程。持有用戶故事的開發(fā)者往往具有較高的可信度
敏捷的4個宣言
- 個體和交互勝過過程和工具
- 客戶合作勝過合同談判
- 可執(zhí)行的軟件勝過完備的文檔
- 響應變化重于遵循計劃
敏捷12原則
- 我們的最高目標是蕉斜，通過盡早和持續(xù)的交付有價值的軟件來滿足客戶
- 歡迎對需求提出變更猛频，即使是在項目開發(fā)后期。要善于利用變更蛛勉，幫助客戶獲得競爭優(yōu)勢
- 不斷交付可用軟件，周期從幾周到幾個月不等睦柴，且越短越好
- 項目過程中诽凌，業(yè)務人員與開發(fā)人員必須在一起工作
- 要善于激勵項目人員，給他們提供需要的環(huán)境和支持坦敌，并相信他們能夠完成任務
- 無論是團隊內還是團隊間侣诵，最有效的溝通是面對面交談
- 可用的軟件是衡量進度的主要指標
- 敏捷過程提倡可持續(xù)的開發(fā)。項目方狱窘、開發(fā)人員和用戶應該保持恒久穩(wěn)定的進展速度
- 對技術精益求精以及對技術的不斷完善將提升敏捷性
- 做到簡潔杜顺，即盡最大可能減少不必要的工作。這是一門藝術
- 最佳的架構蘸炸、需求和設計出自于自組織的團隊
- 團隊要定期反省如何能夠做到更有效躬络，并相應的調整團隊的行為
- 一般來說，敏捷項目是自上而下估算的
- 敏捷團隊應約定試用一種估算方法搭儒，故事點或者理想時間穷当，因為這兩種方法使用不同的測量單位提茁，會造成混亂
- 開發(fā)一個用戶故事的理想持續(xù)時長是2-5天
- 用戶故事是基于顧客價值去優(yōu)先排序的。價值有投資效益馁菜、團隊知識增長茴扁，風險減少決定
價值流程圖是敏捷采用的精益生產分析技能，用于對形成客戶產品或服務的原料和信息（即價值）的流動分析汪疮。執(zhí)行價值流程的5個步驟
- 確認產品峭火、客戶和范圍（即流程的始末）
- 地圖作為團隊或者個人現(xiàn)時價值流，確認流程步驟智嚷，延時和信息需求卖丸。估算流程步驟的持續(xù)時長和前置期持續(xù)時長。前置期是指在發(fā)生前一項流程或事件需要等待的時長
- 分析價值流程圖來確認浪費存在的地方和流程可完善的地方（流程時間通常認為是價值增加時間纤勒，但是應盡量減少整個流程的時間坯苹，由此來縮短向客戶交付價值流的時間）
- 通過分析，總結出一份展示價值流努力達到的前景或目標的未來價值流程圖
- 通過流程完善活動或者其他方法來達到目標的一些工作
- 解聚是指將大的用戶故事分解為小的更易于處理的小故事摇天，類似分解
以價值為基礎的分解：將用戶故事分解為任務粹湃，這將反過來被價值優(yōu)化 - 故事點代表成本，價值點代表利益
- 項目的燃盡圖是一個常用來展示迭代進度的信息發(fā)射源泉坐。它記錄兩項序列：剩余的實際工作和剩余的理想/預估工作为鳄。實際工作序列往往是非線性的，反映開發(fā)的起伏
一個健全的站立會議的重點特征：
- 同輩壓力腕让，因為團隊靠大家孤钦，所以同輩的期望可帶動進步
- 密切的配合，團隊應當理解專注的重要性并獨立工作
- 細節(jié)在專注纯丸，團隊應當理解每日站立會中簡潔的重要性偏形，由此團隊才有效益
- 每日承諾，團隊應當理解每人每日承諾的價值所在觉鼻，并兌現(xiàn)這些承諾
- 辨別障礙俊扭，團隊應當集體意識到每個人的困難，由此團隊可集體嘗試解決
- 價值坠陈、成本萨惑、風險是優(yōu)先考慮處理用戶故事的重點因素
3C
- card
- conversation
- confirmation
- 敏捷開發(fā)的基石是增量交付。增量交付是指為及時反饋和接納仇矾，頻繁向客戶交付連續(xù)有效的工作產品
invest
- independent 獨立的
- negotiable 可協(xié)商的
- valuable 有價值的
- estimable 可估算的
- small 小的
- testable 可測試的
- 在使用負責項目的滾動波或滾動預測未來計劃時庸蔼，敏捷團隊計劃在下幾個迭代中是工作
計劃撲克
- 計劃撲克的參照點用戶故事是中碼或者均碼
- 進行計劃撲克時，每一個用戶故事分配的時間應當是2到3分鐘
- 計劃撲克用來評估開發(fā)中用戶故事的相關付出
- 額外收益是指向現(xiàn)有客戶銷售新產品特性或服務期間實現(xiàn)的額外收益
- 投資回報率roi：用來評估一項投資的效益或者對比若干投資的效益的指標贮匕。一般來說姐仅，產品負責人對投資回報率負責。
- scrum框架的基石是“一直存在一個理論上可傳輸?shù)漠a品”，所以對于對于團隊和產品負責人來說以下兩點非常重要：定義“完成”萍嬉，或終結狀態(tài)下要以何標準考慮用戶的特性和功能
產品負責人所擁有的產品路線圖乌昔，是產品需求的高層次概述，常用作特性優(yōu)先處理壤追，特性歸類和粗略時間框架確定的工具磕道。創(chuàng)建產品路線的步驟：
- 確認需求
- 將需求分類或分定主題
- 評估相對工作量
- 評估粗略時間框架
- 敏捷計劃的三個主要層級為：發(fā)布計劃、迭代計劃行冰、每日計劃
敏捷領導需要做到：
- 授權團隊成員決定敏捷實踐和方法的標準
- 允許團隊進行自主管理和自我約束
- 授權團隊成員和客戶合作決策
- 激勵團隊創(chuàng)造和探索新思想和技術的才能
- 成為倡導者溺蕉，向團隊成員闡釋產品前景，以此激勵完成整體目標
- 移除并解決團隊工作可能遇到的障礙和問題
- 向可能不熟悉敏捷的干系人溝通和宣傳敏捷項目管理的價值和原則
- 確保包括商業(yè)管理人員和開發(fā)者在內的所有干系人有效協(xié)作
- 能夠依據(jù)工作環(huán)境改變領導風格悼做，以此確保有力支持敏捷價值和原則
- 敏捷鐵三角：價值疯特、質量、約束
根據(jù)亞倫·桑德斯所說肛走，敏捷失敗的前12條是：
- 承諾沒有產生組織變化或獲得支持
- 文化不支持變化
- 文化沒有反思漓雅，或者執(zhí)行反思不足
- 在項目收尾過程中丟失標準和質量
- 計劃中缺乏協(xié)作
- 缺乏或者過多產品負責人
- 項目領導力不足，或者scurm主管不信任團隊并不允許團隊自主管理和自我約束
- 沒有現(xiàn)場的敏捷支持者或者教練
- 缺乏一支完善朽色，高績效的團隊
- 不維持嚴格的測試標準的情況下邻吞，技術債務會增加
- 文化維持傳統(tǒng)的績效評估，即推崇個人時丟失團隊方面
- 因為變化難以進行葫男，所以傳統(tǒng)或舊式是經營方式出現(xiàn)
敏捷項目管理的重點特征：
- 持續(xù)完善
- 多功能團隊
- 短迭代
- 增量方法
- 商業(yè)優(yōu)先權
- 客戶價值
- 最小可售功能MMF是一個最小和可市場化的軟件特性或者產品特征
驗收測試驅動開發(fā)atdd迭代的4個步驟4d：
- discuss 討論
- distill 提取
- develop 開發(fā)
- demo 示范
測試驅動開發(fā)tdd的4個步驟
- 編寫測試
- 核對和確認測試
- 編寫產品代碼抱冷，接著采用測試
- 重構產品代碼
r·e·freeman的干系人管理10原則：
- 干系人的利益點需要隨著時間而趨于一致
- 我們需要一個制原則原則——聯(lián)合干系人并經營關系，而不是留給政府
- 我們需要找到同時讓各個顧客滿意的方法
- 我們所做都是為服務顧客梢褐，我們從不以一個人的利益換取他人利益
- 我們充滿目標完成對干系人的承諾旺遮，我們充滿抱負實現(xiàn)我們和他人的夢想
- 我們需要和所有干系人徹底溝通
- 干系人包括有姓名和樣貌的人和小孩，錯綜復雜
- 需要概括市場營銷方法
- 我們與首要和次要干系人接洽
- 我們不斷的監(jiān)督和重新設計過程變得更好的去服務干系人
- 敏捷開發(fā)合同類型：初始階段用固定總價合同盈咳；成本報銷/工料合同耿眉；不超過固定費用合同
敏捷項目中，典型的信息發(fā)射器包括：
- 項目燃盡圖
- 任務板
- 燃起圖
- 缺陷圖表
- 《PMI敏捷社區(qū)實踐章程》提出的社區(qū)價值包括：前景鱼响、仆人式領導跷敬、信任、協(xié)作热押、誠實、好學斤寇、勇氣桶癣、開放、適應力娘锁、領導變革牙寞、透明化
影響項目的5個核心風險：
- 生產率變化（計劃和實際操作之間的差距）
- 范圍漸變（初始協(xié)議以為的大量附加的需求）
- 規(guī)格故障（干系人對需求的共識缺失）
- 內部日程缺陷（對任務工期的錯誤評估）
- 人才流失（人力資源的流失）
統(tǒng)一敏捷流程aup的4個階段：
- 創(chuàng)始
- 細化
- 建立
- 轉變
浪費的形式 widetom：
- waiting等待
- inventory庫存
- defects缺陷
- extra processing額外流程
- transportation運輸
- over-production過度生產
- motion動態(tài)
提高動力的簡單步驟：
- 共度黃金時間，團隊成員可在個人層面上了解他人以此營造社區(qū)氛圍
提供反饋，指導和訓練间雀，贊揚和感謝團隊成員的出色工作悔详，同時為技能和能力提升提供指導和訓練 - 授權，授權團隊成員關鍵決策惹挟，在此期間茄螃，建立信任并顯示領導對團隊能力的信任
構建良好敏捷團隊氛圍的指導包括：
- 團隊成員協(xié)作
- 減少非必要的干擾/分心
- 為信息發(fā)射源專用白板和墻面空間
- 為每日站立會議和其他會議提供空間
- 結對工作站
- 其他任性的措施如植入和舒適的家具
吉姆·海史密斯敏捷企業(yè)架構的4個層次：
- 投資管理分層
- 項目管理分層
- 迭代管理分層
- 技術實踐分層
吉姆·海史密斯項目管理模型的5個階段：
- 構想
- 推測
- 探索
- 適應
- 結束
- 敏捷項目推薦的合同類型：初始階段的一般服務協(xié)議和為迭代和用戶故事分開設置的固定價合同；工料合同连锯；不超過固定費用合同归苍；最后獎勵性合同（固定加激勵；成本加酬金及獎勵合同）
- scrum中迭代計劃會議不應該超過8小時
- 敏捷團隊的基本準則不是教練編寫的运怖，而是由所有項目成員編寫的拼弃，往往也是非正式
- 力場分析是尋找推動和阻礙變化的因素并給因素編號以了解兩邊力量的綜合
- 只有規(guī)定時間內通過驗收的功能包含在時間盒內
- 持續(xù)集成的意思所有代碼變化要每天提交和測試
- 掙值管理分析在迭代時被獲取和用于溝通
- XP項目中定義的角色：教練、客戶摇展、程序員吻氧、測試員、跟蹤員
- 累計流量圖顯示的是任務的工作流而不是過程的工作流
- 精益支持減少浪費咏连。達到此目的一種方式是將未開展的工作最大化
- 正確的測試驅動開發(fā)方法是：測試盯孙、編碼、重構捻勉、交付
- 在零迭代期镀梭，團隊通常做計劃，沒有可用的軟件可交付踱启。在敏捷中計劃不能產生內在價值报账，只有可用的軟件才能轉化價值
- 敏捷中分布式團隊沒有集中式團隊有效。
- 修剪產品樹是一種用于需求收集的創(chuàng)新游戲
- 敏捷宣言于2001年在猶他州瓦薩其山雪鳥滑雪勝地發(fā)表
- 停車場圖用來抓住可能重要的但應該以后再關注的偏離主題的信息
- 計劃撲克應該在開發(fā)用戶故事之后和創(chuàng)建故事點之前使用
沖突管理和解決
- 級別1：解決問題埠偿。協(xié)作：尋求雙贏的局面透罢；共識：學習每位團隊成員對這個問題的看法，并及時達成一致
- 級別2：爭執(zhí)冠蒋。支持：允許對方解決問題羽圃；安全：任何事情都要以安全為基礎
- 級別3：爭辯。容納：為了建立關系抖剿，退讓朽寞；談判：許諾工作和資源
- 級別4：討伐。外交手段：在各方之間傳送信息
- 級別5：世界大戰(zhàn)斩郎。保護：做任何必要的事情來防止大家彼此傷害
Keip三步干預法：
- 1.你有沒有跟他提到過你的顧慮和感受脑融？
- 2.他應該知道你的顧慮。如果我跟你一起去找他會有幫助嗎缩宜？
- 3.我可以告訴他肘迎，你們有這些顧慮嗎甥温？
- 產品負責人對產品中所有功能負責，在干系人出現(xiàn)不同意見時妓布，產品負責人要進行講解直到所有人都清楚的了解功能
- 產品路線圖是產品發(fā)布和主要組件的整體虛擬概述姻蚓。它為項目干系人提供了溝通工具
- 風險燃燒圖實際上是累積的項目風險的嚴重性的堆疊圖
- 回顧會議的步驟：開場、收集數(shù)據(jù)匣沼、生成靈感狰挡、決定要做什么、關閉回顧
- 敏捷團隊是自組織的肛著，他們?yōu)轫椖砍兄Z時間而非SM
- 看板上沒有角色
- kaizen是日本關于持續(xù)改善的術語圆兵，能通過微小的改變來實現(xiàn)
產品待辦項有4大特性deep：
- 詳略得當 detailed appropriately
- 緊急涌入 emergent
- 估算過的 estimated
- 排好順序 prioritized
敏捷教練的風格
- teaching 教學型
- coaching 指導型
- advising 顧問型
- 項目數(shù)據(jù)表是用一頁紙概括主要商業(yè)和質量目標、產品功能和項目管理信息枢贿，這是一個簡單卻有重要影響力的文檔殉农。
收入來源
- new revenue新收入——新客戶帶來的收入
- incremental revenue增量收入——現(xiàn)有客戶增加的收入
- retained revenue留存收入——如果不開發(fā)項目或者主題，公司會損失的收入
- operational efficiency操作效率
- 敏捷關注定性風險分析
sprint評審會的目標
- 真實展現(xiàn)
- 展示和說明
- 獲取直接反饋
- 提供內部情況
- 尋求幫助
繪制燃盡圖的4條原則：
- 只要完成了工作局荚，就要降低頂部
- 對工作重估時超凳，頂部可能上升，也可能向下移動
- 添加新工作時耀态，底部降低
- 去掉工作時轮傍，底部升高
- 產品路線圖勾畫出了多個版本演化過程。該圖表示的時限可以歷時幾年首装，是對產品性能進行的一種概括總會
- 代碼重構是完善工作源代碼的方法创夜，以提高源代碼的有效性、可讀性仙逻、擴展性驰吓、可維護性和降低復雜性。通過重構系奉，可在不改變外部行為的情況下檬贰，重構源代碼來改良內部代碼
Kano模型
- must have 作為閾值的功能（必須的功能）。產品要成功就必須具備的功能
- 線性功能缺亮。越多越好的狀態(tài)的功能
- 興奮點和驚喜點
- 分割用戶故事
- 按照用戶故事所支持的數(shù)據(jù)邊界來分割大型用戶故事
- 按照操作邊界分割
- 去除橫切考慮
- 不用滿足性能限制
- 分割具有混合優(yōu)先級的用戶故事
- 不要把故事分割成任務
- 避免相關變化的誘惑
- 發(fā)布計劃重要的原因
- 發(fā)布計劃可以幫助產品所有者和開發(fā)小組判斷他們獲得一個可發(fā)布的產品之前翁涤，必須花多長時間開發(fā)多少東西
- 發(fā)布計劃傳遞了對于多長時間內可能開發(fā)什么內容的期望
- 發(fā)布計劃可以作為項目小組前進的路標
發(fā)布規(guī)劃的步驟（發(fā)布計劃通常在每次迭代開始時更新）
- 確定滿意條件
- 估計用戶故事的規(guī)模
- 選擇迭代周期長度
- 估計速度
- 確定用戶故事優(yōu)先級
- 選擇用戶故事和發(fā)布日期
- 發(fā)布計劃提供了要構建產品的高層次視圖
- 迭代計劃在迭代規(guī)劃會議上制定
- 迭代規(guī)劃時不分配任務
- 發(fā)布計劃是對整個產品發(fā)布過程的展望，通常是聰哥新項目啟動開始3-6個月的時間萌踱；迭代計劃只是對一次迭代的展望葵礼，通常是2-4周的時間。
- 迭代計劃的主要目標是對粒度較粗的發(fā)布規(guī)劃中建立的假定進行細化
迭代規(guī)劃方法分類：
- 速度驅動 velocity driven
- 承若驅動 commitment driven
- 優(yōu)先級會議通常安排在一次迭代結束前2天的時間
選擇迭代長度應考慮的因素：
- 正在處理的發(fā)布時間的長度
- 不確定性的多少
- 獲得反饋的難易程度
- 優(yōu)先級可以保持多久不變
- 不用外部反饋自行工作的意愿的強弱
- 迭代的系統(tǒng)開銷
- 緊迫感的產生有多快
緩沖區(qū)：
- 功能緩沖區(qū)
- 進度緩沖區(qū)
DSDM dynamic system development method 動態(tài)系統(tǒng)開發(fā)方法把需求分為4類 及 MoSCoW
- must have
- should have
- could have
- won't have
類似SCRUM并鸵，dsdm有三個主要階段
- 初始項目活動
- 項目周期活動
- 結束項目活動
類似scrum的賽前章咧、賽中、賽后能真，dsdm生命周期有5個階段
- 可能性研究
- 交易研究
- 功能模型迭代
- 設計和建立迭代
- 安裝啟用
- 特征驅動開發(fā) fdd使用一個規(guī)范的模型計劃、管理，并從個別軟件特征方面跟蹤軟件開發(fā)流程粉铐。fdd使用兩周或更短時長短迭代來開發(fā)一定的特征疼约。
fdd的五個步驟：
- 開發(fā)整體模型
- 建立特征清單
- 依特征做規(guī)劃
- 依特征做設計
- 依特征進行建立
在迭代計劃中，團隊根據(jù)三步曲去設計迭代代辦事項：
- 團隊分解大的或復雜用戶故事為多元的蝙泼，小的故事
- 團隊把每個用戶故事分解為開發(fā)任務
- 團隊估計任務功力或周期程剥，通常用理想時間
常見敏捷框架/方法論
- scrum
- xp
- 精益軟件開發(fā)
- crystal
- 特性驅動開發(fā) fdd
- 動態(tài)系統(tǒng)開發(fā) dsdm
- 敏捷統(tǒng)一過程 aup
- crystal的一個首要原則是滲透溝通
- 反思提高研討會是crystal方法論的基石
- crystal水晶是軟件開發(fā)靈活輕便方法的方法家族。方法家族是區(qū)分成員的顏色代碼汤踏，例如透明织鲸、黃色、紅色溪胶。顏色選擇取決于成果水平的要求搂擦。在光譜一端是完全透明的。
不考慮顏色哗脖，crystal的三個基本過程：
- 章程（幾天到幾周）
- 交付迭代
- 項目總結
crystal綱領：
- 建設團隊
- 做探索的360
- 為團隊定義實踐標準
- 建立項目初始計劃
精益軟件開發(fā)的原則
- 清除浪費
- 強化學習
- 盡可能晚決策
- 盡可能早交付
- 授權團隊
- 構建完整性
- 全盤檢視
精益軟件中存在的兩種完整（integrity）類型
- 概念性的瀑踢。概念上的完整性由開發(fā)者決定，如果產品集成良好和功能詳細才避，那么完整性大體上會非常高橱夭。
- 感知性的。感知上的完整性是有客戶觀察得出的桑逝，如果客戶最初對產品滿意和在之后產品滿足需求棘劣，那么完整性會很高。
- 信息發(fā)射源是指項目數(shù)據(jù)狀態(tài)的可視化展示
- 發(fā)布耗散圖顯示了在每次迭代開始時剩余的工作量楞遏。它是一個強大的茬暇、關于小組朝目標的前進有多快的可視化指示器。
- 發(fā)布耗散條形圖
- 停車場圖橱健。提供了一個有用的高層次視圖而钞，體現(xiàn)了小組在實現(xiàn)項目中所規(guī)劃的不同主題的進度
- 規(guī)劃是對價值的追求。
可以通過以下活動來支持對價值的追求：
- 減少風險
- 降低不確定性
- 提供更好的決策支持
- 建立信任
- 傳遞信息
- 規(guī)劃通過對風險的認識來提高項目取得成功的可能性
- 經常性地拘荡、可靠地交付承若的功能可以在產品的開發(fā)人員和該產品的客戶之間建立信任臼节。可靠的估計使得可靠的交付成為可能珊皿。
- 計劃可以傳遞對項目的期待网缝，并說明在項目的進程中發(fā)生某些事情的可能性
- 敏捷規(guī)劃不是敏捷計劃。計劃是文檔或者圖表蟋定；它們是我們認為一個項目在不確定的將來會如何展開的快照粉臊。規(guī)劃是一項快照。敏捷規(guī)劃將重點從作為結果的計劃轉向了規(guī)劃過程驶兜。
敏捷規(guī)劃
- 更關注規(guī)劃而不是計劃
- 鼓勵修改
- 產生易于修改的計劃
- 延續(xù)到整個項目過程
敏捷的4大價值
- 個人與交互重于開發(fā)過程與工具
- 可用的軟件重于復雜的文檔
- 尋求客戶的合作重于對合同的談判
- 對變化的響應重于始終遵循固定的計劃
敏捷開發(fā)小組的主要工作方式
- 作為一個整體工作
- 按短迭代周期工作
- 每次迭代交付一些成果
- 關注業(yè)務優(yōu)先級
- 檢查與調整
敏捷小組使用3個層次上規(guī)劃：
- 發(fā)布規(guī)劃（3-6個月）
- 迭代規(guī)劃（2-4周）
- 每日規(guī)劃
規(guī)模估計
- 敏捷估計與規(guī)劃的一個關鍵原則是先估計出規(guī)模然后推算出時間扼仲。
- 敏捷開發(fā)小組并不是依靠某一位專家來進行估計远寸。
- 打規(guī)劃撲克的時間
- 項目正式啟動前或在它的第一次迭代中
- 開發(fā)過程中對迭代中發(fā)現(xiàn)的新用戶故事
- 故事點和理想日是對規(guī)模的估計
- 有利于故事點的考慮因素
- 故事點有助于驅動跨功能的行為
- 故事點估計不會過期
- 故事點是純粹對規(guī)模的度量
- 故事點估計通常更快
- 我的理想日不等于您的理想日
確定優(yōu)先級的因素
- 獲得這些功能帶來的經濟價值
- 開發(fā)（可能還包含支持）新功能所需要的成本
- 開發(fā)新功能所產生的學習和知識的量以及重要性
- 開發(fā)這些功能所能減少的風險
敏捷估計和規(guī)劃的12條原則
- 讓整個小組參與
- 在不同層次上規(guī)劃
- 使用不同度量單位，讓對規(guī)模和持續(xù)時間的估計保持獨立
- 用功能和日期來體現(xiàn)不確定性
- 經常重規(guī)劃
- 跟蹤進度并溝通
- 成人學習的重要性
- 規(guī)劃具有適當規(guī)模的功能
- 確定功能優(yōu)先級
- 把估計和計劃建立在事實上
- 保留一些松弛度
- 通過前瞻規(guī)劃協(xié)調多個小組
scrum會議及參與人
- 用戶故事工作坊屠凶。SM驰后、PO、團隊
- product backlog矗愧。PO
- 估算會議灶芝。團隊、PO唉韭、SM
- sprint planning夜涕。team po sm
- dayly meeting。 sm team
- review meeting属愤。sm team po customer
- restore meeting女器。sm team
- sprint驗收。po
