有效率的團隊互動是敏捷軟體開發的一個重要基石，能與人一起開發軟體是很棒的事情。
小小一本書，拖了這麼久終於整理完了，總計六篇：
Schedule Regular Face Time (進行每日的固定簡短開會)
開會是個溝通必要但又花時間討人厭的事情，在 Agile 方法論裡面提出了一種叫 Stand-up meeting 的每天開會方式，正如其名建議的：請站著開會，這樣才會提醒大家盡早開完。每個人至多兩分鐘報告三件事情 1.距離上次開會，我做了什麼? 2. 到下次開會，我打算做什麼 3. 我碰到的困難。如果有需要討論更細節特定的東西，請再約有關係的人在開完 stand-up 各自帶開即可。一般來說合理的 stand-up meeting 時間約10到15分鐘，至多絕不超過 30 分鐘。另外就是儘量不要等人，時間到了就開始吧。
Stand-up meeting 有幾個好處：1. 繼續專心每天的進度 2. 如果 developer 碰到任何問題，可以有機會發出聲音尋求幫助，加速事情解決 3. 幫助團隊成員了解其他人在做什麼事情。
Architects Must Write Code (架構設計師一定要寫程式)
軟體架構設計師已經變成有點被濫用的職稱了，一個只會畫好看的圖、講厲害的行話、用一堆 Patterns，但是真的要實做前就跑走的設計師是沒有用的。真的設計隨著實際開始實做、實際的 Feedback 之後才會逐漸演化。就像打戰一樣，一旦開打 Plan 就無用了，只能不斷地 Planning，策略決策也許千里遠可以做，但是戰術決定非得實際在戰場上了解才行。
The designer of a new kind of system must participate fully in the implementation. by Donald E. Knuth
作為一個架構設計師，要實際了解設計真的可行才算是負責。真正的 architect 是團隊中的導師，有能力解決較複雜的問題，但絕不放棄 coding。絕對不要用不 coding 的架構設計師，不實際 coding 了解系統是不可能設計好軟體的。 * Good Design evolves from active programmers. *
Practice Collective Ownership (練習集體擁有感)
“這個地方是 xxx 寫的，只有等他放假回來才能修的好”，這種事情很糟糕。請避免讓某一段 code 只能由某特定 developer 處理的情況，試著輪調 developer 去寫系統中不同的模組，分別由不同的人看過也可以讓程式更加被 checked、refactored 和 maintained 過，一旦碰到哪裡急需要修 Bugs 也不會發生等人的窘境。
當然，也許讓 developer 專屬某一領域的工作可能會開發一時會比較快速，不過放長遠一點看，透過多人共同開發的方式會獲得比較好的程式品質，也會比較好維護。整個團隊的 developers 的平均水準也可以拉高。對 developer 來說，知道寫出來的程式將來會被別人看，也會寫的更加用心。
這件事做起來當然是要注意過猶不及，例如太頻繁的輪調造成混亂或是系統中真的有某處需要特定人的特定專業知識。重點是 “你可以不需要了解系統中的每個細節，但是你也不應該害怕要你接手處理系統中的任何一塊”。
在 XP 方法論中，這件事情更是直接透過 Pair Programming 來達成，每一段 code 至少被兩個人擁有(處理) :p
Be a Mentor (當一個導師)
當你發現你比同事都懂的多的時候，請學著分享，正所謂教學相長，讓團隊一起提昇。當 Mentor 不代表要像當老師一樣用上課的方式，透過 Pair Programming 就是一種很好的學習成長方式。
Allow People to Figure It Out (給人魚不如給釣竿)
當 Mentor 不一定就是直接回答人家答案，回答一個方向讓人去思考也是個好方法，也許他還會回報你更多好答案。
Share Code Only When Ready (只 commit 準備好的程式)
千萬不要把(已知)會爛掉的程式 commit 進入版本控制系統，不然其他人更新最新版本之後不能正常執行，影響開發進度。請在做完一個任務或解完 Bug 之後，通過 unit test 之後再 commit 進去。當然，”It’s not ready” 不是一個久久不 commit 的藉口。
Review Code (程式碼複審)
找到程式問題的最佳時機就是剛寫好的時候：也就是在寫好程式及測試之後，輪流由另一外 developer 檢查程式(review code)。另一種採行 review code 的方式就是實行 XP 方法論的 pair programming：一人寫程式打字另一人是導航員。
Review code 要做什麼事情？
- 你可以閱讀看得懂程式嗎? (如果看不懂表示程式沒寫的好懂哩)
- 有沒有任何明顯的錯誤?
- 這程式有沒有任何不期望的副作用?
- 這程式有沒有跟系統其他地方有重複的程式碼?
- 有沒有任何合理的改進或重構可以做?
Code Review 可以大大改進程式品質、降低錯誤率，而且非常實用讓團隊彼此進步。
Keep Others Informed (資訊公開)
不要在 Deadline 那天才報告壞消息。如果任務中途碰到技術困難，也要提出來讓大家想想看怎麼解決，甚至讓客戶知道也許他們願意用其他任務交換。盡量公開進度資訊，團隊跟客戶才會對進度感到放心、知道何時幫助你，讓你贏得信任。不要等著讓別人追問你進度如何。
Code review 還有一種可以優先考慮的方案是，盡量在 continuous integration server 上自動化地跑各種 static analysis 工具。
終於看完了，感謝分享。