2015年5月19日下午Martin Fowler在深圳做了一次講座，我有幸參加了。Martin Fowler分享了Agile精髓和一個(gè)Agile流暢性模型，他演講的內(nèi)容在他的博客中都有,，鏈接如下：

http:///articles/newMethodology.html

http:///articles/agileFluency.html

我本打算整理一下我的筆記,，然后寫篇短文分享出來，結(jié)果在參考上面的鏈接的時(shí)候,，發(fā)現(xiàn)里面的內(nèi)容比他演講的內(nèi)容更加詳盡，所以我就嘗試把他上面的文章翻譯了一下，由于文章內(nèi)容較多，我挑重點(diǎn)翻譯的,，在翻譯方面還處于菜鳥階段,，所以很費(fèi)力，耗費(fèi)一天的時(shí)間才翻譯了第一篇(一套新方法),。下周會(huì)嘗試翻譯另外一篇（Agile流暢性模型）。翻譯中難免疏誤,，歡迎指正,。

從無方法，到計(jì)劃驅(qū)動(dòng)方法,，再到敏捷

大部分的開發(fā)過程一片混沌,，可以簡單的概述為“開發(fā)，然后解bug”,。沒有太多計(jì)劃,，對于整個(gè)系統(tǒng)沒有一個(gè)核心的設(shè)計(jì)，而是根據(jù)短期的需求不斷的打補(bǔ)丁,，當(dāng)系統(tǒng)不大的時(shí)候這種方法還行得通,，但是當(dāng)系統(tǒng)變得越來越復(fù)雜,，添加新功能就會(huì)變得越來越困難，bug就會(huì)越來越多,，而且還很難修復(fù),。這樣的系統(tǒng)在完成一個(gè)功能之后都必須要進(jìn)行一個(gè)很長時(shí)間的測試周期，由于此時(shí)的bug很難調(diào)試而且很難修復(fù),，所以這個(gè)測試周期通常無法預(yù)測,，軟件開發(fā)計(jì)劃也很難進(jìn)行。

最開始,，人們視圖解決這個(gè)問題的方法是制定一系列的流程,，來確保軟件開發(fā)可預(yù)測更高效。于是他們會(huì)制定非常詳細(xì)的流程,，并且特別強(qiáng)調(diào)“制定計(jì)劃“的環(huán)節(jié),，下面我將把這種方法稱之為工程方法(也被廣泛的稱之為計(jì)劃驅(qū)動(dòng)方法)。

工程方法被使用了很長一段時(shí)間,，但沒有成功,；人們對它最多的批評是“太官僚化”，按照這個(gè)方法,，會(huì)有太多的步驟,，整個(gè)流程走下來太耗費(fèi)時(shí)間，拖慢開發(fā)進(jìn)度,。

敏捷方法與工程方法是相對的,，很多人喜歡敏捷是因?yàn)樗幌?em>工程方法那么“官僚”，它是太多流程和無流程之間的折中,，它提供剛好夠用的流程,。

敏捷方法和工程方法的區(qū)別在于他們的側(cè)重點(diǎn)不同，比如,，相比較而言,，敏捷方法不是文檔導(dǎo)向型，而是代碼導(dǎo)向型的,，或者說,，在敏捷方法中，代碼本身就是文檔,。

但是我認(rèn)為這不是二者的核心區(qū)別,，忽視文檔只不過是表象，它們有更深層次的區(qū)別：

敏捷方法強(qiáng)調(diào)自適應(yīng)性而非可預(yù)見性,。工程方法傾向于花較長的時(shí)間,，來給軟件開發(fā)過程制定一個(gè)大而全的計(jì)劃，然后嚴(yán)格按照計(jì)劃執(zhí)行,，在無變化的環(huán)境下這個(gè)方法挺好,，它天性排斥變化,。而敏捷方法，則擁抱變化,；它會(huì)適應(yīng)變化并隨變化生長,，甚至進(jìn)化。

敏捷方法強(qiáng)調(diào)以人為本而非以流程為本,。工程方法的目標(biāo)是制定一個(gè)通用的流程,，不管套用在誰身上，都能適用,。敏捷方法則堅(jiān)定的認(rèn)為,，沒有任何流程可以取代開發(fā)團(tuán)隊(duì)的技術(shù)和能力，而流程,，僅僅是為團(tuán)隊(duì)服務(wù)的工具,。

