敏捷軟體開發一直是我們內部開發的核心概念，強調個人、合作、回應和使用工作軟體(wiki, version control, unit testing, build automaion)，2001年由一群軟體開發者發表宣言如下：
- 個人及互動勝於流程與工具
- 可用的軟體勝於詳盡的文件
- 與客戶合作勝於合約談判
- 回應變化勝於墨守計畫
軟體開發是連續(continuous)的，不是最後才測試，也不是最後才佈署，更不會停止收集需求跟feedback。正是因為開發軟體是如此複雜的活動，任何種類的錯誤如果不儘快修正，往往最後就會無法控制的失敗，因此唯有每天不斷的一點一滴的去修正，每天解決一些比較小的問題而不是最後脫韁野馬的大問題，這才是解決的辦法。
何謂 Agility 的定義，作者給了：
“Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (敏捷開發是一種在高度合作的環境中不斷根據回應來做修正的開發方式)
透過經常性地建構出可以實際使用的軟體，我們持續得到 feedback。程式碼會因為需求擴充而不斷地被修改重構演進。工作的流程被拆成一至四周的短 iterations，每次透過 demo 得到 feedback，確保方向正確。
敏捷開發最大的不同到底是什麼呢? 這本書不談方法論流程(XP、Scurm等)，而是談人本身，談團隊本身，談如何成為一個敏捷的開發人員。書的每一章由數個 Tips 組成，整本書共45個 Tips 來敘述什麼是敏捷的做法。這本書也得到2007年的 Jolts Productivity Award。
前兩章 Beginning Agility 跟 Feeding Agility 講的是基本的專業態度：
Work for Outcome (產出至上)
責怪不能解決問題。當出問題的時候，實際解決問題才是產出，而不是找兇手。
Quick Fixes Become Quicksand
為了很快地修好bug，即使不是很了解 code 怎麼運作，還是不明究理地加了奇怪的code修好了 (word-around)，因為寫這樣會炸，所以加了一行例外條件，blahblah… 然後沒人知道加那個條件是為什麼。anyway… 下一個 programmer 看到這行怎麼辦？ 有些 programmer 也許就跳過看不懂的這行，反正可以 work 就好。好的programmer 會搞清楚”為什麼”需要這行，更重要的是更會思考會有什麼副作用。
當一年一年過去，如果都沒有好的 programmer 在 refactor，可想得知這些 code 會恐怖到什麼程度，新增功能或fixed bug 將越來越困難。
粗淺的修正而沒有深度了解問題及可能的後果，也許當下 it look like it works，但是他傷害的程式可讀性，你可能會碰到有人說”不要改那裡，因為blah blah”，但當他離職了，就沒有知道那裡是幹麼的。
有幾種方式可以改善：
1.不要讓 developer 完全獨立寫 code，developer 要花時間去看別人的 code，確保程式的可讀性及可以理解。程式是寫給人看的，不是給機器看的。
2.寫 unit testing，在寫 testing 的過程中，你會轉換思維成如何設計 API，這將幫助你設計出更好呼叫及更清楚的程式。好的 unit testing 甚至可以當做一種可執行的文件，這也是 BDD 所強調的思維。
Criticize Ideas, Not People (對事不對人)
當有人提出一個點子的時候，不要指責，不要批判，只要說明你關心的問題點即可，討論這個問題而不是爭吵。保持專業，盡量問建設性的關鍵問題，而不是針對個人的情緒性發言。
每個人都有好想法跟不好的想法，別害怕都提出。試著針對優缺點討論，大部分的選項都是有 trade-offs 的。與其說決定最好的解法，不如說要大家同意在這個情境下什麼解決較好。
Damn the Torpedoes, Go Ahead
做正確的事，敢於溝通實話。例如接到一個爛程式要新增功能，你是要讓他爛到最後，還是提出優缺反應說這個很爛要好好改寫。
當你開發到一半，發現自己的方向不對了，勇於說出自己的新解法，即使需要更多時間，詢問看看其他人的想法。而不是默默的交差了事。誠實與勇氣贏得信任。
像布丁大人就常嚴厲地說：”這樣對嗎？”…. 當你知道什麼是對的，就應該去做，而不是含混了事。當你了解現在的錯誤，要有勇氣跟你的團隊/老闆甚至是客戶說明，即使這樣可能會影響時程。
實做一個新功能時，也許你發現前人用的是 copy-paste 大法，你也可以這樣做，而且也許一下就做好了。請鼓起勇氣跟大家說你要重構他。
當團隊不同意你的作法的時候，也許是你的理由解釋的不夠，為什麼這是對的。當團隊依然不同意你的作法的時候，也許他們才是對的。
當然，看到奇怪的code，不要第一時間把他丟掉改寫，沒有足夠的了解不是勇氣而是莽撞。
Keep up with change (跟上科技變化)
有人說科技進步很快，永遠跟不上乾脆就不學了。但東西多半是漸進步的，常常跟上才不會跟不上。
不用精專每項新技術，但保持警覺不要忽略，持續規律地學習跟上腳步。這一行不是學校畢業就可以停止學習。
了解為何新技術這麼重要? 是要解決什麼問題? 他要用在哪裡?
Invest in Your Team (投資你的團隊)
不要藏私，分享能讓團隊興奮的技術或技巧，提昇團隊背景知識絕對有助於溝通與開發效率。建議可以每週安排一場簡短的技術 presentation。
Know when to unlearn (知道什麼是過時的技術)
技術在進步，有時候必須把舊東西給丟掉學新的，例如CPU變快了，Developer time 變重要了，很多以往的舊寫法不再適用必須丟掉。不過最困難的第一步就是了解到是否用了過期的解法。
Question until you understand (問為什麼直到了解)
不要人家告訴你什麼通盤接受，在 debugging、了解 requirement 跟 design 時，要好好了解並提問。系統很複雜， debug 不能只看表面徵兆而已，而是要了解什麼是真正的問題所在。多問 why 想想到底是什麼原因。例如人家跟你說系統每週 reboot 就好啦，但是 why?
Feel the Rhythm (節奏)
持續有節奏地規律處理小任務總是比較簡單，不要讓問題累積到某一天突然炸出來而無法處理。團隊使用 interation 的方法，將專案的工作任務以一到四週為單位。
而對個人來說，以天為單位，今天結束前就應該把東西測試過然後 check in，如果今天沒辦法告一段落，很可能最好明天得重來。而 stand-up meeting 也會是每天規律的工作項目。
念到這裡，雖然都是看似一些很基本的 coding 專業態度，但這些價值觀卻往往比所謂的開發流程還重要不是嗎？
Update: 本系列文共有六篇：
可惜這些價值觀和態度是學校沒有教授，在工作也不會學到的…
好文:))
建議可以一天一週安排一場簡短的技術 presentation。
一週一天？
WM:
筆誤，應是每週一次 :)
關於presentation,如果可以,我認為是不需要用power point.
如果不是在人數很多的狀況下,因為做power point要花的時間很多.
開會效率最重要! 可以在1小時解決的,就在1小時解決,不要拖到3小時.
實際有如原作者講的那麼簡單就好了.