最近在著手準備ACP考試，仔細看了下相關的書籍，對每章知識點進行相應的整理，想著記錄下來，后續如有更好的理解，再回頭更新。
之后會按照以下目錄進行梳理：

• 敏捷的理念
• 價值驅動交付
• 干系人管理
• 打造高績效團隊
• 適應性計劃
• 發現與解決問題
• 持續改進
• 敏捷的實踐

發現與解決問題

• 問題概述
  敏捷的核心是為了持續改進，針對過程中發現的問題，及時反饋和修正，通過高頻次的反饋，發現問題，分析問題，解決問題。
  盡早發現問題和處理變更能有效地減少重復工作從而降低成本，因而缺陷循環時間的概念應運而生，即故障引入到修復的時間，長短代表來對應的修復成本。
  問題的處理流程一般如下，可以通過pdca來理解：

  • 定義問題；
  • 收集信息
  • 分析原因
  • 備選方案
  • 選擇方案
  • 實施方案
  • 跟蹤反饋
  • 問題是否被解決，如有：結束；沒有：重新定義問題

• 發現問題
  以下是發現問題的多個途徑和方法：
  每日站會：站會上的第三個問題：遇到了什么阻礙，就在要盡早發現團隊成員在項目中遇到的問題，盡早曝光，及時解決，而不是等到客戶抱怨不斷或者等到回顧會再來總結；
  站會只需要明確問題三要素即可：問題是什么？誰來解決？什么時間解決？
  循環時間：從任務開始到任務結束的時間。任務結束的定義：獲得了客戶的驗收，因為這樣才能交付商業價值，才算真正的完成；
  循環時間和在制品數量有很大關系，而在制品會帶來浪費、返工和效率的下降，敏捷就是為了最小化循環時間；
  公式：循環時間 = 在制品數量/團隊吞吐量；
  吞吐量在于預測團隊未來的績效，循環時間可以對客戶就交付日期做可靠的承諾。
  故障泄漏
  故障是無法避免的，但是可以針對“已發現的故障泄漏數量”來追溯這類故障產生的原因，通過這個環節幫助團隊不斷評估并提高質量保證和質量控制的效率。
  質量標準
  質量是產品的生命，發現問題&解決問題的目的就是為了確保交付高質量的產品。
  質量標準和時間會包含如下內容：

• 用客戶驗收來衡量產品質量，即客戶的滿意才可以作為驗收標準；

• 盡可能自動化測試；

• 確保每個迭代都進行測試；

• 在下個迭代前，至少修復90%的已發現缺陷；

• 鼓勵質量保證和質量控制人與開發、業務一起工作，對每個功能特性的驗收標準達成一致理解；
  在評估質量時，可以借助一些工具，比如：控制圖、趨勢圖、根本原因分析、魚骨圖、流程圖等
  趨勢圖：基于現實的數據來預測將來的可能性，比如：在累計流量圖中，可以通過趨勢分析來預測完工的日期；
  控制圖：控制圖是用來確定一個過程是否穩定，或者是否具有可預測的績效，是屬于質量控制的常用工具。控制圖的元素主要包括：

  • 均值；
  • 控制界限，常被設置在正負3西格瑪處
  • 規格界限（客戶能接受的最大偏差）
  • 失控（判定失控的范圍：超出界限或是連續7個點在同一側）
  • 七點原則
  • 非隨機原因

• 解決問題
  解決問題的活動

  • 持續集成：持續集成是敏捷項目管理中盡早發現問題的一個典型應用，在現在項目中使用越來越多；
    有如下幾點好處：

    • 及時獲悉代碼合并的錯誤
    • 盡快修復錯誤而不是拖延到發布
    • 及時獲取反饋信息
    • 進行頻繁的單元測試
    • 快速回退版本
      集成測試縮短了問題解決的周期，降低了變更應對的成本；

  • 風險探測：是研究探索性問題的一個快速方法，通過前期小規模實驗和探測來降低項目的風險。
    “快速失敗”的模式，相比于把剩余的資源和資金投入到最終必將失敗的項目中去，“快速失敗”是有益的，節省成本&消除浪費。

  • 頻繁的確認與驗證：通過此類操作，用以改進和提升產品交付的質量；其實在項目中很多實踐都或多或少的運用到：

    • 結對編程：立即反饋；
    • 單元測試：極限編程上一步就是單元測試，持續集成同理，反饋都很快；
    • 客戶合作：頻繁地跟客戶合作和增量交付，及時得到客戶反應和確認，更好的交付高質量產品；
    • 每日站會：每天反饋進展和障礙；
    • 評審會：為來確保交付給客戶是被需要的，也是一種確認和驗證。

    頻繁的驗證也是為了盡早發現問題，將變更成本降到最低；

  • 測試驅動開發（TDD）：主要流程包括：測試、編碼和重構；
    主要優點：

    • 聚焦：聚焦于測試，出發點還是功能需求，確保功能是滿足客戶需求的；
    • 全面：在編碼前編寫測試用例可以最大限度地對代碼進行充分的測試，更高的測試覆蓋率會提升系統的質量；
    • 早期：越早、越頻繁的測試會及時發現開發過程中的問題，避免問題留到后面產生昂貴的代價和修復成本；
    • 靈活：小規模開展單元測試可以提升系統的可擴展和靈活性；

    存在的不足：

    • 同一個人編寫測試代碼和編碼，會對需求的測試和編碼存在同樣的誤解；
    • 對用戶接口類的功能測試比較薄弱，需要投入大量時間；
    • 維護成本高，尤其在變更比較大的情況下，不僅要維護代碼，還要維護測試代碼。

  • 驗收測試驅動開發（ATDD）：測試的關注點從代碼轉向需求，在編寫代碼前就確認功能的驗收標準。

  • 探索性測試：作用在成品軟件上，為了提高產品質量；

  解決問題的步驟

  • 收集數據：
    • 時間軸：相當于劃定好時間范圍，在范圍內的問題進行回顧；
    • 三五成型：3個5，針對5個人，在5分鐘內問5個問題，收集反饋；
    • 顏色標識：用帶顏色的記事貼貼在時間軸上，描述情緒或士氣高低；
    • 尋找優勢：尋找優勢，爭取在下一個迭代中發揮；
    • 滿意度直方圖：迭代中滿意度以直方圖展示；
    • 團隊雷達：多維度數據展示工具，從多個領域去衡量當前迭代表現。
  • 分析原因：
    • 頭腦風暴：安靜書寫、循環發言、自由討論出想法和靈感，通過其他技術（親和圖、思維導圖等）方式進行歸納分類，使用100分法、名義小組等方式進行排序；
    • 名義小組：促進頭腦風暴的一種技術，投票表決；
    • 五問法：起源于精益思想，目的是幫助找到問題的根本原因。
    • 魚骨圖（因果圖、石川圖）：常用的分析原因的方法，五類因素：人、機、料、法、環。
  • 采取行動：敏捷團隊會采用一些群體決策技術對各種解決方案進行確認，確保達成一致的認識，并設置目標進行推進實施；
    常用的技術有：
    • 簡單主題：幫助團隊就采取的行動達成一致。比如在回顧會上使用的：海星圖、快船等方式，就是確認幾個簡單的主題：好的keep，不好的stop；
    • SMART目標：
      • specific：目標是明確具體的；
      • measurable：目標是可以衡量的，即是有明確驗收標準的；
      • attainable：目標是可以達到的；
      • relevant：目標是于組織的其他目標具有相關性；
      • time-based：是有明確截止日期的。