今天早上聽了這一集，重點就是作戰是要靠敏捷的，有時侯計劃是沒用的。讓士兵自己思考要作什麼（修理約克城號、攻擊日本的航母等..），比指揮官一步一步下命令好很多。
我開始相信 Jeff Sutherland 是真的因為當過美國空軍，才讓他創立了 Scrum 。
在 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：
以 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:估算的過程重點在”溝通”，實際上的時間可能還是會不一樣。
傳統團隊
在傳統的開發方法上，常常都是以”月”、”季”為時間單位，因此常會聽到 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：
- QML：這個功能有 UI 介面，需要實作 QML
- C++：實際功能由 C++ 完成
- Unit Test：要對 C++ 實作單元測試
- UAT：要完成自動化驗收測試
- Code Review：這次的 C++ 還蠻難的，雖然有 Unit Test，但還是要進行 Code Review
以 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:估算的過程重點在”溝通”，實際上的時間可能還是會不一樣。
討論是很重要的一件事，而且有時侯一圖勝萬言，因此如果有白板可以讓大家討論是很重要的一件事。在我們團隊的辦公室中，我們便規劃了三面白板，其中一面是當做sprint wall & burndown chart，另外二面就是 member 可以自由討論的地方，以目前團隊人數(10)來說是還蠻夠用的。這個sprint有一個功能是3位成員一起合作完成的，因此我們在白板上畫出了架構與流程來溝通討論介面該如何設計，溝通清楚後，大家在座位上一抬頭就可以看到當初討論的結論了，真是個好白板 XD。
此外，我們這間還有一台投影機及一台電視，電視最近加上了chromecast，讓團隊成員要分享畫面更加容易，有時侯要分享或討論的東西在電腦上，只要按個鈕就可以顯示在電視上跟大家討論，還挺方便的（不過FPS不高，要做影片的分享較不適合，可能還是要裝個 Apple TV 比較好）。
敏捷團隊很重視團隊成員的互相討論與分享，但如果環境因素讓成員不易分享與討論，就很難讓大家願意去分享與討論了。
你的工作環境會讓成員願意討論嗎？
此外，我們這間還有一台投影機及一台電視，電視最近加上了chromecast，讓團隊成員要分享畫面更加容易，有時侯要分享或討論的東西在電腦上，只要按個鈕就可以顯示在電視上跟大家討論，還挺方便的（不過FPS不高，要做影片的分享較不適合，可能還是要裝個 Apple TV 比較好）。
敏捷團隊很重視團隊成員的互相討論與分享，但如果環境因素讓成員不易分享與討論，就很難讓大家願意去分享與討論了。
你的工作環境會讓成員願意討論嗎？