下面我將詳細(xì)闡述他們的區(qū)別。

可預(yù)見性與自適應(yīng)性

1. 設(shè)計(jì)與實(shí)現(xiàn)的分離

我們會(huì)不自覺的受機(jī)械工程方法和土木工程方法的影響,，它們強(qiáng)調(diào)在建造之前要做詳盡的計(jì)劃,。工程師們會(huì)畫出很詳盡的圖紙，在上面標(biāo)記出需要什么樣的材料,，并能表示出如何把這些材料組合出最終的東西,，這些圖紙會(huì)轉(zhuǎn)交給別的團(tuán)隊(duì)，通常是另外一個(gè)公司,，讓他們?nèi)ソㄔ?。這個(gè)方法的前提是，建造過程能夠按照圖紙進(jìn)行下去,，實(shí)際建造的時(shí)候雖然總會(huì)遇到一些問題,，但通常都是些小問題。

因?yàn)閳D紙能夠詳細(xì)表明建造的過程,，那么就能根據(jù)這些圖紙制定一個(gè)計(jì)劃,，比如一共有多少子任務(wù)，每個(gè)任務(wù)的依賴關(guān)系等等,，都可以制定出來,，甚至連工人應(yīng)該怎么工作都有詳細(xì)的說明，于是就能評估時(shí)間表和預(yù)算了,。在這種方式下，工人無需多少知識(shí)技能,，只要手腳麻利就可以了,。

所以設(shè)計(jì)與實(shí)現(xiàn)這兩者的差異就很明顯了，設(shè)計(jì)通常比較困難,，而且很難預(yù)測,，需要昂貴的富有創(chuàng)造力的人才能制定,；而實(shí)現(xiàn)過程則比較容易預(yù)測。只要設(shè)計(jì)圖出來了,，我們就可以計(jì)劃整個(gè)流程,；只要能夠計(jì)劃整個(gè)流程，我們就能很好的預(yù)測,。在土木工程中,，建造過程的成本遠(yuǎn)大于設(shè)計(jì)和計(jì)劃階段的成本。

于是,，人們很容易想到在軟件工程方法中也引入類似的方法：我們也把設(shè)計(jì)實(shí)現(xiàn)分離,，讓高水平的人做出軟件設(shè)計(jì)，然后讓低水平的人去寫代碼,，這樣的話,，軟件開發(fā)過程就能預(yù)測了，也能詳盡的計(jì)劃了,。聽起來不錯(cuò),，但我們首先要找到能詳盡的表示軟件設(shè)計(jì)的方法。

在軟件設(shè)計(jì)中有一個(gè)術(shù)語：“UML”,，如果我們能把所有的決策都用UML來表示,，我們就可以制定一個(gè)實(shí)現(xiàn)計(jì)劃了，然后把設(shè)計(jì)交給碼農(nóng)們?nèi)?shí)現(xiàn)就好了,。

但是這里隱含一個(gè)關(guān)鍵問題：你能給出一個(gè)可以預(yù)測實(shí)現(xiàn)過程并且可以直接轉(zhuǎn)化代碼的設(shè)計(jì)嗎,？即便能，那么做出這個(gè)設(shè)計(jì)的成本足夠少嗎,？能少到值得去做嗎,？

由此我們想到一些問題。首先,，做出一個(gè)能夠交給碼農(nóng)去執(zhí)行的設(shè)計(jì)的難度會(huì)有多大,。問題是，類似于UML這樣的設(shè)計(jì),，往往在紙上看起來挺好看,，在實(shí)際編碼的時(shí)候總是遇到問題。土木工程的設(shè)計(jì)圖是建立在多年的實(shí)踐基礎(chǔ)上的,，而且更關(guān)鍵的是,，它這種設(shè)計(jì)是可以通過數(shù)學(xué)分析和計(jì)算來掌控的。UML這樣的圖表能夠幫助我們做代碼review,，但它常常帶來設(shè)計(jì)上隱性錯(cuò)誤,，這些錯(cuò)誤只有在編碼或者測試的時(shí)候才被發(fā)現(xiàn)，即便是非常高水平的設(shè)計(jì)師，比如說我,，也經(jīng)常在付諸代碼的過程中發(fā)現(xiàn)新問題,。

