我在ThoughtWorks中的敏捷實踐

為了更好地閱讀體驗，歡迎訪問博客原文

本文以我在ThoughtWorks中的E項目經(jīng)歷為依據(jù)，覆蓋了ThoughtWorks日常獨立交付項目中主要的敏捷實踐。

項目回顧

項目背景

E項目是一個在線的物資跟蹤監(jiān)控系統(tǒng)。由ThoughtWorks團隊為客戶提供的一套完善的軟件交付服務。

該系統(tǒng)為資助物資的跟蹤與監(jiān)控提供了完整的網(wǎng)絡解決方案。整個流程涵蓋了客戶對物資來源的管控、庫存管理、物資下發(fā)與跟蹤、客戶與IP(Implementing Partner，合作伙伴)的協(xié)作溝通、IP對運輸結(jié)果的反饋(生成報告，警告通知，短信互動，郵件通知)，以及IP對物資的二次分發(fā)后的記錄跟蹤與監(jiān)控。

該項目屬于海外獨立交付項目，整個開發(fā)過程由ThoughtWorks團隊負責管理。好了，項目信息只能透漏這么多了，不然客戶要找我打官司了。

成員背景

ThoughtWorks提供完整的交付團隊(PM,?BA,?TL,?QA,?DEV,?UX)，團隊為頗具代表性的敏捷團隊，規(guī)模10人左右?？蛻魣F隊主要接口人3位。

ThoughtWorks團隊成員，猶如一架生猛的戰(zhàn)斗機：PM英文一流，敏捷開發(fā)管理相當?shù)轿?，因為看了上萬本腦殘小說，時不時就用到了生活中來。TL擁有7年以上的開發(fā)經(jīng)驗，7年之癢，什么，不用說都懂的。TL還富有學習激情和***精神，黑歷史墻列滿了他的關輝血淚史。QA被譽為IT界的福爾摩斯，DEV都休想逃過她敏銳的鼻子（怎么是鼻子呢？太陶醉了吧，這是境界?。?，最后，就是'苦逼'的DEV，也就是以程序員自居的我們。

我們每個人特點各不相同，但有一點神似：專業(yè)，責任心，追求卓越

我們團隊還有一個workout的文化特色，向??看：

PS：我們的workout自開始之日到項目交付之期，不曾落下過一天，且收到良好的反饋。即便團隊成員分開了，每個人都能將運動精神傳播下去，乃至源遠流長......

技術背景

我們是一個全功能團隊，人人身懷敏捷開發(fā)領域的知識和技能，且有一定的經(jīng)驗積累，所以可以說我們天生敏捷，在開發(fā)過程中大家都能高效地分工合作。

再說技術棧，項目使用的主要技術棧是Python,?Django,?AngularJs,?PostgresSQL,?Docker。而我們DEV在進入這個項目之前，擅長的技術棧是Java,?Springboot,?C#,?Android,?jQuery。

敏捷實踐

項目之所以成功交付，核心在于人，而良好的敏捷流程與實踐也是不容忽視的。

早在2001年，17位追求卓越的志愿者聚集在美國猶他州雪鳥獨家圣地，討論一個新的軟件開發(fā)趨勢，它被稱作輕量型軟件開發(fā)過程，后來他們將它定義為敏捷，并且發(fā)布了敏捷開發(fā)宣言：一種把以人為本、團隊合作、快速響應變化和可工作的軟件作為宗旨的開發(fā)方法。敏捷宣言可以總結(jié)為四句話：

個體與交互????優(yōu)于??流程與工具 客戶協(xié)作?????優(yōu)于??合同談判 響應變化?????優(yōu)于??遵循計劃 可工作的軟件??優(yōu)于??面面俱到的文檔 也就是說，盡管右項有其價值，我們更重視左項的價值。

敏捷開發(fā)的核心就是在一個高度協(xié)作的環(huán)境下，不斷的通過反饋來進行自我調(diào)整和完善。重點強調(diào)的是協(xié)作和反饋，協(xié)作體現(xiàn)在團隊與客戶之間的協(xié)作，團隊成員之間的協(xié)作。反饋則是在開發(fā)中的任何環(huán)節(jié)，包括代碼質(zhì)量、自動化測試、部署、項目進度、需求變更、客戶驗收等，而且反饋越快越好。有句土耳其諺語這么講的："不管你走了多遠，錯了就要重新返回"，所以我們越快得到反饋，就能越早確認自己有沒有走錯路。如果沒有錯，我們會更加充滿信心。反之，及時做出調(diào)整，讓浪費最小化。

