摘要：在敏捷開發(fā)中有很多好的想法和實(shí)踐,，但是還有一些別的并不是那么重要但被很多人接受的想法和實(shí)踐：就算你不遵守這些想法和實(shí)踐你的項(xiàng)目依然可以圓滿成功。

在敏捷開發(fā)中有很多好的想法和實(shí)踐,，這些想法和實(shí)踐都非常管用：把項(xiàng)目分成小版本發(fā)布來(lái)進(jìn)行風(fēng)險(xiǎn)管理和加速回饋;用時(shí)間盒(time-boxing)來(lái)限制WIP(Working In Process)并讓所有人團(tuán)結(jié)一致集中在項(xiàng)目中;僅依靠軟件來(lái)作為進(jìn)程度量;進(jìn)行簡(jiǎn)單的估算并使用速度來(lái)預(yù)測(cè)團(tuán)隊(duì)的表現(xiàn);和客戶保持頻繁而緊密的合作;持續(xù)集成持續(xù)發(fā)布以保證代碼始終穩(wěn)定可運(yùn)行,。

但是還有一些別的并不是那么重要但被很多人接受的想法和實(shí)踐：就算你不遵守這些想法和實(shí)踐你的項(xiàng)目依然可以圓滿成功，也不會(huì)有糟糕的事情發(fā)生,。但是有一些想法實(shí)踐你最好不要去遵守,。

測(cè)試驅(qū)動(dòng)開發(fā)

做快速開發(fā)的團(tuán)隊(duì)需要依賴于一個(gè)快速高效測(cè)試安全網(wǎng)。在一個(gè)測(cè)試先行的或者是測(cè)試驅(qū)動(dòng)(TDD)的敏捷開發(fā)中,，沒有任何借口可以不寫測(cè)試用例,。在你開始編碼前你必須先寫好測(cè)試用例，然后你就可以采用一些高效的自動(dòng)測(cè)試工具來(lái)保證有一個(gè)高水平的覆蓋測(cè)試和回歸測(cè)試,。

TDD不僅僅是一種供開發(fā)人員測(cè)試他們代碼的保證手段,，它更重要的一種開發(fā)技術(shù)，這種開發(fā)技術(shù)能夠得到更高質(zhì)量的代碼和一個(gè)簡(jiǎn)單整潔的設(shè)計(jì),。

微軟和IBM(通過測(cè)試驅(qū)動(dòng)開發(fā)實(shí)現(xiàn)質(zhì)量改進(jìn),，微軟研究院，2008)的研究團(tuán)隊(duì)發(fā)現(xiàn),，雖然TDD增加了15%-35%前期成本(TDD要求開發(fā)人員改變他們的想法和工作方式,，這減緩了他們的的開發(fā)速度，至少在一開始他們的開發(fā)速度慢了很多),，但是跟沒有采取單元測(cè)試的團(tuán)隊(duì)相比缺陷密度降低了40%(IBM)或多達(dá)60%-90%(微軟),。

但是在軟件制作第12章“測(cè)試驅(qū)動(dòng)開發(fā)的有效性有多好”中，由Burak Turhan主導(dǎo)的研究表明雖然TDD表面上提高了質(zhì)量(根據(jù)一個(gè)或多個(gè)通過的測(cè)試用例,，缺陷的數(shù)量,，缺陷密度，每次測(cè)試發(fā)現(xiàn)缺陷數(shù),，修復(fù)缺陷的工作量,，修復(fù)密度，預(yù)防性維護(hù)比例等本衡量)并且可以提高測(cè)試的質(zhì)量(可以使測(cè)試錯(cuò)誤降低,，使測(cè)試變得更加容易),，但TDD并不能一直提高設(shè)計(jì)質(zhì)量,。TDD似乎可以降低代碼的復(fù)雜度，提高代碼的重用率,，但是它也能給耦合內(nèi)聚帶來(lái)負(fù)面的影響,。雖然使用測(cè)試驅(qū)動(dòng)的開發(fā)可以使得方法級(jí)和類級(jí)的復(fù)雜度降低，但包級(jí)和項(xiàng)目級(jí)卻為之變得更加復(fù)雜,。

