敏捷開發的藝術讀書筆記

• 結對編程

以跟多的腦力來實現更優質的代碼。

一我的寫代碼‘駕駛員’，另外一個‘領航員’負責思考。

不要指派合做夥伴，結對是流動的，天然造成的，爭取跟團隊裏的每個人合做。經過交換搭檔來得到全新的想法。

結對編程時，頻繁的切換角色-至少每半個小時一次，也能夠幾分鐘一次。若是領航員老是在告訴駕駛員應該怎麼寫代碼，那就交換一下，讓領航員來寫代碼。

全部的工做均可以結對。

結對的兩我的相互協做，而不是挑毛病。

技能不相稱的時候，創造一些讓兩我的都要相互學習的機會，以此達到結對的平衡。

• 精力充沛的工做

短期的衝刺工做是一回事，長時間的衝刺工做倒是另一碼事。加班不能解決進度問題。事實上，它會帶來嚴重的負面後果。

精力充沛的工做不是偷懶的藉口，合理的工做強度能產生信任。

• 信息化工做場所

白板永遠不嫌多。

手工繪製的表格更方便、快捷、直觀。

• 根源分析

咱們經過根源分析來防止錯誤。

遇到問題時，不該該責備我的。咱們的工做方式應該是‘作什麼樣的改變才能讓問題不易出現。

根源分析的一種經典的方法是問五次」爲何「，古話就是「刨根問底」。

在任何發現問題的時候進行根源分析—當你發現一個bug，注意到錯誤，正在領航，或正在回顧會議上。

• 回顧

咱們持續的改善工做習慣。

最多見的回顧「迭代回顧」發送在每次迭代結束時。（決不能經過回顧來責備和我的攻擊）

步驟：

Norm Kerth的最高指示。

頭腦風暴（30分鐘）：每一個人回顧享受的、失望的、疑惑的、相同的、更多的、更少的事情。並記錄到卡片上。

靜音貼圖（10分鐘）：把相關的卡片貼在一塊兒，湊成一組，並用筆圈上每一個組。投票選出那一組應該在下一次迭代總獲得改善。

回顧目標（20分鐘）：投票結束，有一個分類會勝出。團隊利用根源分析，提出改善問題的方法。自由討論討論並投票選出一個方法，集中精力去解決。

• 信任

客戶和程序員換位思考。

程序員、測試源換位思考。

項目成員共同進餐。

給利益攸關者留一個好映像：可讓項目顯得緊迫一點（精力充沛的工做、信息化的工做場所、適當的彙報、以及迭代演示，這些都有助於讓項目顯得緊迫一點）；按承諾交付。管理問題（你須要把計劃作好。問題越大，你越應該更早的把它說出來， 利益攸關者知道問題的時間越早，他們就擁有更多的時間來找到繞過他的辦法。對加班的依賴暗示着系統性的問題。）。尊重客戶目標。爲團隊作宣傳。誠實。

• 坐在一塊兒

迅速而精確的溝通。

• 真實客戶參與

理解客戶與終端用戶的目標與無賴。

• 統一協做語言

相互瞭解對方的意思。

• 站立會議

咱們知道咱們的隊友在作什麼。

在每日例會上，參與者要回答3個特定的問題：我昨天作了什麼？今天要作什麼？有什麼問題妨礙我取得進展。

要簡潔，一般每人30秒。

按時開始並按時結束，即便在有人缺席的狀況下。

• 編碼規範

接受一種共同的審美觀。

制定咱們能夠接受的最小標準集合。

關注一致性和共識，而不是完美。

好比：咱們都贊成明確命名的變量和最小方法的重要性。咱們之間一致贊成使用斷言讓代碼快速失敗，沒有實際測量不進行優化，並且永遠不在對象之間傳遞空引用。咱們一致贊成應該怎樣或不該該怎樣處理異常，怎樣調試代碼，什麼時候作事件日誌，以及日誌寫到什麼地方。

• 迭代演示

咱們保持真實。從第一週開始，XP團隊每週都產出能工做的軟件。

團隊中任何人均可以作迭代演示，但建議產品經從來作。

整個團隊、關鍵的投資人以及執行發起人都應儘量常常的參加會議。

演示結束，問兩個問題：到目前爲止，咱們的工做令你滿意嗎？咱們能夠繼續嗎？

在最初的一個多月時間，能夠忽視半小時演示原則，並回答利益攸關者的每個問題，以此來創建友好。