項目中所涉及的敏捷實踐主要圍繞迭代進行，用一張圖概括：

可以總結(jié)出以下幾點：

1.?Iteration通常始于IPM?，止于Showcase。2.?每天都會發(fā)生事件有Standup?。3.?Pair、TDD、Code?Review穿插在日常Coding中。4.?Story?kick-off之后，該Story就進入了開發(fā)環(huán)節(jié)。5.?CI屬于基礎設施，通常在一個名為Iteration0的迭代完成，也就是正是開發(fā)開始之前就應該完成CI的搭建。6.?Retro較長一段時間才進行的活動，根據(jù)實際情況，1個月或兩個月舉行一次。7.?Regular?catch?up?with?client也會因項目而異，Daily或者Weekly，甚至某些項目可以省略該項活動。

敏捷的宗旨是減少浪費，所有的敏捷實踐也都是圍繞著高效協(xié)作與快速反饋這兩個核心理念展開。

IPM

IPM(Iteration Plan Meeting)，迭代計劃會議主要是跟客戶保持溝通與信息更新的一個會議。

敏捷宣言里面有一條：客戶協(xié)作優(yōu)于合同談判。在Scrum團隊中有一個角色叫做產(chǎn)品負責人，Ta的核心職責是確保業(yè)務需求的清晰和透明，保證開發(fā)團隊對業(yè)務有足夠的了解，并將這些待完成的業(yè)務需求（Story）按照優(yōu)先級排列出來，按照任務卡的方式來驅(qū)動團隊的開發(fā)。并在客戶需求有變更后能夠第一時間告知團隊以做出調(diào)整。

在我們團隊中，這個角色就是一開始提到的BA。她是IPM主要參與人，另外還有Tech Lead會一起參與討論（團隊中每一個人成員都是可以參與進來的）。IPM按照團隊指定的迭代的周期，通常是兩周，每隔兩周跟客戶接口人一起約一個時間，主要討論以下幾個方面的內(nèi)容：

1.?下一個迭代的Story。2.?對下一個迭代的期望。3.?團隊的人員可用性。4.?風險的評估總結(jié)。

通過這種會議，能夠讓客戶對我們團隊狀況有一個清晰的了解，而且客戶對我們下一個迭代要做的功能有了整體的把控，一起設定好期望，這樣也會大大降低風險。

IPM的主要產(chǎn)出是下一個迭代中完成的Story，這些Story即為下一個Story要完成的目標，我們通過敏捷看板工具來管理它們，例如下圖mingle上位于Backlog欄中的Story:

Regular catch up with client

跟客戶建立信任關系是合作的基礎，而讓客戶保持愉悅，也是項目成功交付的助推劑。

Regular catch up with client，即?定期跟客戶進行溝通，雙方共同商議一個時間（工作時間最佳），一起開個短暫的小會，時間上的成本較低。

Catch up的主要參與人員是BA(PM)和TL，通過于客戶方Face2Face會議或者online會議進行一個短暫的溝通，溝通內(nèi)容主要涉及：

1.?我們團隊昨天的更新.2.?客戶昨天的更新3.?確認Story。如果有變更，能及時作出調(diào)整。4.?提醒客戶使用我們開發(fā)出來的功能，以便我們盡早得到反饋。5.?一些節(jié)日的問候，噓寒問暖，表達我們團隊的關懷。

因項目而異，Catch up實踐可以大體分為兩種：

1.?針對Onsite項目Face2Face形式。因為跟客戶在一起工作，就可以較為高效地組織Face2Face的會議，實踐證明，F(xiàn)ace2Face是效率最高的一種形式。2.?針對獨立交付項目的Online形式。因為地點、時差等原因，適當調(diào)整Catch?up的頻率，另外選擇一個便捷可靠地工具（例如：Fuze,?GTM,?Skype等），提前設置好環(huán)境并分享給客戶相關人員。

通過與客戶進行定期的溝通，產(chǎn)生的價值主要體現(xiàn)在客戶信任和客戶關系方面：

1.?首先，讓客戶有非常強烈的參與感，以及讓他們對項目整個進展的把控（他們會覺得自己才是項目的主導者），增強他們的信心以及對我們的信任。2.?其次，讓客自己決定功能實現(xiàn)以及及時驗收功能，降低了需求變更和打回的風險。3.?最后，則是潤滑劑了，能夠在客戶良好的信任的基礎上，保持合作關系的輕松愉快，這會為項目的成功交付使上勁。

