相信有那麼一天,我們將可以像畢凱艦長一樣用嘴巴叫所有主機做事!


Cheng Wei Chen



Agile Tour Taipei 2015 筆記與心得(五)| Scrum Estimation Model - Joey Chen (91)

在得到「欠筆記文欠過年」的成就之後,硬是擠出一個下午的時間,終於整理完 Agile Tour Taipei 2015 最後一場議程的筆記,壓軸場當然是非同小可,是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。

同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》
因為欠筆記文欠太久,91 哥早已將他分享的內容整理成兩篇文章:
既然講者都已經把內容寫成文章了,所以老實說我有沒有寫這篇筆記文好像也沒差,那本文就此結束吧。(揍飛)

筆記文由此開始,在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例,點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。
  • 範圍 = 簡報總頁數
  • 時程 = 演講可用的時間
  • 速率 = 每分鐘要講幾頁(才能不超時將內容講完)
基本上這是簡單的數學計算,由「範圍」除以「時程」可得出「速率」,反之你也可以由「範圍」除以「速率」得出「時程」,又或是由「時程」與「速率」得出「範圍」,總之這三個重點是彼此互相關聯的。
但實際上講者講話的速率有限,不可能提升至預期的速率,因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況,因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。

透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「 時程」與「速率」的基本概念,整場分享即是完全圍繞著這三大關鍵。

接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。

在這個小故事中一樣有「範圍」、「 時程」與「速率」:
  • 範圍 = 交通距離
  • 時程 = 與朋友約定的到達時間
  • 速率 = 一天要移動多少距離
於是隨著小故事的發展,每一天都有不同的意外,但因為「範圍 = 交通距離」是無法變更的(但有可能會錯估),於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正,嘗試要完成這趟旅程。旅程中就發生了各種突發狀況,例如:
  • 錯估交通距離 = 錯估專案範圍
  • 受傷導致行進速度變慢 = 開發速率下降
  • 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time
    ⋯⋯等等
藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「 時程」與「速率」這三個重點打轉,換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。

那「範圍」到底是啥?範圍就是專案要完成的工作項目有哪些,你的 product backlog 有多少,估算出來的 story point 有多少。

不過在問範圍有多少之前,首先要先問「該如何估算?」

關於估算,91 哥提到了幾個重點:
  • 要SPA,也就是估算要「簡單」、「公開」且有「共識」。
  • 相對估算比絕對估算簡單
    (用小狗的大小當舉例,一隻狗很難描述大小,但問兩隻狗誰大,則很容易回答。)
  • 粒度小比粒度大的精準
    (用做飛機當舉例,做一台紙飛機與戰鬥機,哪一個能估算出比較精準答案)
91 哥也特別用了「一場 NBA 要打多久」當作範例說明「相對估算」。

一般來說 NBA 打一場的時間大約是 1.5 ~ 2 小時。如果要精確的計算,你大可以把每一節的時間、有可能的暫停時間、有可能出現的延長賽時間,全部加在一起嘗試算出精準的時間。但實際上每一場的狀況都不一樣,你很難在比賽結束之前精準地回答這一場比賽要打多久。可是即便沒有經過計算,你還是能根據過往的經驗回答出 1.5 ~ 2 小時這個該略的時間。

相對估算講完了,接著 91哥繼續講大家最在乎的「變化」,延續前面的範例,專案開發當中一定會發生變化,而變化就會影響「範圍」、「 時程」與「速率」。

而常見的變化有哪些?
  • 插件
  • 需求異動
  • 做法異動
  • 人員異動
那要如何面對「變化」,基本上就是「依據變化,時刻調整決策。」
(變化當下,最佳化決策;時時 review,調整決策;持續改善)

基本上老闆對於專案,他最關心的只有「範圍」與「時程」,因為他會優先在乎時間到了產品能不能交貨,畢竟能交貨才能賺錢。所以他通常不會第一時間管你目前的「速率」是多少。假設你跟他說這個 deadline 一定做不完,那他只會跟你說「那你需要多少人?我加給你!」(講到這 91 哥就吐嘲說,他就不相信上面那些人沒看過《人月神話》,真想把書砸到他們臉上。)

當專案發生變化時,PO 與 Developer 應該是在同一陣線,是互相幫助的夥伴;當 PO 估算了範圍與時程,若 Developer 覺得不妥,那 Developer 難道不用 support 更好的意見嗎?別忘了前面提到的 SPA「簡單」、「公開」且有「共識」。Developer 不幫忙 PO,Developer 不幫忙提出更好的解決辦法,那 PO 當然只好自己估算然後直接往上回報。

那在實際上在專案中到底要怎麼估算,91 哥說可以用三種 T-shirt size 來做相對估算。
例如:S = 10 story point、M = 20 story point、L = 40 story point。
因此當你將所有的項目都先分 size 之後即可得到「範圍」;由專案預定的 deadline 得到「時程」。如此就能計算出期望的「速率」(例如每週要完成多少 story point)。

有了「範圍」、「 時程」與「速率」的期望值,我們還需要知道團隊目前的「速率」基準。這裡 91 哥採用的方法是昨日天氣(yesterday weather),就是用過去的數據做加權平均,來當作下一次的基準。假設第一個月完成了 30 story point、第二個月完成 20 story point,那第三個月速率的基準就是 25。