另一個(gè)問題是相比較下的成本。如果你建造一座橋,，設(shè)計(jì)成本不過占10%,，剩下的都是實(shí)現(xiàn)成本。在軟件中,，通常只有15%的編碼和單元測試時(shí)間,，即便你把所有的測試時(shí)間算做實(shí)現(xiàn)時(shí)間，那么剩下的設(shè)計(jì)時(shí)間依然不少于50%（譯者注：解bug時(shí)間應(yīng)該算作是對設(shè)計(jì)的完善,，也屬于設(shè)計(jì)時(shí)間）,。這就引發(fā)了一個(gè)重要的問題：軟件設(shè)計(jì)與土木工程上的設(shè)計(jì)到底有何本質(zhì)不同？

對于這個(gè)問題,，Jack Reeves認(rèn)為：源代碼本身就是設(shè)計(jì)文檔,，實(shí)現(xiàn)階段實(shí)際上是編譯和鏈接階段。的確,，任何你被認(rèn)為是實(shí)現(xiàn)的東西都已經(jīng)能夠并且應(yīng)該自動(dòng)化,。

由此我們得出一些重要結(jié)論：

在軟件開發(fā)中，實(shí)現(xiàn)過程的成本已經(jīng)接近于零,。

軟件的所有工作都是設(shè)計(jì),，所以需要富有創(chuàng)造力和才華的人

創(chuàng)造性的過程是很難被計(jì)劃的，所以預(yù)測它是無法完成的任務(wù),。

我們必須對傳統(tǒng)工程學(xué)方法保持警惕,，不同的活動(dòng)需要不同的方法。

2. 需求的不確定性

經(jīng)常有開發(fā)者抱怨說“項(xiàng)目的需求總是在變化”,。其實(shí)這背后是有原因的,。

我們通常把需求的變化歸結(jié)為需求分析人員的工作不到位。并且以為,，需求分析師應(yīng)該詳細(xì)的列出需求條款,，然后讓客戶在上面簽字畫押，后面再制定一些限制需求變化的流程,。

這里隱藏一個(gè)問題,，完全理解需求條款是很難的。更讓客戶為難的是,，軟件開發(fā)方通常不會(huì)在需求條款里提供成本信息,。

因?yàn)轭A(yù)估成本是非常困難的。首先,，軟件開發(fā)本身是一個(gè)設(shè)計(jì)活動(dòng),，很難去計(jì)劃和評估成本；其次，軟件開發(fā)對于參與進(jìn)來的個(gè)體具有非常強(qiáng)的依賴,，而個(gè)體是有差異，也很難去預(yù)測和量化,。

另一方面,，軟件是看不見摸不著的。你很難弄清除一個(gè)軟件功能到底能給你帶來多少價(jià)值,，除非你真實(shí)的使用它,；只有當(dāng)你見到早期版本的時(shí)候，你才能看到哪些功能有價(jià)值哪些沒有價(jià)值,。

于是就有了這個(gè)諷刺的結(jié)論,，人們希望需求可以變化。畢竟,，軟件應(yīng)該是“軟”的,。所以，需求不僅是可變的,，而且應(yīng)該是可變的,。和軟件的客戶一下子敲定需求是很難的，特別是那些對軟件開發(fā)了解一點(diǎn),，但不是很多的人,，更難；因?yàn)樗麄儭爸馈避浖且鬃兊摹?/p>

今天的商業(yè)力量在改變軟件新功能的價(jià)值,，客戶在6個(gè)月前定義的需求已經(jīng)不是那么有價(jià)值的需求,，即使客戶曾經(jīng)確認(rèn)了需求并且敲定，商業(yè)世界也不會(huì)因此而停止,，客戶的價(jià)值還是會(huì)有損失,；于是，如果別家的軟件可以根據(jù)需求變化,，那么你將不具有競爭力,。

軟件開發(fā)中的一切都依賴于需求，如果你無法保證需求變化,，你也就無法制定一個(gè)可以預(yù)測的計(jì)劃,。

3. 預(yù)測是可能的嗎？

簡短的回答是,，不可能,。有一些軟件開發(fā)是可以預(yù)測的。比如像NASA（美國國家航空航天局）這樣的機(jī)構(gòu),，他們的軟件開發(fā)是可以預(yù)測的,。因?yàn)樗麄冇泻芏嗟臅r(shí)間，很大的團(tuán)隊(duì)，和穩(wěn)定的需求,，他們的項(xiàng)目都是太空飛行器,。然而，我認(rèn)為大多數(shù)的商業(yè)軟件都不屬于這一類,，你需要另外一種方法,。