并不是每一個項目都會有這個實踐，有些獨立交付的項目，他們每日站會的時候客戶也會參與進來，就不需要額外單獨的時間去做這件事情了，而有些項目，因為特殊性，客戶可能不希望這么頻繁的Catch up，這時候需要團隊靈活變通，與客戶一起商討出一個合適的時間周期，做出一些權(quán)衡，讓客戶自身覺得舒服?？傊琄eep住的一點是：保持跟客戶的信息溝通，盡可能早的得到客戶的反饋，保持良好的客戶關系。

Standup

Standup是一項成本小收益大的活動，做好它是敏捷的第一步。

Standup，就是每日站會。我聽過一個有趣的事情：在敏捷開發(fā)方法興起的時候，很多傳統(tǒng)開發(fā)模式的團隊躍躍欲試，他們選擇從Standup切入。然后每天早上上班后，大家聚在一起開個會（站著、坐著都有），然后該怎么做還是怎么做。他們會對別人說，我們在搞敏捷開發(fā)...

沒錯，Standup就是團隊在一起快速地開一個會，大家挨個的更新一下自己的狀態(tài)，更新包含以下幾個方面：

1.?昨天完成的工作。2.?今天計劃做什么。3.?面臨什么阻礙。4.?自己手頭Story的進展。5.?是否存在技術風險。

既然是快速的會議，Standup的時間就不宜過長，建議5~15分鐘。最好是站著開會，因為研究表明，當人們坐著開會的時候，會議的時間會被無形中拉長。Standup的時間安排在工作時間開始后的半個小時最佳（比如9:00上班，9:30開始），這樣大家就不用一到公司就急急忙忙的參加Standup，大家有個緩沖的時間，比如說設置電腦，泡咖啡，沏茶，整理今天的todo list等。

沒有什么特殊原因的情況下，確保團隊成員都要參加，如果一些人因為特殊原因經(jīng)常不按時到，適當調(diào)整Standup的時間，但也不宜太晚。

而對于規(guī)模很小的團隊（3~5人），也強烈建議執(zhí)行Standup，因為它的成本真的很低。

或許有人會覺得：大家天天都在一起工作，溝通如此方便，何必要這項活動？ 這有點深處酒巷中不覺酒香的味道了。站會能夠給團隊帶來的價值不容忽視：

1.?讓大家進入一天的工作狀態(tài)。2.?清楚自己的Story的進展，提醒自己把握好時間，或者激勵其他成員的開發(fā)進度。3.?讓團隊成員知道項目其他地方的進展。4.?如果誰遇到不好解決的問題，可以將問題拋出來，大家一起積極討論解決方案，也能尋求其他人員的技術支持。5.?避免在重復造輪子而耗費時間，讓大家知道目前團隊中可供復用的解決方案。6.?幫助Team?Leader了解哪些領域需要更多的幫助，從而更好地分配資源。

下面是我們團隊的Standup:

PS: Standup的時候，選一實物作為Token，發(fā)言時拿著Token。上圖中我們選擇了瑜伽球作為Token，逗比們說：健身無處不在~

Story kick-off

在一個Story開始前，確保BA,?QA,?DEV對Story的理解達成一致，并嚴格按照AC來驗收。當然，前提是Story本身是不容置疑的。

Story kick off，指的是對某一個Story進行開卡，也就是啟動該Stroy，從而使其進入開發(fā)階段。Story kick off的時候，通常需要三個角色一起參與：BA、QA以及要開發(fā)該Story的DEV。

Story由BA預先寫好，并通過專業(yè)的敏捷管理工具進行管理。DEV在kick off的時候，BA會給DEV講解這個Story要完成的功能，以及它的AC。DEV如果對其中的描述有任何疑惑，需要及時提出來，當場弄明白才可以正確的去完成這些功能。在后續(xù)的開發(fā)過程中，如果碰到任何疑惑，隨時找BA或者QA了解清楚，不應該自己猜測著開發(fā)，更不可跟著心走。

Story kick off 的核心目的是確保DEV開發(fā)出的功能都是符合客戶期望的。而Story本身存在錯誤并不在討論范圍之內(nèi)。實際上在開發(fā)過程中，也未發(fā)生過這種情況，因為一旦客戶的需求變更后，Story卡也會及時變更過來。Story kick off 可以follow以下實踐：

