摘要：在敏捷開發(fā)中有很多好的想法和實踐，但是還有一些別的并不是那么重要但被很多人接受的想法和實踐：就算你不遵守這些想法和實踐你的項目依然可以圓滿成功。
在敏捷開發(fā)中有很多好的想法和實踐，這些想法和實踐都非常管用：把項目分成小版本發(fā)布來進行風(fēng)險管理和加速回饋;用時間盒(time-boxing)來限制WIP(WorkingIn Process)并讓所有人團結(jié)一致集中在項目中;僅依靠軟件來作為進程度量;進行簡單的估算并使用速度來預(yù)測團隊的表現(xiàn);和客戶保持頻繁而緊密的合作;持續(xù)集成持續(xù)發(fā)布以保證代碼始終穩(wěn)定可運行。
但是還有一些別的并不是那么重要但被很多人接受的想法和實踐：就算你不遵守這些想法和實踐你的項目依然可以圓滿成功，也不會有糟糕的事情發(fā)生。但是有一些想法實踐你最好不要去遵守。
測試驅(qū)動開發(fā)
做快速開發(fā)的團隊需要依賴于一個快速高效測試安全網(wǎng)。在一個測試先行的或者是測試驅(qū)動(TDD)的敏捷開發(fā)中，沒有任何借口可以不寫測試用例。在你開始編碼前你必須先寫好測試用例，然后你就可以采用一些高效的自動測試工具來保證有一個高水平的覆蓋測試和回歸測試。
TDD不僅僅是一種供開發(fā)人員測試他們代碼的保證手段，它更重要的一種開發(fā)技術(shù)，這種開發(fā)技術(shù)能夠得到更高質(zhì)量的代碼和一個簡單整潔的設(shè)計。
微軟和IBM(通過測試驅(qū)動開發(fā)實現(xiàn)質(zhì)量改進，微軟研究院，2008)的研究團隊發(fā)現(xiàn)，雖然TDD增加了15%-35%前期成本(TDD要求開發(fā)人員改變他們的想法和工作方式，這減緩了他們的的開發(fā)速度，至少在一開始他們的開發(fā)速度慢了很多)，但是跟沒有采取單元測試的團隊相比缺陷密度降低了40%(IBM)或多達60%-90%(微軟)。
但是在軟件制作第12章“測試驅(qū)動開發(fā)的有效性有多好”中，由BurakTurhan主導(dǎo)的研究表明雖然TDD表面上提高了質(zhì)量(根據(jù)一個或多個通過的測試用例，缺陷的數(shù)量，缺陷密度，每次測試發(fā)現(xiàn)缺陷數(shù)，修復(fù)缺陷的工作量，修復(fù)密度，預(yù)防性維護比例等本衡量)并且可以提高測試的質(zhì)量(可以使測試錯誤降低，使測試變得更加容易)，但TDD并不能一直提高設(shè)計質(zhì)量。TDD似乎可以降低代碼的復(fù)雜度，提高代碼的重用率，但是它也能給耦合內(nèi)聚帶來負面的影響。雖然使用測試驅(qū)動的開發(fā)可以使得方法級和類級的復(fù)雜度降低，但包級和項目級卻為之變得更加復(fù)雜。
喜歡TDD的人為之瘋狂，如果你也熱衷于TDD，那就盡管用它吧。就算你對TDD并不那么感冒，測試先行非常自然的場景也是時不時出現(xiàn)——尤其是當(dāng)你不得不通過一種特殊的方式來解決一個特殊的問題，或者你要修正一個bug而測試用例已經(jīng)為你寫好的時候。但是更重要的是，你要寫一組很好的測試用例不斷更新并且時不時運行它們，這跟你在寫代碼前還寫寫好代碼后沒有關(guān)系。
結(jié)對編程
根據(jù)VersionOneState of Agile Development Survey 2012(敏捷開發(fā)調(diào)查狀況2012)，幾乎有1/3的團隊采用了結(jié)對編程的開發(fā)方式——這是一個出乎意料的高數(shù)字，這顯示出結(jié)對編程的良好的組織紀律性，同時表明有很多的團隊使用了可以進行結(jié)對編程的XP(2%)和Scrum/XP(11%)方法。
有采用結(jié)對編程的非常好的理由：開發(fā)人員一起工作可以通過持續(xù)的非正式的審查來提高代碼質(zhì)量和進行信息共享。讓開發(fā)人員結(jié)對或者讓開發(fā)人員和測試人員結(jié)對來一起工作的情況非常常見，尤其是當(dāng)你在解決一個非常困難的設(shè)計問題，或者你碰到一段以前從來都沒有接觸過的代碼而以前開發(fā)過類似代碼的人就在旁邊可以請教，或者你碰到了一個高壓力的問題需要解決為此你豪無頭緒，或者你在測試系統(tǒng)的一個非常難的部分，或者你的團隊又加入了新的成員而這些成員需要基礎(chǔ)學(xué)習(xí)的時候。
一些(尤其是性格外向的)人非常喜歡結(jié)對編程，喜歡它提供的非常強大的能量和非常難得的認識團隊其他成員的機會。但是去強迫那些更喜歡自己單獨工作的人去和自己不喜歡的人進行緊密的合作，這顯然不是什么明智的作法。結(jié)對編程要花費社交成本：和一些有能力的，技術(shù)強的，有工作經(jīng)驗的，有自己獨特方式的，有自己鮮明個性的或者是有自己職業(yè)道德的人一起結(jié)對編程你需要非常小心。而且長時間的結(jié)對編程讓人精疲力竭——一項研究(Vanhanenand Lassenius 2007)發(fā)現(xiàn)人們通常一天只結(jié)對編程1.5至4個小時，因為成天的結(jié)對編程工作強度太大以致于無法接受。
在結(jié)對《編程或許是有害的》一文中，JonEvans說結(jié)對編程對創(chuàng)造力有負面影響：
研究強烈支持這個觀點：當(dāng)在享受更多的不被打擾的自由和隱私空間時，人們才有最好的創(chuàng)意......區(qū)別表現(xiàn)突出的大公司的開發(fā)人員的并不是更豐厚的工作經(jīng)驗和更高的薪酬，而是他們可以享受的不被打擾的自由的私人空間?！币黄~約時報的文章大罵結(jié)對編程這種所謂“新的集體思維”時這樣說。
另外在PeteMcBreen的“依然質(zhì)疑極限編程”中指出了一些結(jié)對編程的其他缺點和弱點：
不鼓勵鉆研思路，結(jié)對編程時開發(fā)專注編寫代碼，所以除非有一天的時間來鉆研團隊代碼才能對代碼有一點膚淺的理解。
開發(fā)變得過度依賴單元測試，假如測試通過了，那么代碼就OK了。(這就缺乏鉆研了)
沒有進行詳細的極端測試和邊緣測試研究，特別是如果他們很難寫出測試。
當(dāng)結(jié)對編程時很難做到經(jīng)過詳細思考設(shè)計的編碼，除非另外一個搭檔完全控制這個編碼過程。通過平時搭檔間的權(quán)衡，很難建立技術(shù)復(fù)雜的設(shè)計，除非他們已經(jīng)確定了一個獨自會話。
結(jié)對編程時的個人風(fēng)格問題，并不是所有的結(jié)對者都能像其他人一樣。
和打字技能、熟練程度不同的人結(jié)對編程，往往會導(dǎo)致打字技能好的人完成全部的編碼而其他人變得完全被動。
在分布式團隊中結(jié)對編程顯然也不會有效(取決于距離，不同的時區(qū)，工作方式，語言)，即使這樣，一些人仍然在嘗試。
雖然結(jié)對編程相比獨自編程提高了代碼質(zhì)量，你也可以通過較低代價的代碼復(fù)審來獲得同樣的代碼質(zhì)量提高，并且還有一些信息共享的優(yōu)勢。代碼復(fù)審——特別輕便，離線復(fù)審——比結(jié)對編程更容易安排，代價更低點并且沒有打擾。就像詹森科恩指出的那樣即使開發(fā)們結(jié)對編程，你或許仍然需要代碼復(fù)審,因為結(jié)對編程確實是共同解決問題，但是它并沒有包含所有代碼復(fù)審所涉及的全部問題。
還是喬恩埃文斯關(guān)于結(jié)對編程的老話：
真正的答案是有沒有答案：獨自編程，結(jié)對編程還是小組合作要根據(jù)環(huán)境用你最好的判斷來動態(tài)結(jié)合才是最有效的。結(jié)對編程的確有它存在的意義。(定律又沒用了!)在某些情況下，甚至是“絕對對的”。但是堅持100%結(jié)對編程是盲目的教條主義，和所有的盲目教條主義一樣，最終只會適得其反。
緊急設(shè)計和隱喻
增量開發(fā)管用，而且嘗試保持設(shè)計簡單感覺起來不錯，但試圖飛速定義一個架構(gòu)是愚蠢且不切實際的。幾乎沒有人遵循緊急設(shè)計有一個原因：它不管用。
依賴于高水平的隱喻(系統(tǒng)是一條"流水線"或一個"物料清單"或一箱"蜂箱的蜜蜂")，這些隱喻被團隊共享為某種 代替建筑 是更加荒謬的。 卡內(nèi)基梅隆大學(xué)基金會 的研究顯示，自然語言的隱喻，無論對技術(shù)和非技術(shù)項目成員之間增進溝通，還是在開發(fā)架構(gòu)方面，相對來說都不是很有用。
總之幾乎無人理解系統(tǒng)隱喻是什么，或者它怎樣使用，或者怎樣選擇一個有意義的隱喻，或者如果你搞錯了又怎樣改變它(還有你怎么會知道你選錯了)，其中有人提出了這樣的想法：
好吧我還是不妨公開說出來—— 我仍然不能找到這種隱喻事情的竅門。我發(fā)現(xiàn)它管用，而且在C3項目中工作的很好，但這并不意味著我知道怎么做，更不要說如何解釋怎樣做到了。
Martin Fowler, 設(shè)計滅亡了嗎?
敏捷開發(fā)方法促進了開發(fā)的成功率，并且展現(xiàn)出處理許多不同軟件開發(fā)問題的更好方法——但不是架構(gòu)和設(shè)計。
每日站立會議
當(dāng)你有了一支新的團隊，而每個人都需要相互了解，并且需要更多的時間理解項目是關(guān)于什么的;或者當(dāng)這個團隊迫于超級壓力，正在試圖修復(fù)些什么或者結(jié)束些什么的緊急的狀況，那么將大家聚集起來開工作例會，甚至也許一天超過一次，這是必要的且有價值的。但是每個人是站還是坐，最終他們在會議上討論些什么，將由你決定。
如果你的團隊已經(jīng)合作一段時間也合作的很好，而他們每個人都互相了解并且知道他們在做的是什么，如果開發(fā)人員做完事情的時候，在任務(wù)板或看板上更新卡片，或者在一個電子系統(tǒng)里更新狀態(tài)，如果他們足夠成熟可以在需要的時候請求幫助，那么你不需要每個早上在房間里讓他們都站著。
集中式代碼所有權(quán)
讓每個人的工作都涉及到所有代碼并不總是有效(因為不是團隊中的每個人對每個問題都有必備的知識或者經(jīng)驗)，并且集中式代碼所有權(quán)對代碼質(zhì)量有負面影響。
共享代碼看起來似乎更有意義，但事實上卻是不是每個人或者是應(yīng)該為系統(tǒng)的每一部分工作。
像寫故事一樣編寫需求
每一個需求規(guī)格說明都能以用戶故事的方式，以1到2行寫到卡片上的想法，需求應(yīng)該簡明扼要(以致開發(fā)者必須向某人解釋真正的需求是什么)，堅持他們應(yīng)該應(yīng)該以相同形式的模板。
“作為某一類用戶，我有目標期望因此某些問題…”
是非常愚蠢和沒有必要的。在15年前，這同樣是一類簡單而又傳統(tǒng)的想法，讓每個人都用UML的用例的形式試圖去捕捉所有需求。
有更多不同的方式來有效的表達需求。有時候需求需要被規(guī)定到細節(jié)級別(當(dāng)你必須滿足合規(guī)性或者符合一種標準，或是與現(xiàn)有系統(tǒng)集成，或是實現(xiàn)特定的算法。。。)。有時候從一個測試用例或者一個具體的用例場景或一個框架或一切別的類型的模型開始會更有效，因為這樣會讓人知道如何推進，并且有些細節(jié)已經(jīng)就緒。因此，運用格式化和細節(jié)層級能更有效也更容易開展工作。
對產(chǎn)品所有者的依賴
依賴作為產(chǎn)品擁有者的人，當(dāng)項目失敗的時候，就如客戶唯一的聲音和“一個發(fā)不出聲音的喉嚨”，無法擴展，無法持續(xù)，將團隊和項目以及事實上的業(yè)務(wù)推向風(fēng)險的邊緣。很自然的，危險逐漸靠近正在設(shè)計的產(chǎn)品和管理中的開發(fā)項目，將比解決危險帶來更多的問題。
一些團隊意識到這一點，并試圖與產(chǎn)品所有者的想法保持一致，因為他們必須這樣做。為了成功，一個團隊需要在各個層次的真實而持續(xù)的客戶合同，他們需要對自己負責(zé)，為確保他們得到他們所需要的，而不是依賴某一個人去完成所有的一切。
聯(lián)系客服
