在 Scrum Team 中很強調 透明(transparency),這次跟大家分享的是 Developer Resource 透明化帶來的好處。
傳統團隊
在傳統的開發方法上,常常都是以”月”、”季”為時間單位,因此常會聽到 PM 說:可不可以再加這個 X 功能、這個 Y 功能,還有那個 Z 也順便加進來好了,這一季完成這些,應該沒問題吧?
身為 developer 能拒絕他嗎?有點難,因為感覺一季的時間應該可以做蠻多事情的,就算你覺得不可以,PM也很容易這樣感覺:一季耶,三個月你竟然沒辦法幫我多做 X+Y+Z?
在 Developer Resource 不透明的的狀況下,還真的很難回答。而不透明的原因,其實是因為週期太長、功能多且不明確,倒不是因為什麼溝通或互信的關係。
敏捷團隊
但在敏捷團隊中,我們在每個 Sprint Planning Meeting 時,便會先算出這個 sprint 有多少資源可以用:6(hours) * 6(developer) * 8(days) = 288 points
接著在 Story 介紹、Story Point 估算、決定 priority 等等活動之後,便開始討論 PO 這次最後決定的 stories:A,B,C,D,E,F,把這 6 個 stories 再細拆分成各個 tasks,例如 Story A 可能會被拆分成下列 tasks:

  1. QML:這個功能有 UI 介面,需要實作 QML
  2. C++:實際功能由 C++ 完成
  3. Unit Test:要對 C++ 實作單元測試
  4. UAT:要完成自動化驗收測試
  5. Code Review:這次的 C++ 還蠻難的,雖然有 Unit Test,但還是要進行 Code Review

然後,接下來團隊成員根據每一項 tasks 開始打牌,決定每一項的 tasks 所需的時間。這裡是關鍵,因為要由這過程去弄清楚 PO 真正想要的東西,也讓 PO 了解這個 task 為什麼需要這些時間來開發。
以 C++ 這項 task 來看,如果一開始大家出的點數差異有點大,例如:3,3,3,5,20,3,5,便要請出3及20的成員們分別說明一下他認為是3及20的原因。
張飛(RD):我覺得這個 雙向語音 很簡單,用原本單向語音模組來改就可以了!
關羽(RD):可是他不是全雙工嗎?這樣我們要改很多地方才能做全雙工..
劉備(PO):耶,不用考慮全雙工,我們這個應用基本上只要雙工就可以了!
關羽(RD):原來如此,是我想太多了..
在一番討論後,大家才能真正清楚 PO 想要的東西,而不會多做或少做,或著方向不對。此時再出一次牌,通常就能取得共識了。
在經過撲克牌大賽後,可以得到每個 tasks 需要的時間:QML 5, C++ 20, Unit Test 20, UAT 20, Code Review 8,合計73小時。
剩餘的 Story B ~ Story F 也是照一樣的方式去得到需要的時間,可能是 B:80, C:100, D:64, E:38, F:48,這樣 PO 就很清楚,在這個 sprint 有限的資源內(288),可以去完成那幾個 stories(D應該做不完,E跟F就不要想了…除非運氣很好。
PO 很清楚知道資源有限的狀況下,他就必需去做抉擇。如果現在只有 1 個 sprint 的時間,你沒辦法 A~F 全做,你要考慮清楚最重要、對客戶最有價值的到底是那幾個!全做當然最好,但資源攤在你眼前,很清楚的告訴你:不可能!
所以我覺得透明性的帶來的好處,除了明確了解需求外,也可以讓 PO 理解資源有限,他必需非常認真的選擇他要的功能!

註1:我們認為每位 developer 一天當中完全專注在工作上的時間是六小時左右,扣掉上廁所、休息、上網,工作轉換的overhead等)。
註2:一個 sprint 為二週,扣掉第一天的 Planning Meeting 及最後一天的 Review & Retrospective meeting,剩下8天。
註3:估算的過程重點在”溝通”,實際上的時間可能還是會不一樣。

Facebook Comments Box