1.?DEV自己先完整地過一遍Story的描述。2.?DEV給BA和QA去講這個Story的功能以及AC。3.?要能夠清晰的講出來，并且三者達成一致，如果有疑惑，需要當場得到解決。4.?DEV開始開發(fā)Story，并自行將Story參照AC拆分成很多個子任務列表，然后逐一干掉它們。

最后一個實踐嚴格上講不是kick off環(huán)節(jié)里面的，它發(fā)生在kick off后，DEV自行決定怎么去完成功能。我比較推薦DEV在kick off后將Story劃分成子任務列表，按照依賴關系和優(yōu)先級排序，逐個干掉他們。一些敏捷管理工具(Trello,?mingle,?Pivotal Tracker,?teambition)都支持這種任務拆分，你還可以很容易的記錄與跟蹤。

Story kick off也是一項短時間高收益的活動，因為在我們DEV界中，有一句邪門的定律：

猜出來的需求往往是不靠譜的，最終需要打回重做！

所以kick off能夠有效的避免Dev自行臆測業(yè)務需求而產(chǎn)生的浪費。除此之外，能夠彌補BA在編寫Story的時候技術視角的一些遺漏。

一些項目會引入好的開發(fā)實踐，比如說BDD。它能按照人類自然語言去描述一個功能的實現(xiàn)。我們的Story描述通常會參照這種方式:?as...when...then...when...then。這個時候，DEV、QA、BA可以在Story kick off的時候利用一些測試工具（Cucumber）一起來編寫Story驗收測試用例（主要由QA來編寫），DEV負責編寫代碼來通過這些測試。理想情況下，驗收測試用例如果正確完整，當所有測試都通過后，意味著Story功能已經(jīng)完成。而且這種TDD的方式，代碼出現(xiàn)bug的幾率也會大幅度降低。

下面是一對Pair做Story kick off：

Pair

結(jié)對編程的開發(fā)速度通常小于簡單地將一個人的開發(fā)速度乘以2，但它依然能創(chuàng)造價值：知識的共享，代碼質(zhì)量的提高，缺陷率的降低。

XP里面提到了結(jié)對編程，經(jīng)過事實證明，它是一項利大于弊的實踐。

通俗地講，Pair就是兩個人同時工作在同一個Story上，一起討論Story的解決方案，并編寫代碼實現(xiàn)功能，一個人敲鍵盤，一個人看屏幕，穿插著進行。Pair的小伙伴在快速敲擊鍵盤的時候會伴隨一些交流，并時不時停下來討論說笑片刻，亦或是在欣賞一下自己漂亮的代碼。

兩個人一起寫代碼即為Pair，那么如何進行高效的Pair呢，也有一些良好的實踐：

1.?搭檔的選擇上，兩個人的技能和經(jīng)驗最好是相當?shù)模@樣就不至于一個人成為被教育的對象，而另一個人成為鍵霸。2.?有新人加入時，需要一個經(jīng)驗較豐富的老人Pair，最好是有良好Coach技能的老人，老人盡量只提供思路啟發(fā)，并讓新人多思考和動手實現(xiàn)。3.?經(jīng)驗相當?shù)腜air時，可以一起討論解決方案，并達成一致，然后一個人寫測試，另一個人編寫代碼通過測試，兩人同時保持focus。4.?定期更換Pair，粒度可以控制在以一個Story完成為節(jié)點。大一點的Story可以keep住一個人不動，另一個人進行更換。5.?遇到技術阻礙時，分頭并行尋找解決方案，并最終一起決定采取什么方案。6.?當兩個人對實現(xiàn)細節(jié)的優(yōu)劣拿捏不定時，邀請團隊經(jīng)驗豐富的老人做出建議參考。7.?在一些很簡單的defect上，可以不采用Pair。

Pair將本來可以并行工作的兩個人聚焦在一件事情上，表面上是在降低生產(chǎn)力，實際上它確實是有一定的成本的。而這種付出并不會打水漂，最明顯的好處是能夠最大化知識的共享（尤其是更換pair的場景下）,包括業(yè)務知識的共享、技術方案共享、解決問題思路的共享，這一點尤其體現(xiàn)在團隊有新人融入的時候，通過Pair能夠快速帶領新人成長起來，提高整個團隊的戰(zhàn)斗力。另一方面可以提高代碼質(zhì)量，Pair實際上是兩個人一直在不停的做Code Review，兩個人的思維碰撞能夠避免很多代碼小聰明和不好的編碼習慣。

