Sealyu

在職業(yè)生涯的大部分時(shí)間里，我都是按照瀑布模型的方式進(jìn)行工作。不久之后，我加入了Xebia，開始以敏捷的方式做活。特別是，我們一直把遵循 Scrum和XP方法論與TDD相結(jié)合作為重點(diǎn)強(qiáng)調(diào)的實(shí)踐。從瀑布模型到敏捷的轉(zhuǎn)變，就像從宇宙中的一顆行星突然跨到另一顆一樣巨大。一旦完成這種轉(zhuǎn)變， 你的世界將發(fā)生翻天覆地的變化，你的思維、工作或協(xié)作方式等等，所有一切都會(huì)改變。

我參加的隊(duì)伍由8名專業(yè)人士組成，出乎我意料的是我們中有6個(gè)之前根本沒有任何采用敏捷完成工作的經(jīng)驗(yàn)。這樣，我們在其中2名有經(jīng)驗(yàn)的同伴指導(dǎo)下開 始工作了。一開始，讓人高興的事情并不多，大部分的事情都讓人感到沮喪。我們認(rèn)識(shí)到，敏捷并不只是沖刺（Sprint）和沒有文檔 - 有不少細(xì)微之處你得花功夫?qū)W才行。

這里說明一下曾經(jīng)發(fā)生過的事情：

開始的麻煩

1. 思維轉(zhuǎn)變

敏捷講的全是當(dāng)下的考量、當(dāng)前的沖刺、當(dāng)前的用戶故事等。當(dāng)一路走來突然有其他某個(gè)故事出現(xiàn)在面前的時(shí)候，我們并不會(huì)事先考慮事情將如何發(fā)展。過去 在瀑布模型里，我們常常是首先考慮整個(gè)系統(tǒng)，HLD（高層設(shè)計(jì)）和LLD（低層設(shè)計(jì)）是第一步，在繼續(xù)前進(jìn)之前，它們必須凍結(jié)。

相反，敏捷的內(nèi)容完全是當(dāng)前狀態(tài)和不斷改變，要是我們的需求未來會(huì)變化，我們的設(shè)計(jì)也將隨之演變；但是我們對于超越當(dāng)前沖刺的事情并不是特別關(guān)注。要接受這一事實(shí)得花點(diǎn)時(shí)間。

2. 持續(xù)換檔

敏捷是一個(gè)不斷變化的環(huán)境。“響應(yīng)變化”是其主導(dǎo)原則之一。為了響應(yīng)，開發(fā)者必須跟市面上的技術(shù)保持同步，否則它將讓你異常痛苦。

我們曾在項(xiàng)目中使用了一種搜索引擎庫，但我們中只有一人對其有了解。由于這個(gè)缺陷，我們在估時(shí)、結(jié)對、站立式會(huì)議，以及其他日常實(shí)踐里都遇到了問題。

我們面對的另一個(gè)問題是恰當(dāng)?shù)剡M(jìn)行TDD。從技術(shù)觀點(diǎn)看，TDD已經(jīng)有了不少選擇。你可以依賴不同的模擬和測試框架，這些往往都是你在瀑布模型里不使用的東西。要是你想采用TDD，那么就必須具備對它們的豐富知識(shí)，否則整個(gè)過程就不會(huì)太順利。

緩慢地沖刺

1. 測試驅(qū)動(dòng)開發(fā)說的是先寫測試，然后由測試導(dǎo)出業(yè)務(wù)邏輯。這是最難適應(yīng)的事情之一，因?yàn)樗耆嵏擦四愕挠^念。

   在瀑布模型里，總是代碼先完成，然后再進(jìn)行些測試（通常都有，但并非總是有）；但TDD則完全是紅、綠和重構(gòu)。這種方法要求我們用抽象術(shù)語 進(jìn)行思考，然后由它們演變出具體的事物。由于一開始難以適應(yīng)，我們往往求助于先寫出邏輯，然后確保存在覆蓋它們的測試。我把這稱為開發(fā)驅(qū)動(dòng)測試（DDT） 方法。

   DDT并沒有增加太多的意義。假如你知道你的代碼將會(huì)很好地工作，那為何還要寫個(gè)測試呢？只是要證明這段代碼確實(shí)有效？應(yīng)該不止這一點(diǎn)。的確是這樣。例如，寫測試可以讓你的代碼在耦合性方面表現(xiàn)更好，而且還能夠?yàn)閷淼拇a變更提供一個(gè)巨大的安全網(wǎng)。