搜集完這些數據後,不管是哪一種「變化」都能反映在 Burn Down Chart 上,就能由此看到變化帶來的影響。例如:
  • 插件 = 影響範圍
  • 需求異動 = 影響範圍或時程
  • 做法異動 = 影響範圍或時程
  • 人員異動 = 影響速率
看到變化帶來的影響之後,接著就要想辦法解決它,那有哪些方法呢?

首先關於「範圍」,它具備有 Queue 及 Priority 的概念,因此你會知道哪些項目要先做,哪些項目又可以無限延後。(友善提醒,不是不做,只是無限延後,晚一點做!)

在「時程」上則有很多方法,其中一個很常聽見的方法是「分階段上線」。

最後是「速率」,這也是 Developer 最能發揮的地方。

速率優化的治標方法有:
  • 檢視 priority(很多東西真的沒這麼急。先做有價值的項目,有些東西可以無限延後。)
  • 調整作法(人都快死了先做鋼鐵人一代就好,有錢有閒再來做二代、三代)
  • 有計劃的欠債(欠債是要還的!)
  • MVP(先求有,再求好)
  • 如果是老闆,可以幫 Developer 提升硬體校能(也能提升人員士氣)
而治本的方法是老話一句「持續改善」,這也是王道,重點即是團隊有沒有一起變好!由團隊一起找到最適合團隊的實踐,那才是最佳實踐(best practice)。

所以老闆不要直白的跟團隊成員說我們來導入 Agile、Scrum 或其他東西,成員只會立即產生反彈。應該要先建立團隊的信任感及透明度,然後讓團隊彷彿是自己找到問題並自己提出解決方案(但其實你早已在團隊中安插 Spy 帶風向),等到最後團隊就會忽然發現,原來我們在 run Agile 或 run Scrum。

最後 91 哥有實際 DEMO 他們使用的工具,他在 excel 中將「範圍」、「 時程」與「速率」這些數據都互相關聯,只要輸入資料、調一下數字即可看出變化產生的影響,透過一個良好的工具確實的輔助面對變化該如何決策。

如此一來所有的決策都有數據在背後支持,不管是遇到要提前上線、有人離職、需求變更,只要將數據輸入 excel,就能看出影響層面,即可從中得到足夠的資訊來作出應變的決策。

例如:老闆要提前上線,你就可以跟他說,新的 deadline 我只能完成 200 story point(範圍),可以先調 Priority 優先作重要的,然後超過的部分先不做嗎?或可以改變做法,讓其中某幾個 L size 品質下降一點,但變成 M size 嗎?

但如果老闆堅持全部都要做完,那就只好調整速率,大家來加班,短期內衝刺讓速率變快。但要知道這一定有副作用,可能未來維護會更麻煩,可能下個月就一堆人請假或離職。

當有了足夠的資訊可以證明實際情況,老闆也比較能做出決策,也比較會被說服接受你提出的解決方案。

心得

之前一直聽見社群朋友們對 91 哥一再的讚不絕口,搞得我非常想要親身體驗一次,所以當初看到 Agile Tour Taipei 2015 的議程表中有 91 哥的場子,二話不說立刻搶票,等到活動當天還被朋友罵說有 91 哥的場子怎麼沒有找他一起來,由此可知 91 哥的魅力值有多高。

等到親身體驗之後,還真是驚為天人,整場分享非常順暢連貫且毫無冷場,分享的內容具備深度且實用,並有超多名言金句可以收錄。若用最近流行的話來形容,只能說這場分享的「含金量很高」。聽完後,對於 Burn Down Chart 有更明白的認識,更在聽完 91 哥分享了他們團隊是如何落實它,用它去面對「變化」並解決問題,讓人更能理解實務上該如何應用。

其他 91哥分享中包含的一些觀念也很受用,像是:
  • 我們期待團隊能「依據變化,時刻調整決策」,但前提是你要有足夠的資訊來協助你作出決策。
    延伸思考所以「記錄資訊 => 認識現況 => 看見問題」是很重要的。在 DevOps 中也有借用了這樣的觀念。
  • 團隊轉型(成長)的精髓就是「自主管理」及「持續改善」。
    持續改善的觀念不用說,不管是個人、團隊、工具,甚至是你的程式碼,都需要如此。
  • Scrum、Agile 其實是讓你「面對現實」的照妖鏡。
    「看見」很重要,不只讓你看見問題,還有足夠的資訊來真正的面對問題。

參加這一次的 Agile Tour Taipei 2015 ,真的收獲很多,讓我對於 Agile、Scrum 及 KanBan 有更多的認識與信心,我記得隔週團隊開例會的時候,我已經迫不及待的想跟夥伴分享所見所聞,希望這樣的好東西也能慢慢融入團隊裡,讓「持續改善」不只是落實在我們的「工具」層面,在「專案管理」在「團隊運作」也都能持續地向前邁進。

老實說這個筆記與心得文真的是拖了太久的時間了,有許多的細節已經遺忘,好在 91哥自己已經把文章寫出來,也有提供當天簡報的重點內容,不然能寫出的內容應該會再減少許多。所以一定要再推薦一次 91哥的這兩篇文章,含金量很高,務必要拜讀一下!



沒有留言:

張貼留言

不歡迎留言打廣告,所以有進行留言管理,敬請見諒。