喜歡TDD的人為之瘋狂，如果你也熱衷于TDD,，那就盡管用它吧。就算你對(duì)TDD并不那么感冒,，測(cè)試先行非常自然的場(chǎng)景也是時(shí)不時(shí)出現(xiàn)——尤其是當(dāng)你不得不通過一種特殊的方式來(lái)解決一個(gè)特殊的問題,，或者你要修正一個(gè)bug而測(cè)試用例已經(jīng)為你寫好的時(shí)候。但是更重要的是,，你要寫一組很好的測(cè)試用例不斷更新并且時(shí)不時(shí)運(yùn)行它們,，這跟你在寫代碼前還寫寫好代碼后沒有關(guān)系。

結(jié)對(duì)編程

根據(jù)VersionOne State of Agile Development Survey 2012(敏捷開發(fā)調(diào)查狀況2012),，幾乎有1/3的團(tuán)隊(duì)采用了結(jié)對(duì)編程的開發(fā)方式——這是一個(gè)出乎意料的高數(shù)字,，這顯示出結(jié)對(duì)編程的良好的組織紀(jì)律性，同時(shí)表明有很多的團(tuán)隊(duì)使用了可以進(jìn)行結(jié)對(duì)編程的XP(2%)和Scrum/XP(11%)方法,。

有采用結(jié)對(duì)編程的非常好的理由：開發(fā)人員一起工作可以通過持續(xù)的非正式的審查來(lái)提高代碼質(zhì)量和進(jìn)行信息共享,。讓開發(fā)人員結(jié)對(duì)或者讓開發(fā)人員和測(cè)試人員結(jié)對(duì)來(lái)一起工作的情況非常常見，尤其是當(dāng)你在解決一個(gè)非常困難的設(shè)計(jì)問題,，或者你碰到一段以前從來(lái)都沒有接觸過的代碼而以前開發(fā)過類似代碼的人就在旁邊可以請(qǐng)教,，或者你碰到了一個(gè)高壓力的問題需要解決為此你豪無(wú)頭緒，或者你在測(cè)試系統(tǒng)的一個(gè)非常難的部分,，或者你的團(tuán)隊(duì)又加入了新的成員而這些成員需要基礎(chǔ)學(xué)習(xí)的時(shí)候,。

一些(尤其是性格外向的)人非常喜歡結(jié)對(duì)編程，喜歡它提供的非常強(qiáng)大的能量和非常難得的認(rèn)識(shí)團(tuán)隊(duì)其他成員的機(jī)會(huì),。但是去強(qiáng)迫那些更喜歡自己?jiǎn)为?dú)工作的人去和自己不喜歡的人進(jìn)行緊密的合作,，這顯然不是什么明智的作法。結(jié)對(duì)編程要花費(fèi)社交成本：和一些有能力的,，技術(shù)強(qiáng)的，有工作經(jīng)驗(yàn)的,，有自己獨(dú)特方式的,，有自己鮮明個(gè)性的或者是有自己職業(yè)道德的人一起結(jié)對(duì)編程你需要非常小心。而且長(zhǎng)時(shí)間的結(jié)對(duì)編程讓人精疲力竭——一項(xiàng)研究(Vanhanen and Lassenius 2007)發(fā)現(xiàn)人們通常一天只結(jié)對(duì)編程1.5至4個(gè)小時(shí),，因?yàn)槌商斓慕Y(jié)對(duì)編程工作強(qiáng)度太大以致于無(wú)法接受。

在結(jié)對(duì)《編程或許是有害的》一文中,，Jon Evans說結(jié)對(duì)編程對(duì)創(chuàng)造力有負(fù)面影響：

研究強(qiáng)烈支持這個(gè)觀點(diǎn)：當(dāng)在享受更多的不被打擾的自由和隱私空間時(shí)，人們才有最好的創(chuàng)意......區(qū)別表現(xiàn)突出的大公司的開發(fā)人員的并不是更豐厚的工作經(jīng)驗(yàn)和更高的薪酬,，而是他們可以享受的不被打擾的自由的私人空間,。”一篇紐約時(shí)報(bào)的文章大罵結(jié)對(duì)編程這種所謂“新的集體思維”時(shí)這樣說,。

另外在Pete McBreen的“依然質(zhì)疑極限編程”中指出了一些結(jié)對(duì)編程的其他缺點(diǎn)和弱點(diǎn)：

不鼓勵(lì)鉆研思路,，結(jié)對(duì)編程時(shí)開發(fā)專注編寫代碼，所以除非有一天的時(shí)間來(lái)鉆研團(tuán)隊(duì)代碼才能對(duì)代碼有一點(diǎn)膚淺的理解,。

開發(fā)變得過度依賴單元測(cè)試,，假如測(cè)試通過了，那么代碼就OK了,。(這就缺乏鉆研了)

