2.1.軟體開發應該有乙個計畫並相應地跟蹤。
2.1.1.你的隊友想知道你在做什麼，這樣他們就可以有效地與你合作。
2.2.敏捷開發是一種軟體開發模型，廣泛用於快速交付高質量的軟體。
2.3.要了解敏捷開發實踐，首先必須了解敏捷哲學。
2.4.敏捷開發誕生於 2001 年，是來自極限程式設計、Scrum、功能驅動開發和實用程式設計等先前開發流程的領導者之間的合作。
3.1.個人和互動優先於流程和工具。
3.2.工作軟體高於詳盡的文件。
3.3.客戶合作優先於合同談判。
3.4.應對變化比遵循計畫更重要。
3.5.雖然右邊的專案有它的價值，但我們更看重左邊的專案。
3.6.敏捷實踐側重於與團隊成員和客戶的協作。
3.7.識別、接受和消化變化。
3.8.專注於迭代改進，而不是大規模的開發和發布。
3.8.1.敏捷開發模型經常與瀑布模型形成對比，瀑布模型指的是在專案開始時進行詳盡的規劃，這是一種過時的做法。
4.1. scrum
4.2.看板。
5.1.不要使用像 Scrum 這樣的固定週期衝刺。
5.2.看板定義工作流中所有工作項所經歷的階段。
5.3.看板相當於乙個儀表板，其中為每個工作流階段設定了垂直列，標題框表示的任務會隨著狀態的變化在列之間移動。
6.1.所有計畫通常從前期工作開始。
6.2.衝刺的週期各不相同，但最常見的是兩周。
6.3.在每個衝刺結束時，團隊都會進行回顧，以回顧已完成的工作、討論新發現、審查關鍵指標並微調執行過程。
6.4.使用者故事。
6.4.1.一種特殊的任務工單，它以“作為使用者，我想這樣做”的格式從使用者的角度定義功能的要求。
6.4.2.使用者情景的乙個常見誤用是將常規任務描述塞入使用者情景中。
6.4.3.使用者情景的標題和說明旁邊通常有屬性。
6.4.4.兩個最常見的屬性是估計工時和驗收標準。
6.4.4.1.使用者情景的估計工作量是對實現該使用者情景所需工作量的猜測。
6.4.4.2.驗收標準定義使用者情景何時完成。
6.4.5.小使用者故事通常是工作的門票。
6.4.6.大型使用者情景與實施票證或子任務相關聯。
6.4.7.尖峰是有時限的調查，允許完成其他故事。
6.5.任務分解。
6.5.1.可能需要將單個使用者情景分解為較小的任務，以估計完成所需的時間，將工作分配給多個開發人員，並跟蹤實現進度。
6.6.故事點。
6.6.1.團隊的工作能力以故事點來衡量，故事點是商定的規模單位（以小時、天或“複雜性”為單位）。
6.6.2.衝刺迭代的能力是通過將開發人員數量乘以每個開發人員的故事點數來計算的。
6.6.3.使用者故事的估計時間也是以故事點數來定義的，衝刺迭代中所有故事點的總和不應大於最大衝刺迭代容量。
6.6.4.乙個故事點相當於乙個工作日。
6.6.4.1.基於工作日的估計通常需要考慮非任務工作——會議、中斷、審查等，並將工作日定義為 4 小時。
6.6.5.估計故事點是主觀的，人們往往是糟糕的估計者。
6.6.6.提高估計精度的一種方法是使用相對大小來派生數值。
6.7.消化積壓工作。
6.7.1.積壓分類或梳理（在修剪樹木的意義上）通常在計畫會議之前進行。
6.7.2.積壓工作 （backlog） 是候選使用者情景的列表，經過會審以保持其最新、相關和優先。
6.7.3.最受歡迎的是 Scrum，它鼓勵短迭代，並且通常有檢查點來調整計畫。
6.8.衝刺計畫。
6.8.1.前期工作完成後，將召開衝刺計畫會議。
6.8.2.規劃會議是協作式的，工程團隊與產品經理一起決定要做什麼。
6.8.3.衝刺迭代的能力是通過檢視以前的衝刺中已完成的任務數來確定的。
6.8.4.衝刺最重要的特點是周期短，通常為兩周。
6.9.常設會議。
6.9.1.衝刺計畫完成後，工作開始，團隊舉行站立會議，也稱為 Scrum 會議或抱團會議。
6.9.2.站立通常安排在每天早上 15 分鐘（速度快到可以站立完成，但您實際上可以選擇是否必須站立）。
6.9.3.站立會議是定期的系統檢查。
6.9.3.1.如果您的團隊正在舉行同步站立會議，您應該盡最大努力準時。
6.9.3.2.當出現排程衝突時，跳過停靠點是可以接受的。
6.9.4.Scrumban 是 Scrum 和 Kanban 的混合體。
6.10.評判機制。
6.10.1.演講是會議的重點。
6.10.2.有些團隊只關注專案狀態的審查。
6.10.3.作為標準，每個衝刺周的評審不應超過一小時。
6.10.3.1.為期兩周的衝刺迭代將有兩小時的衝刺評審。
6.10.4.不要為衝刺評審做過度準備。
6.10.5.評論是為了慶祝團隊勝利、創造團結、提供反饋並讓團隊對進步保持誠實。
6.10.6.專案狀態評審還可以幫助團隊就真正“完成”的內容以及他們如何朝著目標前進達成一致，並且可以在衝刺回顧中討論已確定的問題。
6.10.7.評審的重點是衝刺 （sprint） 中完成的工作。
6.11.回顧的。
6.11.1.領導者（或敏捷專家）將舉行回顧會議，要求每個人分享他們在上乙個衝刺中的成功和失敗。
6.11.2.回顧的重點是流程和工具。
6.11.3.回顧也是敏捷實踐有這麼多風格的原因之一。
6.12.路線圖。
6.12.1.為期兩周的衝刺迭代是完成中小型工作的好方法，但大型專案需要更高階的規劃。
6.12.2.路線圖應該鼓勵每個人對團隊正在構建的內容進行長期思考。
6.12.2.1.較遠的地方應該更模糊，而更近的地方應該更準確。
6.12.2.2.不要自欺欺人地相信任何季度都是 100% 準確的。
6.12.3.與鎖定的衝刺迭代不同，路線圖是要發展的。
6.12.4.許多公司都會經歷乙個年度計畫週期，經理們試圖在每年的最後乙個季度計畫接下來的四個季度的工作。
6.12.4.1.年度計畫幾乎總是乙個討價還價的平台。