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