在 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:估算的過程重點在”溝通”，實際上的時間可能還是會不一樣。