沒有進(jìn)行詳細(xì)的極端測(cè)試和邊緣測(cè)試研究,，特別是如果他們很難寫出測(cè)試。

當(dāng)結(jié)對(duì)編程時(shí)很難做到經(jīng)過詳細(xì)思考設(shè)計(jì)的編碼,，除非另外一個(gè)搭檔完全控制這個(gè)編碼過程。通過平時(shí)搭檔間的權(quán)衡,，很難建立技術(shù)復(fù)雜的設(shè)計(jì),，除非他們已經(jīng)確定了一個(gè)獨(dú)自會(huì)話,。

結(jié)對(duì)編程時(shí)的個(gè)人風(fēng)格問題,，并不是所有的結(jié)對(duì)者都能像其他人一樣,。

和打字技能、熟練程度不同的人結(jié)對(duì)編程,，往往會(huì)導(dǎo)致打字技能好的人完成全部的編碼而其他人變得完全被動(dòng),。

在分布式團(tuán)隊(duì)中結(jié)對(duì)編程顯然也不會(huì)有效(取決于距離，不同的時(shí)區(qū),，工作方式,，語(yǔ)言)，即使這樣,，一些人仍然在嘗試,。

雖然結(jié)對(duì)編程相比獨(dú)自編程提高了代碼質(zhì)量，你也可以通過較低代價(jià)的代碼復(fù)審來(lái)獲得同樣的代碼質(zhì)量提高,，并且還有一些信息共享的優(yōu)勢(shì),。代碼復(fù)審——特別輕便,，離線復(fù)審——比結(jié)對(duì)編程更容易安排，代價(jià)更低點(diǎn)并且沒有打擾,。就像詹森科恩指出的那樣 即使開發(fā)們結(jié)對(duì)編程,，你或許仍然需要代碼復(fù)審, 因?yàn)榻Y(jié)對(duì)編程確實(shí)是共同解決問題，但是它并沒有包含所有代碼復(fù)審所涉及的全部問題,。

還是喬恩埃文斯關(guān)于結(jié)對(duì)編程的老話：

真正的答案是有沒有答案：獨(dú)自編程,，結(jié)對(duì)編程還是小組合作要根據(jù)環(huán)境用你最好的判斷來(lái)動(dòng)態(tài)結(jié)合才是最有效的。 結(jié)對(duì)編程的確有它存在的意義,。(定律又沒用了!)在某些情況下,，甚至是“絕對(duì)對(duì)的”。但是堅(jiān)持100%結(jié)對(duì)編程是盲目的教條主義,，和所有的盲目教條主義一樣,，最終只會(huì)適得其反。

緊急設(shè)計(jì)和隱喻

增量開發(fā)管用,，而且嘗試保持設(shè)計(jì)簡(jiǎn)單感覺起來(lái)不錯(cuò),，但試圖飛速定義一個(gè)架構(gòu)是愚蠢且不切實(shí)際的。幾乎沒有人遵循緊急設(shè)計(jì)有一個(gè)原因：它不管用,。

依賴于高水平的隱喻 (系統(tǒng)是一條 "流水線"或 一個(gè)"物料清單"或 一箱"蜂箱的蜜蜂") ,，這些隱喻被團(tuán)隊(duì)共享為某種 代替建筑 是更加荒謬的。 卡內(nèi)基梅隆大學(xué)基金會(huì) 的研究顯示,，自然語(yǔ)言的隱喻,，無(wú)論對(duì)技術(shù)和非技術(shù)項(xiàng)目成員之間增進(jìn)溝通，還是在開發(fā)架構(gòu)方面,，相對(duì)來(lái)說都不是很有用,。

總之幾乎無(wú)人理解系統(tǒng)隱喻是什么 ，或者它怎樣使用,，或者怎樣選擇一個(gè)有意義的隱喻,，或者如果你搞錯(cuò)了又怎樣改變它(還有你怎么會(huì)知道你選錯(cuò)了)，其中有人提出了這樣的想法：

好吧我還是不妨公開說出來(lái) —— 我仍然不能找到這種隱喻事情的竅門,。我發(fā)現(xiàn)它管用,，而且在C3項(xiàng)目中工作的很好，但這并不意味著我知道怎么做,，更不要說如何解釋怎樣做到了,。

Martin Fowler, 設(shè)計(jì)滅亡了嗎?

敏捷開發(fā)方法促進(jìn)了開發(fā)的成功率，并且展現(xiàn)出處理許多不同軟件開發(fā)問題的更好方法——但不是架構(gòu)和設(shè)計(jì),。


