本書概覽
2 敏捷概述
2.1 可確定工作與高度不確定的工作
可確定性的工作項目具有明確的流程，它們再以往類似的項目中被證明視行之有效的，并且執行的不確定性和風險通常較低。
高度不確定的項目變化速度快，復雜性和風險也高。是探索性的。這些特點可能會給傳統預測法帶來問題，傳統預測法旨在預先確定大部分需求，并通過變更請求過程控制變更。
而敏捷的出現是為了在短時間內探討可行性，根據評估和反饋快速調整。
2.2 《敏捷宣言》及思維模式
四大價值觀
1 個體以及互動而不是過程和工具
2 可用的軟件而不是完整的文檔
3 客戶合作而不是合同談判
4 應對變更而不是遵循計劃
十二大原則
1 我們的最高目標是，通過今早持續交付有價值的軟件來滿足客戶的需求
2 歡迎對需求提出變更，即使在項目開發后期也不例外。敏捷過程要善于利用需求變更，幫助客戶獲得競爭優勢
3 要經常交付可用的軟件，周期從幾周到幾個月不等，且越短越好
4 項目實施過程中，業務人員與開發人員必須使用通力協作
5 要善于激勵項目人員，給予他們所需要的環境和支持，并相信他們能夠完成任務
6 無論是對開發團隊還是團隊內部，信息傳達最有效的方式都是面對面的交談
7 可用的軟件是衡量進度的首要衡量標準
8 敏捷過程提倡可持續的發展。項目發起人、開發人員和用戶應該都能夠始終保持步調穩定
9 對技術的精益求精以及對設計的不斷完善講提高敏捷性
10 簡潔，即盡最大可能減少不必要的工作，這是一門藝術
11 最佳的架構、需求和設計講出自于自組織團隊
12 團隊要定期反省怎樣做才能更有效，并相應地調整團隊的行為
敏捷方法
根據具體情況，敏捷可用是一種方法、手段、實踐、技術、框架。本實踐指南使用“方法”一詞。
敏捷方法囊括，各種框架和方法的涵蓋性術語，它指的是符合敏捷宣言價值觀和原則的任何方法、技術、框架、手段或實踐。
下圖把敏捷方法和看板方法視為精益方法的子集，原因是他們都是精益思想的具體實例，反映了關注價值、小批量、消除浪費。
兩種策略踐行敏捷價值觀和原則
一種正規的敏捷方法，那變更和裁剪前，需花時間學習和理解敏捷方法，且不成熟和隨意的裁剪會讓敏捷方法效果大打折扣。
一種以適合項目背景的方式對項目實踐進行變更，以便在核心價值觀或原則方面取得進展。使用
使用時間盒創建功能，使用特定技術迭代優化功能，在適用于特定項目背景下，考慮將一個大項目劃分為幾個部分發布。不為敏捷而敏捷。
2.3 精益與看板方法
敏捷和看板方法被視為精益思想的衍生物。精益思想是一個超集，與敏捷和看板方法擁有共性。
比如：交付價值、尊重人、減少浪費、透明化、適應變更、持續改善等
2.4 不確定性、風險和生命周期選擇
不確定性->風險->較少的工作增量->迭代、增量方法
- 非常短的反饋循環
- 頻繁調整過程
- 重新進行優先級排序
- 定期更新計劃
- 頻繁交付
需求、技術程度的不確定性
簡單的->線性方法；繁雜的、復雜的->自適應方法；混亂的->冒險
當技術和需求的不確定性都很高時，項目會極端復雜，陷入無序狀態。為了使項目可靠，要遏制其中一個不確定性的變量。
迭代、增量和敏捷方法適用一下特點的項目：
-需要研究和開發
-變更速度極快
-具有不明確或未知的需求、不確定性或風險
-最終目標難以描述
通過構建一個小的增量，對其進行測試和評估，團隊可用在短時間內以低成本探索不確定性，降低風險，最大程度地實現商業價值的交付。
3 生命周期選擇
預測型：充分利用已知和已證明的事務，不確定性和復雜性減少，允許項目團隊將工作分解成一系列可預測的小組。
迭代型：允許對部門完成或未完成的工作進行反饋，從而對該工作進行改進和修改。
增量型：可向客戶提供完成的可交付成果，讓客戶能夠立即使用。
敏捷型：同時利用迭代屬性和增量特征。
先使用敏捷應對不確定性、復雜性、風險，然后到明確、可重復的發布階段。
如敏捷的逐步過渡。
預測為主，敏捷方法處理不確定性、復雜性或范圍蔓延機會項目的一部分，而使用預測管理項目的其余部分。
敏捷為主，當某個特定要素不可協商或者使用敏捷方法不可執行時，可能會使用這種方法。
混合敏捷方法：
漸進過渡設計要增加更多的迭代技術，以便改進學習，加強團隊和相關方的一致性。可以現在一個風險不大、具有中低程度不確定性的項目中嘗試新技術，在組織成功的使用混合方法后，在嘗試增加更多的增量技術，以加快發起人的價值和投資回報，以及使團隊適應并接受變革的就緒情況而調整的漸進混合過渡
剪裁項目的影響因素：
4 實施敏捷：創建敏捷環境
4.1 從敏捷思維模式開始
敏捷方法管理項目，團隊要采用敏捷思維模式，一下問題，有助于制定實施策略：
項目團隊如何以敏捷方式行動?
為了使下一個交付周期受益，團隊需要快速交付哪些成果并獲得早期反饋？
團隊如何以一種透明的方式行動？
為了專注于高優先級的項目，可以避免哪些工作?
仆人式領導對團隊打成目標有何益處？
4.2 仆人式領導為團隊賦權
仆人式領導通過對團隊服務來領導團隊的實踐，注重理解和關注團隊成員的需要和發展，旨在使團隊盡可能達到最高績效。
仆人式領導的作用時促進團隊發現和定義敏捷，實踐并傳播敏捷，按一下順序從事項目工作：
目的，與團隊一期定義目的，以便圍繞目標進行何做互動。整個團隊在項目層面而不是在人員層面優化。
人員，目標確立后，鼓勵團隊創造一個人人都能成功的環境。要求每個團隊成員在項目中做出貢獻。
過程，不要機會遵循“完美”的敏捷過程，而是要注重結果。如果跨職能團隊能偶常常交付完成的價值并反思產品和過程，團隊就是敏捷的。
促進團隊的成功：
提升自我意識；傾聽；為團隊服務；幫助他人成長；引導與控制；促進安全、尊重與信任；促進他人精力和才智提升
成功的敏捷團隊信奉成長思維模式，團隊成員自己能能夠學到新技能。
4.2.1 職責
通過管理管理，在團隊內和組織中建立溝通與先做
4.2.2.1 促進作用
工作重點從“管理協調”轉向“促進合作”，幫助每個人各盡所能的思考和工作，鼓勵團隊參與、理解，并對團隊輸出共同承擔責任。幫助團隊創建可接受的解決方案。
如，在團隊內部與團隊之間幫助發現瓶頸問題，并進行相應溝通，然后，團隊解決這些問題。
鼓勵大家通過交互式會議、非正式對話和只是共享展開協作。通過成為公正的搭橋者和教練來做到這一點，而不是代替責任人作出決策。
4.2.2.2 消除組織障礙
敏捷價值觀關于個人與過程和工具的交互。對仆人式領導而言，更好的職責是認真審視阻礙團隊敏捷或組織敏捷的過程，并努力使其合理化。
仆人式領導還穎關注其他冗長的過程，這些過程往往造成瓶頸問題，阻礙團隊或組織的敏捷性。
4.2.2.3 為他人貢獻鋪路
與各方合作，為團隊鋪路，讓團隊盡其所能。影響項目，鼓勵組織以不同方式思考。
除仆人式領導，團隊成員要重視自身的人機關系技能和情商技能，而不僅僅是專業技能。
團隊每一個成員都要努力展示更多的主動性、正直、情商、誠實、合作態度、謙虛和以不同方式溝通的意愿，才能促進整個團隊攜手共進。
4.2.2.4 職責
教育相關方，使其了解為什么要敏捷如何敏捷，根據優先級說明商業價值的好處，對被賦權團隊加強問責，提高工作效率，并通過頻繁的評審改進質量。
通過指導、鼓勵和幫助為團隊提供支持。
通過技術管理活動，如量化風險分析來幫助團隊。
慶祝團隊的成功，為團隊與外部合作提供支持，并起到橋梁作用。創建互相欣賞的積極氛圍，建立加強合作的良好意愿。
項目經理的價值不在于他們的崗位，而在于他們能夠讓每個人都變得更好。
4.2.2 項目經在敏捷環境中的角色
是未知的，務實的敏捷實踐者和組織認識到，許多情況下，項目經理都能創造重要的價值。關鍵的區別在于，他們的角色和職責看起來有些不同。
4.2.3 項目經理應用仆人式領導
PMBOK，項目經理：由執行組織委派，領導團隊實現項目目標的個人。
PM習慣于作為項目的協調中心，負責跟蹤項目的狀態，并向組織中的其他成員反應，當項目被分解為鼓勵的功能時，這種方法沒有問題。
但對于高不確定性的項目，復雜性時一個人無法管理的，而跨只能團隊技能協調自身的工作，還能與業務代表（產品負責人）開展合作。
敏捷項目，PM的角色轉變為團隊和管理人員提供服務，仆人式領導，工作重點變為引導需要幫助的人，促進團隊的合作，保持與相關方的需要一致。PM經理要鼓勵將責任分配給團隊成員，分配給那些掌握完成任務所需只是的人。
4.3 團隊構成
敏捷的價值觀和原則有一個核心宗旨，強調個人和交互的重要性。敏捷優化了價值流，強調了向客戶快速交付功能，而不是怎樣“用”人。
要善于激勵項目人員，為他們提供所需要的環境和支持，信任他們能夠完成工作。
團隊考慮如何優化價值流時，好處顯而易見：
人員更有可能合作；
團隊更快地完成有價值的工作；
由于不從事多任務，也不必重新建立環境，團隊減少了時間浪費。
4.3.1 敏捷團隊
最有效的敏捷團隊由3-9個成員組成，集中在一個團隊工作場所工作，100%專職成員。鼓勵自我管理團隊，由團隊成員覺得誰執行下一階段定義的范圍內的共工作。
團隊集體對工作負責并共同擁有完成工作所需的所有必要技能。
協同工作而不落入迷你瀑布的陷阱中。
4.3.2 敏捷的角色
跨職能團隊成員
產品負責人
團隊促進者
4.3.3 通才型專家
I型人才和T型人才，I有深度，T能夠通過支持在一個領域補充自身的專業只是，在相關領域的技能雖有欠缺，但擁有良好的合作技能。
團隊的目標，提高國恒效率，優化整個團隊的產能。
團隊規模小會促進團隊合作，產品負責人確保團隊從事最高價值的工作。
4.3.4 團隊結構
相互協助的跨職能團隊，自組織團隊。
4.3.5 專職小組成員
100%專職工作，作為一個團隊持續協作，更高效
多任務切換，會降低團隊工作的產出，并影響團隊預測交付能力的一致性
如在兩個任務中切換，并非各占50%，可能損失率在20~40%，人一心多用時更容易犯錯，任務切換消耗工作記憶。
4.3.6 團隊工作場所
平衡公共和社交區域（公共區）與個人工作不被打擾的安靜區或私人區域。
在不同地點工作時，使用文檔共享、視頻會議等等協作技術幫助人員實現遠程協作。
分散式團隊掛你溝通：魚缸窗口、遠程結對
如，長期視頻會議鏈接，自然看到彼此互動，減少不同地點工作協作的滯后性；使用虛擬會議工具來共享屏幕，包括語言和視頻鏈接，建立遠程結對
4.3.7 克服組織孤島
組織敏捷團隊的最好開端是，擁有基本信任和安全的工作環境，確保團隊成員都有平等的話語權，意見都能被聽到并得到考慮。再加上構建敏捷思維模式，再此基礎上，其他挑戰和風險都能夠緩解。
孤島組織，給跨職能敏捷團隊的組建帶來重重障礙，跨職能團隊想不同的管理人員報告，管理人員采用不同的標準衡量他們的績效。管理人員需要關系不是資源利用率，而是過程效率。（和基于團隊的指標）
來自不同職能團隊，培養管理者和領導的敏捷思維模式，敏捷開發早期就讓他們參與其中。
為克服孤島問題，要與團隊成員的不同管理者合作，讓他們為跨職能團隊安排必要的專職人員。這樣不僅盡力團隊協作，而且讓組織看到怎樣用人才能優化癥狀進行中的項目和產品。
敏捷項目領導，首要重點放在如何組建跨職能團隊，讓所有團隊成員100%投入團隊工作。
5 實施敏捷：在敏捷環境中交付
5.1 項目章程和團隊章程
敏捷項目，團隊至少還需要項目愿景或目標，以及一組清晰的工作協議。
敏捷項目章程回答：
我們為什么要做這個項目？這是項目愿景
誰會從中受益?如何受益？這可能是項目愿景/項目目標的一部分
對此項目二驗，達到哪些條件才意味著項目完成？這是項目的發布標準
我們將怎樣合作？這說明預期的工作流
團隊章程：（團隊的社會契約，規定團隊成員之間彼此互動的方式）
團隊價值觀，例如可持續的開發速度和核心工作實踐
工作協議，例如“就緒”如何定義，這是團隊可接受工作的前提，“完成”如何定義，這樣團隊才能一致的判斷完整性；考慮時間盒；或使用工作過程限制
基本規則，例如有關一個人在會議上發言的規定
團隊規范，例如團隊如何對待會議實踐
5.2 常見敏捷實踐
5.2.1 回顧
讓團隊學習、改進和調整其過程
關鍵時刻回顧：
團隊完成一個發布或加入一些功能時
自上次回顧以來，又過了幾周時間
當團隊出現問題時，以及團隊協作完成工作不順暢時
當團隊達到任何其他里程碑時
團隊可以計劃用充足的時間學習受益，無論在項目中還是結束時。團隊需要了解他們的工作產品和工作過程。團隊可以計劃用充足的時間組織回顧，以此收集數據、處理數據、在決定之后要嘗試的實驗做法。
回顧針對定性的（人的感覺）和定量的（衡量指標）數據，然后利用這些數據找到根源，設計對策，并制定行動計劃。
要對所有改進事項進行排序，并確定如何衡量結果，選擇合適數量的改進事項。
5.2.2 待辦事項列表編制
工作開始之前，不需要為整個項目創建所有故事，只需要了解第一個發布的主要內容正確即可，然后就可以為下一個迭代開發足夠的項目。
考慮使用影響地圖查看產品如何組合在一起，一般產品負責人領導這項工作。
產品負責人（或產品負責人價值團隊）可能會繪制一個產品路線圖，以顯示預期的可交付成果序列。產品負責人根據團隊的實際成果重新規劃路線圖。
5.2.2 待辦事項列表的細化
團隊通常有一個目標，每周用不超過1小時的實際來為下一批工作細化故事。盡可能把時間花在工作上，而不是計劃上。
細化過程：
基于流程的敏捷的即時細化、基于迭代的敏捷團隊在兩周迭代中用1個小時的時間盒討論、基于迭代的敏捷團隊的多次細化討論。
細化會議：（產品負責人）
鼓勵團隊在開發人員、測試人員、業務分析人員和產品負責人三方面開展合作，一起討論和撰寫故事。
把整個故事的概念呈現給團隊。團隊進行討論，并根據需要將其細化為許多故事。
與團隊一起尋找各種方法探索和撰寫故事，確保所有的故事都足夠小，以便團隊能源源不斷的交付完成工作。考慮每天至少完成一個故事。
5.2.4 每日站會
一般不超過15分鐘，過一下看板或任務板，團隊任何人都可以主持站會。要體現團隊工作需要的密切合作，進行順利，站會就非常有用。要針對團隊何時需要站會、站會是否有效等問題有意識地做出決定。
基于迭代的敏捷，輪流回答：
上次站會以來我都完成了什么？
從現在到下次站會，我計劃完成什么？
我的障礙（或風險或問題）是什么？
基于流程的敏捷，將注意力集中在團隊的產出上，團隊從右到左對看板進行評估：
我們還需要做些什么來推進這一工作？
有人在做看板所沒有的事情嗎？
作為一個團隊，我們需要完成什么？
工作流程是否存在瓶頸或阻礙？
反模式：站會變成狀態報告會議、問題變得明顯時，團隊才開始解決問題，站會是為了發現存在問題，而不是解決他們。將問題添加到停車場區，然后創建另一次會議，在站會后再召開。
5.2.5 展示/評審
當團隊以用戶故事的形式完成特定功能時，團隊會定期展示工作產品。看過展示后，產品負責人接受或拒絕故事。
基于迭代的敏捷，團隊在迭代技術是展示所有已完成的工作項，基于流程的敏捷中，團隊在需要時展示完成的工作，通常是當完成的功能累計到足夠構建一個連貫組合時。團隊都需要反饋來決定何定需要產品反饋。
一般，每周至少展示一次團隊的工作產品。防止朝著錯誤的方向前進，讓團隊成員保持產品開發足夠清晰，按照自己希望或需要的頻率構建一個完整的產品。
5.2.6 規劃基于迭代的敏捷
不同團隊能力各不相同，不同負責人的典型故事大小也各不相同。團隊要考慮迭代中所能完成工作的能力。
產品負責人當了解，當人員不可用時，團隊能力降低。團隊無法完成與前一時期相同的工作量。在能力降低的情況下，團隊只會計劃相應能力能夠完成的工作。
團隊估算能完成的工作，也是一種能力的衡量。團隊無法100%確定自己能交付什么，他們無法知道意外情況。當拆分故事使其變小時，團隊看到的時產品的完成進度，團隊就會知道他們將來能夠做什么。
敏捷團隊在一個工作塊中不會只計劃一次。開始計劃一點，交付、學習，然后再一個持續的循環中重新規劃更多的東西。
5.2.7 幫助團隊交付價值的執行實踐
重視質量
持續集成
再不同層面測試
驗收測試驅動開發（ATDD），atdd團隊一起討論產品的驗收標準
測試驅動開發（TDD）和行為驅動開發（BDD），在編寫創建產品之前編寫自動化測試，幫助人員設計產品，防范產品錯誤
刺探（時間盒研究或實驗），在團隊需要學習一些關鍵技術或功能要素時，刺探會很有幫助
5.2.8 迭代和增量如何幫助交付工作產品
幫助團隊為交付和多種反饋創建一個節奏，團隊會收到關于產品的外觀和運行方式的反饋，團隊成員回顧如何檢查和挑戰有關過程以取得成功
團隊應經常為反饋進行演示，并展示進度。鼓勵PMO和其他感興趣的人觀看演示，以便決定項目組合的人能夠看到實際的進展。
演示或評審時敏捷項目流程的必要組成部分。為團隊的交付節奏安排適當的演示。
5.3 解決敏捷項目的挑戰
5.4 敏捷項目的衡量指標
狀態避免西瓜現象，外綠里紅。
替代性指標（如完成百分比，紅黃藍燈）不如經驗指標（如已完成功能）更有用。
定量指標衡量進度，定性指標衡量團隊情況。
5.4.1 敏捷團隊的衡量結果
敏捷傾向于基于經驗和價值的衡量指標，而不是預測型衡量指標。敏捷衡量團隊所交付的成果，而不是團隊預測將交付的成果。
對于習慣掌握項目基準、估算的掙值和投資回報率（ROI）的團隊，可能會實施一個項目而不是管理一個基準感到茫然。敏捷基于對客戶有可見價值的工作產品。
基準通常是嘗試預測的產物，敏捷中，團隊故事最多限于未來幾周時間，如果團隊可變性不高，團隊能力文檔，對未來幾周做出更好的預測。
團隊并不能創造出更多的工作能力，然而，工作量越少，人員就越有可能交付。
6 關于項目敏捷性的組織考慮因素
項目存在于組織環境下，文化、結構和政策可能會影響到所有項目的方向和成果。這些動態編號可能會對項目領導提出挑戰。
項目領導無法根據自己的意愿來改變組織動態變化，但可以有技巧的引導這些動態變化。
6.1 組織變更管理
《組織變革管理實踐指南》建議：
說明變更動態變化的模型
實現變革的框架
項目、項目集、項目組合層面的變革管理實踐的應用
6.1.1 變革管理驅動因素
與加速交付相關的變革（接受組織可能尚未做好加速納入這些輸出的充分準備）
與敏捷方法相關的變革（高級別協作可能需要團隊、部門和供應商之間的頻繁交流）
6.1.2 變革就緒情況
變革友好型特征：
管理層的變革意愿
組織在員工認知、審核和評估方式上做出改變的意愿
集中或分散項目、項目集和項目組合管理職能
專注于短期預算和指標而不是長期目標
人才管理成熟度和能力
變革阻礙特征：
工作被分解為部門孤島，阻礙加速交付的依賴關系，而不是構建在能力中心指導下的跨職能團隊
采購策略基于短期定價策略而不是長期能力
獎勵領導的一句時本地效率而不是端到端項目交付流或整體優化情況（就組織而言）
員工屬于特定領域人才，實現技能多元化的工作或獎勵有限，不重視培養T型專家人才
分散化項目組合使用員工分配到過多的項目，而無法專注于單個項目
項目領導嘗試多種方法加速文化兼容性：
積極明確的管理層支持
變革管理實踐，包括溝通和引導
諸葛項目應用敏捷實踐
向團隊增量的引入敏捷實踐
通過采用適用的敏捷技術和實踐示范引導
6.2 組織文化
組織文化就是組織的DNA，組織的核心標識。文化影響敏捷方法的使用。
“文化能把戰略當早餐吃”-彼得德魯克
6.2.1 創建安全環境
安全、誠實、透明
6.2.2 評估文化
根據組織文化決定和要求來確定優先級，引導這些動態變化，項目領導應花時間去評估組織通常所關注的重點。
6.3 采購和合同
多層結構，除了在單個文檔正式說明整個合同關系，項目方可通過在不同文檔說明不同方面來提高靈活性
強調價值交付，許多供應商關系是由中間人為因素的固定里程碑或“階段關口”控制，而不是由增量業務價值的完全可交付成果控制。通常，這些控制會限制利用反饋來改進產品。于之相反的是，里程碑和支付項目可以根據價值驅動可交付成果來構建，以增強項目敏捷性。
總價值增量，項目分解為總價微型可交付成果，而不是將整個項目范圍和預算鎖定到單個協議中
固定時間和材料，將整體預算限制為固定數量
累進的時間和材料，高效率獎勵，低效率扣除一定費用
提前取消方案，如在一半時間便可交付足夠價值，則為剩余一部分支付取消費用
動態范圍方案，調整功能以適應能力
團隊擴充
支持全方位供應商，多供應商策略
6.4 商業實踐
需求產生時，組織創新能力的意愿和能力時組織敏捷的標志，透明和開發協作至關重要
跨職能團隊交付價值時，團隊和個人可能會遇到組織多種支持職能方面的問題
如定期交付價值，財務部門和采購部門需頻繁交付價值并與團隊保持同步
團隊開始協作后，對內部管理策略提出挑戰，人力資源要重新審視績效評估
組織發展到更高敏捷性時，業務部門要更改交互方式并履行自己的職責，以提高整個組織的效率
6.5 多團隊協作和依賴關系（擴展）
6.5.1 框架
敏捷方法如scrum和極限編程，專注與單個小型且集中辦公的跨職能團隊活動。
項目集或項目組合中多個敏捷團隊協作，目前有許多框架，如大規模敏捷框架、大規模敏捷開發、規范敏捷和方法scrum of scrums來應對
6.5.2 考慮事項
團隊需要將多個敏捷項目工作擴展到單個敏捷項目集中
6.6 敏捷和項目管理辦公室（PMO）
PMO目的：
指導商業價值，確認目標
提供團隊教育、培訓和項目支持
針對給定項目或項目集提供相關商業價值方面的管理建議
6.6.1 敏捷PMO為價值驅動型
所有項目都應在合適的實踐為合適的受眾提供合適的價值
以客戶協作思想為基礎，并存于所有PMO項目集中
PMO應努力按需交付并緊跟客戶需求，確保了解并適應他們的需求，內部創業方法
6.6.2 敏捷PMO為面向創新型
強制執行某些解決方案或方法
6.6.3 敏捷PMO為多學科型
將其PMO轉換為卓越敏捷中心以提供一下服務：
制定和實施標準
通過培訓和指導發展人才
多項目管理，不同項目交流協調敏捷團隊，如分享進度、問題、回顧性發現和改進等，借助適當的框架，幫助管理層的主要客戶發布和項目組合曾的投資主題
促進組織學習
管理相關方
招聘、篩選和評估項目領導
執行專業化項目任務
6.7 組織結構
組織結構會嚴重影響其轉向新信息或轉變市場需求的能力：
地理
職能結構，高度職能結構的項目可能會在組織內部協作方面遇到很大阻力
項目可交付成果的大小
項目人員分配
重采購型組織，通過供應商實施項目
6.8 組織演變
將變更過程視為一個敏捷項目
7 行動呼吁
檢查、適應和透明度時成功交付價值的關鍵因素
學習、實驗、獲取反饋、再實驗
PMI和敏捷聯盟
https://www.projectmanagement.com/blogs/347350/Agile-in-Practice
