概念解釋
Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自於橄欖球中的“帶球過人”。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應變。 不同於瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，衝刺），一般為期2～4周。
圖解敏捷開發
關鍵詞
三個角色，三個工件，四個流程（五個事件），四大支柱，五大價值觀
三個角色
Product Owner
產品負責人負責的事項：
- 清晰地表達產品代辦事項列表條目
- 對產品代辦事項列表中的條目進行排序,最好地實現目標和使命
- 確保開發團隊所執行工作的價值
- 確保產品代辦事項列表對所有人可見、透明、清晰,並且顯示 Scrum 團隊的下一步工作
- 確保開發團隊對產品代辦事項列表中的條目達到一定程度的理解
Scrum Master
Scrum Master 負責確保 Scrum 被理解並實施。為了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則。Scrum Master是Scrum團隊中的服務式領導。
Scrum Master 幫助 Scrum 團隊外的人員瞭解他們如何與 Scrum 團隊互動是有益的。 Scrum Master 通過改變這些互動來最大化 Scrum 團隊所創造的價值。
Scrum Team
開發團隊包含了專業人員,負責在每個 Sprint 的結尾交付潛在可釋出的“完成”產 品增量。只有開發團隊的成員才能創造增量。
開發團隊由組織構建並授權,來組織和管理他們的工作。所產生的協同工作能最大化 開發團隊的整體效率和效力。開發團隊有以下幾個特點:
- 他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發團隊如何把產品 代辦事項列表變成潛在可釋出的功能。
- 開發團隊是跨職能的,團隊作為一個整體擁有創造產品增量所需要的全部技能。
- Scrum 不認可開發團隊成員的頭銜,無論承擔哪種工作他們都是開發者。此規則無一例外。
- 開發團隊中的每個成員可以有特長和專注領域,但是責任歸屬於整個開發團隊
- 開發團隊不包含如測試或業務分析等負責特定領域的子團隊。
三個工件
分別指的是產品待開發項，衝刺待開發項（開發角度），可交付軟體（文件）
四個流程
四個支柱&&五個價值觀
四個支柱
- 迭代開發
- 自組織團隊
- 高優先順序的需求驅動
- 增量交付
五個價值觀
- 承諾 – 願意對目標做出承諾
- 專注– 把你的心思和能力都用到你承諾的工作上去
- 開放– Scrum 把專案中的一切開放給每個人看
- 尊重– 每個人都有他獨特的背景和經驗
- 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重
前置條件
敏捷的團隊
敏捷團隊要求其成員具有以下的一些基本特點。
- 具有多年工作經驗，在自己的負責領域有專業的認知和獨立完成能力
- 有較好的執行力，對自己允諾的事情能完整的完成
- 有較好的溝通反饋能力，對敏捷本身的正確理解，在遇到問題、風險、不確定性、協作等時能快速的通過溝通完成溝通的目的
- 對其他技術棧或者專業領域有一定的認知，有較少的認知壁壘，較快達成共識
- 團隊在此之前有至少半年到一年的磨合
比較固定的流程，文件，需求
- 需求是控制穩定性的根本，對於需求一定是整體可控的，並且是可以由迭代內進行調整的，而不是定死的
- 流程是指什麼時間什麼人該做什麼事是高效的，明確的
- 文件是指每個流程階段具有可交付或者可查閱參考文件，不是口頭或者個人評定
可靈活調整，允許試錯
- 檢查
檢查是指在每天的站會中檢查每個人的工作狀態，是否能完成自己的任務，存在什麼問題，完成效果如何。另外就是保證整體在每天的進度，是否有有整體效果，如果沒有完成今天的整體效果，需要檢查是否符合整體迭代。
- 調整
調整是指檢查發現迭代的進度或者外界環境發生變化時，及時調整當前迭代的開發任務，保證迭代最終產物的準確及時性變動。當然，這種變動是不允許太多的，一般情況下在需求沒有做詳細分析時，不接受；在當前有風險的情況下，撤銷某些需求；其他情況不做描述。
- 試錯
正是由於檢查以及調整的策略，保證了迭代的靈活性，我們可以在敏捷團隊中嘗試一些較革新、新的功能點或者技術點，如果實驗成功則可以對外擴充；如果不行，可以快速切換方案。
適用場景
- 不確定的開發流程，技術方案
- 不成熟的產品
- 產品快速多方面優化
- 產品新特性研發
- 技術重構
問題場景&&錯誤認識
- 一個團隊閉關開發一個專案就是敏捷
正確理解：敏捷不等於閉關，只是可能坐一起效率更高，其倡導的是何時都可以發生溝通，並準備一白板可以隨時討論方案；敏捷團隊質量以及效率高於一般團隊；敏捷團隊開發的是以迭代為單位，不是專案；
- 有了任務細分，開發白板，站會就是敏捷
正確理解：任務細分、白板、站會都是其形式，關鍵還是其將迭代的內容進行細化，可執行化，用高頻的溝通反饋提高開發、溝通、理解的效率。
- 把最好的成員都攢一起了就是敏捷
正確理解：這些成員除了各自的專業水平還需要各自的磨合，溝通水平，對其他職能的一定的瞭解。
- 開發很快，快速交付的是敏捷
正確理解：開發快、快速交付產物只是敏捷的一個特點，也要深刻理解其交付的只是一個迭代的，並不是一個完整的產品。
- 只有軟體開發團隊才有敏捷
正確理解：符合可以將任務明細，具有一個可執行團隊，一個監督者，都可以嘗試敏捷的管理。
- 敏捷團隊沒有特殊前置條件
正確理解：前面有講到敏捷對團隊，需求，文件，流程，調整等都有比較完整的規定。
- 敏捷團隊做的事情沒有差別性
正確理解：敏捷完成的任務具有明細化，分階段性，可調整性。所以在開發相關任務時，也具有類似的特點。
- 敏捷團隊會完整完美的交付產物
正確理解：敏捷在迭代結束只交付該階段的可交付產物，很可能不完整不完美，對於可交付也有不同的理解。
更多
有興趣可以持續關注的後續講解，會針對使用者故事、需求管理、跟蹤反饋等多角度分析執行敏捷的要點。
參考文件
- 《火星人敏捷開發手冊》
- scrum中文官網