將利益攸關則的問題記錄在像故事同樣記錄在卡片上，在會議後讓產品經理定優先級別。不在演示會議上解決問題。

若是此次迭代徹底失敗了，應該讓利益攸關者知道你在採起什麼行動來阻止一樣的事情再次發生。

• 彙報

咱們在團隊決策中培養信任。

進展彙報：好比一次迭代演示或一次發佈計劃。良好的進展彙報能使利益攸關者信任團隊的決策。

須要提供的進展彙報：願景陳述；每週演示；發佈和迭代計劃；burn-up圖。

• 所有完成

測試完成、編碼完成、設計完成、集成完成、成功構建、成功安裝、成功移植、評審完成、修復完成、用戶接受。

測試人員應該完成非功能性測試和探索性測試。

• 沒有bug

編寫更少的bug：測試驅動開發、精力充沛工做、結對編程、坐在一塊兒、客戶測試、探索性測試、迭代演示、編碼規範、所有完成，均可以幫助咱們編寫更少的bug。

消除滋生bug的溫牀：技術債務滋生bug。

如今修復bug：在實踐中，不可能當即修復每一個bug。當你發現一個bug時，你若是正在進行別的工做，可讓領航員在這個問題寫在咱們的todo列表上。在一二十分鐘後，在方便中斷手頭工做的時候，回頭看這個問題。若是沒有足夠的時間，估算一下修復這個bug的代價，而後請產品經理決定是否在此次發佈中修復它。若是這個修復很重要，就把它安排到下次迭代中。

測試你的過程（探索性測試）：不要徹底依賴探索性測試來尋找軟件中的bug，面對bug，主要的防線應該是測試驅動開發以及其它敏捷開發的優秀實踐。

修正你的過程：在你編寫測試並修正設計的同時，必定要多問幾個問題。爲何以前沒有測試防止這個問題？爲何須要設計修改？利用五個爲何的方式去考慮根本緣由。

• 版本控制

咱們將項目相關的全部內容都保存在單一可靠的地方。

對於數據庫，可讓構建數據庫的初始化腳本放入版本控制系統。

• 十分鐘構建

消除了構建和配置麻煩。

• 持續集成

咱們保證代碼隨時能夠交付。

如何作到持續集成：每隔借個小時持續集成一次代碼。保證構建、測試和其它發佈的組建都及時更新。

永遠不要打破構建：你須要一臺閒置的開發機做爲中心集成環境。

• 代碼集體全部制

咱們應共同提升代碼的質量。

無論在哪裏發現問題，修復它們。

在不熟悉的代碼上工做：開始時經過結對編程克服問題。在你工做的同時，尋找重構代碼的機會。

• 文檔

記錄必要信息。

過程文檔：需求文檔、設計文檔。面對面的交流比書寫文檔更加快捷有效。爲避免編寫過程性文檔。必須嚴格遵照全部的XP實踐（坐在一塊兒）。

產品文檔：用戶手冊和API文檔。建立故事，估算它，並排定優先級來完成。

• 願景

咱們明白本身的工做什麼重要，也知道怎樣才能得到成功。

願景陳述記錄三件事：項目應該完成什麼？項目爲何有價值？項目的成功標準是什麼？

• 發佈計劃

咱們爲成功而計劃。

一次一項目：每次只着手一個項目。

儘早發佈，常常發佈。

爲本身留一些餘地。

最終的故事列表就是你的發佈計劃。

在最後責任時間制定計劃：在實際中意味着，越遙遠的事情，你的發佈計劃須要爲之包含的細節就應該越少。（適應性計劃）

• 計劃博弈

任何人均可以建立一個故事或選擇一個未歸入計劃的故事。

程序員估算故事。

客戶按照相對優先次序將故事歸入計劃中。

重複這些步驟，知道全部的故事都被估算並歸入計劃。

• 風險管理

咱們作出並實現長期的承諾。

通常的風險管理計劃：每一個項目都會面臨一組常見的風險（推翻之前的工做；出現新的需求；工做中斷等），這些分享會對你的時間估算代買倍增的效應。

倍增係數表

概率百分比	嚴格的	冒險的	描述
10%	X1	X1	幾乎不可能（忽略）
50%	X1.4	X2	50多50的概率（彈性目標）
90%	X1.8	X4	近乎肯定（承諾）

