本文中，來自阿里內(nèi)貿(mào)團隊的工程師分享了所在團隊打造合作型“精英”小團隊的敏捷實踐方法，同時講述了實踐的效果，旨在給大家一些啟發(fā)，以供參考和借鑒。

能打造出Facebook里所提倡的“精英團隊”固然非常好，但這樣會對團隊中的每位成員都有較高的要求。我所在的團隊希望通過將團隊合 作精神運用在項目的各個階段來打造出一支強有力的合作型小團隊，并且取得了很不錯的戰(zhàn)績：每兩周發(fā)布一個版本，完成了幾次零Bug的項目，實現(xiàn)了一年線上 零故障。

我們團隊由2名產(chǎn)品經(jīng)理、6名開發(fā)人員和2名QA組成，并根據(jù)團隊特點量身定制了一套敏捷的開發(fā)方式。本文主要分享在需求、設(shè)計、開發(fā)和總結(jié)等階段中如何提高團隊成員的合作意識，從而形成團隊合力的最佳實踐。

需求串講評審

提倡需求串講。上游的質(zhì)量決定了下游的質(zhì)量。在軟件開發(fā)中需求文檔屬于最上游的輸出，所以我們格外重視需求評審。為了讓團隊成員能充分理解需求，并提高團隊 成員的參與度，項目需求不能總由產(chǎn)品經(jīng)理來講解，而應(yīng)采用輪流講解的方式，每次迭代由不同的人員講解。需求文檔會提前發(fā)給所有團隊成員，請大家消化和準(zhǔn) 備。在進行需求評審時選某一名成員上臺講解需求。雖然需求評審最核心的任務(wù)是在“評”上，但如果團隊成員都不能很好地理解需求或者不能很好地參與到需求評 審上，是很難做好需求評審的。

全員參與設(shè)計

為了提高設(shè)計和評審的效率，并且能夠讓全員充分參與到設(shè)計和評審中，我們團隊提倡結(jié)對設(shè)計、簡單設(shè)計、交叉設(shè)計和全員參與設(shè)計評審。

• 提倡結(jié)對設(shè)計。需求評審?fù)曛?#xff0c;會讓團隊成員一起來認領(lǐng)任務(wù)，但每個任務(wù)必須由兩名成員認領(lǐng)，這兩名成員分別是這個任務(wù)的主Owner和輔Owner，并結(jié)對設(shè)計這個任務(wù)。
• 提倡簡單設(shè)計。第一是設(shè)計快并易懂，第二是只做必要的設(shè)計。在設(shè)計評審前做的設(shè)計只能算設(shè)計草稿，用Visio等軟件做設(shè)計比較費時間，在設(shè)計評審后還要 修改，如此反復(fù)很浪費時間。而事實上一支筆和一張紙足以完成一次設(shè)計，先在紙上畫出自己的設(shè)計思路，然后同結(jié)對的成員進行討論，最后評審?fù)曛髮⒃O(shè)計圖拍 照提交到文檔庫。對于互聯(lián)網(wǎng)產(chǎn)品的開發(fā)，提倡只做必要的設(shè)計，需要時再重構(gòu)。因為根據(jù)以往的經(jīng)驗，擴展性良好的業(yè)務(wù)設(shè)計通常會有三個問題：第一，設(shè)計和開 發(fā)時間比較長；第二，代碼不易讀；第三，大部分?jǐn)U展以后都不會用到。
• 提倡交叉設(shè)計。為了讓團隊中每個人都能充分了解各個模塊，所以在不同的項目中每個人負責(zé)的模塊會不一樣。項目1中設(shè)計A模塊的人，可能會在項目2中設(shè)計B模塊。
• 全員參與設(shè)計評審。為了全體成員都能充分參與到設(shè)計評審中，我們制定了幾個固定的策略。

評審時間要短。因為大部分人在會議中只能專注20分鐘，所以設(shè)計評審要在40分鐘內(nèi)結(jié)束，設(shè)計者可使用PPT或直接在黑板上畫出設(shè)計思路。讓參與者充分了解設(shè)計的模塊。如果是對已有功能的修改，設(shè)計者必須先講這塊功能原來什么樣，現(xiàn)在需要修改成什么樣，涉及哪些修改點，是如何設(shè)計的。這能讓其他模塊的設(shè)計者更了解這個模塊，參與到這個模塊的設(shè)計評審中。

