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

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

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

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

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

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

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

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

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

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

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

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