若是你採用XP實踐（每一輪迭代中嚴格堅持「所有完成」，你的速度是穩定的，並且你的每一輪迭代中修正全部的bug），那麼你的風險就會下降。能夠採起「嚴格的」這一列的風險係數。相反，你應該使用「冒險的」一列中的風險因子。

項目特定的風險：應建立風險普查

團隊聚在一塊兒討論，並寫在卡片上：項目中什麼事情會使你晚上睡不着覺；設想在項目災難性的失敗一年以後，你被採訪，當被問及當時項目中出了什麼問題的時候，你會怎樣回答？；關於這個項目，你最美的夢想是什麼？而後寫下相反的一面？；在什麼狀況下，項目會在沒有任何人犯錯誤的狀況下失敗？；若是是利益攸關者的錯，項目會怎樣失敗？若是是客戶、測試員、程序員的錯、或者是管理上的錯，你本身的錯誤等，狀況又會怎樣？；在什麼狀況下，項目會成功，但某個利益攸關者卻會不滿意或者很生氣？

自由談論後，留下部分人繼續討論找出的風險，估算風險發生的可能性，風險的影響。

若是發現一些風險並不重要，再也不考慮它們。

對於剩下的，肯定你是否能夠經過不採起風險動做而避免這種風險；預留更多的時間和資金來容納它；或者採起減輕其影響的步驟來緩解它。

肯定：

過分指標：告訴你何時風險會變成現實。如：服務器利用率達到80%時可能出現宕機的風險。

緩解行爲：預先作什麼能夠減輕風險的影響。如：準備負載均衡器

應變行爲：風險發生時作什麼能夠減輕風險的影響。如：安裝負載均衡器

風險敞口：你應該預留多少的時間或資金來容納風險。

若是風險100%會發生，那就再也不是風險，修改你id發佈計劃來應付它。

應該指派一我的來監測風險。

怎樣承諾發佈任務：

風險校訂的剩餘點數 = （剩餘迭代次數 - 風險敞口） x 速度 / 風險倍增因子

如：使用嚴格的方法，你離發佈還有12次迭代，你的速度是每次迭代14個故事，而你的風險敞口是一次迭代

那麼：剩餘點數 = (12 -1) x 14 = 154點

           10%的概率： 154 / 1 = 154點

           50%的概率： 154 / 1.4 = 130點

           90%的概率： 154 / 1.8 = 86點

你能夠把它畫成更直觀的burn-up圖。每週注意一下大家完成了多少個故事點，下一次迭代中總共還有多少點（完成的加上剩餘的）。

咱們通常答應交付完成概率在90%的特性。

成功比時間表更重要。

風險管理只能用於你對外的任務承諾。在團隊內部，應該把精力集中在發佈計劃的實現上，按進度要求時間未調整的發佈計劃。

• 迭代計劃

咱們預先肯定一個時間間隔並保持不變，而後每隔一段時間便停下來將實現與計劃做比較。

-演示前一輪迭代（半小時）

-回顧前一輪迭代（一小時）

-制定迭代計劃（半小時到一小時）

-承擔故事的交互（5分鐘）

-開發故事（剩下時間）

-準備發佈（小於10分鐘）

咱們應該選擇一個合適團隊的迭代開始時間，並堅持它。

首先把故事分解爲工程任務。你們集思廣益，討論一下完成本次故事須要哪些任務。一塊兒討論任務是一種設計行爲，這是編碼開始以前一次很好的討論機會，不須要考慮太多的細節。每項任務的細節應該給結對們在拿到任務後本身去弄清楚。

結束討論後，看看這些任務能不能足以完成全部的故事》是否重複或重疊？誰還有不清楚的地方？發現任何問題都要討論一下。

你們討論估算時間，取得一致意見。使用理想時間來估算任務，即你將所有精力集中到任務下，不停頓，須要多少時間。若是任務超過6小時，分紅更小的任務。若是任務小於兩個小時，組合任務。

查看總的本次迭代估算計劃，考慮增長或刪除本次迭代的故事。

你們一塊兒承諾迭代的任務。不要強迫任何人承諾。有問題一塊兒討論。

一些程序員自願的承擔某項任務，而後在一我的跟他結對。

迭代結束後，取下卡片，填寫迭代編號、日期等信息，並夾在一塊兒歸檔。

勤務員：處理突發請求。

迭代長度能夠是任意的，許多團隊喜歡兩週的迭代。對新團隊，建議一週 的迭代。迭代開始時間，建議每週三。