一個(gè)較大的風(fēng)險(xiǎn)是對于一個(gè)無法預(yù)測的工作使用一個(gè)預(yù)測性的流程。這對人很有吸引力,，大家都期望事情是可以預(yù)測的,，然而，在無法預(yù)測的時(shí)候選擇相信事情是可以預(yù)測的,，將會(huì)使人們早早的制定詳盡的計(jì)劃,，但卻不能正確處理計(jì)劃“摔跟頭”的情形，你只能眼睜睜的看著計(jì)劃和現(xiàn)實(shí)越來越遠(yuǎn),，你可以假裝計(jì)劃仍然有效,，但是，最終你將看到計(jì)劃“摔跟頭”的情形,，而且會(huì)“摔”的很疼,。

所以，當(dāng)你處在一個(gè)無法預(yù)測的環(huán)境中時(shí),，就不要使用預(yù)測性的方法?，F(xiàn)實(shí)總是殘酷的。也就是說,，控制項(xiàng)目的模型,，為客戶關(guān)系所建立的模型，都不再有效,。預(yù)測性的方法很好,，放棄它很難，這有點(diǎn)像“最困難的事情就是承認(rèn)困難存在”,。

然而,，放棄預(yù)測，并非意味著回到之前完全失控的混沌狀態(tài),，你需要一套可以控制不可預(yù)見性的方法,，這正是我要說的自適應(yīng)性方法。

4. 控制不可預(yù)測的方法－迭代

那么,，我們?nèi)绾卧谖粗氖澜缰锌刂谱约耗?？最重要的，也最難的是,，弄清楚我們在哪兒,，我們需要一個(gè)誠實(shí)的反饋機(jī)制,，來每隔一小段時(shí)間精確的告訴我們當(dāng)下所處的位置。

建立這種反饋機(jī)制的核心是迭代開發(fā),。這不是個(gè)新思路,。迭代開發(fā)已經(jīng)有段歷史了，它有許多其他的名字：增量開發(fā),，演進(jìn)開發(fā),，階段開發(fā)，螺旋式開發(fā)...等等很多名字,。迭代開發(fā)的關(guān)鍵是經(jīng)常產(chǎn)生一個(gè)可用版本，這個(gè)可用版本的功能是最終版本的子集,，每個(gè)迭代新增的功能都很小,，但每個(gè)版本都向最終版本更近一步，它們會(huì)像發(fā)布最終版本一樣,，都要經(jīng)過集成并通過完整測試,。

這么做是因?yàn)闆]有什么能比一個(gè)經(jīng)過集成測試后的系統(tǒng)更真實(shí)，更讓人放心,。文檔常常存在缺陷,，未經(jīng)測試到代碼中也常常隱藏著缺陷，但是當(dāng)人們坐下來,，真實(shí)的使用系統(tǒng)的時(shí)候,，才會(huì)發(fā)現(xiàn)缺陷，可能是bug,，也可能是需求的錯(cuò)誤,。

迭代式開發(fā)也適應(yīng)于可預(yù)測的工作中。但是,，對自適應(yīng)性流程來說,，迭代是必不可少的，因?yàn)樽赃m應(yīng)流程需要處理好需求的變化,。于是計(jì)劃就變成這樣子的：長期的計(jì)劃可能會(huì)變,，但基礎(chǔ)不經(jīng)常變，而每次迭代都是完成一個(gè)短期計(jì)劃,，每個(gè)短期計(jì)劃都是執(zhí)行大計(jì)劃中比較穩(wěn)定的部分,。迭代式開發(fā)的每個(gè)迭代，都給下個(gè)迭代的短期計(jì)劃打下堅(jiān)實(shí)的基礎(chǔ),。

有人會(huì)問,，一個(gè)迭代應(yīng)該要多久呢。不同的人可能有不同的答案,。極限編程建議迭代是一到兩周,，SCRMUM則建議一個(gè)月,，而現(xiàn)在的趨勢是，盡量把迭代時(shí)間縮短到你能承受的程度,，這會(huì)帶來更快的反饋,，你也因此更加頻繁的知道自己在哪兒。

5. 自適應(yīng)的客戶