有些時候，因為項目進度的緊張，Pair并不會這么理想的被落實，團隊可以進行靈活的調(diào)整。如果Pair的時間減少了，可以通過加長Code Review的時間來做一些彌補。

下圖是我跟TL Pair的剪影：

TDD

TDD，測試驅(qū)動開發(fā)，這項人人都稱贊、卻很少有人真的去做的活動，不應該只是一個被供奉起來的神。接地氣，再接地氣一點。

TDD，即測試驅(qū)動開發(fā)，強調(diào)的是測試先行。TDD是一個存在爭議的主題，因為在一個連測試的沒有的代碼庫中（多數(shù)客戶也不關心測試代碼，他們通常只想要看得到的功能），它的立身之本就不復存在了。我經(jīng)歷過只有純手工黑盒測試的項目，沒有單元測試、沒有集成測試、沒有E2E測試（測試金字塔, Martin Folower)，所以TDD無從談起。我也經(jīng)歷過客戶要求測試覆蓋率的項目，有專門的測試覆蓋率工具(coveralls)來檢測代碼庫，有的甚至集成在CI上作為一個硬性指標。

所以，TDD必須在一個有測試的項目中去講。它跟我們先實現(xiàn)功能代碼后添加測試的過程恰恰相反。我們根據(jù)對業(yè)務理解，先寫一些測試（E2E，Integration, Unit），此時得到運行結(jié)果為紅色（測試運行失敗），然后編寫業(yè)務代碼讓其變綠（測試運行成功）。

當然，TDD實踐存在一定的門檻，TDD更多地考察一個人的設計能力，所以需要有一定經(jīng)驗的開發(fā)人員，而新人往往是很難做到這一點，但這不應該是新人不去嘗試TDD的借口。

在實際項目中，可以根據(jù)團隊自身的條件，靈活采取TDD去編碼。就我個人的經(jīng)驗而言，TDD編碼的時候剛一開始的時候并不是那么順手（因為TDD更偏重設計），心里會覺得比較耗費時間，最終Story的完成時間相差無幾，而TDD除了有效地降低缺陷率，還有以下三個方面的好處。

1.?從宏觀把握Scope，開發(fā)人員不會在開發(fā)的過程中擴大或偏離Scope。舉個例子，開始一個功能點時，一上來添加一個E2E測試，整個Scope在此時就被框定，然后再細分到內(nèi)部實現(xiàn)，最終以通過這個測試來完成這個功能。2.?提高代碼的設計。當我們先寫測試的時候，就會考慮到被測試的對象要盡可能被方便的測試，此時我們會盡可能的改良我的的API設計，以便利于測試，這樣一來，我們寫出的代碼更具有可測試性，這樣的代碼往往具備較高的質(zhì)量。3.?確保功能不會被遺漏。我們一開始更多關注的是業(yè)務，而不是代碼的實現(xiàn)細節(jié)，此時寫出來的測試會更全面的涵蓋不同的Case。

Code Review

不可否認的一個事實：人人都愛整潔的代碼。而一個人單獨編碼難免會耍一些小聰明，或引入一些自身習慣難以察覺的不良代碼。Code Review能讓你提高警惕，并改善代碼的質(zhì)量。

Code review，檢查代碼，也叫代碼審查，就是開發(fā)人員湊在一起來檢閱彼此所產(chǎn)出的代碼。看看有沒有新的代碼壞味道，看看有什么不合理的設計甚至是錯誤的設計，等等。

既然是開發(fā)人員湊在一起審查代碼，那么Code Review會產(chǎn)生一定的時間成本（根據(jù)團隊的規(guī)模1~2小時 = 5~10個開發(fā)人員），所以需要一些良好的實踐來確保Code review的高效產(chǎn)出：

1.?團隊一起擬定一個開始時間和時長，并落實到位，保證團隊成員的參與度和Focus。2.?短時間的描述自己的Story業(yè)務，主要Focus在代碼上。3.?持續(xù)跟蹤記錄，并獲取反饋。這需要有一個人記錄問題（可以按天輪流），結(jié)束后交給Owner執(zhí)行更改，并且下一次Code?Review的時候先過上一次的更改。4.?必要的時候拉長時間，條件允許下建議在一個有大顯示器的會議室中進行。

