Odd-e CSD Course Day 1
First 強烈的建議，記得準備好當地的 SIM 卡及插座轉接頭，在這五天中很好用的 
接下來，我就各個主題來介紹一下相關的心得。首先我們這五天裡會依照 Scrum 的流程，完全的跑過一次，從一開始的需求定義，到最後的 Sprint Review 一個都沒有少
Requirement workshop / A-TDD
在 Workshop 練習中，PO 會針他的需求不明確的地方做講述，身為 Agile developer 你需要做的是，先問出他實際的需求，再轉化成 A-TDD ，A-TDD 這個名詞有些人比較不常聽過，但教練一提到 BDD ，大家其實就都明白了。
所以在 Product Backlog Refinement (PBR) 裡，「討論」與「釐清」是一件很重要的事。並且這當中也提到了，何時該做 PBR , Before Sprint or After Sprint . 這裡提的是 Before Sprint (通常在Sprint Review 之前)
另一個更重要的是，開發團隊在這時候是協助 PO 去釐清一些真相，為什麼要特別提這事呢？
想像一下 PO 今天說，我想要能夠登入系統，但這真是 PO 的需求嗎？
也許他只希望進入系統後能顯示使用者的姓名 (在這裡開發團隊就相較之前多了好幾種解決方案)
有趣的事，最近看到一張圖來說明，為什麼我們需要「討論」
(人類已經演化成發現別人錯誤的最有效生物)
from: https://www.slideshare.net/ziobrando/the-sweet-spot-41853270
在分別寫下 A-TDD 的案例過程中，也引發了蠻多的討論。
e.g.
1. 當寫了多組相似的 A-TDD , 如何重新組合成單一案例? (keyword: Scenario Outlines)
2. 當 A-TDD 完成了，如何應用這個案例產生 Business Rule 或是反過來產生新的案例
3. A-TDD 的內容該怎麼寫？ (只有工程師看的懂就好嗎？或是應該要讓 PO 也看的懂)
這裡想起以前 91 (Joey Chen) 在 TDD 課程中提的，如何讓 PO or PM 一起加入寫 BDD Case
除了 Nature Language 外，另一個就是團隊成員如何一起協助你的 PO or PM (適時的提出一些技術面的想法或常見的做遙)
現在開始別讓你的 PO or PM 成為邊緣人。一起完成 A-TDD 的案例吧！
from: http://physicalculturist.ca/leave-me-alone-collection/
並在中間舉了 Parkinson's law of triviality 做為團隊在討論問題時常見的迷思 
此外一個重要的點我覺得是先前提的如何產出你的 Business Rule
from : https://www.slideshare.net/tcmak/adopting-technical-practices-2013
從這張圖可以看出，開發團隊在開發的其實是在最下層的 Technical Activity
但 Technical Activity 事實上是從 Workflow 而來，而 Workflow 是由 Rule 決定的
這裡存在一個很大的風險是，當在你的 Rule 不明確時就進行開發，這不叫 Agile 這叫 idiot
所以透過 A-TDD 與 PO 反複進行討論的同時，其實是要把 Rule 與 Workflow 訂出來
才能讓在最後需求變動時，影響的範圍較小，而且比較不會 Over Design
SCM,Build Automation and other tools
在這個單元中，其實著重在的是如何進行你的流程。工具其實真的不是太重要
(Day 2 會特別詳細討論這個)
在這裡介紹了許多常見的 Build Tools
e.g. cake 、 coypu
中間其實有提了這次 Sprint 裡我們的 Definition of Done
Sprint Planning
在 Sprint Planning 中，我們一共做了兩次，兩次其實都隱含了對 Product backlog 做出承諾這件事
Sprint V1
在 Sprint V1 中 跟以前玩的打牌遊戲不太一樣，感覺更簡單許多。直接將費式數列排出後，由某個成員選出一個他認為相對最小的 backlog 做為基準，在 1-2 輪中每個成員就依序進行 backlog 移動，並且在這當中"絕對不要進行討論" ，最白話的理由便是，不要讓你提出的理由影響到其它人的決定。
但在後面幾輪中，移動 backlog 時就需要提出你的理由了！而有趣的是，在這此 Spring Planning 中，我們團隊中其實有兩個需求不明確的 backlog ，在某次移動的當下我便直接詢問 PO 他對於這個 backlog 的想法為何，經過再次澄清後，其實就很容易能相對估算出這個 backlog 的大小為何了！當然我們在這當中也有犯了一個小小的錯，我們在其中一個 backlog 還不明確的清況下，將它估算的相對太小。 這時候 PO 也直接提出了，如果實際上我的需求其實難易度很高，那這個 backlog 是不是就會相對來說變的比較大？
(簡單來說，任何在這過程中不清楚的通通都要提出來問，問 Team member 、 PO 、 Scrum Master 、 balala… )
而當 PO 在我們估算結束後，進行排列時。 有成員提出了，如果按照 backlog 上的估算來進行 backlog priority 的排列是不是比較好？
但事實上， PO 並不在意估算, PO 關心的是在他排列完之後，他的需求能不能被完成
另一點是，有小夥伴提出了，如果 backlog 裡有相依性該怎麼辦
其實答案也一樣，對於 PO 而言不關心使用者故事相依性，關心的是你怎麼實現他的夢想
Sprint V2
在 Sprint V2 中，我們將上一輪最後評估能做的 backlog 做"細節拆分"外，一樣透過團隊成員來決定這樣的拆分是否可行，只要有一個人說 NO 。這時候就必需停下來，傾聽成員解釋相關原因
這裡用了很簡單的 Fist of Five ，具體可以參考這裡 (簡單的說是透過1到5只手指來做投票)
http://agileforall.com/learning-with-fist-of-five-voting/
Pair Programming
最後就進行了第一天的 Pair Programming ，第一天的過程其實就比較順利
因為我的夥伴聽不太懂我在說啥，只能用文件進行溝通。不過最後算是有順利完成我們的目標啦(茶)
當然我其實是蠻喜歡 Pair Programming 的，透過這樣的方式去觀察其它人遇到問題時的解決方式，來偷學幾招。其實蠻有趣的！其中一個點是，我發現印度人在遇到問題時，第一個不會先找 Stackoverflow ，而是先翻文件。跟我的習慣不太一樣，通常一般的錯誤丟 Stackoverflow 就有了！但翻文件的時間可能就會比較久。
另外在每天結束時，每個人都會針對今天的內容做短暫的回顧分享。透過反饋來重新學習與複習今天所學到的內容
對課程有興趣的同學，可以到以下網站找到相關的資訊