這種自適應(yīng)的方法需要一種不同的客戶關(guān)系,，以往的客戶期望固定價(jià)格的合同,，告訴軟件開發(fā)公司他們需要什么，詢問報(bào)價(jià),，接受報(bào)價(jià),，然后開發(fā)任務(wù)就交給軟件開發(fā)公司了。

而在自適應(yīng)方法中,，客戶能更精細(xì)的調(diào)控軟件開發(fā)過程,。每個(gè)迭代中，他們可以檢查進(jìn)度,，也可以改變軟件開發(fā)的方向,。這就使得客戶和軟件開發(fā)者的關(guān)系更親密，更像合作伙伴,。這種參與,，不是因?yàn)榭蛻簦膊皇且驗(yàn)檐浖_發(fā)者,，而是因?yàn)橹挥羞@樣,，自適應(yīng)方法才能得到良好發(fā)揮。

這么做能給客戶帶來巨大的優(yōu)勢,。首先,，他們的需求能得到快速反饋。一個(gè)可用的盡管很小的系統(tǒng),，可以較快的上線,，盡早的給客戶帶來價(jià)值，然后客戶可以根據(jù)商業(yè)的變化改變它的功能需求,，而且也可以在這個(gè)過程中自然的學(xué)習(xí)到該系統(tǒng)的用法,。大部分人應(yīng)該已經(jīng)注意到，人們通常一開始不知道自己對軟件的需求是什么,，當(dāng)他用到軟件的時(shí)候才意識(shí)到哪些功能是真正能給他帶來價(jià)值的,。敏捷方法鼓勵(lì)人們在每個(gè)迭代發(fā)布的版本中發(fā)現(xiàn)自己的需求，這種隨需求變化而構(gòu)建的軟件具有較強(qiáng)的競爭力,。

所有方法都有一個(gè)評定項(xiàng)目成功與否的方式,。可預(yù)測的項(xiàng)目,，通常由它與原計(jì)劃的契合度來評定,，如果按時(shí)按量完成就是成功,。但這種方法對于敏捷來說沒有任何意義，敏捷主義者追求的是商業(yè)價(jià)值——客戶是否獲得比成本更高的價(jià)值,。一個(gè)好的可預(yù)測項(xiàng)目根據(jù)計(jì)劃進(jìn)行,，而一個(gè)好的敏捷項(xiàng)目則會(huì)打造一個(gè)比最初所計(jì)劃的更好的計(jì)劃。

以人為本

執(zhí)行自適應(yīng)方法不容易,。它需要一個(gè)非常有效的開發(fā)團(tuán)隊(duì),，而且每個(gè)成員要有效，成員間的協(xié)作也要有效,。有一個(gè)有趣的現(xiàn)象：不僅僅自適應(yīng)性的流程需要一個(gè)強(qiáng)有力的團(tuán)隊(duì),，大部分的優(yōu)秀開發(fā)者也喜歡自適應(yīng)的流程。

即插即用的編程單元

傳統(tǒng)方法的目標(biāo)之一是,，開發(fā)出一個(gè)流程,，使得參與流程中的人們是可以被替換的。在這種流程中,，你可以把人看作是資源，不同技能的人是不同類型的資源,。比如分析師,，碼農(nóng)，測試人員,，以及經(jīng)理,，每個(gè)個(gè)體都不是特別重要，重要的是角色,。于是,，如果你計(jì)劃一個(gè)項(xiàng)目，哪個(gè)分析師或者哪個(gè)測試參與進(jìn)來都無關(guān)緊要,，你只需要知道有多少資源,，你就能知道你的計(jì)劃會(huì)不會(huì)受到影響。

但是這里有一個(gè)關(guān)鍵問題,，軟件開發(fā)中的個(gè)體是可以被替換的嗎,？敏捷方法給出的答案是否定的。

或許反對把人當(dāng)作資源的聲音最高的人當(dāng)屬Alistair Cockburn,，在他的一篇論文里指出,，“人是高度可變的，非線性的,，有時(shí)高效有時(shí)低效,，這些都是很直接的并且不容忽視的因素...人是軟件開發(fā)中最重要的因素?！?/p>