每日站立會(huì)議

當(dāng)你有了一支新的團(tuán)隊(duì),，而每個(gè)人都需要相互了解，并且需要更多的時(shí)間理解項(xiàng)目是關(guān)于什么的;或者當(dāng)這個(gè)團(tuán)隊(duì)迫于超級(jí)壓力,，正在試圖修復(fù)些什么或者結(jié)束些什么的緊急的狀況,，那么將大家聚集起來(lái)開工作例會(huì)，甚至也許一天超過一次,，這是必要的且有價(jià)值的,。但是每個(gè)人是站還是坐，最終他們?cè)跁?huì)議上討論些什么,，將由你決定,。

如果你的團(tuán)隊(duì)已經(jīng)合作一段時(shí)間也合作的很好，而他們每個(gè)人都互相了解并且知道他們?cè)谧龅氖鞘裁?，如果開發(fā)人員做完事情的時(shí)候,，在任務(wù)板或看板上更新卡片，或者在一個(gè)電子系統(tǒng)里更新狀態(tài),，如果他們足夠成熟可以在需要的時(shí)候請(qǐng)求幫助,，那么你不需要每個(gè)早上在房間里 讓他們都站著。

集中式代碼所有權(quán)

讓每個(gè)人的工作都涉及到所有代碼并不總是有效(因?yàn)椴皇菆F(tuán)隊(duì)中的每個(gè)人對(duì)每個(gè)問題都有必備的知識(shí)或者經(jīng)驗(yàn)),，并且集中式代碼所有權(quán)對(duì)代碼質(zhì)量有負(fù)面影響,。

共享代碼看起來(lái)似乎更有意義，但事實(shí)上卻是不是每個(gè)人或者是應(yīng)該為系統(tǒng)的每一部分工作,。

像寫故事一樣編寫需求

每一個(gè)需求規(guī)格說明都能以用戶故事的方式,，以1到2行寫到卡片上的想法，需求應(yīng)該簡(jiǎn)明扼要(以致開發(fā)者必須向某人解釋真正的需求是什么),，堅(jiān)持他們應(yīng)該應(yīng)該以相同形式的模板,。

“作為某一類用戶，我有目標(biāo)期望因此某些問題…”

是非常愚蠢和沒有必要的,。在15年前,，這同樣是一類簡(jiǎn)單而又傳統(tǒng)的想法,，讓每個(gè)人都用UML的用例的形式試圖去捕捉所有需求。

有更多不同的方式來(lái)有效的表達(dá)需求。有時(shí)候需求需要被規(guī)定到細(xì)節(jié)級(jí)別(當(dāng)你必須滿足合規(guī)性或者符合一種標(biāo)準(zhǔn),，或是與現(xiàn)有系統(tǒng)集成，或是實(shí)現(xiàn)特定的算法,。,。。),。有時(shí)候從一個(gè)測(cè)試用例或者一個(gè)具體的用例場(chǎng)景或一個(gè)框架或一切別的類型的模型開始會(huì)更有效,，因?yàn)檫@樣會(huì)讓人知道如何推進(jìn)，并且有些細(xì)節(jié)已經(jīng)就緒,。因此,，運(yùn)用格式化和細(xì)節(jié)層級(jí)能更有效也更容易開展工作。

對(duì)產(chǎn)品所有者的依賴

依賴作為產(chǎn)品擁有者的人，當(dāng)項(xiàng)目失敗的時(shí)候,，就如客戶唯一的聲音和“一個(gè)發(fā)不出聲音的喉嚨”,，無(wú)法擴(kuò)展，無(wú)法持續(xù),，將團(tuán)隊(duì)和項(xiàng)目以及事實(shí)上的業(yè)務(wù)推向風(fēng)險(xiǎn)的邊緣,。很自然的，危險(xiǎn)逐漸靠近正在設(shè)計(jì)的產(chǎn)品和管理中的開發(fā)項(xiàng)目,，將比解決危險(xiǎn)帶來(lái)更多的問題,。

一些團(tuán)隊(duì)意識(shí)到這一點(diǎn)，并試圖與產(chǎn)品所有者的想法保持一致,，因?yàn)樗麄儽仨氝@樣做,。為了成功，一個(gè)團(tuán)隊(duì)需要在各個(gè)層次的真實(shí)而持續(xù)的客戶合同,，他們需要對(duì)自己負(fù)責(zé),，為確保他們得到他們所需要的，而不是依賴某一個(gè)人去完成所有的一切,。