2. 在敏捷里，以抽象術(shù)語進(jìn)行思考是開發(fā)人員必須具備的技能。在敏捷中我們并不像瀑布模型那樣進(jìn)行預(yù)先設(shè)計(jì)，通過創(chuàng)建抽象和開發(fā)工作流，設(shè)計(jì)到了一定的時(shí)候自然就會(huì)現(xiàn)身。敏捷中的開發(fā)人員必須至少精通基本的設(shè)計(jì)模式，否則他們將產(chǎn)生一大堆垃圾代碼，從中只能得出拙劣的設(shè)計(jì)。

   TDD在這里對我們大有幫助。它要求我們按抽象術(shù)語進(jìn)行思考。此外，只要我們開始修改測試，我們就必須考慮進(jìn)行重構(gòu)，讓我們的代碼變得更 好。DDT也能幫助我們立即識(shí)別任何質(zhì)量問題，這樣它們就能及時(shí)地得到修復(fù)。這樣，我們最終認(rèn)識(shí)到必須拋棄“首先編代碼，然后寫測試”的套路，后來我們重 新開始采用了TDD方法。

3. 代碼質(zhì)量是團(tuán)隊(duì)的職責(zé)，團(tuán)隊(duì)成員將時(shí)不時(shí)的重構(gòu)代碼或者可能會(huì)重新編寫，直到它符合預(yù)先制訂的標(biāo)準(zhǔn)。我們不要把任何情緒跟我們的代碼關(guān)聯(lián) 起來，應(yīng)該準(zhǔn)備不斷地拋棄或重寫它。遵循Venkat Subramaniam在集體所有制實(shí)踐方面的建議：“每次執(zhí)行檢入代碼操作時(shí)，我們都應(yīng)該致力于改善代碼的質(zhì)量。”

4. 在瀑布模型里，需求是要簽字的，有點(diǎn)像血誓，然后你再繼續(xù)向前移動(dòng)。但在敏捷里，需求與解決方案同步演變。這幫助我們在前進(jìn)的過程中讓事 情變得越來越清晰，但這也導(dǎo)致系統(tǒng)需要不時(shí)的重新設(shè)計(jì)，在最初的沖刺（1-4）里，這種情況經(jīng)常會(huì)發(fā)生。此外，Backlog也能在沖刺的中間改變，因 此，團(tuán)隊(duì)?wèi)?yīng)該根據(jù)這些變化進(jìn)行調(diào)整，因?yàn)樵诿總€(gè)沖刺結(jié)束時(shí)交付可工作的軟件是敏捷的座右銘。

5. 結(jié)對一開始讓人覺得是浪費(fèi)時(shí)間和精力。兩人一起在同一故事上進(jìn)行工作就像是各浪費(fèi)了一半的時(shí)間和精力。而且，多人完成同一故事的不同任務(wù)似乎是導(dǎo)致速度下降的原因。

   但是，敏捷中的團(tuán)隊(duì)鐘情于這種合作做事的方式，不喜歡相同項(xiàng)目組或房間里的人單槍匹馬地干活。當(dāng)團(tuán)隊(duì)一起工作時(shí)，他們會(huì)竭盡所能地把事情向前推進(jìn)，結(jié)果你有極大的可能性是以一致的方式完成事情，而不是最終在多個(gè)戰(zhàn)線失利。