如果設(shè)計方案審批沒通過，則需要設(shè)計者返工。為了提高效率，不需要再開一次會議評審重新設(shè)計的方案，將相關(guān)人叫到座位旁邊確認就可以。

結(jié)對Code Review

• 提倡結(jié)對Code Review。如果模塊是由一個人設(shè)計的，那么Code Review時審查者只能幫助隊友Review出代碼中是否有壞味道，卻很難Review業(yè)務(wù)邏輯是否完全正確。因此，提倡結(jié)對Code Review，每個模塊由兩個人設(shè)計，然后分開開發(fā)，最后交叉Code Review，這樣能Review對方代碼中的業(yè)務(wù)邏輯是否正確。
• 提倡主動Code Review。結(jié)對的成員相互Review代碼會存在一定局限性，所以項目經(jīng)理要對核心功能進行Review。如果團隊中有人提前完成功能，也提倡他們主動幫其他人Review代碼。
• 代碼審查的時間。在時間充裕時，提倡每天進行一次Code Review，好處是修改成本低。通常情況下，在提交測試前2天開始做Code Review，但如果時間比較緊，也會在項目結(jié)束后做Code Review。

尋求幫助的晨會

晨會通常用于匯報工作進度，而我們希望將打造成尋求團隊合作的會議。很多時候，項目質(zhì)量低下主要是因為團隊成員開發(fā)時間不夠。如果某位成員實現(xiàn)某個功能發(fā)生 了延遲，那么他肯定沒時間寫單元測試，更沒有時間幫別人做Code Review。此時，就應(yīng)該在晨會上將這個問題告知團隊其他成員。我們不會因某名成員實現(xiàn)功能延遲而責(zé)怪他，更不會讓他加班追趕進度，而是在晨會時請其他 團隊成員幫他完成單元測試和Code Review。我們是一個團隊，有問題絕對不會讓團隊的某名成員獨立承擔(dān)。

不斷精進的項目總結(jié)

這些方法不是團隊創(chuàng)建之初就有的，是通過每次項目總結(jié)和下個項目實踐不斷精進出來的。在做項目總結(jié)時，所有成員都要針對本次項目的不足提出下個項目需要改善的地方，定出下個項目中可嘗試的實踐，并確定一位負責(zé)人和完成時間。

根據(jù)經(jīng)驗，如果不確定負責(zé)人和完成時間，任何實踐基本都很難完成。另外，我們通常只定一個實踐在下個項目中執(zhí)行，定多了也很難完成。而且為了讓大家能夠在項目總結(jié)會議中暢所欲言，通常會將項目總結(jié)會議辦成一個茶話會的形式。

為團隊質(zhì)量而賭

在項目開始前，開發(fā)人員和QA會輪流坐莊，賭本項目的Bug數(shù)會是多少個，輸?shù)囊环揭o贏的一方買飲料喝。這么做主要是為了在提高項目質(zhì)量的同時培養(yǎng)團隊合 作意識。如果開發(fā)要想獲勝，那么團隊中的每名開發(fā)人員都盡量不要產(chǎn)生Bug，避免拖累整個團隊，而團隊的其他成員為了實現(xiàn)目標(biāo)會更加主動地幫助同學(xué)做 Code Review。但這個目標(biāo)必須定得非常合理，如果項目中涉及到大量的前端開發(fā)，則Bug數(shù)會更多，目標(biāo)要定低一點。在本次項目目標(biāo)達成之后，下一個項目會 定更高的目標(biāo)。

作者方騰飛，花名清英，淘寶資深開發(fā)工程師，關(guān)注并發(fā)編程。目前在淘寶廣告技術(shù)部從事無線廣告聯(lián)盟的開發(fā)和設(shè)計工作。個人網(wǎng)站：http://ifeve.com

本文轉(zhuǎn)自：

http://www.programmer.com.cn/15217/

總結(jié)

以上是生活随笔為你收集整理的如何打造合作型团队——阿里内贸团队敏捷实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。