其實(shí)許多軟件開發(fā)的思想家,，都持有軟件開發(fā)應(yīng)以人為先的觀點(diǎn),。但是要推行以人為先是一個(gè)很大的決定，需要很大的決心去推動(dòng),。因?yàn)榘讶水?dāng)作資源的觀念已經(jīng)在商業(yè)思維中根深蒂固,，它起源于Frederick Taylor's的《科學(xué)管理方法》一書。在工廠生產(chǎn)中,，Taylor的方法可以奏效,，但是對于高度創(chuàng)新性和專業(yè)的工作，比如軟件開發(fā),，就不怎么奏效了,。（實(shí)際上，現(xiàn)在的制造方法已經(jīng)開始放棄Taylor的方法了,。）

碼農(nóng)是負(fù)責(zé)任的專業(yè)人士

Taylor觀點(diǎn)認(rèn)為,，實(shí)際干活的人無法評估自己最大能干多少活。在工廠中這可能是有道理的,，原因之一可能是工廠的工人不是那么聰明和富有創(chuàng)造力的人,，也可能是因?yàn)楣芾韺雍凸と酥g有種緊張的氣氛，因?yàn)楣芾韺訏甑玫腻X多而工人掙得少,。

最近的歷史越來越表明,，軟件開發(fā)中沒有這樣的事。越來越多的聰明能干的人被吸引到軟件開發(fā)中來,，因?yàn)樗犉饋砀叽笊隙夷軖甏箦X,。（我就是因此而從電氣工程轉(zhuǎn)行過來的。）盡管在00年代早期出現(xiàn)過下滑,，但在軟件開發(fā)行業(yè)中仍然涌現(xiàn)出了大量的天才和創(chuàng)新,。

當(dāng)你想要雇傭和保留好的人才時(shí)，你需要甄別出他們是否是有能力的專家,。就本身而論,，他們自己才是指導(dǎo)自己工作的最佳人選。Taylor的觀念是把計(jì)劃部門分離出來,，來專門做計(jì)劃,，告訴工人如何工作，這種方式只有在計(jì)劃者比工人更懂得如何工作的情況下才可行,。如果你有一個(gè)批聰明主動(dòng)的人工作,，就不要采用這種方法了。

管理以人為本的流程

這里的關(guān)鍵因素之一是,，接受流程而非強(qiáng)加一個(gè)流程,。通常軟件流程是被管理層強(qiáng)加上去的，于是開發(fā)人員會(huì)反抗,，特別是當(dāng)管理層人員已經(jīng)很長時(shí)間沒有參與開發(fā)活動(dòng)的情況下,，更是如此,。接受一個(gè)流程需要用心投入，需要整個(gè)團(tuán)隊(duì)的主動(dòng)參與,。

由此得出一個(gè)有意思的結(jié)論,，只有開發(fā)者自己可以選擇采用哪個(gè)自適應(yīng)流程。

另外一個(gè)結(jié)論是,，開發(fā)者必須能夠做技術(shù)決策,。

于是技術(shù)型的領(lǐng)導(dǎo)面臨一個(gè)很大的轉(zhuǎn)變，他需要分享他的責(zé)任給開發(fā)者,，并且在領(lǐng)導(dǎo)項(xiàng)目的時(shí)候與開發(fā)者處在一個(gè)相等的位置,，注意我說的是*相等*，管理人員仍然扮演著他應(yīng)有的角色,，但需要考慮到開發(fā)者的專業(yè)意見,。

現(xiàn)在科技行業(yè)發(fā)展很快，過不了幾年現(xiàn)有的技術(shù)就會(huì)過時(shí),，近50年的科技行業(yè)的發(fā)展是其他行業(yè)無法匹敵的,。甚至技術(shù)人員也開始意識(shí)到，進(jìn)入管理層就以為著自己的技術(shù)水平將會(huì)枯萎,；已經(jīng)進(jìn)入管理層的*前開發(fā)者*需要認(rèn)識(shí)到,，他們的技術(shù)水平將會(huì)快速消失，他們需要信任并依賴當(dāng)前的開發(fā)者,。

評估的困難

在Taylor的方法中,，做計(jì)劃設(shè)計(jì)的人和實(shí)際干活的人是不同的人,，于是領(lǐng)導(dǎo)們需要一種方法來評估干活的人的有效性,。《科學(xué)管理方法》一書中特別強(qiáng)調(diào)說,，要開發(fā)出一種客觀的評估勞動(dòng)成果的方法,。

但是，評估軟件是一件非常困難的事情,，即便我們竭盡全力,，也很難對軟件中哪怕很簡單的東西進(jìn)行評估，比如產(chǎn)量,。如果沒有辦法對這些東西很好的評估,，任何外部的控制都是徒勞的。

