本文抽取Scrum中的一些重要思想和概念，對Scrum敏捷執行的主題流程進行精要的介紹。
一、基本思想
個體和互動 高於 流程和工具
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
二、主要特性：
- 迭代式、增量式
- 自組織的小團隊
- 快速反饋的短週期
- 按照業務價值的優先順序排序
三、scrum中的角色
Stakeholders：利益相關人
Scrum master：保證流程正確
四、開發過程
- 產品規劃
- 編制使用者故事列表（Product Backlog）
- 制定迭代計劃（Sprint Planning）
- 迭代開發
- 迭代評審、回顧
- 制定釋出計劃（Release Planning）
五、使用者故事
icesrcum：使用者故事管理軟體
使用者故事是什麼？
描述系統需求的一個單元，（“誰” “做什麼”）[ “目的”]
特性：
- 獨立
- 可更改
- 有價值
- 可估計
- 大小合適
- 可測試
實踐：
- Product Owner提出最初的產品設想，主要的使用者故事
- 頭腦風暴
- IceScrum
- 任何人都可以建立使用者故事，新建立的故事放在Sandbox中
- 開會討論，建立使用者故事列表（Product Backlog）
六、迭代計劃
- 調整使用者故事（增加、刪除、修改、改變優先順序等）
- 確定迭代時間長度
- 描述迭代目標
- 按照優先順序選取使用者故事
- 每個使用者故事的工作量估計
- 任務分解
- 確定迭代演示和回顧日期，並立刻發出會議通知
- 確定每日站立會議時間，並立刻發出會議通知
每個使用者故事的工作量估計
- 使用者故事描述的比較詳細，單位： “理想人天”
- 使用“計劃撲克牌”（Planning Poker），可選值：0 ， 1 ， 2 ， 3，5 ， 8 ， 13 ， ？
- 理想人天*1.5
- 關於迭代速率（velocity）的歷史資料
- 團隊成員都可以針對使用者故事給出自己的工作量評估牌
任務分解
- 會議結束之後，所有細分任務都有一個明確的責任人
- 確定迭代演示和回顧日期，並立刻發出會議通知
- 確定每日站立會議時間，並立刻發出會議通知
七、迭代開發
- 團隊溝通和協作
- 參考使用XP（極限程式設計）的工程實踐，如持續整合、重構、結對程式設計等
- 程式碼審查
- Bug生命週期管理
每日站立會議主題：昨天做了什麼，今天計劃什麼，有什麼問題（迭代計劃並不確定任務的完成時間段）
實踐：
及時更新IceScrum系統中任務的狀態
不定期的結對程式設計
程式碼審查
-
- 迭代內，所有程式碼都要被審查
持續整合
-
- 持續構建
- 持續審查
- 持續測試
- 持續資料庫整合
- 持續部署
- 持續通知
Bug跟蹤：
- 我們目前使用Redmine作為工具
- 任何人發現bug，都可以提交
- 一些小的功能增強，也可以bug的方式進行跟蹤
八、迭代演示和回顧
迭代演示 （Sprint Review）
- 一定要有一個可工作的迭代增量
- 對管理層：更好的專案可視度
- 對團隊：階段性壓力、階段性成就感 – 激勵團隊
迭代回顧（Sprint Retrospective）
- 針對工程實踐，而不是產品功能本身
- 做得好的：使用者故事裁剪
- 需要改進的：持續整合
實踐：
- Scrum Master主持會議
- 檢視迭代目標和迭代內承諾交付的使用者故事
- 產品演示
九、釋出計劃
工作量估計
速率（velocity）估計
- 根據以往迭代，進行估計
- 留有餘地
確定之後，要明確告知團隊和相關利益負責人
可以調整
- 記住，範圍（釋出那些使用者故事）是有彈性的
十、Scrum整體流程最佳實踐
- 估計使用者故事之前，要明確其範圍
- 使用“計劃撲克牌”（Planning Poker）的技術進行估計
- 端到端的整合，從第一個迭代開始，貫穿始終
- 迭代計劃會議上明確任務分解和責任人
- 迭代演示和回顧日期在迭代計劃會議之後就確定，並立刻發出會議通知
- 漸進式功能開發，過早優化是陷阱