本文中，來自阿里內貿團隊的工程師分享了所在團隊打造合作型"精英"小團隊的敏捷實踐方法，同時講述了實踐的效果，旨在給大家一些啟發，以供參考和借鑑。
能打造出Facebook裡所提倡的"精英團隊"固然非常好，但這樣會對團隊中的每位成員都有較高的要求。我所在的團隊希望通過將團隊合作精神運用在專案的各個階段來打造出一支強有力的合作型小團隊，並且取得了很不錯的戰績：每兩週釋出一個版本，完成了幾次零Bug的專案，實現了一年線上零故障。
我們團隊由2名產品經理、6名開發人員和2名QA組成，並根據團隊特點量身定製了一套敏捷的開發方式。本文主要分享在需求、設計、開發和總結等階段中如何提高團隊成員的合作意識，從而形成團隊合力的最佳實踐。
需求串講評審
提倡需求串講。上游的質量決定了下游的質量。在軟體開發中需求文件屬於最上游的輸出，所以我們格外重視需求評審。為了讓團隊成員能充分理解需求，並提高團隊成員的參與度，專案需求不能總由產品經理來講解，而應採用輪流講解的方式，每次迭代由不同的人員講解。需求文件會提前發給所有團隊成員，請大家消化和準備。在進行需求評審時選某一名成員上臺講解需求。雖然需求評審最核心的任務是在"評"上，但如果團隊成員都不能很好地理解需求或者不能很好地參與到需求評審上，是很難做好需求評審的。
全員參與設計
為了提高設計和評審的效率，並且能夠讓全員充分參與到設計和評審中，我們團隊提倡結對設計、簡單設計、交叉設計和全員參與設計評審。
提倡結對設計。需求評審完之後，會讓團隊成員一起來認領任務，但每個任務必須由兩名成員認領，這兩名成員分別是這個任務的主Owner和輔Owner，並結對設計這個任務。
提倡簡單設計。第一是設計快並易懂，第二是隻做必要的設計。在設計評審前做的設計只能算設計草稿，用Visio等軟體做設計比較費時間，在設計評審後還要修改，如此反覆很浪費時間。而事實上一支筆和一張紙足以完成一次設計，先在紙上畫出自己的設計思路，然後同結對的成員進行討論，最後評審完之後將設計圖拍照提交到文件庫。對於網際網路產品的開發，提倡只做必要的設計，需要時再重構。因為根據以往的經驗，擴充套件性良好的業務設計通常會有三個問題：第一，設計和開發時間比較長；第二，程式碼不易讀；第三，大部分擴充套件以後都不會用到。
提倡交叉設計。為了讓團隊中每個人都能充分了解各個模組，所以在不同的專案中每個人負責的模組會不一樣。專案1中設計A模組的人，可能會在專案2中設計B模組。
全員參與設計評審。為了全體成員都能充分參與到設計評審中，我們制定了幾個固定的策略。
評審時間要短。因為大部分人在會議中只能專注20分鐘，所以設計評審要在40分鐘內結束，設計者可使用PPT或直接在黑板上畫出設計思路。讓參與者充分了解設計的模組。如果是對已有功能的修改，設計者必須先講這塊功能原來什麼樣，現在需要修改成什麼樣，涉及哪些修改點，是如何設計的。這能讓其他模組的設計者更瞭解這個模組，參與到這個模組的設計評審中。
如果設計方案審批沒通過，則需要設計者返工。為了提高效率，不需要再開一次會議評審重新設計的方案，將相關人叫到座位旁邊確認就可以。
結對Code Review
提倡結對Code Review。如果模組是由一個人設計的，那麼Code Review時審查者只能幫助隊友Review出程式碼中是否有壞味道，卻很難Review業務邏輯是否完全正確。因此，提倡結對Code Review，每個模組由兩個人設計，然後分開開發，最後交叉Code Review，這樣能Review對方程式碼中的業務邏輯是否正確。
提倡主動Code Review。結對的成員相互Review程式碼會存在一定侷限性，所以專案經理要對核心功能進行Review。如果團隊中有人提前完成功能，也提倡他們主動幫其他人Review程式碼。
程式碼審查的時間。在時間充裕時，提倡每天進行一次Code Review，好處是修改成本低。通常情況下，在提交測試前2天開始做Code Review，但如果時間比較緊，也會在專案結束後做Code Review。
尋求幫助的晨會
晨會通常用於彙報工作進度，而我們希望將打造成尋求團隊合作的會議。很多時候，專案質量低下主要是因為團隊成員開發時間不夠。如果某位成員實現某個功能發生了延遲，那麼他肯定沒時間寫單元測試，更沒有時間幫別人做Code Review。此時，就應該在晨會上將這個問題告知團隊其他成員。我們不會因某名成員實現功能延遲而責怪他，更不會讓他加班追趕進度，而是在晨會時請其他團隊成員幫他完成單元測試和Code Review。我們是一個團隊，有問題絕對不會讓團隊的某名成員獨立承擔。
不斷精進的專案總結
這些方法不是團隊建立之初就有的，是通過每次專案總結和下個專案實踐不斷精進出來的。在做專案總結時，所有成員都要針對本次專案的不足提出下個專案需要改善的地方，定出下個專案中可嘗試的實踐，並確定一位負責人和完成時間。
根據經驗，如果不確定負責人和完成時間，任何實踐基本都很難完成。另外，我們通常只定一個實踐在下個專案中執行，定多了也很難完成。而且為了讓大家能夠在專案總結會議中暢所欲言，通常會將專案總結會議辦成一個茶話會的形式。
為團隊質量而賭
在專案開始前，開發人員和QA會輪流坐莊，賭本專案的Bug數會是多少個，輸的一方要給贏的一方買飲料喝。這麼做主要是為了在提高專案質量的同時培養團隊合作意識。如果開發要想獲勝，那麼團隊中的每名開發人員都儘量不要產生Bug，避免拖累整個團隊，而團隊的其他成員為了實現目標會更加主動地幫助同學做 Code Review。但這個目標必須定得非常合理，如果專案中涉及到大量的前端開發，則Bug數會更多，目標要定低一點。在本次專案目標達成之後，下一個專案會定更高的目標。
更多精彩文章，點此閱讀
能打造出Facebook裡所提倡的"精英團隊"固然非常好，但這樣會對團隊中的每位成員都有較高的要求。我所在的團隊希望通過將團隊合作精神運用在專案的各個階段來打造出一支強有力的合作型小團隊，並且取得了很不錯的戰績：每兩週釋出一個版本，完成了幾次零Bug的專案，實現了一年線上零故障。
我們團隊由2名產品經理、6名開發人員和2名QA組成，並根據團隊特點量身定製了一套敏捷的開發方式。本文主要分享在需求、設計、開發和總結等階段中如何提高團隊成員的合作意識，從而形成團隊合力的最佳實踐。
需求串講評審
提倡需求串講。上游的質量決定了下游的質量。在軟體開發中需求文件屬於最上游的輸出，所以我們格外重視需求評審。為了讓團隊成員能充分理解需求，並提高團隊成員的參與度，專案需求不能總由產品經理來講解，而應採用輪流講解的方式，每次迭代由不同的人員講解。需求文件會提前發給所有團隊成員，請大家消化和準備。在進行需求評審時選某一名成員上臺講解需求。雖然需求評審最核心的任務是在"評"上，但如果團隊成員都不能很好地理解需求或者不能很好地參與到需求評審上，是很難做好需求評審的。
全員參與設計
為了提高設計和評審的效率，並且能夠讓全員充分參與到設計和評審中，我們團隊提倡結對設計、簡單設計、交叉設計和全員參與設計評審。
提倡結對設計。需求評審完之後，會讓團隊成員一起來認領任務，但每個任務必須由兩名成員認領，這兩名成員分別是這個任務的主Owner和輔Owner，並結對設計這個任務。
提倡簡單設計。第一是設計快並易懂，第二是隻做必要的設計。在設計評審前做的設計只能算設計草稿，用Visio等軟體做設計比較費時間，在設計評審後還要修改，如此反覆很浪費時間。而事實上一支筆和一張紙足以完成一次設計，先在紙上畫出自己的設計思路，然後同結對的成員進行討論，最後評審完之後將設計圖拍照提交到文件庫。對於網際網路產品的開發，提倡只做必要的設計，需要時再重構。因為根據以往的經驗，擴充套件性良好的業務設計通常會有三個問題：第一，設計和開發時間比較長；第二，程式碼不易讀；第三，大部分擴充套件以後都不會用到。
提倡交叉設計。為了讓團隊中每個人都能充分了解各個模組，所以在不同的專案中每個人負責的模組會不一樣。專案1中設計A模組的人，可能會在專案2中設計B模組。
全員參與設計評審。為了全體成員都能充分參與到設計評審中，我們制定了幾個固定的策略。
評審時間要短。因為大部分人在會議中只能專注20分鐘，所以設計評審要在40分鐘內結束，設計者可使用PPT或直接在黑板上畫出設計思路。讓參與者充分了解設計的模組。如果是對已有功能的修改，設計者必須先講這塊功能原來什麼樣，現在需要修改成什麼樣，涉及哪些修改點，是如何設計的。這能讓其他模組的設計者更瞭解這個模組，參與到這個模組的設計評審中。
如果設計方案審批沒通過，則需要設計者返工。為了提高效率，不需要再開一次會議評審重新設計的方案，將相關人叫到座位旁邊確認就可以。
結對Code Review
提倡結對Code Review。如果模組是由一個人設計的，那麼Code Review時審查者只能幫助隊友Review出程式碼中是否有壞味道，卻很難Review業務邏輯是否完全正確。因此，提倡結對Code Review，每個模組由兩個人設計，然後分開開發，最後交叉Code Review，這樣能Review對方程式碼中的業務邏輯是否正確。
提倡主動Code Review。結對的成員相互Review程式碼會存在一定侷限性，所以專案經理要對核心功能進行Review。如果團隊中有人提前完成功能，也提倡他們主動幫其他人Review程式碼。
程式碼審查的時間。在時間充裕時，提倡每天進行一次Code Review，好處是修改成本低。通常情況下，在提交測試前2天開始做Code Review，但如果時間比較緊，也會在專案結束後做Code Review。
尋求幫助的晨會
晨會通常用於彙報工作進度，而我們希望將打造成尋求團隊合作的會議。很多時候，專案質量低下主要是因為團隊成員開發時間不夠。如果某位成員實現某個功能發生了延遲，那麼他肯定沒時間寫單元測試，更沒有時間幫別人做Code Review。此時，就應該在晨會上將這個問題告知團隊其他成員。我們不會因某名成員實現功能延遲而責怪他，更不會讓他加班追趕進度，而是在晨會時請其他團隊成員幫他完成單元測試和Code Review。我們是一個團隊，有問題絕對不會讓團隊的某名成員獨立承擔。
不斷精進的專案總結
這些方法不是團隊建立之初就有的，是通過每次專案總結和下個專案實踐不斷精進出來的。在做專案總結時，所有成員都要針對本次專案的不足提出下個專案需要改善的地方，定出下個專案中可嘗試的實踐，並確定一位負責人和完成時間。
根據經驗，如果不確定負責人和完成時間，任何實踐基本都很難完成。另外，我們通常只定一個實踐在下個專案中執行，定多了也很難完成。而且為了讓大家能夠在專案總結會議中暢所欲言，通常會將專案總結會議辦成一個茶話會的形式。
為團隊質量而賭
在專案開始前，開發人員和QA會輪流坐莊，賭本專案的Bug數會是多少個，輸的一方要給贏的一方買飲料喝。這麼做主要是為了在提高專案質量的同時培養團隊合作意識。如果開發要想獲勝，那麼團隊中的每名開發人員都儘量不要產生Bug，避免拖累整個團隊，而團隊的其他成員為了實現目標會更加主動地幫助同學做 Code Review。但這個目標必須定得非常合理，如果專案中涉及到大量的前端開發，則Bug數會更多，目標要定低一點。在本次專案目標達成之後，下一個專案會定更高的目標。
更多精彩文章，點此閱讀