另外，從團隊規(guī)模和時間安排上，可以遵循以下兩個原則

1.?對于規(guī)模很小的團隊，可以適當減少Code?Review的時間和頻率，如果團隊經(jīng)常Switch?Pair，也可以適當減少Code?Review的時間。2.?安排在下班前進行。一方面，大家經(jīng)過一天的高強度的思考與編碼，適當停下來，看看其他人寫的代碼，同時將自己代碼講解出來，還能意外的獲得一些靈感，或許能解決自己面臨的阻礙（你所面臨的問題可能已經(jīng)被其他人解決了）。另一方面，如果這個時候發(fā)現(xiàn)代碼的壞味道，需要改進的地方，下班后可以花少量時間作出更改。

長期的實踐證明，Code Review能帶來的好處有：

1.?讓每一個人提高警惕：自己寫的代碼并不是只有自己看的，所以要督促自己做好。比如規(guī)避不想寫測試，代碼?？岬取?.?共同找出代碼的壞味道（命名規(guī)范，代碼整潔，API內(nèi)聚性，面向?qū)ο笤O計），及時做出改正，提高代碼庫的質(zhì)量，有助于后期擴展和維護。3.?讓團隊成員知道他人在做什么以及怎么做，分享好的編碼習慣和技術實現(xiàn)，有助于團隊整體進步。

下面是某個時刻，我們Team四個人正在專注地討論為一個函數(shù)取個更好的名字（猜猜誰是表情帝？？）：

Showcase

不管客戶有多忙，也要定期讓客戶確認自己的期望是否得到滿足。在簽訂合同前，要跟客戶達成一致：Showcase的地位不可動搖。

Showcase就是給客戶演示我們上一個迭代已經(jīng)完成的功能，它的宗旨是及時得到客戶的反饋，確認團隊的產(chǎn)出是否滿足客戶的期望，降低需求變更返工的風險。

Showcase從項目開始時周期性地進行，并直到項目交付。這個時間間隔是基于團隊設定的迭代周期，我們團隊是兩周一次。團隊跟客戶安排一個遠程會議（如果是在客戶現(xiàn)場，一些參與討論效果更好），主要涵蓋了以下內(nèi)容：

1.?跟客戶確認上一個迭代的Story列表。2.?項目目前的交付狀態(tài)。是否正常進度，會不會延期。3.?演示上一個迭代完成功能。在線系統(tǒng)演示，需要一個staging環(huán)境。4.?客戶對功能確認，對達到期望的story簽字，反之。我們記錄下問題，并修改，再次確認簽字。

Showcase的目標是客戶，需要針對不同的客戶有不同的策略。如若客戶覺得每兩周一次過于頻繁，團隊可以變通調(diào)整迭代周期，通常建議的是1~4周，不宜太長，太短也沒什么效果，至于如何權(quán)衡這個時間，有兩點可以參考：

1.?在探索中找到適合團隊的迭代周期，如果發(fā)現(xiàn)每個迭代時間不夠用，要么是story劃分太大，要么是迭代周期太短，這時需要根據(jù)幾次的平均結(jié)果做出調(diào)整，適當擴大迭代周期，或者更合理的拆分Story。2.?如果Showcase的時候功能背離了客戶的期望，通常是因為迭代周期太長。因為用戶的需求以及團隊對需求的理解都在隨著時間的推移而變化，導致發(fā)布時的產(chǎn)出并不是客戶需要的。這個時候，可以考慮適當縮短迭代周期，讓反饋來的更快更舒緩一些，而不是更慢更猛烈。

試想一下傳統(tǒng)瀑布開發(fā)模式下，一個功能的演示通常安排在在某個里程碑節(jié)點，此時項目或許開展了半年或一年甚至更久，客戶這個時候見到自己的系統(tǒng)，簡直會驚叫起來，原來這壓根不是他們想要的東西（因為客戶一開始都不知道自己要什么），即便開發(fā)團隊嚴格按照預先的設計文檔。這是一種時常發(fā)生的災難，它導致大量的浪費，且很難挽救。

敏捷開發(fā)可以規(guī)避這種災難性事件的發(fā)生。而Showcase在敏捷開發(fā)中是一個不容忽視的環(huán)節(jié)，它契合了敏捷宣言中的擁抱變化優(yōu)于遵循計劃。Showcase能夠讓團隊在每個迭代完成后及時從客戶那得到反饋，對變化做出快速的響應，避免了勞動成果的浪費以及方向的偏離，也能最大化讓客戶的期望得到滿足。