• 鬆弛

咱們安裝迭代的承諾交付軟件。

研究時間。

當承諾遭遇風險時：

-將重構用做減震器，當遇到問題或落後與計劃進度是，優先完成迭代承諾。之後在清理技術債務

-主動付出一點加班時間

-取消研究時間

若是你一值在利用大多數鬆弛時間，說明你承諾的太多了。

研究時間也能夠結對。

缺少良好的客戶支持和技術債務，須要你須要更大的鬆弛度來實現承諾。

利用鬆弛度來清理一下技術債務，就會自動下降你未來所須要的鬆弛度。

• 故事

經過小的、以客戶爲中心的片斷來計劃咱們的工做。

故事是爲計劃準備的。

故事的合適尺度依賴於你的速度。每次迭代中你應該可以完成4-10個故事。

特殊的故事：文檔故事；‘非功能性’故事；bug故事；實驗故事；估算；會議；架構、設計、重構和技術基礎設施（不要爲技術細節建立故事）

故事不能替代需求。你須要另外一種得到細節的方法，如：現場專家客戶，或者需求文檔。

• 估算

咱們提供可靠的估算。

客戶或利益攸關者感受你的估算時間太長的時候。應該跟他們解釋爲何任務須要怎麼多時間，要禮貌而堅決的拒絕改變你的估算。

• 增量式需求

咱們在進行其它工做的同時定義需求。

現場的客戶就是活動的需求文檔。

客戶評審：在開發各個故事的過程當中，在它們被所有完成以前，評審沒一個故事，確保它按客戶指望的方式工做。

• 客戶測試

關注業務規則。

程序員可使用它們喜歡的工具把客戶示例轉化成自動測試。如Fit。

不要用客戶測試來替代驅動測試開發。客戶測試是一種協助交流複雜業務規則的工具，而不是一宗全面的自動測試工具。

• 驅動測試開發

第一步：思考。

第二步：紅色進度條。測試編寫後，運行所有測試套件，看着測試失敗。

第三步：綠色進度條。編寫足夠的產品代碼讓測試經過。再次運行你的測試，看着測試經過。

第四步：重構

第五步：重複

單元測試：跑起來很快，若是不快，就不是單元測試。

若是一個測試須要：訪問數據庫、進行網絡通訊、使用文件系統、須要對環境作特殊處理。這個測試就不是單元測試，而是集成測試。

聚焦集成測試：只測試與外界進行的一次交互。確保各個測試之間相互隔離，每個測試均可以獨立運行。

• 重構

每一天，咱們的代碼都比前一天好一點點。

• 簡單設計

作儘可能少的預期，並保持乾淨整潔。一個簡單的設計是乾淨和優雅的。

原則：一次有且僅有一次（每一個概念在代碼中表達一次）

自解釋代碼：解釋並不壞，但它卻暗示着代碼的複雜程度可能超出了須要。

隔離第三方組件：將第三方組件隔離在一個你所控制的藉口以後。建立本身的基類來擴展框架中的類，而不是直接該源類的代碼在擴展功能。

• 增量式設計和架構

方法的增量設計

類的增量設計

架構的增量設計：開始時只在設計的某個部分上嘗試新模式。將它持續使用一段時間以確認這種改變能在實際中正常工做，再調整到其它部分。重構的同時仍要堅持不斷交付故事。

• 實驗方案

小的、孤立性的實驗。

若是在估算一個故事的時候就預見到有的地方須要試驗，那就在故事的估算總包含試驗所需的時間。有時，試驗太複雜，就建立一個試驗故事並對它進行估算。

• 性能優化

必要的時候進行優化。

使用性能分析器（profiler）來指導你的優化行爲。

優化有兩大缺點：經常致使複雜的問題代碼，佔用了原本能夠用來交付特性的時間。僅當優化能夠服務與真實的、可度量的需求時再進行優化。

編寫性能故事：應包含吞吐量、延時、響應性。如：每分鐘至少100屢次交易；每次交易能夠延時6秒鐘；點擊後10秒內完成搜索。

• 探索性測試

經過測試驅動開發來建立全面的、自動化的迴歸測試套件。將探索性測試的重點放在新特性上，特別是那些行事方式不一樣與之前特性的新特性。

不要試圖將探索性測試用於迴歸測試策略。迴歸測試應該是自動化的。

僅當你可能揭示新的信息並可能根據這種信息採起行動時，再使用探索性測試。