Chapter 14 sprints

950 views

Published on

Succeeding With Agile: Software Development Using Scrum
Chapter 14 Sprints

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
950
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Chapter 14 sprints

  1. 1. Succeeding With Agile: Software Development Using Scrum David Ko
  2. 2. 如何在每個Sprint中,交付可運行的軟體是新的Scrum團隊必須克服的最大挑戰之一
  3. 3. + 鼓勵回饋 – Demo可收集到更多更好的意見 – 只有文件容易讓人遺忘和忽略+ 可衡量進度 – Project最大的風險是不知道還剩多少東西沒完成+ 在需要時可及早發布
  4. 4. + 達到某個里程碑的標準 – 並非意味著沒有defect – 重點是否做到了當初DoD (Definition of Done)所 要求的+ 意味被測試過+ 不意味整個功能是完整的+ 意味著CI(Continuous Integration)已經做好
  5. 5. + 嘗試將功能分解, 以便在每次sprint可以交付+ 對於無法展示的功能, 多加一些額外的工作 來展示其成果 – Ex: Fake UI 或是測試執行結果報告+ 縱向切割比橫向切割好
  6. 6. + 在每個sprint中花點時間準備下一個sprint+ Ken Schwaber 建議約花10%時間準備下一個 sprint+ 當然, 團隊可根據自己的經驗, 適當地調整
  7. 7. + User story大小不能無法在一個sprint內完成+ 對於還不清楚的user story – 在sprint前, 先充分理解, 而不是完全理解 – 若放入sprint 內的story, 必須被理解透徹
  8. 8. + 跨職能的成員一起合作+ 不是將工作由一個角色, 交給另一個角色+ 在scrum中不建議循序地執行工作, 也就是 不斷地交接
  9. 9. + 原因如下 – 進度的不確性增加  因為取決於前一個sprint完成的品質如何  不易估計下個sprint要花多久處理 – 花很長時間來確認功能的特性  要經過數個sprint, 一個功能才被完成  無法盡早回饋 Analysis Design Coding Sprint Testing Sprint Sprint Sprint
  10. 10. + 團隊有固定的節奏 – 知道何時開始, 何時要demo, 何時要開scrum的 會議+ Sprint計畫變得容易 – 經過2-5次的sprint, 容易根據歷史資料來規劃下 次sprint的工作+ Release planning變得容易 – 容易規劃要幾次sprint, 每個sprint要處理多少事 情+ 不用每次sprint前, 都花時間討論這次要多長
  11. 11. + 否則成員會覺得deadline是可以延長的+ 但是這代表你會有些東西在這個sprint中無 法完成+ 因此若是有看到這跡象, 要及早馬上討論甚 麼該被完成, 甚麼該被丟下
  12. 12. + 不建議 – 通常是產品負責人缺乏遠見, 以至於計畫變動頻 繁且快速+ Scrum的作法 – 宣布目前sprint異常終止 – 重新對於新的變動加以計畫, 以建立新的sprint

×