對于無法評估的東西使用評估性方法來管理會(huì)導(dǎo)致問題,。Robert Austin對此曾進(jìn)行過精彩的論述,。他指出，當(dāng)評估績效的時(shí)候,，你必須獲得所有需要評估的重要因素,，任何一個(gè)因素的缺失都將導(dǎo)致這樣一個(gè)結(jié)果：干活的人會(huì)改變他們的產(chǎn)出物以獲得最佳的評估結(jié)果,，即使他們的做法明顯損害了產(chǎn)出物的質(zhì)量，他們也會(huì)這么做,。這種管理失效的情況是基于評估的管理方法的阿克琉斯之踵,。

Austin的結(jié)論是，你必須在基于評估的管理方法和授權(quán)式管理方法（這種方法下,，干活的人自行決定如何干活）中做出選擇,。基于評估的管理最適應(yīng)于重復(fù)的簡單性工作,，對知識(shí)要求很低而且容易評估產(chǎn)出——這與軟件開發(fā)的特點(diǎn)剛好相反,。

總而言之，傳統(tǒng)的方法都基于這樣一個(gè)設(shè)想,，基于評估的管理方法是最高效的管理方法,。敏捷社區(qū)發(fā)現(xiàn)，軟件開發(fā)很特別,，如果對它采用基于評估的方法管理,，將會(huì)導(dǎo)致管理失效；在實(shí)踐中,，采用授權(quán)式管理更加高效,，而這正是敏捷人的核心方法之一。

業(yè)務(wù)領(lǐng)袖的角色

然而,，技術(shù)人員無法單獨(dú)搞定整個(gè)開發(fā)過程,，他們需要業(yè)務(wù)需求的指導(dǎo)。這就引出了敏捷方法另外一個(gè)重點(diǎn)：開發(fā)者需要與業(yè)務(wù)專家緊密配合,。

這種緊密程度超出了大多數(shù)類型的項(xiàng)目,。敏捷團(tuán)隊(duì)如果只是與業(yè)務(wù)專家進(jìn)行偶爾的交流，那它就不能稱之為敏捷團(tuán)隊(duì),，他們需要不間斷的交流,；并且這種交流的通道不能僅僅限于管理層，每個(gè)開發(fā)者也應(yīng)該能隨時(shí)獲取,。既然開發(fā)者能勝任自己的專業(yè)工作,，那么他們也需要能夠與其他領(lǐng)域的專業(yè)人士進(jìn)行協(xié)作。

當(dāng)然,，這很大程度上是因?yàn)?，敏捷開發(fā)方法的本質(zhì)。既然敏捷開發(fā)的大前提是事物在快速變化,，那么你就需要經(jīng)常聯(lián)系開發(fā)者,，告訴他們什么發(fā)生了變化。

對于開發(fā)者來說，沒什么能比,，眼睜睜的看著自己的工作白白的浪費(fèi)掉,，更痛苦的了。所以,，保證業(yè)務(wù)專家的專業(yè)水平,，讓開發(fā)人員信服，以及保證他與開發(fā)者之間溝通的暢通性,，就變得非常重要,。

方法本身的自適應(yīng)

至此，我們討論了軟件開發(fā)項(xiàng)目為了適應(yīng)客戶需求的變化必須不斷調(diào)整,。然而,，還有另外一個(gè)角度來看待自適應(yīng)性：那就是自適應(yīng)方法本身隨時(shí)間演變。一個(gè)項(xiàng)目,，在開始時(shí)采用的自適應(yīng)方法,，與一年后采用的自適應(yīng)方法，在具體準(zhǔn)則和細(xì)節(jié)上,，不會(huì)完全一樣,。隨著時(shí)間的推進(jìn)，團(tuán)隊(duì)將會(huì)發(fā)現(xiàn)怎么做會(huì)更好,，然后會(huì)改進(jìn)自適應(yīng)方法本身,。

要做到方法本身的自適應(yīng)性需要對方法進(jìn)行定期的回顧，通?？梢栽诿總€(gè)迭代中進(jìn)行,。在每個(gè)迭代結(jié)束時(shí)，開一個(gè)小會(huì),，團(tuán)隊(duì)捫心自問以下問題：

我們哪里做得不錯(cuò),？

我們學(xué)到了什么？

我們哪里可以做得更好,？

我們有何困惑,？