• 讓客戶做決定
• 讓設(shè)計指導(dǎo)而不是操縱開發(fā)
• 合理的使用技術(shù)
• 提早集成溶锭，頻繁集成，降低新代碼集成帶來的破壞性變化
• 一直保持可以發(fā)布
• 提早實現(xiàn)自動化部署
• 使用演示獲得頻繁反饋
• 使用短迭代忧侧，增量發(fā)布

10 讓客戶做決定

開發(fā)者（及項目經(jīng)理）能做的一個最重要的決定就是：判斷哪些是自己決定不了的，應(yīng)該讓企業(yè)主做決定挣菲。

讓你的客戶做決定贮喧。開發(fā)者、經(jīng)理或者業(yè)務(wù)分析師不應(yīng)該做業(yè)務(wù)方面的決定舔庶。用業(yè)務(wù)負(fù)責(zé)人能夠理解的語言抛蚁，向他們詳細解釋遇到的問題，并讓他們做決定惕橙。

11 讓設(shè)計指導(dǎo)開發(fā)而不是操縱開發(fā)

設(shè)計滿足實現(xiàn)即可瞧甩，不必過于詳細
Design should be only as detailed as needed to implement

嚴(yán)格的需求—設(shè)計—代碼—測試開發(fā)流程源于理想化的瀑布式②開發(fā)方法，它導(dǎo)致在前面進行了過度的設(shè)計弥鹦。這樣在項目的生命周期中肚逸，更新和維護這些詳細的設(shè)計文檔變成了主要工作，需要時間和資源方面的巨大投資彬坏，卻只有很少的回報朦促。我們本可以做得更好。

設(shè)計可以分為兩層：戰(zhàn)略和戰(zhàn)術(shù)栓始。前期的設(shè)計屬于戰(zhàn)略务冕，通常只有在沒有深入理解需求的時候需要這樣的設(shè)計。更確切地說混滔，它應(yīng)該只描述總體戰(zhàn)略洒疚，不應(yīng)深入到具體的細節(jié)歹颓。

良好的戰(zhàn)略設(shè)計應(yīng)該扮演地圖的角色，指引你向正確的方向前進油湖。任何設(shè)計僅是一個起跑點：它就像你的代碼一樣巍扛，在項目的生命周期中，會不停地進一步發(fā)展和提煉乏德。

好的設(shè)計應(yīng)該是正確的撤奸，而不是精確的。也就是說喊括，它描述的一切必須是正確的胧瓜，不應(yīng)該涉及不確定或者可能會發(fā)生變化的細節(jié)。它是目標(biāo)郑什，不是具體的處方府喳。

CRC（類—職責(zé)—協(xié)作）卡片的設(shè)計方法

• 類名
• 職責(zé)：它應(yīng)該做什么？
• 協(xié)作者：要完成工作它要與其他什么對象一起工作蘑拯？

白板钝满、草圖、便利貼都是非常好的設(shè)計工具申窘。復(fù)雜的建模工具只會讓你分散精力弯蚜，而不是啟發(fā)你的工作。

12 合理的使用技術(shù)

盲目地為項目選擇技術(shù)框架剃法，就好比是為了少交稅而生孩子碎捺。

每一門技術(shù)都會有優(yōu)點和缺點，無論它是開源的還是商業(yè)產(chǎn)品贷洲、框架收厨、工具或者語言，一定要清楚它的利弊恩脂。

13 保持可以發(fā)布

下面是一個簡單的工作流程帽氓，可以防止你提交破壞系統(tǒng)的代碼。

本地運行測試
檢出最新的代碼
提交代碼

14 提早集成俩块，頻繁集成

敏捷的一個主要特點就是持續(xù)開發(fā)。

15 提早實現(xiàn)自動化部署

提早在客戶的機器上進行部署浓领，避免最后部署時才發(fā)現(xiàn)問題玉凯。同時也要實現(xiàn)自動化部署。

質(zhì)量保證人員應(yīng)該測試部署過程
QA should test deployment

一開始就實現(xiàn)自動化部署應(yīng)用联贩。使用部署系統(tǒng)安裝你的應(yīng)用漫仆，在不同的機器上用不同的配置文件測試依賴的問題。質(zhì)量保證人員要像測試應(yīng)用一樣測試部署泪幌。

