截止到現在自己已經有了3年多的敏捷團隊實踐，包括有一年多的敏捷團隊管理經驗。個人對敏捷還是比較推崇的，但是必須要注意結合實際進行落地，否則就成了邯鄲學步。其中我感覺落地的重點就是千萬不要生搬硬套敏捷的實施條款，而是去理解其精髓去融匯貫通。恰好《高效程序員的45個習慣——敏捷開發修煉之道》就給了我們這麼一個機會去深入瞭解敏捷的精髓，在第二次讀此書之際我對書中內容進行了些總結歸納，分享給大家。
第1章：什麼是敏捷？
“不管路走了多遠，錯了就要重新返回。”
- 敏捷意味着可以快速適應變化。
- 敏捷開發宣言：一種把以人爲本、團隊合作、快速響應變化和可工作的軟件作爲宗旨的開發方法。
- 人員：它並不要求所有人都是有經驗的專業人員，但必須具有專業的工作態度——每個人都盡最大可能做好自己的工作。
- 開發需持續不斷，持續地推進系統前進和完善。
一句話總結敏捷：敏捷開發就是在一個高度協作的環境中，不斷地使用反饋進行自我調整和完善。
第2章：態度決定一切
“選定了要走的路，就是選定了它通往的目的地。”
- 在敏捷團隊中，大家的重點是做事。你應該把重點放到解決問題上，而不是在指責犯錯者上面糾纏。
- 團隊成員在一起工作，應互相幫助，而不是互相指責。
- 壓力會迫使你走捷徑，只看眼前利益，但是請記住：欲速則不達。
- 一個大型系統你自然不可能搞明白所有代碼，但是你可以從更高的層面來了解大部分代碼的功能。
- 對事不對人：在一個需要緊密合作的開發團隊中，如果能稍加註意禮貌對待他人，將會有益於整個團隊關注真正有價值的問題，而不是勾心鬥角，誤入歧途。
- 工作中不感情用事是需要剋制力的，而你需要能展現出成熟大度來。
- 做正確的事。要誠實，要有勇氣去說出實情。
一句話總結：專業的態度應該着眼於項目和團隊的積極成果。關注個人和團隊的成長，圍繞最後的成功開展工作。
第3章：學無止境
“即使你已經在正確的道路上，但如果只是停止不前，也仍然會被淘汰出局。”
-
如何才能跟上技術變化的步伐呢？
- 迭代和增量式的學習；
- 瞭解最新行情；
- 參加本地的用戶組活動；
- 參加研討會議；
- 如飢似渴的閱讀；
- 你不需要精通所有技術，但要清楚知道行業的動向，從而規劃你的項目和職業生涯。
- 一個學習型的團隊纔是較好的團隊。
- 新技術會讓人感到有一點恐懼。你確實需要學習很多東西。已有的技能和習慣爲你打下了很好的基礎，但不能依賴它們。
- 爲了解決問題，你需要很好地瞭解系統的全局。
- 許多不成功的項目中，基本上都是隨意安排工作計劃，沒有任何規律，那樣的隨機安排很難處理。項目開發需要有一致和穩定的節奏。
一句話總結：在一個企業化的社會中，只有一個人會爲你負責——你自己。是否能跟上變化，完全取決於你自己。
第4章：交付用戶想要的軟件
“沒有任何計劃在遇敵後還能繼續執行。”
- 業務應用需要開發者和業務負責人互相配合來開發。這種配合的感覺就應該像一種良好、誠實的工作關係。
- 設計可以分爲兩層：戰略和戰術。前期的設計屬於戰略，通常只有在沒有深入理解需求的時候需要這樣的設計。更確切的說，它應該只描述總體戰略，不應該深入到具體的細節。
-
在考慮引入新技術或框架之前，你需要找到需要解決的問題，接下來考慮如下幾個方面:
- 這個技術框架真能解決這個問題嗎？
- 你將會被它拴住嗎？
- 維護成本是多少？
- 保證你的系統隨時可以編譯、運行、測試、部署、演示。
- 提早集成，頻繁集成。代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
- 提早實現自動化部署。
- 使用演示獲得頻繁的反饋。
- 大部分用戶都是希望現在就有一個夠用的軟件，而不是一年之後得到一個超級好的軟件。
- 確定使產品可用的核心功能，然後把它們放在生產環境中，越早交到用戶手裏越好。
- 讓團隊和客戶一起，真正地在當前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
一句話總結：敏捷——成功的軟件開發方法——取決於你識別和適應變化的能力。只有這樣纔有可能在預算之內及時完成開發，創建真正符合用戶需求的系統。
第5章：敏捷反饋
“一步行動，勝過千萬專家的意見。”
- 爲了應對代碼的變化，你需要持續獲得代碼健康狀態的反饋：它是在做你期望的事情嗎？最近一次修改有沒有無意破壞了什麼功能？這時你該帶上守護天使——自動化單元測試。
-
進行單元測試的理由：
- 單元測試能及時提供反饋。
- 單元測試讓你的代碼更加健壯。
- 單元測試是有用的設計工具。
- 單元測試是讓你自信的後臺。
- 單元測試是解決問題時的探測器。
- 單元測試是可信的文檔。
- 單元測試是學習工具。
- 人們不編寫單元測試的很多借口都是因爲代碼中的設計缺陷。通常，抗議越強烈，就說明設計越糟糕。
- 只在有具體理由的時候纔開始編碼。你可以專注於設計接口，而不會被很多實現的細節干擾。
- 不同環境，就有不同問題。使用持續集成工具，在每一種支持的平臺和環境中運行單元測試。要積極的尋找問題，而不是等問題來找你。
- 我們不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒有完成。
- 如果能一直讓下一步工作是可見的，會有助於進度度量。最好的做法就是使用待辦事項（backlog）。
- 不管它是否是產品的bug，還是文檔的bug，或是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。
- 每一個抱怨的身後都隱藏了一個事實。找出真相，修復真正的問題。
一句話總結：從實踐中得到反饋，確保你明確知道項目的正確狀態，而不是主觀臆測。
第6章：敏捷編碼
“任何一個笨蛋都能夠讓事情變得越來越笨重、越來越複雜、越來越極端。需要天才的指點以及許多的勇氣，才能讓事情向相反的方向發展。”
- 開發代碼時，應該注重可讀性，而不是隻圖自己方便。
- 作爲一個開發者，應該時刻提醒自己是否有辦法讓寫出的代碼更容易理解。
- 代碼被閱讀的次數要遠超過被編寫的次數，所以在編程時多付出一些努力來做好文檔（利用代碼本身；利用註釋），會讓你在將來受益匪淺。
- 與其花費時間去提升千分之一的性能表現，也許減少開發投入，降低成本，並儘快讓應用程序上市銷售更有價值。總而言之，要想應用成功，降低開發成本和縮短上市時間同樣重要。
- 對代碼做一些持續而有用的事情，而不是做一段長時間的編程或重構。
- 開發人員更應該爲自己能夠創建出一個簡單並且可用的設計而驕傲，不要進行過分設計，也不要將代碼複雜化。
- 讓類的功能儘量集中，讓組件儘量小。
- 保持系統靈活性的關鍵方式，是當新代碼取代原有代碼之後，其他已有的代碼不會意識到任何差別。
一句話總結：在編寫代碼時，每天付出一點小的努力，可以避免代碼“腐爛”，並且保證應用程序不至變得難以理解和維護。
第7章：敏捷調試
“你也許會對木匠那毫無差錯的工作印象深刻。但我向你保證，事實不是這樣的。真正的高手只是知道如何亡羊補牢。”
- 把你曾經遇到的棘手問題的解決方案記錄下來，方便下次使用。不要在同一個地方跌倒兩次，也不要付出更多地時間成本查找曾經的解決方案。
- 儘量將編譯器的警告視爲錯誤來解決，但實際中有些編輯器或第三方庫會產生一些無法也不必消除的警告，你需要仔細區分。
- 識別複雜問題的第一步，是將他們從大型系統中分離出來。
- 處理或是向上傳播所有的異常，而不是忽略或者壓制。
- 一方面要提供給用戶清晰、易於理解的問題描述和解釋；另一方面還要提供關於錯誤的詳盡技術細節來方便開發人員定位解決問題。
一句話總結：即使運作得最好的敏捷項目，也會發生錯誤，你所要做的就是提高自己的調試能力去“亡羊補牢”。
第8章：敏捷協作
“我不僅發揮了自己的全部能力，還將我所仰仗的人的能力發揮到極致。”
-
使用站立會議，每個人都應該只回答下述三個問題：
- 昨天有什麼收穫？
- 今天計劃要做哪些工作？
- 面臨着哪些障礙？
- 一個真正的架構師應該指導開發團隊，提升他們的水平，以解決更爲複雜的問題。架構師也應該參與代碼編寫，一個系統的設計者也應該親自投入到實現中去。
- 實行代碼集體所有制：版本管理系統，結對編程，代碼評審都是手段。
- 分享自己的知識——付出的同時便有收穫。還可以激勵別人獲得更好的成果，而且提升了整體團隊的實力。
- 作爲一個指導者，告訴團隊成員解決問題的方法，培養他們的思維和能力，而不是直接幫助他們解決。
- 及時通報進展與問題。讓協作者和管理者瞭解項目的進度與問題。
一句話總結：項目的成功與否，依賴與團隊中的成員如何一起有效的工作，如何互動，如何管理他們的活動。全體成員的行動必須要與項目相關，反過來每個人的行爲又會影響到項目。