在實施 Scrum 時, 最常遇到的一個狀況, 就是忽然說有急件, 希望團隊可以趕快處理.
根據 Scrum 的定義, 在 iteration 中途, 是不能再加功能, 也不能變更iteration 的長短.
可是如果真的需要處理這些緊急的要求這些急件可能是新的需求, 或者是之前出貨的產品有嚴重的瑕疵, 那該怎麼做才是比較合理呢?
1. 仔細把關
Sales 或是產品經理老是說, 如果沒有這個功能就賣不出去; 或者是說有了這個項目, 客戶就會簽約. 但是事實會是這樣嗎? 大多狀況都是做了以後, 也不會賺進半毛錢. 產品負責人需要好好把關, 和 Sales 和產品經理好好討論, 很慎重告訴他們, 黃牛太多次後, engineers只會越做越慢, 反而造成之後兩敗俱傷.
2. 下個 iteration 再做
有很多東西可能是要做沒錯, 但是不一定要馬上立即做. 有時候可能讓產品負責人先去討論需求, 來來回回確認之後, 其實已經是下個 iteration 的開始. 因為很名正言順的下個 iteration 開始做. 完全不會打亂正常 scrum 的作息.
3. 拿還沒開工的 story 來換
有時候真的強迫開始開工, 這時候可以看看 iteration 中是否有還沒開工的 story, 如果有的話, 便可以和這個緊急事件交換, 或許大小不一定相等; 並且你可能還要花時間評估, 以及拆解細部的 task, 但是這樣已經降低不少傷害. 比被強迫再多做一個新的項目好很多.
4. 10% 的 buffer.
這個方法是在每次挑選功能時, 只拿出 90% 的火力來做事, 保留 10% 的能量, 以備不時之需. 如果你所在的環境中, 常常有急件的狀況發生, 說不定這是一個不錯的方式. 但是如果常常有急件進來, 或者急件的複雜度很多, 10% 的 buffer 可能也是吃不下.
5. 採用 Kanban 的做法.
如果急件在你的組織是常態, 那這時候可能要思考, scrum 是否是合適的選擇. 說不定可能沒有 iteration 限制的 Kanban, 比較合適在你的團隊中. 只要目前手頭的做完, 下一個便處理你所謂的急件.
6. 兩個團隊
一個團隊處理原先 sprint 要做的事情, 另一個團隊專門處理外面來的急件, 某種程度和 10% 的 buffer 很類似. 但是這完全是分開的兩組人馬處理, 這樣另一組人員就可以完全專心工作.
但是不管你採取哪種方法, 最後有件事, 值得你去思考一下: 做一下魚骨圖分析, 為什麼 PM/sales 定好的功能, 老是跟急件的不一樣? 或者你的程式為什麼老是不穩定, 導致有重大的 bug 要立即修復? 救急不是辦法, 或許要解決源頭才是根本!!
而昨天在 Lean Coffee 聚會時, 有人問到當 sprint 時間要到, 可是 story 還沒做完, 是否要結束. 這是一個很好的問題, 因為這是一開始執行 scrum 的團隊, 必定會遭遇的問題, 即使是很有經驗的團隊也會碰到.
首先, 我們先來看如果延長會有什麼問題:
1. 有可能不知道什麼時候會結束
因為隨時都可能發現某些部分沒做好, 或是忘了做. 或者有些地方因為技術不確定, 很可能不知道還要做多久. 如果 sprint 要展延, 很可能會不知道哪一些才可以結束. 這樣的不確定性, 讓專案很難規劃, 並且老闆也會很擔心你為什麼老是變來變去的
2. 節奏老是不固定
如果 sprint 會延長, 那表示有時候 sprint 可能是 10 天, 有時候是 13 天, 還有時候是 15 天. 員工很難知道這時候是否要進去下個 sprint, 或者該先安排什麼事情. 如果就是固定 2 周(假設從星期一開始), 那他就知道星期一早上就是要招開 sprint planning meeting, 然後第二周星期五下午就是要開 retrospective meeting.
3. 紀律會容易鬆弛
如果你跟大家約法三章說這些事情就是要這樣進行, 可是遇到困難, 或者是一些意外, 就不遵守你約定好的事情, 以後大家都會覺得規定的事情可以打折扣. 我想很多歷史故事可以都可以看出落實規定的重要性. 例如孫武練兵就是好的範例. 並不是說我要 command and control, 但是基本的紀律還是要有的.
因此比較好的方式是準時結束, 然後來檢討為什麼做不到, 是規劃的時程有問題, 還是什麼地方需要改進.
接著還有人問說, 那 demo 的時候怎麼辦呢? 當然是只有 demo 你有做完的功能. 例如這個 sprint 要做 10 個功能, 你只做完了 7 個, 那就只 demo 7 個. 不要對沒有做完的也 demo, 否則老闆會有錯覺, 認為你都做完了 XDDD
也有人有疑慮如果 sprint 準時結束, 那會不會 engineer 認為做不完也沒有關係? 基本上, 我相信人性本善, 他們都是想實踐自己的承諾. 我想你若是 sprint planning 有說好要做這些功能, 並且要在 review meeting 中 demo 這些功能, 大多的 engineers 都是會儘自己的能力做好.
所以比較重要的是要在 retropective 中討論可能的原因, 是否有哪些項目要改進, 例如可能是 spec 常常不確定, 或是 review 所花的時間超出預期, 或者原先架構太複雜加個小功能要很多時間. 重點要知道病因, 才能對症下藥. 而不是立馬責怪 engineer.
當然啦, 也是可能會有白目的 engineer, 就是喜歡愛摸魚, 或者真的是能力不勝任, 這時候這種人可能就不是任何 process 可以幫忙的 XDDD
另外，91 寫了一篇文章: "估算需求複雜度（3）如何評估專案時程”, 是談有關如何估算專案多久能完成. 這是一個很好的問題, 也是 PM 們在接觸到 agile 時面臨最大的問題.
http://www.codedata.com.tw/social-coding/project-schedule-estimation/
因此我把握這個機會, 在 Facebook 的 Scrum community in Taiwan 的社群中, 問了下面幾個常見的問題, 期待能夠得到各方的經驗談
"這個項目不是做的人去估, 這樣會準嗎?" 或者問說: "我又不懂這項, 那估出來的東西有意義嗎?"
"如果時程一直變, 那我很難跟老闆交代. 改一次還好講, 如果改多次, 或是改的幅度很大, 那我還真的很難開口"
"我做的是 contract 的project, 時間和範圍是固定的，那一直變是不行的。或者問說：那 scrum 是不是不合適 contract base 的 project"
“如果 Scrum 的 schedule 會一直變, 那是不是 Scrum 可能不適合很多地方?"
很高興在這次的討論中, 很多人出來分享他們的經驗談, 我把大家的想法整理了一下:
1. Scrum schedule 會一直變, 是在反映團隊現況, product backlog 的現況, 以及每段時間後離目標還有多遠, 是否需要調整目標的順序跟範圍. (91)
2. 利用 agile 的方法去做估算, 這些時程的變動都是有數據作輔助, 而非某個人憑感覺猜想的 (91)
3. 這樣的變動是在告訴老闆真實的狀況. 也就是給他一個有意義的 schedule, 而不是一個達不到的 schedule. (91)
4. 這樣變動的 schedule, 其實是 product owner 讓發現問題的工具. (91)
5. Scrum 的 schedule 不是估的準不準的問題, 而是文化與溝通的問題. Product Owner 是 team 與 stakeholders 之間的橋樑, 用 stakeholders 聽得懂的話跟他們說明時程, 把壓力阻擋在團隊之外, 是PO/SM重要的職責. 壓力必須到PO/SM為止... (董大偉)
6. Run Scrum真的不是流程方法框架問題, 是文化問題. 一個本來就有既定文化和制度的公司, 真的有一定的難度, 是事實, 但也不是全部沒有改變或改善的空間. 做法有很多, 但經驗告訴我, 核心問題最後都在"溝通”上~ (董大偉)
7. contract 如果不是敏捷式合約, 要完整的 run Scrum 也幾乎是不可能的. 只是沒必要 run 完整的Scrum.
8. 即使你無法 run pure Scrum, 把 waterfall 改成 milestones base delivery (例如: 每一個月交付部分功能), 裡面用不用 agile practices 可以再議, 或者你 milestone 內用 mini waterfall 也可以. 但是因為你有定期交付, 就會讓老闆覺得還蠻安心的, 因為你都有進度. 順便也可以定期從客戶得到一些回饋.我比較是從可以得到的好處來說服 boss or PM. (David)
9. iteration 開發的一個重點, 是在讓團隊養成持續改進的文化. 然後在他們遇到困難時, 才慢慢推一些 agile practice 給他們. 也就是利用 gateway drugs 的原理, 來誘拐他們朝 agile 前進 (David)
10. 把 焦點放在大家想解決的痛點上, 可能比較不容易失焦. 比如說針對” 這個項目不是做的人去估, 這樣會準嗎?” 這個問題, 背後的痛點到底是什麼? 是本來常常估不準嗎? 原本個估算方式有盲點嗎? 還是說原本的評估方式曠日費時, 無法套用到快速的 release計畫中? 痛點清楚後, 討論起方法來才會更具體 (Aska)
11. 估算從來都不會準, 做了出來之後才算準. 問題是, 為什麼估算? 誰需要這估算的數據? 而且是用來做什麼的? (Steven)
12. Time and Material 合約會比較能跟 agile 配合 (Steven, 董大偉)
13. 需求的來源如果具有一個比較長一點的沉澱、發展時間, refinement workshop 應該是可以達到一個讓 PO 和 stakeholder 稍稍比較容易掌握目前狀況的一個狀況. (Richard Hsiao)
其實用 waterfall 就可以給個準確的 schedule 嗎? 如果是的話, 為什麼還有這麼多專案 delay? 如果每個人估他自己做的部分, 然後加起來就可以有個比較準確的答案, 那為什麼還有這麼多專案 delay?
Scrum 只是在嘗試另一種方式處理專案時程評估的問題. 它不認為大家在早期估算可以很準, 因此她利用了 whole team approach 來集思廣益. 然後再藉由 iteration planning, 得到回饋, 不斷地修正專案時程.
跟大家分享一下艾森豪的名言: Planning is everything. Plans are nothing! 這就是 agile planning 的精神.
這些理由可以說服你使用 agile 嗎? 即使在估不準的狀況下 XDDD
作者：David Ko
作者簡介：David具備Certified Scrum Master以及Certified Scrum Product Owner的認證，也是台灣最早期 Agile 社群（AgileCommunity.tw）發起人之一。 為了推廣Agile知識，還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管，並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。
文章出處：David Ko的學習之旅
原文連結：
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
