敏捷工具箱
1. wiki ** 是乙個很友好的支援協作的工具，團隊中的每乙個人都可以根據需要動態的新增和重新組織網頁中的內容
2. 版本控制 使用cvs
3. 單元測試 《junitrecipes 中文版》
4. 自動構建 《專案自動化之道》
5. 供.net平台使用的持續整合工具，通過windows 服務的方式執行。
6. 7. //物件導向設計原則
8. //測試驅動開發
9. //測試工具在內的資源集合.
第一章 敏捷---高效軟體開發之道
1.先難後易。我們要首先解決困難的問題，把簡單的問題留到最後。
第二章 態度決定一切
1. 做事：把矛頭對準問題的解決辦法，而不是人。這是真正有有用處的正面效應。
2. 欲速則不達：不要墜入快速的簡單修復之中，要投入時間和精力保持**的簡潔、敞亮。
3. 對事不對人：讓我們驕傲的應該是解決了問題，而不是比較誰的主意更好。
4. 排除萬難，奮勇前進；做正確的事情.要誠實，要有勇氣去說出實情。有時，這樣做很困難，所以我們要有足夠的勇氣。
第三章 學無止境
5.跟蹤變化：跟蹤技術變化，你不需要精通所有的技術，但是需要清楚知道行業的動向，從而規劃你的專案和職業生涯。
下面是一些建議：
迭代和增量式學習。每天計畫用一段時間來學習新技術。記下你想要學習的東西——當你聽到不熟悉的術語或者短語的時候，記錄下來.
了解最新**;
參加本地的使用者組活動;
參加研討會議；
如飢似渴的閱讀。
6.對團隊投資: 提供你和團隊學習的更好的平台。通過午餐會議可以增進每乙個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對專案大有裨益。
7.懂得丟棄: 學習新的東西，丟棄舊的東西。在學習一門技術的時候，要丟棄會阻止你前進的舊習慣。畢竟，汽車要比馬車車廂強的多。
8.打破砂鍋問到底： 不停的問為什麼。不能只滿足於別人告訴你的表面現象。要不停的提問直到你明白問題的根源。
9.把握開發節奏: 解決任務，在事情變得一團糟之前。保持事件之間穩定重複的間隔，更容易解決常見的重複任務。
第四章 交付使用者想要的軟體
10.讓客戶做決定：讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，並讓他們做決定。
11.讓設計指導而不是操縱開發：好設計是一張地圖，它也會進化。設計指引你向明確的方向前進，它不是殖民地，它不應該標識具體路線。你不要被設計（或者設計師）操縱。
12.合理的使用技術：根據需要選擇技術。首先決定什麼是你需要的，接著為這些具體的問題評估使用技術。對任何要使用的技術，多問一些挑剔的問題，並真實地作出回答。
13.保持可以發布:保持你的專案時刻可以發布。保證你的系統隨時可以編譯、執行、測試、並立即部署。
14.提早整合，頻繁整合: **整合是主要風險**。要想規避這個風險，只有早整合，持續而又規律的進行整合。
15.提早實現自動化部署：一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置檔案測試依賴的問題。質量保證人員要像測試應用一樣測試部署。
16.使用演示獲得頻繁反饋：清晰可見的開發。在開發的時候，要保持應用可見（而且客戶心中也要了解）。每隔一周或者兩周，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。
17.使用短迭代，增量式開發：發布帶有最小卻可用功能塊的產品。每個增量開發中，使用1-4周左右迭代週期。
18.固定的**就意味著背叛承諾：基於真實工作的評估，讓團隊和客戶一起，真正地在當前專案中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
第五章 敏捷反饋
19.守護天使：使用自動化的單元測試。好的單元測試能夠為你的**問題提供及時的警報。如果沒有到位的單元測試，不要進行任何設計和**修改。
20.先用它再實現它：程式設計之前，先測試。將tdd(test driven development，測試驅動開發)作為設計工具，它會為你帶來更簡單更實效的設計。
21.不同環境，就會有不同問題：使用持續整合工具，在每一種支援的平台和環境中執行單元測試。要積極地尋找問題，而不是等問題來找你。
22.自動驗收測試：為核心的業務邏輯建立測試。讓你的客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動執行。(fit,即 整合測試框架 http：
23.度量真實的進度：度量剩下的工作量，不要用不恰當的度量來欺騙自己或者自己的團隊。要評估那些需要完成的代辦事項。
24.傾聽使用者的聲音：每乙個抱怨的背後都隱藏了乙個事實。找出真相，修復真正的問題。
第六章 敏捷編碼
第七章 敏捷除錯
33.記錄問題解決日誌：維護乙個問題及其解決方案的日誌。保留解決方案是修復問題過程的一部分，以後發生相同或相似問題時，就可以很快找到並使用了。
34.警告就是錯誤：將警告視為錯誤。簽入帶有警告的**，就跟簽入有錯誤或者沒有通過測試的**一樣，都是極差的做法。簽入構建工具中的**不應該產生任何警告資訊。
35.對問題各個擊破：對問題各個擊破。在解決問題時，要將問題域與周邊隔離開，特別是在大型應該中。（用原型進行分離）。
36.報告所有的異常：處理或是向上傳播所有的異常。不要將它們壓制不管，就算是臨時這樣做也不行。在寫**是要估計會發生的問題。
37.提供有用的錯誤資訊：展示有用的錯誤資訊。提供更易於查詢錯誤細節的方式。發生問題時，要展示出盡量多的支援細節，不過別讓使用者陷入其中。
第八章 敏捷協作
成為指導者意味著要分享——而不是固守——自己的知識、經驗、和體會。意味著要對別人的所學和工作感興趣，同時願意為團隊增加價值，一切都是為了提高隊友和你能力與水平而不是毀掉團隊。
然而，努力爬到高處，再以蔑視的眼神輕視其他人，這似乎是人類本性。也許在沒有意識的情況下，溝通的障礙就已經建立起來了。團隊中的其他人可能出於畏懼或尷尬，就不願提出問題，這樣就無法完成知識
的交換了。這類團隊中的專家，就像是擁有無數金銀財寶的有錢人，卻因健康因無福享受。我們要成為指導別人的人，而不是折磨別人的人。
42.允許大家自己想辦法：給別人解決問題的機會。指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。
43.準備好後再共享**：絕不要提交尚未完成的**。故意簽入編譯未通過或是沒有通過單元測試的**，對於專案來說，應視做玩忽職守的犯罪行為。
44.做**複查：複查所有的**。對於提公升**質量和降低錯誤率來說，**複查是無價之寶。如果以正確的方式進行，複查可以產生非常實用而高效的成果。要讓不同的開發人員在每個任務完成後複查**。
例如：通宵複查、檢拾遊戲、結對程式設計。
45.及時通報進展與問題：發布進展狀況、新的想法和目前正在關注的主題。不要等著別人來問專案狀態如何。及時通報進展與問題，有情況發生時，就不會讓別人感到突然....
《高效程式設計師45個習慣》 敏捷開發有感
高效程式設計師的45個習慣 敏捷開發修煉之道 standing on shoulders of giants 站在巨人的肩膀上 2014年9 月20日星期六 h該書一共用了兩天時間通讀完，簡單的翻看其中的道理，把其中有用的好的道理和哲理摘錄和用自己的話說出來，引以為用。希望對看過該文的人有所幫助。在...
高效程式設計師的45個習慣 敏捷開發修煉之道
高效程式設計師的45個習慣 敏捷開發修煉之道 融知識 哲理 實踐於一體的奇書 定價 35.00 會員價 26.25 75折 樣章免費試讀 17 使用短迭代，增量發布 69 18 固定的 就意味著背叛承諾 73 第5章 敏捷反饋 76 19 守護天使 78 20 先用它再實現它 82 21 不同環境，...
高效程式設計師的45個習慣 敏捷開發修煉之道
筆者 寫道 在去年就在豆瓣上看到這本不錯的書，近來才拿到這本書好好的研讀一下。讀了之後又對本書有了更深的認識。我如此推崇她，因為我覺得她不像有些書那樣的長篇大論，講的都是大道理，看了雲裡霧裡的。而這本書呢，講的都是我們專案開發中實實在在遇到的，只是平時不太注意，作者只是用更樸素易懂的語言組織總結出來...