16 使用演示獲得頻繁反饋

定期地盲厌，每隔一段時間署照，例如一個迭代的結(jié)束，就與客戶會晤吗浩，并且演示你已經(jīng)完成的功能特性建芙。

要頻繁地獲得反饋。如果你的迭代周期是一個季節(jié)或者一年（那就太長了）懂扼，就應(yīng)把周期縮短到一周或者兩周禁荸。完成了一些功能和特征之后，去積極獲得客戶的反饋阀湿。

清晰可見的開發(fā)赶熟。在開發(fā)的時候，要保持應(yīng)用可見（而且客戶心中也要了解）陷嘴。每隔一周或者兩周映砖，邀請所有的客戶，給他們演示最新完成的功能灾挨，積極獲得他們的反饋邑退。

17 使用短迭代，增量發(fā)布

確定使產(chǎn)品可用的核心功能涨醋，然后把它們放在生產(chǎn)環(huán)境中瓜饥，越早交到用戶的手里越好。

即使是美國國家航空航天局（NASA）也使用迭代和增量開發(fā)方式開發(fā)用于航天飛機的復(fù)雜軟件浴骂。

根據(jù)項目的大小乓土，理想的發(fā)布周期是幾周到幾個月束亏。在每個增量開發(fā)周期里驹尼，應(yīng)該使用短的迭代（不應(yīng)該超過兩周）闽晦。每個迭代都要有演示酿雪，選擇可能提供反饋的用戶员寇，給他們每人一份最新的產(chǎn)品副本梯刚。

關(guān)于迭代時間長短一直是一個有爭議的問題输莺。
有時團隊無法在開發(fā)新的代碼的同時又要維護很多已經(jīng)完成了的代碼答憔。解決方案是喳挑，在每4周的迭代中間安排一周的維護任務(wù)彬伦。沒有規(guī)定說迭代必須要緊挨著下一個迭代。

18 固定的價格就意味著背叛承諾

固定價格的合同會是敏捷團隊的一大難題伊诵。我們一直在談?wù)撊绾斡贸掷m(xù)单绑、迭代和增量的方式工作。但是現(xiàn)在卻有些人跑過來曹宴，想提早知道它會花費多少時間及多少成本搂橙。

試試下面的辦法。
主動提議先構(gòu)建系統(tǒng)最初的笛坦、小的和有用的部分（用建筑來打個比方区转，就是先做一個車庫）苔巨。挑選一系列小的功能，這樣完成第一次交付應(yīng)該不多于6~8周废离。向客戶解釋侄泽，這時候還不是要完成所有的功能，而是要足夠一次交付厅缺，并能讓用戶真正使用蔬顾。

第一個迭代結(jié)束時客戶有兩個選擇：可以選擇一系列新的功能，繼續(xù)進入下一個迭代湘捎；或者可以取消合同诀豁，僅需支付第一個迭代的幾周費用，他們要么把現(xiàn)在的成果扔掉窥妇，要么找其他的團隊來完成它舷胜。

如果他們選擇繼續(xù)前進。那么這時候活翩，應(yīng)該就能很好地預(yù)測下一個迭代工作烹骨。在下一個迭代結(jié)束的時候，用戶仍然有同樣的選擇機會：要么現(xiàn)在停止材泄，要么繼續(xù)下一個迭代沮焕。

對客戶來說，這種方式的好處是項目不可能會死亡拉宗。他們可以很早地看到工作的進度（或者不足之處）峦树。他們總是可以控制項目，可以隨時停止項目旦事，不需要繳納任何的違約金魁巩。他們可以控制先完成哪些功能，并能精確地知道需要花費多少資金姐浮」人欤總而言之，客戶會承擔(dān)更低的風(fēng)險卖鲤。
而你所做的就是在進行迭代和增量開發(fā)肾扰。

敏捷不是意味著“開始編碼，我們最終會知道何時可以完成”蛋逾。你仍然需要根據(jù)當(dāng)前的知識和猜想白对，做一個大致的評估，解釋如何才能到達這個目標(biāo)换怖，并給出誤差范圍。