6. 在采用TDD時(shí)，結(jié)對的效果最好。Driver和Navigator一起努力開發(fā)更好的系統(tǒng)。但如果你是按照DDT的方式進(jìn)行結(jié)對編程， 那它就不是最佳的前進(jìn)之路。在這種情況下，兩個(gè)合作者都不會(huì)知道該如何前進(jìn)，例如系統(tǒng)設(shè)計(jì)應(yīng)該像什么樣子，這樣你將得到很多噪音，產(chǎn)生最終必須重寫的一堆 源代碼文件。

   遵循TDD是最佳的方式，但要是你還沒有適應(yīng)它，你仍然可以結(jié)對：利用一塊玻璃（白）板，首先畫出某個(gè)設(shè)計(jì)流程圖，然后其中一個(gè)合作者可以編寫代碼，而另一個(gè)則可以編寫測試用例。

7. 在演示時(shí)交付可工作的軟件就像是沖刺的“石蕊測試”。但是，要是軟件不是可發(fā)布的，你會(huì)不會(huì)僅僅因?yàn)檐浖梢詷?gòu)建、可工作，而認(rèn)為一個(gè)沖刺就成功了呢？

   當(dāng)個(gè)別故事全部完工而某些沒有，這樣的沖刺算不算成功呢？那假如沖刺的全部故事基本完成但還有些煩人的小問題呢？

   團(tuán)隊(duì)?wèi)?yīng)該關(guān)注讓整個(gè)故事完工，所有問題得到解決，并且滿足完工標(biāo)準(zhǔn)；而不是慌慌張張地盯著Backlog馬虎了事。一次實(shí)施蹩腳的沖刺沒有 任何意義，除了在繼續(xù)前進(jìn)之前必須將已完成的事情返工。時(shí)間常常是一個(gè)約束條件，因此根據(jù)故事的相對重要程度，團(tuán)隊(duì)?wèi)?yīng)該找出一種對他們提議的解決方案更具 質(zhì)量意義的實(shí)施方法。位于Backlog頂端的故事必須盡量以最好的方式開發(fā)解決，隨著我們逐漸移動(dòng)到Backlog的底部，對解決方案的質(zhì)量可能會(huì)有些 妥協(xié)，但并不是對完工標(biāo)準(zhǔn)而言。對于故事的實(shí)現(xiàn)，更好的方式是寧缺勿濫。

8. 站立式會(huì)議是鐵律。它們意味著成為一個(gè)共享平臺(tái)，不只是你個(gè)人的有機(jī)會(huì)告訴其他人你做過什么和接下來要做什么。人們應(yīng)該試圖去傾聽周遭發(fā)生的事情，而不只是檢查自己的檢查表看完成了哪些活動(dòng)。

   莊嚴(yán)的站立式會(huì)議也必須控制在一定時(shí)間之內(nèi)。我們常常會(huì)抑制不住開始就某個(gè)問題進(jìn)行討論的誘惑，但那是必須要避免的。

9. 敏捷團(tuán)隊(duì)相當(dāng)小，在這樣一個(gè)環(huán)境里，人們經(jīng)常會(huì)因?yàn)樗麄冊谡玖⑹綍?huì)議上的言論而被他人評判。那么，你就應(yīng)該說我們在彼此進(jìn)行腦力激蕩或者我昨天什么也沒做，再或者是我們重構(gòu)了代碼，而現(xiàn)在我搞不清楚怎么回事了之類的事情嗎？這些都只會(huì)給新人造成一種尷尬的局面。

10. 計(jì)劃會(huì)議肯定是費(fèi)腦子和讓人精疲力竭的活兒。坐在椅子里4個(gè)鐘頭確定故事點(diǎn)數(shù)就像是在玩輪盤賭。這些數(shù)字將決定包含在沖刺里的內(nèi)容，但是怎樣在你根本沒有經(jīng)驗(yàn)的時(shí)候決定數(shù)字呢？你一定會(huì)估計(jì)錯(cuò)誤。

    但這些數(shù)字注定就是可能會(huì)出錯(cuò)的大致數(shù)字，這并不意味著你純粹是靠運(yùn)氣來開始玩輪盤賭。這些數(shù)字在未來的幾個(gè)沖刺之后將給予你某種指示，告訴你能夠完成的工作量。

