因為今天是最後一天了，我趕緊在這次結束前提出一些前一晚上想到的問題
1. 在TDD的循環中有重構，那 DB 也會進行重構嗎？
在TDD 的重構的過程，其實也經常會重構資料庫 ，
但重構資料庫這裡有一個很重要的點，是要如何做 DB Migration
from : Odd-e CSD Course
經過討論後，整理出上面這張圖，可以看出。不管在 Test Case 與 Production Class 及 DB 的部分，
都會有重構的動作產生
2. 在 TDD 的過程中，是否就是在做 Domain Driven Design 呢？
TDD 其實也有一點 Domain Driven Design 的味道。 但事實上還是有差別的 ， 可以將這個當做你的一項武器，需要的時候就可以直接拿來用 。 並不一定都是 TDD
3. 如果我們都寫了測試，那這樣 QA 這個角色是否就不需要了？
TDD 的方式，其實最後在做測試的 都是已知的東西 。 而未知的東西就可以透過像探索性測試，
或是 Developer 之間互相測試 。 在這種情況下 ＱＡ的職責其實並不是這麼的明確或需要了
而且一個良好的程序員是可以成為良好的 QA ，但一個良好的 QA 要來編程就有些困難了
中午吃飯後 Terry 播了一段很讓人深思的影片，提到了 Rule 是如何讓組織變得沒有生產力
有興趣的同學可以看看
Code Review
在這天早上的 Code Review 裡，也重新提到了一個不好的測試是怎樣的，及透過了重構來讓這個測試目的看起來比較明確，此外 Terry 也提醒了，當寫了這種看起來複雜的測試時，應該要回頭想一想。這一個測試實際上要測的是什麼？是不是多了那些多餘的東西
from : Odd-e CSD Course
詳細可參考 https://github.com/nerds-odd-e/Mailer/commit/fe1767d37d02bd1da80a0a1539b252da35119650
Craftsmanship
在這個部分主要在探討軟體工程師的演進
從學徒到工匠最後到大師，而一個好的匠人應該要有那些心態，並且需要學習那些相關的技能
有興趣的同學，可以看看底下的宣言
http://manifesto.softwarecraftsmanship.org/
Stanly 提到他在學咖啡拉花的時候，遇到了瓶頸 ，但某次遇到一位 Mentor 後，透過 Mentor 的指點，讓他在突破那塊碰壁的天花版後，發現學習開始變的容易。
而其中有位教練曾經面試三關都過了，但對方最後告知沒有錄取。
原因是因為現在沒有資深的能帶他半年，對我來說是蠻有趣的方式，而且據說他們軟體開發的品質也非常的好。
最後還可以透過多參加社群聚會，藉由 Coding Dojo 的方式來提昇自已..等等
Retrospective
Sprint Review
這次 Sprint Review 其實是失敗的，整個團隊但很有收獲。
首先夥伴提到了一個，如果 Task 沒有符合當初 DOD 合約裡面的條件，其實是不能算做是 DONE 的應該稱為 It's Work
原因是前幾天我們都佈署的非常順利，但在週五的時候才實際開始做 Jenkins 上的
Acceptance Test ，結果一路 Fail 到 Spring Review 之前 。感覺起來挺可惜的
回顧會議
透過時間軸的方式，從週一到週五 分別利用便利貼 寫下 你喜歡、不喜歡、還好的事項 。 每個人要行投票後，談談這個事項的想法
在這中間我們的夥伴問到開發團隊應該要關注產品風險嗎？
Terry 說，其實在一開始的 product backlog 裡。 產品風險就已經分散了，而且在 PB 裡 只有做的優先順序，沒有所謂的風險順序。
最後畫了一張圖來談說，事實上 PO 會談論的觀注點是那些 (紅框處)
from : Odd-e CSD course
最後要小心一個點 ，不要為了想證明自已是很行的，而從工程師轉變為管理階層 ，通常這樣都不太有好下場，在現在世界變化快速的情況下，保持自已良好的工程思維是很重要的。
此外，在提到經驗時也舉例了，有些人說他有十年的經驗，但實際上可能十年都在做同樣的事，要突破自已要先跨出安逸區
收尾
最後我們團隊每個一人寫下 未來的長期目標 以及下週 Sprint 想做的事
大聲的對著河的對面的未來自已說出來，許下承諾
而我的初期目標其實是想建構 Jenkins 流程到我們的公司裡 ，但 Terry 提醒我 記得在做 Jenkins 時，要將這樣的東西加入版控
因為如果沒有了版控。 如果專案有天不幸要 Rollback 的話，很有可能目前的建構環境是完全不能符合需求的，這時候的 Continue Integration 就失效了
最後問了下 System Thinking 是不是他們目前有在使用， 他們說針對大項目時其實是會用的 。 但小項目幾乎是沒有在使用
最後
這幾天我其實都一直問教練關於我們公司裡的問題 。 事實上，有些問題其實我心裡應該也有答案了，但總是想找些支持。不過透過這樣的問答，有些時間讓我多了一些新想法
比如其中一個是，不要做 Prototype ，而事實上我再仔細問了下，其實是如果要做的話，利用 Backlog 的方式來進行也許會比較好。 我再仔細想了一下，當整個 Prototype 都完整做完了 。其實有點像是 PM 已經把所有的功能都定死了 ，開發只要 follow 就可以了！
此外，最主要的是，了解到一個 Agile 開發團隊要著重的是什麼 ？ (事實上就是 Product backlog 的完成)
在經歷了這五天的燒腦後，有些東西其實更明白了。但其實遺憾的是，我覺得我準備的問題其實不夠多。如果能再多一點，相信收獲可以更多。
我也十分推薦這門課程，如果你對 How to be a Agile Developer 十分有興趣，可以在這五天中找到你所想要的答案，也提醒你！這門課程很辛苦，但 Stanly 泡的咖啡十分好喝，可以搭配服用 !!
最後附上一張這五天的一個設計總結，如何透過測試了解當下的設計是否已經達到商業目標
一般來說早期的設計不太會往右側移動，也就是一開始的設計不會常常見到泛化的設計手段
比如： List<T> 、 Interface 、Design Pattern 等等…
當早期發現有種現象出現時，很有可能已經 Over Design 了
from: Odd-e CSD Course
對課程有興趣的同學，可以到以下網站找到相關的資訊