Chapter 15 planning

Succeeding With Agile: Software Development
Using Scrum

David Ko

+ 做計劃是scrum的基礎
+ Agile團隊所做的計劃比waterfall團隊更準確

+ 早期規劃只要掌握要交
付內容的重點
+ 不考慮細節, 並不是不想承諾,
要交付的內容是甚麼
+ 而是要保留一些空間, 來處理
不確定性的事情
+ 細節放到以後再考慮

+ 將時間上的浪費減少到最低
– 避免對假設性太高的東西做計劃
+ 允許在最佳的時間點才做決定
– 避免一開始做太多決定, 確定了解才做決定
+ 允許我們改變要走的路徑
– 充分計畫只讓我們知道大方向
– 隨著細節的出現, 我們再做出調整
+ 幫助我們避免掉落”計畫是完美”的陷阱

+ 加班一個星期是可以的
– 可提高效率並增加一些
額外的時間
+ 但是不能連續兩周加班
以上
– 否則代表你有了一個不
能通過加班來解決的問
題

+ 讓你保留一些能量, 在
真正需要時使用
+ 讓你保有創造力的空間
+ 讓你不會上完班後就枯
竭了, 下班後還能有動
力持續學習

+ 時間無法增加, 只能增加熱情
– 團隊中熱情的人越多, 團隊就越容易充滿能量
+ 定期的短暫休息

+ 固定長度的工作週期
– 25 min
 全力衝刺工作
 不接電話, 不回郵件

– 5 min: 短暫休息
+ 每四個週期過後, 有一
個15-30min的休息

範圍時程
品質

資源

+ 這是短視的作法
+ 之後團隊會因為rework或是系統不穩定而讓
我們無法全速前進
+ 快速前進的最好方式就是保持高度品質
+ 就算要犧牲品質, 你也無法決定要怎麼做才
夠趕上進度, 如
– 要犧牲多少品質, 或是
– 要犧牲那些品質

+ 訓練新人需要花時間
+ 人多溝通會增加複雜度
+ 加人的時間點是個藝術
+ 加了人是否有幫助無法預測

+ 可行, 但是很多時候不適用. 如
– 若是合約已經簽訂了怎麼辦?
– 若是產品展期或是廣告日期已經確定了怎麼辦?

+ 它是放棄某些功能的一
種優雅說法
+ 如果要調整範圍, 要先
確定我們是依照優先順
序來開發
+ 雖然令人失望, 但不是
世界末日

+ 犧牲品質不是一個好的選擇
+ 增加資源的效果是不確定的
+ 延展時程是可行的, 但是不確定是否需要更
久時間
+ 改變範圍是不錯的選擇, 但是要確保照優先
順序來實作功能

+ 主管常常把它們視為相同

+ 估算不能是一個單一數值, 應該是個範圍
+ 需要增加信心指標
+ 例如
– 在這個sprint可以處理30-35人時的工作
– 達成這個承諾大約有90%信心程度

Recomendados