一、敏捷革命
1.當我們將試驗成本減少到足夠低時，整個產品開發的經濟學就會發生改變——從以預測為基礎的流程（定義、設計，然后建造）轉變為一個以適應為基礎的流程（構想、探索，然后適應）
2.當生產不同產品的成本突然降低，而把這些不同產品集成到一個產品的成本又很低時，那么這個很大的產品可以說不是生產出來的，而是進化出來的
3.羅伯特·庫珀：“各地的公司，無論蔬菜銷售商還是堅果銷售商，無論是開罐器制造商還是汽車制造商，都參與了新產品研發戰爭 ，而前沿部隊就是產品開發團隊。在這個新產品戰場上，閃電般的攻擊能力——計劃充分且出擊迅速——越來越成為成功的關鍵因素。而機動性或者速度則可以保證閃電攻擊能夠抓住機會或者捕捉到敵人”
4.最終客戶價值是在銷售時交付，不是在計劃時交付
5.任何以敏捷方法為幌子進行特殊開發的人，都是徹頭徹尾的騙子
A.敏捷商業目標
1.一個良好的探索流程（如敏捷項目管理）需要實現5個關鍵的商業目標：
* 1）持續創新，滿足當前客戶的需求
* 致力于向客戶提供價值，以及創造滿足當今客戶需求的產品，是這個持續創新流程的推動力
* 創新思想并不會在模式化的、獨裁的環境中產生，而會在基于自我組織和自我約束為原則的不斷適應氛圍中產生
* 2）產品適應性，滿足未來客戶的需要
* 要想讓產品持久地占有市場，唯有努力提高產品的適應能力
* 在敏捷項目中，卓越技術通過兩方面判定：一是現在提供客戶價值的能力；二是創造強適應性產品的能力
* 敏捷技術的做法將重點放在減少技術債務（提高適應能力），將其作為開發流程的組成部分
* 在敏捷項目中，開發人員致力于卓越技術，而項目經理則提供支持
* 3）縮短交付進度，滿足市場，提高投資回報率（return on investment，ROI）
* 縮短交付周期、滿足市場需求仍然是項目經理和主管要優先考慮的企業目標
* 敏捷項目管理的迭代開發、基于功能的本質可以通過3種方式縮短交付周期：突出重點、簡化流程和培養技能
* 4）人員和流程適應性，對產品和企業變化做出迅速反應
* 如果我們想要適應能力強的產品，就必須建立一支適應能力強的隊伍——其成員都樂于變革
* 敏捷項目管理的指導原則和架構鼓勵把學習和適應當做向客戶提供價值的組成部分
* 5）可靠的結果，支持業務增長和贏利能力
* 探索項目不能產生已知的、完全預告規定的結果，但可以產生有價值的結果——一個滿足客戶目標和商業需求的可以交付的產品
* 良好的探索流程可以不斷地提供創新
2.重復的流程是指按照同樣的方式做同樣的事情 ，并產生同樣的結果；而可選是指無論在生產過程中遇到什么障礙，都能達到目標，它意味著為達到一個目標而不斷改變
3.如果目標是提供符合已知的、不變的說明要求的產品，就用重復的流程。相反，如果目標是提供有特定限制的價值的產品，而變化和截止日期都是非常重要的因素，那么可靠流程更為適用
B.敏捷的定義
1.敏捷是制造并響應變化從而在動蕩的商業環境中創造利潤的能力
2.敏捷是平衡靈活性和穩定性的能力
3.制造變化可以擾亂競爭對手（及其整個市場系統），而對變化作出反應能防止競爭沖擊。制造變化需要創新：開發新產品、建立新的銷售渠道、縮短產品開發周期、為日益變小的細分市場定制個性化產品。此外，公司還必須能夠迅速響應競爭對手和客戶制造的可預見和不可預見的變化
4.復雜性理論告訴我們，創新（即創造一些我們不能完全預見的新東西、突發的結果）最容易出現在混亂和秩序、靈活性和穩定性之間的平衡點時
5.組織結構太嚴密會抑制創造性，太松散會導致效率低下
C.敏捷價值觀
1.敏捷強調的是態度而不是流程，它是氛圍而不是方法
2.那些卓越的公司創立的基礎（核心價值和目的）往往是永恒不變，但其策略（商業）和做法（業務實踐）是變化的
3.在業績優良的團隊中，領導管理原則，而原則管理團隊
4.團隊為何存在、要創造什么產品、為誰而創造以及如何共同工作，這些組成了敏捷項目管理的核心原則。如果想要創造優秀的產品，就需要有優秀的人才；如果想吸引并留住優秀的人才，就需要有優秀的原則
5.沒有行動的宏偉原則純屬幻想，相反，缺乏指導原則的具體的實踐通常都是不合理的應用
6.敏捷宣言
* 個體和交互勝過流程和工具
* 可以工作的軟件勝過面面俱到的文檔
* 客戶合作勝過合同談判
* 響應變化勝過遵循計劃
* 雖然右項也具有價值，但我們認為左項更具有價值
7.相互依賴聲明
* 通過持續為客戶創造價值來提高投資回報
* 通過不斷地與客戶交互、共享所有權來交付可靠的結果
* 預測不確定性，并設法通過迭代、預防、適應來應對不確定性
* 個體價值是團隊價值的源泉、創建能讓個體卓越的環境，實現創造和創新
* 通過激發成員的使命感和責任感來提高團隊績效
* 通過使用根據具體情況而定的策略、流程和做法來提高效率和可靠性
8.平等主義精英的核心價值觀強烈影響著敏捷運動。當然，這個核心價值觀并不是唯一能制造產品的價值觀，但其定義了大多數敏捷主義者對自己的認識
9.敏捷管理者應該具有的信心價值觀：
* 交付價值勝過滿足約束（價值勝過約束）
* 領導團隊勝過管理任務（團隊勝過任務）
* 適應變化勝過遵循計劃（適應勝過遵循）
10.傳統的項目管理者注重按計劃行事，盡量做到和計劃沒有出入；而敏捷項目管理者則關注如何 成功地去適應那些不可避免的變化
11.技術質量：價值持續產生的決定性因素
D.敏捷績效評估
1.敏捷項目評估的3個目標：
* 價值目標——提供可交付的產品
* 質量目標——提供可靠的、適應性強的可交付產品
* 約束目標——在可接受的約束內，實現價值和質量目標
2.敏捷三角形的演變
E.敏捷項目管理架構
1.以生產為導向的項目管理流程和做法強調完整的早期計劃和要求說明，并且要求以后將盡量不會改動；而基于探索的流程雖然也強調早期計劃（僅是名義上的），但它更強調足夠好的要求和可實驗可改進的設計方案，而且隨后會通過不斷學習，做出重大改動
2.敏捷項目管理交付方法包括5個階段：構想、推測、探索、適應和結束
3.構想階段產生一個清晰明白的業務或者產品構想，為后面的階段劃出邊界；在推測階段，團隊推測產品的規格，制定一個發布計劃，隨著項目的不斷進行，技術要求和客戶要求會隨著新知識的獲得不斷演變；然后是探索階段，它和迭代平等作業，其中要完成最初的功能和需求設計；在適應階段，這些試驗的結果需要經過技術、客戶和企業的個案審查，以便在下一次迭代過程中繼續做出調整
F.敏捷項目成功率
1.至少，敏捷方法有潛力極大地提高競爭優勢。它能很大程度上提高生產力和質量縮短時間，而這些最終會改變整個商業模式
2.敏捷項目管理不限于一小套做法和技巧，它定義了如下的策略能力：提供可交付的產品、創造和適應變化 、在靈活性和結構之間保持平衡、挖掘開發團隊的創造力和創新能力以及引導組織度過動蕩和不確定的時期
二、價值勝過約束
1.盡管諸如成本和進度這樣的約束很重要，但為客戶創造價值也很重要。通常人們總是關注容易測量的因素，而忽視了真正至關重要卻難以量化的特征
2.如果團隊關注結果——哪怕僅給予最小的關注，他們也更有可能交付真正商業價值
3.結果包括產品構想、商業目標和性能（高級產品功能），而沒有具體需求
4.質量目標定義了交付可靠的、可適應的（可工作的并易于改進）產品，這些都是很關鍵的價值特質
5.項目領導可以通過以下幾種方式來關注產品價值：價值確定（與客戶一起）、價值優先級排序（訂單管理）、價值創造（迭代開發）
* 價值確定通常是業務經理和產品經理的職責，但項目領導也經常參與成本/效益分析和價值判斷（特別是在產品公司）
* 價值優先級排序也大多是產品經理的工作，但項目領導者也要參與，特別是面對客戶或不知道技術需求的情況下
* 價值創造是在項目組內指的是與客戶合作、把客戶需求分組、減少技術債務（保證質量和價值交付）等活動
A.持續創造客戶價值
1.通過持續創造客戶價值來提高投資回報——相互依賴宣言
2.價值是指企業或組織的產出結果，往往與財務收益有關
3.持續是指價值能經得起時間的考驗——無論是現在還是將來
4.軟件設計行業，適時交付軟件第一個版本固然重要，但交付高質量并能適應未來需求的產品更重要
5.客戶和產品經理推動著敏捷開發
6.客戶闡明產品應該具備的性能、帶來的價值和實現量化該價值的商業目標
7.符合當前客戶需求，但不容易適應未來需要的產品，注定其生命周期是很短暫的
8.成功的秘笈很簡單——今天交付，明天適應
9.客戶是用創造的產品來產生商業價值的個人或群體
10.“利益相關方”表示與項目相關的、協助定義產品商業價值和其他約束的個人
11.如果希望交付的產品具有重大的客戶價值，就必須在客戶和開發人員之間建立伙伴關系，一種雙方都承擔責任和義務的關系
12.敏捷團隊不斷地尋求客戶參與，并總向客戶提問“我們所做的對您實現企業目標有幫助嗎？”
13.提供客戶價值涉及3個特別重要的話題：一是將重點放在創新和適應性而不是效率和優化，二是專注于執行，三是精益思維
14.“我們生活在一個由創造力、創新和想象力推動世界發展的時代”——湯姆·吳杰克和桑德拉·馬斯喀特
15.創造新產品和新服務不同于對現有產品作微小改進
* 前者必須將重點放在創新和適應性，而后者通常注重效率和優化
* 效率提供我們能想見到的產品和服務，而創新提供的是我們想象不到的產品
* 效率和優化是生產型項目的有利助推器，而創新和創造力卻是探索型項目的助推器
* 生產型思想傾向會限制對可行性方案的想象，而探索型思想傾向幫助探索看似不可能的事情
* 優化意味著已經知道如何做某事，只是現在需要改進它；創新意味著不知道如何做，所以探求知識就顯得極為重要
16.如果項目經理將精力集中于交付活動，他們為項目增加了價值；而如果集中于計劃和控制，就可能增加管理費用
17.傳統項目管理方法由3個信息交流流程組成：計劃、控制和執行
18.傳統計劃存在一些問題：
* 計劃的動機通常來自項目之外，即制定計劃的目的是為了滿足法律法規或者管理要求
* 制定計劃的動機往往與控制欲有關，而不是與實際工作的實施需要有關
* 計劃和控制成為焦點，而執行被看作是最不重要的
19.在敏捷項目管理中，項目經理的首要任務是促進產品構想的構思，并指導團隊去實現該構想，而不是制定計劃和進度表、控制進度，保證“計劃”得以實行
20.敏捷項目管理不是反計劃的模型。計劃（和控制）是敏捷項目管理的一個組成部分，只不過它不是重點
21.敏捷運動的許多想法都源于精益生產。精益生產的一個基本原則是系統地消除浪費，即減少不向客戶提供價值的活動
22.一個簡化項目（做較少的事、做正確的事、消除瓶頸）的方法是區分交付活動和合規活動，以及對每種活動分別采用相應的策略
23.過多的結構不僅會扼殺主動性和創新，而且消耗了大量的時間。根本問題不在于這些方案有無價值，而在于他們從根本上將流程凌駕于個人知識和能力之上
24.交付的相關活動與合規活動對項目經理有特殊的重大意義：
* 項目經理需要分析項目活動，以保證用在交付活動上的時間最多
* 項目經理必須分析他們自己的活動，以確定他們是在從事交付活動還是合規活動
B.迭代、基于功能的交付
1.如果想創新，就必須迭代
2.敏捷項目可以快速并遞增地在整個項目期內交付價值。采用迭代、基于功能的交付方式，能在早期捕獲價值，而且通常可以極大地提高項目的投資回報率
3.完成一個需求文件只是證實這個團隊成功地收集到了一套需求；而完成或演示一套可以工作的產品功能證實開發團隊實際已經向客戶交付了有形的東西
4.敏捷的迭代組成部分可以用4個關鍵詞表示：迭代、基于功能、時間框和增量
* 迭代開發是指要建造產品的部分版本，然后通過連續的短期開發以及評審和修改，擴展該版本
* 基于功能的交付是指設計團隊建造最終產品的功能，或者至少是與最終產品最接近的代表物（如模擬、模型），尤其是對于工業產品
* 迭代要求在一定的時間期限內——時間框（對于軟件是1-4個星期）——產生一個結果，該時間框強制迭代的結束，強迫人們在準備充分之前，就制造出部分實體
* 增量開發是指建造的產品，在經過一次或多次迭代后都可以及時的被調用
5.功能交付方法：客戶決定進度和功能的優先次序，而產品工程師確定提供這些功能需要的任務，以及完成這該任務要花費的時間和成本
6.對于需求可能會隨時間推移而演變的項目和產品，讓客戶在開發過程期間評審結果，使其盡可能接近實際產品，就顯得尤為關鍵
7.迭代開發同時也是自我糾正的過程。自我糾正最重要的方面是客戶在產品演變過程中提供的反饋信息
8.隨著演變融入后面的迭代開發，客戶對產品的信心會增加，或者相反，開始清楚地認識到該產品無法工作，應該趁早拋棄
9.促進探索很關鍵，但知道何時停止也很關鍵
10.“在我實行迭代開發的前幾年，認為時間框實際上是關于時間的，但后來我逐漸意識 到，時間框的作用實際上是強制做出困難的決定”
C.卓越技術
1.敏捷開發人員致力于卓越技術，不是因為美學，而是因為致力于卓越技術可以交付客戶價值。項目領導必須是卓越技術的擁護者；他們在密切注視其他項目目標的同時，必須支持并提倡卓越技術
2.高品質能確保公司在未來交付價值。許多軟件都是苦于技術債務和低質量的做法帶來的問題的積累
3.敏捷開發人員認為迭代、新興設計和頻繁反饋可以產生更出眾的設計
4.任何公司都不可能制造出完美的產品，但制造提供客戶價值并保持技術完整的產品是商業成功的關鍵，也是令技術團隊滿意的關鍵
5.項目經理需要與團隊一起，討論和決定開發的技術方法，而且在決定技術問題時，讓團隊不要忘記企業目標。項目經理可以不做決定，但他們應該具備足夠的知識，去引導團隊成員相互交流，以確保團隊充分地消化吸收項目資料，并及時做出正確的技術決定
6.項目經理必須支持卓越技術，因為它是適應能力和低成本迭代的關鍵，而這兩者是產品長期成功的推動力。項目經理不必是技術權威人士，但必須具備足夠的知識，才能與這樣的技術權威交流
D.簡化
1.“如果想讓船走得更快，那么割斷錨繩比加大馬力要來得容易”——盧克·霍
2.如果想快速而又敏捷，就要保持事情簡單。速度不是簡化的結果，但簡化能提高速度
3.“簡化非常關鍵，它是最大程度地減少不必要工作的藝術”——敏捷宣言
4.采用去掉詳細的基于任務的結構和合規工作來簡化流程，就強迫人們思考和交流
5.簡單原則是復雜性理論“群體智能”的一個方面，其思想是一套簡單正確的規劃，應用到一個高度相互作用的群體中，然后產生諸如創新和創造力之類的復雜行為
6.再生做法：一個系統在一起正常運轉的小最單位，它并不規定一個轉化需要做的每件事，而是確定那些具有非常高的價值、適用于幾乎每個項目的做法。采用這些做法，項目團隊將“生成”其他必要的輔助做法，作為他們裁減和改變該套做法、適應具體需要的一部分
7.在決定流程、方法、做法、文檔以及產品開發的其他方面時，簡化理念告誡我們應該把方向引向剛剛足夠、精簡和實施的“比剛剛夠少一點”
* 簡化需要平衡速度需求和靈活性，同時保持足夠的穩定性，避免疏忽錯誤
* 剛剛足夠并不意味著不足，也不意味著“無文檔”或者“無流程”
8.在產品開發中，缺乏速度會導致競爭劣勢，而倉促會導致錯誤。平衡，是敏捷的關鍵之一
9.如果領導者能夠巧妙地將復雜問題簡單化、能夠制定剛剛足夠的流程、能夠找到快速和倉促之間的分界線，那么他無疑有更高的成功機率
10.如果不能區分交付和合規，就會導致合規工作——為管理機構、律師或者高層管理編制文件——不斷增加，而將產品降到次要位置
11.“系統主義”：盲目地相信系統，認為可以通過系統達到任何必要的目標
12.約翰·格爾反對系統主義：
* “根本問題不在于某個特定系統，而在于類似的系統”
* “系統往往不斷擴張，填補已知世界”
* “系統往往反對他們自身的正確功能”
13.一些合規活動是必要的。每個組織、每個項目團隊都有一定的合規活動。例如醫療行業醫藥許可
三、團隊勝過任務
1.敏捷領導者領導團隊，非敏捷領導者管理任務
2.敏捷項目管理強調團隊管理，提倡建立自我組織團隊和發展服務型領導方式。這比管理任務更加困難，但最終的結果會更令人滿意。在敏捷項目中，團隊成員關注任務，項目領導關注團隊
A.領導團隊
1.“在戰斗中，你管不了人，你只能管事情……并領導別人”
2.項目管理和領導的區別：管理處理復雜性，領導就會變化
3.想建立適應能力強的、自我組織的項目團隊，領導者應該引導而不是控制，在某些情況下，他們影響、輕推、促進、教授、建議、協助、催促、勸告以及指導
4.項目領導應該即是管理者，又是領導者，隨著項目的探索系數增高，后者的重要性將迅速上升
5.領導者之所以成為領導者，不是因為他們所做的事情 ，而是因為他們扮演的角色
6.領導者在很大程度上依靠的是影響力而非權力，影響力來自于人們的尊敬而不是敬畏。取決于領導者的性格。領導者雖然得到組織的授權，但他們真正的權力不是自上而下委派的，而是自下而上贏得的
7.領導者鼓勵變化：提出未來可能性的想象（通常細節很少）；通過大量人員交流，發現能夠幫助將產品構想變為現實的新信息；以及激發目的感，激勵人們致力于一些超出常規的事情
8.管理幻想（霍奇森和懷特）：
* 為什么認為你處于受控狀態？
* 為什么認為你能夠預測未來及其結果和效果？
* 為什么認為你曾成功過的方法就能夠再次行得通？
* 為什么認為任何重要的事情都是可以評估的？
* 為什么認為諸如領導、管理和變化這些詞對任何人來說，意思都一樣？
* 為什么認為降低不確定性必然會增加確定性？
9.敏捷項目經理幫助他們的團隊在混沌的邊緣保持平衡——一些而不是過多的組織結構、適度而不過多的文件、一些事先準備但不過多的體系結構工作，找到這些平衡點是敏捷領導才能的藝術
10.領導-協作的管理風格創建了這樣的社會體系結構：一個可以讓組織和團隊面對環境多變性的結構。這種社會體系融合了這些概念：平等主義、才干、激情、自律和自我組織
11.“指揮官知道目標，領導者把握方向；指揮官發號施令，領導者施加影響；控制者提出要求，協作者加以促進；控制者事事管理，協作者不斷鼓勵。支持領導-協作模式的經理非常清楚他們的主要角色是設定方向、提供指導以及促進人們與團隊之間的聯系”
12.“在混沌時代，成功較少取決于生搬硬套而更多的是依賴于理智；較少取決于少數人的權力而更多的是依賴于多數人的判斷；較少取決于強制而更多的是依賴于激勵；較少取決于外部控制而更多的是依賴于內部紀律”
13.“敏捷”是社會技術運動，它有兩個推動力：一個是愿望——創造一種特定的工作環境；另一個是信念——適應性強的環境是向客戶提供創新產品目標的關鍵
B.建立自我組織（自律）團隊
1.自我組織團隊是敏捷項目管理的核心，他們結合了自由和責任、靈活性和結構。面對矛盾和模糊性，團隊的目標是始終如一地在項目范圍內和產品構想基礎上進行交付（包括適應性）
2.在自我組織的團隊中，個人負責管理自己的工作量，根據需要和最適合原則輪班工作，并對團隊效率負責
3.對于如何“交付結果”，團隊成員有自己保有較大的靈活性，但他們對結果負責，并在制定的靈活框架內工作
4.“自我組織的團隊的特征不是缺乏領導，而是一種領導風格”
5.創建自我組織的團隊需要：
* 1）找到適當的人員
* 項目領導者有權否決其他經理單方面想指派到該項目的任何團隊成員
* 任何流程都不能克服優秀工程師、產品經理、客戶和主管缺乏的問題
* 高效率的項目經理將重點依次放在人員、產品和流程。沒有適當的人員，將不能建造任何任何產品；不將精力放在產品上，其他無關系的活動就會滲入；沒有一個最低限度的流程框架，就會出現效率低下乃至混亂
* 2）清楚表達產品構想、界限和團隊角色
* 3）鼓勵協作
* 4）堅持負責
* 通過激發成員的使命感和責任感來提高團隊績效——相互依賴聲明
* 團隊成員相互承諾 ，團隊對客戶承諾，項目經理承諾為團隊提供特殊資源，他們就都同意了承擔責任
* 每個團隊成員都有責任提高團隊協作，每個團隊成員和項目領導相互履行承諾 是義不容辭的責任
* 5）培養自律
* 自律是自由和授權的前提。如果個人和團隊想要更多的自主權，他們就必須有更多的自律
* 自律的人可以：對結果負責；用嚴謹的思維對抗現實；參與激烈的交流和爭辯；愿意在自我組織框架內工作；尊重同事
* 自律也是建立在能力、堅持和愿意承擔結果的責任之上，才干不僅是技能和能力，它是態度和經驗
* “關鍵是首先要找到自律的人，他們進行嚴謹思維并會在一致的系統框架內采取守紀律的行動”
* 6）引導而不是控制
6.敏捷不會因為有良好的意圖就自動發展。敏捷團隊的成長和成熟需要時間，也需要致力于建立關系和鼓勵協作
C.鼓勵協作
1.自我組織團隊的能力在于協作，即兩個或更多的人相互交流和合作以共同產生一個結果
2.協作的結果可以分為：有形的可交付物、決定和共享知識
3.如果沒有有著正確技能和行為規范的合適人選，任何的流程和工具都不會產生任何結果
4.協作結果的質量優劣取決于信任與尊重的程度、信息流動的自由度、辯論以及積極的參與，同時也受到參與式決策流程的約束
5.健康團隊關系的核心是信任和尊重，自信和自負僅有一線之隔
6.如果協作太少、信息交流太少，團隊就會分歧嚴重，整合就會變成一個惡夢（因此需要經常整合）；而如果協作太多、信息交流太多，團隊就會陷入會議和信息超載
7.參與式決策：
* 決策是協作的心臟和靈魂，領導也是良好決策的關鍵
* 高效率的領導“吸收”模糊性、負責做決定并讓團隊繼續其工作。知道何時和如何應對模糊是高效率領導者的一個標志
* 重新構思意味著將多種想法合并起來，創造一種比任何一個單獨想法更好的東西。它不是放棄而是增加
* 創新是通過相互交流、逐步擴展想法，然后融合這些想法后突然出現的
* “妥協造成兩極分化、重新構思導致聯合”
* 自我組織的團隊偶爾需要經理做出單方面的決定，但他們的主要風格是包容，鼓勵團隊成員廣泛地參與決策以便做出最好的決策
8.共享空間：
* 創新并不會因為一些確定性的流程而得到保證，創新是安全性流程的結果，在這個流程中，具有創造性想法的個人相互交流，引發了某些新穎的、與眾不同的東西的產生。演示、原型、模擬和模型是相互交流的催化劑，他們組成了“共享空間”，其中開發人員、市場人員、客戶和經理可以做有重大意義的交流
* 共享空間有兩個要求：直觀化和公共性
* 直觀化：當工程師與客戶討論原型、致力于功能而不是文檔時，相互交流的質量就會得到很大提高
* 公共性：意味著原型需要得到開發工作的所有利益相關方的理解
9.客戶合作：
* 客戶或者產品團隊應該是任何敏捷開發工作不可或缺的一部分
* “敏捷”經常指出客戶和產品團隊的不足，并且需要和產品團隊定位自已的角色
D.不再需要自我組織團隊
1.如果讓自我組織繼續發揮價值，那么有幾個問題要處理：
* 需要擺脫掉一個觀點——敏捷項目無領導或者誰是領導取決于不同的情境
* 授權型自我組織團隊的支持者已經過時了——適宜的領導保留適當的決策權與授權給團隊相結合的方式
四、適應勝過遵循
1.“傳統的項目管理者注重按計劃行事，盡量做到和計劃沒有出入；而敏捷項目領導者關注如何成功地去適應不可避免出現的變化”
2.以客戶價值和質量為目標，計劃就是實現這些目標的方式，而不是目標本身
3.傳統經理不斷修正實際結果來符合基線，PMBOK稱為糾偏行為，用來引導團隊回歸基線；適用行為用來描述應該采取 什么行動方針（其中一個行為可能被修正以符合計劃要求）
4.《敏捷宣言》和《相互依賴聲明》中包含了5個與適應性有關的原則：
* 《聲明》：預測不確定性，并設法通過迭代、預防 、適應來應對不確定性
* 《聲明》：通過使用根據具體情況而定的策略、流程和實踐來提高效率和可靠性
* 《宣言》：響應變化勝過遵循計劃
* 《宣言》：即使在產品開發后期，也樂于接受變化的需求，敏捷流程充分利用變化以增加客戶競爭優勢
* 《宣言》：團隊定期反省如何做到更有效，然后相應調整團隊行為
5.上述原則可以概括為：
* 預測變化（不確定的），然后做相應調整，而不是遵循過期計劃
* 根據需要調整流程和做法
6.團隊必須適應，但是不能脫離最終的項目目標，無論是適應性流程還是預測性流程
7.可以用4個問題來評估流程：
* 在發布產品的同時，是否交付了價值？
* 是否實現了創造可靠的、具有適應性的產品質量目標？
* 項目進程是否滿足可接受的要素范圍？
* 團隊是否在有效地適應管理、客戶和技術等方面的變化？
8.適應可以看做是對變化做出的沉思熟慮的回應
9.“變化”：變得不同，使事物的性質、形態變得與原來不同
10.“適應”：不斷作相應的改變以滿足一定用途或形勢
A.適應學
1.如果認為世界是靜止的，則生產型管理做法將占主導地位；但如果認為世界是動態的，則探索型的管理做法將涌現出來。通常會出現靜態和動態的混合。
2.復雜適應系統，無論是生物學還是經濟學，都是以下獨立行動者的集合：
* 通過相互影響創造生態系統的行動者
* 其相互交流定義為信息交流的行動者
* 其個體行為基于一些內部規劃系統的行動者
* 按照非線性方式自我組織、產生安全性結果的行動者
* 顯示出秩序和混亂兩個特征的行動者
* 隨時間演變的行動者
3.個體行動者的行動由一套內部規則推動：敏捷項目管理的核心思想和原則
4.一套簡單的規則會產生復雜的行為和結果，而另一方面，復雜的規則通常會變成官僚作風，這些規則的表達方式對復雜系統的動作有非常大的影響
5.安全性是復雜適應系統的一個特性，復雜適應系統通過各部分（自我組織的行動者的行為）的相互作用，會創造出整個（系統行為）系統的更大特征。這個安全性系統行為是不能完全用行動者的標準行為來解釋的，安全性結果不能以正常的因果關系來預測，但可以通過以前產生類似結果的模式來預見他們的發生
6.適應性開發流程與優化流程具有不同的特征。優化反映的是說明性的“計劃-設計-建造”周期，而適應反映的是有機的、進化的“構想-探索-適應”周期。適應流程不是以一個解決方案開始，而是以多個可能的解決方案（試驗）開始，然后，應用一系列的適合性測試（實際產品功能或者模擬，取決于驗收試驗），根據反饋信息進行改變，從而探索并選擇最好的解決方案
7.如果不確定性低，則適應方法的風險是高成本，而如果不確定性高，則優化方法的風險在于太早的確定某個解決方案會抑制創新
B.探索
1.擁有響應變化的能力固然很好，但是如果能給競爭對手創造變化則更佳
2.創造變化，就是向對手展開競爭攻勢，響應競爭對手的變化，就是在防守
3.“適應的速率要超過市場變化的速率”
4.敏捷領導者需要鼓勵和激發團隊成員通過這些高度變化的環境所造成的困難。鼓勵包括保持自我鎮靜、鼓勵試驗 、借鑒成功和錯誤經驗，以及幫助團隊成員理解這種鼓勵的所有部分
5.偉大的探索者清楚表述出可以激發人們靈感的目標——讓人們激動、自我激勵的目標，這些目標或者構想作為一致的工作重點，刺激人們并在團隊中建立團隊精神，激發靈感的目標必須是充滿活力的、令人信服的、清楚的、可行的但又剛好的，它融入團隊的激情中
6.鼓勵型領導者知道好目標和壞目標之間的區別。鼓勵型領導知道設定一個產品的構想需要團隊的努力，需要基于分析、理解和現實的風險評估，同時還要有一點冒險精神
7.創新產品開發團隊是被引導的而不是被管理的。他們容許他們的領導是有靈感的，將領導者的鼓勵變成自我意識 的一部分。優秀的新產品、現有產品的顯著改進和創新的新業務方案都是由激情和靈感推動的
8.領導者清楚團隊目標。團隊成員了解這些目標并以此激勵自己。內在的激勵可以激發探索。如果沒有探索和失敗，如果不探索多個方向并最終找到那個似乎有前途的方向，我們就不可能獲得新的、更好的和與眾不同的東西
C.響應變化
1.“預測變化 （不確定性），然后做相應調整，而不是遵循過期計劃”
2.上述宣言可進一步歸納為：
* 構想—探索與計劃—執行
* 適應與預見
3.每個項目都有已知的未知的條件、有確定因素和不確定因素，因此，每個項目都必須在計劃和變化之間找到平衡
4.影響項目管理類型的另一個因素是迭代的成本，即試驗成本
D.產品、流程和人員
1.適應性有3個組成部分：產品、流程和人員
2.許多軟件組織實施敏捷的障礙是他們沒有處理遺留代碼中的技術債務
E.障礙還是機會
1.伊斯雷爾·干特“新玩具”綜合癥：“把重點放在新的開發上而忽視遺留代碼”
2.經常集成好處非常大，它可以減少許多以前遺留的問題，遲早發現那些直到發布期快結束的時候才發現的問題
3.大多數情況下，人們感覺適應變化有障礙（成本太貴）是因為做事效率低下——沒能抓住機會簡化流程并提高組織的適應能力
4.敏捷開發需要短期迭代：做短期迭代需要找到快速、低成本的做重復事情的辦法；快速、低成本的做事情使得團隊采用以前從沒有想到的方式去適應變化
F.可靠，但不重復
1.重復意味著按照同樣的方式做同樣的事情 ，并取得同樣的結果；而可靠意味著無論在前進道路中遇到什么障礙，都能達到目標，也意味著為達到一個目標而不斷改變
2.可重復流程通過評估和不斷的流程糾正，減少可變性
3.可靠流程將重點放在輸出，而非輸入
4.可靠性是以結果為推動力，重復性是以輸入為推動力
5.“重復流程最多只能交付事先規定的東西，而可靠、突發流程可以交付比開始時每個人的設想都更好的結果，只要你足夠機敏且具備預見能力，突發流程就可以產生最初希望的東西”
6.敏捷項目中需要考慮的正確范圍不是限定的要求，而是清晰、明白的產品構想——一個可發布的產品
7.評估項目成功的方法可以簡化成一個問題：“我們有可發布的產品嗎？”，而不是制造出了在項目開始時就規定好的特定功能的產品
8.盡管敏捷項目管理是可靠的，但它不是一貫正確的，它也不能消除不確定性的反復無常和在探索中遇到的出乎意料的事情
G.反思和回顧
1.適應變化需要具備這種理念和技巧
2.如果希望有較強的適應性，就必須愿意認真嚴格地評估個人和團隊的績效。有效的團隊在回顧時會涉及4個領域：產品、流程、團隊、項目
3.在每次迭代結束時和項目末期，對這些領域進行回顧和反饋，然后適應，從而提高績效
H.從原則到做法
1.“根據需要調整流程和做法”
2.原則和做法是向導，他們幫著確定和加強人們的行為
3.在敏捷項目中，既要有預見性也要有適應性的流程和做法。根據已知信息發布計劃來預見未來，反思根據隨后 在項目中發現的信息來適應代碼
五、敏捷項目管理模式
A.敏捷企業架構
1.投資組合治理層提供一些常見的檢查點：項目管理層對各種項目的管理提供指導。項目管理層和迭代管理層不同，其差異可以洞察運行項目、制定發布計劃和日常短期迭代管理的不同。區分迭代管理層和技術做法層，有助于把核心技術做活融合到幾個項目或者迭代管理方法中去
2.投資組合治理：主管們都想知道項目的價值（及投資回報率）和獲取該價值的確定性和不確定性
3.項目管理層：管理發布，與核心小組的外圍利益相關者打交道
4.迭代管理層：關注每個短期迭代的計劃、執行和團隊領導
5.技術實踐層：包括從持續集成到結對編程，從測試開始到重構等做法
B.敏捷交付架構
1.流程也許不如人那么重要，但它絕非不重要
2.如果企業目標是重復性的制造，那么常規性流程是完全合理的；而如果目標是可靠的創新，則流程架構必須是有組織的、靈活的和容易適應的
3.敏捷交付架構需要：
* 支持企業目標
* 支持構想、探索、適應文化
* 支持自我組織、自律的團隊
* 根據項目的不確定性程度，盡量提高可靠性和連貫性
* 保持靈活和易于適應
* 支持流程的透明化
* 合并知識
* 囊括支持各個階段的做法
* 提供管理檢查點
4.敏捷項目管理模式的結構：構想—推測—探索—適應—結束，重點在交付（執行）和適應
5.敏捷項目管理架構與傳統項目階段的區別：
* “構想”代替較傳統的“開始”，指出構想的重要性
* 推測階段代替計劃階段：“計劃”已經與預測和相對確定性相關聯，而“推測”表示未來是不確定的
* 敏捷項目管理模式用探索替代通常的設計、構建和測試階段，探索是非線性的、并存的、非瀑布式的模式；敏捷項目管理模式強調執行以及探索性而非確定性。實施敏捷項目管理的團隊密切關注構想、監控信息，從而適應當前情況，這就是適應階段
* 敏捷項目管理模式以結束階段收尾，這個階段的主要目標是傳遞知識，當然它也是一個慶典
6.敏捷項目管理的5個階段是：
* 1）構想：確定產品構想、項目目標和控制要素、項目社團以及團隊如何共同工作
* 該構想包括什么、誰提供和如何提供
* 構想是項目早期 “成功的關鍵因素”
* 產品及項目范圍構想
* 需要構想參與者都有誰：客戶、產品經理、項目團隊成員和利益相關方組成的社團
* 項目團隊成員必須構想他們打算如何共同工作
* 2）推測：制定基于性能和/或功能的發布計劃，確保交付構想的產品
* “根據不完全的事實或者信息猜測某事”
* 對于探索性的項目來說，計劃是基于不完全的信息推測或猜測
* 包括：收集初始的、廣泛的產品要求；將工作量定義為一個產品功能清單；制訂一個迭代的、基于功能的交付計劃；把風險降低策略納入計劃；估計項目成本，并生成其他必要的行政管理和財務信息
* 3）探索：在短期內計劃和提供經測試的功能，不斷致力于減少項目風險和不確定性
* 通過管理工作量和合作適當的技術方法和風險降低策略，按計劃交付產品功能
* 建立協作的、自我組織的項目社團，這是每個人的責任但需要由項目經理和迭代領導者推動
* 管理團隊與客戶、產品經理和其他利益相關方的相互交流
* 4）適應：審核提交的結果、當前情況以及團隊的績效，必要時做出調整
* 控制和糾正是這個周期階段常用的術語
* 計劃制定了，結果監控了，糾正也完成了，這個流程意味著計劃是正確的，而如果實際結果與計劃不同，則表明計劃是錯誤的
* 適應意味著修改或改變，而不是成功或失敗
* 非常特別的流程并不能從錯誤中吸取教訓，而吸取教訓是敏捷項目管理的關鍵部分
* 在適應階段，需要從客戶、技術、人員和流程績效，以及項目狀況等方面對結果進行檢查
* 思考實際的與修訂后的項目前景，修改后的結果將反饋并應用到重新計劃工作中，以開始新的迭代
* 自構想階段以后，其循環通常是推測—探索—適應，每次迭代都不斷地優化產品。但是對團隊收集新信息來說，定期修正構想階段也萬分重要
* 5）結束：終止項目、交流主要的學習成果并慶祝
* 結束階段（以及每次迭代末尾的小型結束）的主要目標是：學習并將學到的東西融入下一次迭代工作中，或者傳遞給下一個項目團隊
7.敏捷項目管理的構想和探索周期
8.沒有做法的原則只是個空殼，而沒有原則的做法經常會被毫無判斷地生搬硬套；沒有簡單原則 ，人們往往會過多地看重做法的形式和儀式。原則指導做法，做法用實際例子證明原則 ，兩者是相輔相成的
9.“沒有最好的做法，只有更適合具體情況的做法”
10.過分強調線性會導致停滯不前，而過分強調演變會導致無休止的、最終證明是盲目的變化
11.“一切工作都應該是循序漸進的，即使是架構開發。序列開發中前期架構出錯通常意味著長期適應性較差，因為沒有人能夠經得起在項目晚期再改變架構”
12.一個500人的團隊可能不如一個10人團隊敏捷，但它可以比競爭對手的500從團隊更敏捷。只要將重點集中在價值、交付、自我組織和自律，即使團隊再大，面臨的協調問題再復雜，它也能隨時應對商業、技術和組織的變化
C.擴展的敏捷交付架構
六、構想階段
1.“在人類行為領域，很難發現非常一致的事情 。因此，一旦一個團隊被認為是功能有效的，人們便歸功于它們對目標有明確的了解”——拉森和拉法斯
2.雖然要求和設計的細節可能是易變的和模糊的，但企業目標和產品構想必須是非常明確的
A.可發布的產品
1.產品的一個發布標準是功能或者故事的完成，既從開發人員的角度（編碼、單元測試）完成，也從產品團隊的角度（驗收測試）完成
2.可發布的產品和可用到的產品構想框和項目數據表中的信息可以定義為：
* 1）可交付的產品；產品構想框；項目數據表——項目目標聲明、企業目標、性能、性能價值
* 2）可靠的、適應性強的產品：項目數據表——質量目標
* 3）在可接受的約束內：項目數據表——均衡矩陣（范圍、進度、成本）
B.構想做法
1.目的是明確地鑒定需要做什么以及如何做，需要回答以下幾個問題：
* 1）客戶的產品構想是什么？
* 2）該產品的主要性能是什么？
* 3）項目的商業目標是什么？
* 4）項目的質量目標是什么？
* 5）項目的約束是什么（范圍、進度和成本）？
* 6）誰是項目社團的合適參與者？
* 7）團隊將如何交付產品（方法）？
2.如果沒有共同的構想，項目就會步履蹣跚。沒有構想，啟動就成為官僚作風和缺乏新意的形式
3.構想階段應該舉行一系列的協調會議，讓開發和產品團隊成員參與進來
4.在敏捷項目管理的構想和推測階段，尤其重要的是要記住：
* 1）團隊成員應該經常自問：“我們需要的剛好足夠的流程和文檔是什么?”
* 2）與團隊交付“方式”有關的所有做法都需要隨著項目的進行，不斷做出裁剪和調整，以提高業績
* 3）項目社團將會不斷演變其團隊做法
5.4類做法：
* 1）產品構想
* 產品構想框和電梯測試說明書
* 產品體系結構和指導原則
* 2）項目目標和約束
* 項目數據表
* 3）項目社團
* 找到合適的人選
* 確定參與者
* 客戶團隊-開發團隊界面
* 4）方法
* 流程和做法的截取
C.產品構想
1.產品構想（產品構想框和電梯測試聲明）激勵團隊成員將各自對產品的不同觀點集中成簡練的、直觀的簡短文本格式
2.創新（創造我們無法預測的突發結果）需要一個能夠容納探索和錯誤的演變流程
3.每個產品需要有一個營銷主題、一個簡明直觀的圖像和功能描述，其目的是吸引潛在客戶對該產品作進一步的了解
4.提出15個或20個產品功能很容易 ，但要想確認哪3個或4個功能能夠吸引其他人來購買該產品卻很困難，這通常會引發關于真正客戶身份的激烈討論
5.在每個小組遞交產品構想框后，要討論如何將不同的重點功能縮減成每個人都同意的幾個功能
6.“電梯測試說明書”，編寫產品定位的簡短陳述 ，用幾個句子表明目標客戶、主要好處和競爭優勢
7.“電梯測試說明書”的格式：
* 對于（目標客戶）；
* 誰（需要或有機會聲明）；
* 這個（產品名稱）是（產品類別 ）；
* 它（主要的優點、引人注目的購買原因）；
* 不同于（主要的競爭產品）；
* 我們的產品（主要差別）
8.產品構想框和電梯測試說明書強調項目的目的是制造產品，可以讓團隊的客戶產品思想有據可循
9.最后需要花費幾個小時討論記錄活動掛圖紙上的產品構想，團隊可以對一個1-2頁的完整產品構想文檔有更好的概括認識。這份文檔可能包括任務說明、構想框圖、目標客戶及其各自的需要、電梯測試說明書、客戶滿意評估標準、主要技術和業務要求、關鍵產品限制（性能、操作的簡便性、體積）、競爭分析，以及主要財務指標
10.交付進度越關鍵、項目越多變，團隊對于最終需要的結果是否有較好的構想就顯得越重要。如果沒有這個構想，迭代開發項目就很可能變得搖擺不定，是因為每個人看到的都是細節而不是宏偉的藍圖
11.產品體系結構的目標是描述項目的內部溝通渠道，是一種促進探索和指導正在進行的產品開發的設計
12.一個早期的“骨架”產品體系結構不僅能指導技術工作，也能指導執行技術工作人員的組織工作。它旨在把較大的項目背景傳達給開發團隊，而不是局限于一個設計
13.敏捷開發中，體系結構是引導，而不是緊箍咒
14.在敏捷發展中，體系結構和設計不是一次性的活動，而是隨著自身演變在每次迭代中都會出現的活動
15.如果在一次又一次的迭代中，主要的體系結構不斷發生變化 ，很明顯，可能是什么地方出問題了
16.雖然通常來說，敏捷做法鼓勵變化和適應，但是某些變化有更大的影響，而需要認真地協作；如果技術體系結構不好，就會使得這個變化的協調工作非常困難。一旦部件之間的協調或者整合花費了過多的時間，機敏的項目團隊就會認識到體系結構決策不恰當，而需要修正
17.功能分解結構（Feature Breakdown Structure,FBS）可以用來描述軟件或硬件項目產品體系結構
18.在項目早期階段人力組織和技術體系結構同時演變，這個模式有利于大型項目中各個項目功能團隊與主要的產品部件保持一致
19.指導原則（Guiding Principles,GP），用來協助開發團隊塑造產品，滿足客戶需求。通常不是可衡量的要求或者限制，而只是概念上的指導
20.早期的指導原則可以在以后的演變中成具體要求
21.每個原則應該用一兩個句子描述，而且在任何情況下，一個項目的全部原則描述不得超過10個句子
D.項目目標和約束
1.產品構想勾勒的目標沒有限制，但是作為一個項目來講就需要有目標和限制
2.項目需要有明確的商業目標（不同于客戶的產品構想）、質量目標和一套明確定義的性能，從而開始界定出可交付產品的范圍
3.項目數據表（Project Data Sheet，PDS）是項目目標和約束的最少文檔編制
4.項目數據表是用一頁紙概括主要商業和質量目標、產品功能和項目管理信息。這是一個簡單卻有重要影響力的文檔。它簡潔的格式，對整個項目社區呼吁并且不斷提醒他們哪些是項目的戰略方面
5.根據不同的組織和項目類型，項目數據表包括：
* 顧客/客戶：主要顧客或者客戶一覽表
* 項目經理：項目經理的姓名
* 產品經理：產品經理的名稱（產品擁有者）
* 高級主管：負責決策項目計劃和約束的人
* 項目目標聲明（Project Objective Statement，POS）：明確而簡短的聲明（不超過25個字），其中包括重要范圍、進度和成本信息
* 商業目標：做這個項目的總的金融和商業原因
* 權衡矩陣：確立項目范圍、進度和成本的相對優先次序的表格
* 探索系數：衡量項目風險和不確定性的度量標準（1~10）
* 延誤成本：項目延誤所造成的每日、每周或者每月成本（進度被列為最優先次序時尤其有用）
* 功能：主要功能一覽表
* 質量目標：一個可發布的產品的定量、定性質量目標
* 性能/質量屬性：產品主要性能和質量屬性清單
* 體系結構指導方針：修正設計決定的主要體系結構指導方針
* 問題/風險：對項目有負面影響的因素
6.權衡矩陣幫助開發團隊、產品團隊和各利益相關方管理項目期間的變化，它告知所有參與方變化的重要性，是團隊決策的依據。這個矩陣顯示出敏捷三角形（價值、質量、約束）所確定的3個約束（范圍、進度、成本）的相對重要性。如果組織必須適應變化，那么他們需要知道哪方面最具有靈活性
7.當項目啟動的時候，項目計劃估計在價值、質量和約束三者之間的健康平衡非常重要。當這個平衡被打破的時候，權衡矩陣就開始發揮作用。——肯·科利爾
8.探索系數用來表示項目的不確定性和風險的指標。探索系數為10表示問題領域是以探索為主（高風險），而系數為1表示比較穩定的環境
9.闡明項目的探索系數有助于管理客戶和主管的期望值
10.探索系數是從產品需求（目的）的易變性及其技術平臺（手段）的新穎性（也就是不確定性）派生出來的
11.探索系數矩陣
12.如果沒有認識到不同的問題領域，整齊劃一的項目流程和做法也許還有理由；而一旦有了這樣的認識，按具體的問題量身定制適合的流程和做法將會使項目團隊取得成功
E.項目社團
1.產品開發同其他大多數工作一樣，找到合適的人員是成功的關鍵因素。這里的“合適的”包含了兩層意思：具備適當的技術能力（或者專業技術）；表現出適當的自律行為
2.找到合適的人員并不意味著要找到最具天賦的、經驗最豐富的人，而是說要做這個工作最適合的人選
3.如果計劃承擔困難的、極其苛責的項目，就需要最優秀的人才；而如果承擔的是要求不很高的項目，并且有高于平常人的人才，仍然可以做得很好
4.幾乎每個人在某些方面上都有超出平均水平的潛力。幫助他們發現自己的潛力是經理的工作
5.兩個因素決定了團隊是否有“合適”的人員：能力和自律。合理的流程可以幫助適當的人員有效地在一起工作，但這并不能彌補人員配置不恰當的問題
6.合適的人員將重點放在交付上，而不合適的人員帶來更多的合規工作
7.確定參與者
* 1）3類參與者：客戶（可能包括最終用戶、他們的經理、產品專員、產品經理和高級主管）、開發團隊成員和利益相關方
* 2）如果產品團隊成員忘記他們僅僅是代表真正的客戶，而不是真的客戶的話，就會發生大問題
* 3）利益相關方3個級別：
* 關鍵的：無論在實施之前或之后，這些參與者都可以阻止項目成功，換句話說，他們是特別有影響力的人
* 必需的：在實施之前或之后，這些參與者可以拖延項目成功，換句話說，要圍繞他們工作
* 非必需的：這些參與者是感興趣者，對項目沒有直接影響，但是如果不將他們包括在社團內，他們可能變成關鍵或者重要的參與者
* 4）項目參與者可能包括：高級主管、項目領導者、產品經理、產品專員、迭代經理、總工程師（開發人員、架構師）、高層管理、產品團隊、項目團隊、開發團隊、供應商、政府等
* 5）參與者的群體越復雜，項目領導者在管理期望值、做關鍵的項目決策和防止團隊不受到太多方向的牽制等方面花費的時間就越多
8.產品團隊——開發團隊交互
* 1）產品團隊負責“建造什么”，開發團隊負責“如何建造它”
* 2）如果沒有強有力的產品經理，就會出現最壞的情況——無法確定優先次序
* 3）組織內部IT項目失敗或者表現不佳的其中一個關鍵原因是：錯誤地理解了項目經理和產品經理這兩個角色的本質，產品經理必須來自IT部門外部
* 4）盡管角色界定很重要，實際上角色具有靈活性，應該根據擔任該角色的人做出適當調整。強迫人們按照固定的角色描述不僅是不可能的，也是違背敏捷原則的
* 5）人員不僅比流程重要，也比角色重要
* 6）“建造什么”的決策要由客戶團隊做出，而開發團隊做“如何建造”的決策。優秀的開發團隊是有豐富的產品知識，應該積極參與“建造什么”的決策，而產品經理和客戶團隊成員通常可以對產品“如何”設計做出重大貢獻
* 7）每個團隊的責任和兩個團隊之間的交流是成功的關鍵
9.交付方法
* 1）團隊自律的部分內容是團隊就某種方法達成一致，然后實際地應用它。無論是否達成一致，還是沒有執行該方法，都是缺乏自律的表現
* 2）流程和做法和裁剪工作定義了項目團隊交付某個產品將使用的方法
* 3）自我組織策略將重點集中在人們如何一起工作、如何協作以及協作的機制上
* 4）流程和做法是不斷演變的
10.自我組織策略
* 1）自我組織策略讓團隊將精力首先集中在相互交流上，即與項目有關的每個人如何在一起工作。該策略確定了團隊的溝通、協調、協作、決策，以及其他個人與個人和團隊與團體的相互交流方法
* 2）自我組織策略問題
* 我們如何與客戶協作？
* 來自不同功能團隊的項目成員如何相互協作？
* 亞特蘭大的團隊如何與西雅圖或者孟買的團隊協作？
* 授權對我們團隊來說意味著什么？
* 誰需要在何時與誰交流？
* 相互交談的這些人如何決策？
* 誰負責什么？
* 他們打算用哪些做法來推動上面提出的問題？
* 3）僅有溝通是不夠的，還涉及相互交流以產生一些共同結果。協作是把大家的想法綜合為一個整體
11.流程架構裁剪
* 流程架構應該努力找出剛剛好（可以接受的最小程度）的項目組織標準
* 即流程組成元素的數量、必要的過渡產物數量、決策的數量、文檔形式越多，項目的敏捷度就越低
12.做法的選擇和裁剪
* 1）敏捷開發和項目管理是建立在一個基本前提下的，即個人能力是成功的基石，而且個人是獨一無二的貢獻者
* 2）不應該塑造人，使其適應一套共同的流程和做法；而應該按照團隊自身特點，塑造流程和做法
* 3）4個基本問題：
* 哪些做法是必需的？
* 還需要哪些輔助性做法？
* 需要對選擇的做法做那些修改？
* 做法的編檔、批準和更改需要什么手續和形式？
* 4）“如果文檔是正確的，即使很少，它也大有幫助”
* 5）“不是文檔的問題，而是理解的問題”
七、推測階段
1.計劃既是對未來的猜想——在已有的信息基礎上猜測將發生的事情 ，也是對未來的指南——確定想要的事情并促使其發生
2.計劃是重要的活動，但隨著不確定性的增加，用推測這個術語更加恰當
3.推測確立目標和方向，同時也表明期望在項目期間存在許多變化，不是狂熱的冒險，而是“根據不完整的事實或者信息猜想某些事情”
A.推測產品和項目
1.推測階段的產品是發布計劃，基于要交付的功能而并非活動（指傳統的項目計劃中的活動）
2.迭代計劃和開發方法有兩個至關重要的組成部分——短期迭代時間框和功能
3.基于功能的計劃和開發的首要目標是制定有形的、客戶團隊可以理解的流程
4.功能是開發工程師和產品團隊之間的界面——共同理解的一個媒介。這個共同的媒介采用故事卡片的形式。每個故事都寫在一個另外的索引卡上，把功能拆分成可以執行的小塊任務。索引卡的前面包含需求信息，用于制定計劃，背面包含技術任務信息，可以讓團隊估計并管理其工作
5.敏捷項目推測有助于項目團隊：
* 確定產品及其功能在當前版本中如何演變
* 隨著項目的開展，平衡預期和適應
* 在項目早期將重點放在價值最高的功能上
* 考慮項目、企業目標和客戶期望值
* 為管理層提供必要的預算和進度信息
* 為權衡決策建立優先級
* 協調團隊之間的相關活動和功能
* 考慮其他選擇和應變措施
* 為分析項目期間出現的事件提供基準
6.敏捷項目領導者需要通過行動、績效評估和構想，不斷地鼓勵團隊隨著項目的進行，不斷地學習并適應。演化的項目是困難的，它充滿了模糊性、變化和不穩定性，但是適應以交付價值的回報是豐厚的
B.產品功能清單
1.產品功能清單是對構想階段制定的清單的擴充和提煉，列出那些經過可行性分析或市場研究、初步需求收集工作和產品構想等工作收集起來的產品功能
2.產品經理維護這個清單，使得這個清單及伴隨的功能卡成為發布、里程碑和迭代計劃的主要資料來源
3.功能細節隨著開發階段的演變而演變。在構想階段，團隊創建初步的功能或者產品細目結構。在推測階段，團隊擴充這個清單，并為每種功能都建立一張或多張“故事”卡，其中包含基本的描述和估計的信息。在探索期間的每次迭代，按照計劃實施功能、詳細地確定需求、建造和測試功能
4.軟件是最有可塑性的產品，公司需要利用這個特點來增加競爭優勢，堅持傳統的瀑布式開發方法則減少這個優勢
5.需求說明流程的結果，無論涉及什么設計內容，都應該按照產品功能等級如（產品、平臺、功能組和功能）制成文檔
6.功能、故事的概念
* 1）功能或者故事被定義為產品的一部分，向客戶提供一些有用的、有價值的功能
* 2）功能和故事的基本區別是：故事是一個小的可交付的有用功能，但構不成一個完整的功能
* 3）性能、功能和故事構成一個分層結構，該分層結果用來管理越來越大的產品規模
7.故事的重點
* 1）對于有開發技術任務經驗的個體來說，定義故事會非常困難。對于詳細的迭代計劃，故事被拆分成技術任務，供開發團隊使用
* 2）缺少明確的客戶能夠理解的故事會導致項目快速地脫離軌道，在一次迭代期間，把幾個故事中的任務結合起來做，大多數所謂的效率低下情況就會消除
* 3）一些故事不是一次迭代就能完成，往往需要較長的時間或似乎較長的時間。通常情況下，當團隊被迫把大故事分解成小故事時，他們也就找到了方法，不能按這種方式拆分任務通常是因為缺乏經驗而不是故事不可拆分
* 4）在客戶功能之前構建技術功能的危險是“黑洞”。技術團隊“涉黑”時間越長（構建技術人員的東西），項目在得到客戶團隊的反饋之前 偏離軌道就越遠
8.故事卡片
* 1）目的是提供簡單的媒介，用于收集有關故事的基本信息、記錄高層次的需求、開發工作估計和定義驗收測試
* 2）故事卡片用于列出功能，而不是詳細定義功能
* 3）故事卡片的用途是客戶和項目團隊成員在一次迭代期間詳細需求的討論（以及抽成最低限度的文檔）后達成的協議。討論是理解的關鍵，而理解是估計的關鍵
* 4）故事卡片信息：
* 故事ID和名稱
* 故事描述：用一兩個句子，從客戶的角度描述功能
* 故事類型（C=客戶領域、T=技術領域）
* 估計工作量：交付該故事所需的工作量的估計，包括需求收集、設計、編碼、測試和文檔編制
* 估計價值點
* 需求不確定性（無規律的、波動的、常規的、穩定的）：每個特定故事采用一個探索系數
* 故事依賴關系：可能影響實施順序的依賴關系
* 驗收測試：客戶團隊用于接收或拒絕該故事的標準
* 5）開發團隊也會用任務分解來估算實施該故事所需要的工作量
* 6）需求不確定性的程度和技術風險因素不僅會影響故事進度，而且會影響團隊實施該故事的方法
* 7）高風險的故事（無規律或者波動的）將安排在早期的迭代中
9.創建功能清單
* 1）功能清單是產品團隊確定的產品性能、功能和故事的一列表，通常包括ID、名稱、簡要描述、優先級別、探索系數和估算等項目
* 2）發布計劃和迭代計劃都會使用功能清單上的數據
* 3）主要分為兩個工作：誰做這項工作、確定和定義功能清單項目的做法
* 4）有3個因素與理解程度密切相關：涉及的人、確定這些人要履行哪些職責、把功能拆分成若干可執行的塊
C.發布計劃
1.發布計劃是團隊在項目數據表中所描述的在項目目標和約束內實現產品構想的路線圖
2.故事驅動表現在它將計劃和執行的主要重點從任務轉變為產品功能
3.敏捷目標是在任何一次迭代結束時都能具備可以部署的產品，即功能、測試、文檔和其他可交付的產品可以打包并部署
4.客戶價值和風險是推動發布計劃的兩個主要因素
5.發布計劃的主要任務是以價值風險為基礎把故事分配到迭代中
6.在將故事分配到迭代時，最優先考慮的是交付產品團隊規定的產品價值，然后是制定故事的進度計劃，以便遲早降低項目風險。但有時，技術風險需要放在首要位置
7.其他因素，如資源的可用性、依賴關系以及其他，都排在價值和風險因素之后
8.范圍演變
* 1）范圍蔓延不是問題，如果范圍改變是隨意和惡意想出來的，那么它們對于項目有害無利。但一般而言，從滿足不斷演變的客戶需求出發、在認同它對項目的影響的基礎上做出的范圍變更會提高項目成功的可能性
* 2）讓功能隨著項目周期不斷演變（當然有一定的限度），這比在開始時幻想需求、又在沒有客戶經常參與的情況下構建功能會更快速、更節省。構建最少功能策略以及簡單、適度地適應變化會使團隊受益匪淺
* 3）敏捷開發進關于焦點和平衡的：集中于項目的主要構想和目標，強迫做出困難的權衡決策，以保持產品各方面的平衡
* 4）產品范圍的推動因素應該包括：客戶價值、技術可行性、成本和關鍵的業務進度需要
* 5）“簡化非常關鍵，它是最大程度地減少不必要的工作的藝術”——《敏捷宣言》
* 6）敏捷項目中的短期迭代結合迭代結束時的客戶評審，使整個團隊（包括開發人員、客戶和經理）都認清了現實
* 7）“當進度出現問題的時候，瀑布式方法縮減任務，通常是減少測試，而敏捷方法減少功能，前者降低質量，后者縮小范圍”
* 8）短期迭代也讓開發人員精力高度集中。由于每隔幾周就有一個截止日期臨近，因此，“增強”功能的傾向就會減少
9.第0次迭代
* 1）“0”意味著在時間期限內沒有任何有用的東西（即功能）可以向客戶交付
* 2）第0次迭代有助于團隊在預期和適應之間保持平衡
* 3）有可能做為構想階段的一部分
* 4）使用不熟悉技術之前可能需要的培訓時間
10.第1~N次迭代
* 1）制定發布計劃涉及的活動
* 確定已知的風險對迭代計劃的影響
* 確定進度目標（不考慮可實現性，只從產品管理的角度確定進度目標）
* 為每次迭代編制主題
* 將故事卡片分派給每次迭代，必要時，平衡價值、風險、資源和依賴關系
* 結合故事卡片布局（通常在墻上）、完事的發布計劃或者項目停車場圖總結該計劃
* 運用權衡矩陣，必要時，調整完成的計劃
* 2）客戶價值和風險是制定功能進度計劃的主要因素
* 為了降低風險，會首先選擇實施高風險的功能，而推遲開發正常情況下應該首先實施的高價值的功能
* 應該認真檢查風險清單，確定風險降低對發布計劃的影響，特別是改變功能順序和納入高風險項目對發布計劃的影響
* 3）目標交付日期，由營銷部門、高層管理或者客戶共同選擇并確定。該目標確定項目團隊之外的人想要得到什么東西
* 4）對于每次迭代，團隊應該制定一個指導主題，這有助于團隊確定重點并確保在功能的深度和廣度兩者之間保持平衡
* 5）主題的制定通常是從分配功能到迭代的流程中演變成而來，但有時也可以預先設定一個主題
* 6）其他技巧幫助制定可靠的進度計劃：
* 在每次迭代中為迭代評審期間找出的已知變化分配額外的時間，在每次迭代中放入一個標為“返工和意外事故”的故事卡
* 對于探索系數高的項目，在項目結尾留出一個或者多個“空的”迭代
* 7）在制定發布計劃時，為每次迭代多安排10%的時間以應對返工和意外事件，可以使計劃更加精確
11.第一個可行的部署
* 1）第一個可行的部署（FFD），即確定第一個可以部署產品的迭代
* 2）開發團隊可以獲得收入，也有助于驗證產品概念并得到用戶反饋
* 3）可部署和已部署問題一直困擾著敏捷主義者。迭代開發建造產品的可部署部分。這些可部署的部分在隨后的開發中會根據不同情況逐步實施或者不被實施（部署）。實際部署更受歡迎，但并非必需
12.估計
* 1）“如何估計”這個問題暗含幾個問題：
* 估計未知因素
* 按功能而非活動進行估計
* 循序漸進地估計
* 估計會非常浪費時間
* 估計與設定界限
* 使用故事點和員工工作時間估計
* 2）面對未知因素時，您是在猜測而不是估計，這也是我們唯一能做的，這也是進度和成本被看作是限制而非估計的原因
* 3）項目經理必須學會將他們估計任務的經驗運用到估計功能上，他們逐個地估計功能，而不是估計整個項目的需求
* 4）精益思想的原則即減少浪費，對于研究活動來說，就是消除或減少不直接產生客戶價值的活動
* 5）一個減輕估計負擔的方法是把估計和設定界限區分開來。設定界限是基于擁有足夠的有關項目規模的信息，從而感覺發布計劃是可行的
