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