Succeeding With Agile: Software Development Using Scrum Chapter 14 Sprints

1. Succeeding With Agile: Software Development
Using Scrum
David Ko

2. 如何在每個Sprint中,交付可運行的軟體
是新的Scrum團隊必須克服的最大挑戰之一

3. + 鼓勵回饋
– Demo可收集到更多更好的意見
– 只有文件容易讓人遺忘和忽略
+ 可衡量進度
– Project最大的風險是不知道還剩多少東西沒完成
+ 在需要時可及早發布

4. + 達到某個里程碑的標準
– 並非意味著沒有defect
– 重點是否做到了當初DoD (Definition of Done)所
要求的
+ 意味被測試過
+ 不意味整個功能是完整的
+ 意味著CI(Continuous Integration)已經做好

5. + 嘗試將功能分解, 以便在每次sprint可以交付
+ 對於無法展示的功能, 多加一些額外的工作
來展示其成果
– Ex: Fake UI 或是測試執行結果報告
+ 縱向切割比橫向切割好

6. + 在每個sprint中花點時間準備下一個sprint
+ Ken Schwaber 建議約花10%時間準備下一個
sprint
+ 當然, 團隊可根據自己的經驗, 適當地調整

7. + User story大小不能無法在一個sprint內完成
+ 對於還不清楚的user story
– 在sprint前, 先充分理解, 而不是完全理解
– 若放入sprint 內的story, 必須被理解透徹

8. + 跨職能的成員一起合作
+ 不是將工作由一個角色, 交給另一個角色
+ 在scrum中不建議循序地執行工作, 也就是
不斷地交接

9. + 原因如下
– 進度的不確性增加
 因為取決於前一個sprint完成的品質如何
 不易估計下個sprint要花多久處理
– 花很長時間來確認功能的特性
 要經過數個sprint, 一個功能才被完成
 無法盡早回饋
Analysis Design
Coding Sprint Testing Sprint
Sprint Sprint

10. + 團隊有固定的節奏
– 知道何時開始, 何時要demo, 何時要開scrum的
會議
+ Sprint計畫變得容易
– 經過2-5次的sprint, 容易根據歷史資料來規劃下
次sprint的工作
+ Release planning變得容易
– 容易規劃要幾次sprint, 每個sprint要處理多少事
情
+ 不用每次sprint前, 都花時間討論這次要多長

11. + 否則成員會覺得deadline是可以延長的
+ 但是這代表你會有些東西在這個sprint中無
法完成
+ 因此若是有看到這跡象, 要及早馬上討論甚
麼該被完成, 甚麼該被丟下

12. + 不建議
– 通常是產品負責人缺乏遠見, 以至於計畫變動頻
繁且快速
+ Scrum的作法
– 宣布目前sprint異常終止
– 重新對於新的變動加以計畫, 以建立新的sprint