為了達到更好的Presentation效果，Showcase通常提前準備一個總結(jié)性的Slide來引導整個過程的推進，結(jié)束后該Slide即為產(chǎn)出的一部分，另外也會有一封總結(jié)性的郵件來跟蹤記錄Showcase的結(jié)果。

CI

沒有CI的項目開發(fā)是在耍流氓。CI在Agile中是一項最基礎的設施，它通過自動化來提供有效的反饋機制以及高效的部署，大大降低代了碼集成和項目交付的風險。

CI，持續(xù)集成。在敏捷開發(fā)中，它是一個項目開始前必須搭建起來的基礎設施。當代的軟件開發(fā)項目中，幾乎沒有項目是只有一個人在開發(fā)的。超過一個人就形成了團隊，每個人同時并行開發(fā)不同模塊的功能，這就涉及到代碼的集成，所以代碼集成是幾乎所有開發(fā)團隊都要面臨的問題（一個人的開發(fā)項目不在本文范疇中）。

持續(xù)集成跟團隊開發(fā)人員獨立開發(fā)沒有沖突，相反，借助一些工具（Jenkins,?GoCD(ThougthWorks開發(fā)),?Travis CI），它能快速的對我們開發(fā)人員提交到代碼庫的代碼作出反饋。開發(fā)人員每天都在代碼庫提交代碼，版本控制工具（比如Git）在提交前必須更新代碼庫最新的代碼（解決沖突，代碼合并，應用更改），然后將代碼提交到代碼庫中。這個過程是代碼集成的第一步，最重要的是如何確保這些集成是可靠的，以下是一些關于CI的良好實踐：

1.?開發(fā)人員對自己編寫的代碼添加足夠的測試覆蓋率。這是基本，基本最無敵：一來驗證代碼的正確性，二來防止被誤更改。2.?每個人提交代碼到代碼庫之前在自己的機器上保證單元測試都能通過，很耗時集成測試和E2E測試可以更多的交給CI去跑。3.?借助一些CI工具（見上文）,將代碼集成的結(jié)果反饋展示在團隊所有人都能看到的Dashboard上，一定要大家都可以看到。4.?CI定期檢查代碼庫的更新，只要有更新，就要運行所有的測試。這里有個權(quán)衡：不耗時的單元測試每次全部運行，集成測試也要頻繁的運行，耗時的E2E測試可以稍微執(zhí)行少一點（比如設置夜間執(zhí)行）。我們這個項目，是每次檢查到更新就會運行所有的測試（單元測試+集成測試6分鐘，E2E測試30分鐘）5.?CI如果沒有通過，所有人都應該停止向代碼庫中提交代碼，直到CI被修復，所以如果CI掛了，能夠及時通知相關開發(fā)人員，要第一時間修復。6.?所有測試通過之后，CI負責自動化部署到不同的環(huán)境（Test，開發(fā)團隊測試環(huán)境；Staging，客戶ShowCase環(huán)境；UAT和Production，用戶驗收測試環(huán)境和生產(chǎn)環(huán)境，通常開發(fā)團隊沒有權(quán)限），并正常啟動所有的服務。

通過這些實踐，CI能帶來的價值也是相當可觀的，主要體現(xiàn)在五個方面：

1.?減少重復的過程。CI通過自動化，將一些需要重復執(zhí)行的操作（代碼審查、編譯、測試、構(gòu)建、部署）自動化管理起來，大大減少了重復的過程，節(jié)省了大量的時間。2.?降低風險。開發(fā)過程中，每天進行多次集成，并且添加了足夠相應的測試，每次集成CI都會快速檢查代碼中的缺陷并提供及時的反饋，降低了未知的風險。3.?可視化。CI提供了大量真實且最新的數(shù)據(jù)，能夠讓我們關注當前集成的趨勢（例如構(gòu)建時間、構(gòu)建失敗比例、測試覆蓋率等），有利于有效決策。4.?增強團隊的信心。每次構(gòu)建的結(jié)果都是公開透明的，所有人清楚地知道自己的每次提交改動對軟件所造成的影響。5.?隨時隨地可以生成可部署的軟件（CD）。對于客戶來說，可以部署的軟件產(chǎn)品是最實際的資產(chǎn)，而CI讓我們可以在任何時間發(fā)布可以部署的軟件。