11. 分配故事點(diǎn)數(shù)是一個(gè)復(fù)雜的任務(wù)，應(yīng)該按階段完成。團(tuán)隊(duì)內(nèi)部應(yīng)該首先分析故事，并與產(chǎn)品負(fù)責(zé)人進(jìn)行討論以清晰地了解需求。在得到清晰的視圖 之后，就要進(jìn)行廣泛的技術(shù)討論，考慮可以實(shí)現(xiàn)的最佳可能解決方案。這步要是完成不好，將導(dǎo)致在故事應(yīng)該如何實(shí)現(xiàn)方面模棱兩可，進(jìn)而導(dǎo)致有缺陷的估計(jì)。假 設(shè)，如果某個(gè)故事接觸到了一個(gè)新的未探索領(lǐng)域，那么它應(yīng)該會(huì)相當(dāng)復(fù)雜，即便它是一個(gè)簡單的任務(wù)。即使在已知領(lǐng)域，技術(shù)解決方案的不同也會(huì)導(dǎo)致故事相當(dāng)復(fù) 雜。

    簡單干脆的故事最容易被估算，即清楚地知道需求是什么，再加上點(diǎn)應(yīng)該如何實(shí)現(xiàn)的細(xì)節(jié)。產(chǎn)品負(fù)責(zé)人無法提供這么干脆的故事。它們只能通過跟團(tuán)隊(duì)一起討論得出來。因此，團(tuán)隊(duì)必須花點(diǎn)時(shí)間來為下一個(gè)沖刺進(jìn)行調(diào)整。

12. 回顧就像是在投票時(shí)間被賜予的演講。我們應(yīng)該已經(jīng)完成這個(gè)或那個(gè)，在下一個(gè)沖刺里我們可以完成這個(gè)或那個(gè)，但是要是這個(gè)沖刺里沒有接受某 些活兒，什么都不會(huì)發(fā)生。人們可以表達(dá)出對于不同方面的滿意與否，但是團(tuán)隊(duì)?wèi)?yīng)該著眼于從回顧的觀點(diǎn)里得到某些具體任務(wù)，否則境況將永遠(yuǎn)保持下去。

在扎進(jìn)敏捷之前，你可以做點(diǎn)準(zhǔn)備工作：

1. 熟悉市面上的技術(shù)，尤其是像JUnit、Fitnesse、EasyMock這樣的測試工具。此外，人們應(yīng)該不斷地為更好的解決方案而奮斗，因此出去找找改進(jìn)流程的新工具和新方法，尋找解決反復(fù)出現(xiàn)的問題的新框架或新設(shè)計(jì)思想和模式。

2. Venkat Subramaniam和Andy Hunt的“高效程序員的45個(gè)習(xí)慣：敏捷開發(fā)修煉之道”是每位涉足敏捷的開發(fā)者的必讀書籍。

3. 讀讀Robert C Martin在objectmentor.com上的“Craftsman series”和“Clean Code” 。一開始，你可以不用急著去讀它們，但在你碰到一堆麻煩的時(shí)候，你就會(huì)知道什么時(shí)候該去讀了。

4. 在站立式會(huì)議/計(jì)劃/討論，人們評估你建議的時(shí)候中保持一顆開放的心。說出你的觀點(diǎn)，或者必要的時(shí)候要求幫助，你是這個(gè)項(xiàng)目的受益人。

5. 測試不僅僅是為了代碼覆蓋率或質(zhì)量度量。它們還提供了某種類型的持續(xù)保持更新的文檔。人們可以先看看測試代碼，然后就知道該如何使用這段代碼了。

6. 在項(xiàng)目開始就自動(dòng)化構(gòu)建過程的所有事情。如果像Checkstyle這樣的小事都遺漏了，那么它的結(jié)果跟其他模型里的一樣，說得多做得少。當(dāng)你意識(shí)到這一點(diǎn)，求助于某種補(bǔ)救手段時(shí)，時(shí)間往往都太晚了。

學(xué)會(huì)說A到Z，然后再讓你忘記，重新學(xué)Z到A往往不會(huì)太容易。這會(huì)帶來些痛苦，但完成轉(zhuǎn)變之后，你就會(huì)知道這樣做是值得的。

話就說這么多，同志們，上路吧！！:)

查看英文原文：Confessions of A New Agile Developer