可以借助一些工具，比如Chrome插件BuildReactor可以將CI的多個Pipeline集中展示出來。

下面是我們CI的Dashboard，使用了一個Chrome插件BuildReactor（如果加載不了就說明需要***）將Go的多個Pipeline集中展示出來。

Retro

團隊專注于交付目標，埋頭干活的同時，也要懂得停下來總結(jié)過去，并更好地抬頭看路。

Retro是Retrospective的簡寫，即回顧。團隊通常以回顧會議的形式進行，大家坐在一起，對過去的這段時間里，我們Team的工作狀態(tài)（團隊合作，技術實踐，團隊氛圍等）做一個總結(jié)，它有一點基本思想：對事不對人，大家思想自由Open。如何做到這一點，下面是我們Team的實踐：

1.?確認構(gòu)建安全的環(huán)境。什么意思呢？就是每個人都是覺得當前的會議是可以自由發(fā)表意見的，而不是因為某些人（比如說不友善的Leader）而不敢發(fā)表意見。開始前每個人對安全系數(shù)打分，1~10分，如果平均分數(shù)偏低（比如低于6分），需要將Leader從會議中"驅(qū)趕出去"，直到大家覺得安全了才好。2.?建立幾項總結(jié)指標（Well,?Less?Well，Suggestion，Action），大家分別對前三項提出自己的看法。第四項是綜合所有前三項的結(jié)果總結(jié)出來后面要做的事情。3.?使用Sticker紙片，最好是用馬克筆寫（這樣一張Sticker就不能泛泛無邊的寫），一張Sticke寫上一個點的內(nèi)容即可。4.?編寫Sticker內(nèi)容的時間控制在5分鐘以內(nèi)，每個人自己將Sticker按照分欄貼好，然后Facilitator（通常是PM或BA）開始帶著大家過每一欄的Sticker，對Less?Well欄中，將同一類的問題歸納起來，總結(jié)出相應的解決措施。5.?將Action欄中的Sticker指派Owner，并落實。6.?如果跟客戶關系融洽且相對容易參與進來，可以將客戶Involve進來，然后一起構(gòu)建一個安全的環(huán)境（有可能因為大家的打分較低，客戶不得不“出場”，所以客戶參與不是必須的）。

說得天花亂墜，沒有行動，猶如竹籃打水。Retro這個環(huán)節(jié)最核心的產(chǎn)出物是Action，團隊共同一致商量出來的措施，有沒有效果就在于行動了，所以Action分配了Owner之后，一定要跟蹤這些Action有沒有落實執(zhí)行。一方面，需要Owner擁有高度的責任心和執(zhí)行力，盡職將這些Action落實執(zhí)行。

Retro的細節(jié)因團隊而有些差異，而它的理念是一致的：總結(jié)過去，做的好的方面繼續(xù)保持及加強，做的欠佳的方面一起討論改進措施，并盡全力落實。Retro讓團隊在實踐中摸索出適合團隊的最佳實踐，引導團隊和個人不斷自我完善，追求卓越。

我們Team的一次Retro

總結(jié)

這是我參加的一個關于敏捷實踐很完善的項目，個人親身經(jīng)歷了這些，深深體會到這些敏捷實踐帶來的益處以及個人的成長是非常大的。敏捷很好，但不只在于這些流程形式，在形式背后，我們應該深入思考這些實踐是否真的讓團隊變得高效？讓交付變得更加順利？每個團隊都是不同的，不必拘泥于這些流程形式，而是要追求這些流程產(chǎn)生的真正價值與意義。

PS：文章中提供的鏈接在有網(wǎng)絡的情況下如果不能訪問，確認自己是否可以***，如不可以，切勿較真。

術語注釋

PM：Project Manager，項目經(jīng)理

BA：Business Analyst，業(yè)務分析師

TL：Technical Leader，技術領導

QA：Quality Assurance，測試人員

DEV：Developer，開發(fā)人員

UX：User Experience，用戶體檢設計師

AC：Acceptance Criteria，驗收條件

UAT：User Acceptance Test，用戶驗收測試

Retro：Retrospective，回顧會議

TB: Team building，團隊建設

此文章已經(jīng)發(fā)布于InfoQ，閱讀InfoQ文章

本文轉(zhuǎn)載自異步社區(qū)

軟件開發(fā) 軟件開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。