在這個移動網際網路的時代，作為移動開發團隊，對「快」這個字看得尤其重要。不僅僅是移動開發團隊，其實每個開發團隊都在注重團隊效率，具體而言，就是關心開發效率和產出。管理者經常會發出這樣的提問：還能更快的上線嗎？還能增加每個迭代的產出嗎？
影響團隊效率的因素很多，且往往是綜合作用的結果，僅針對更快速的產品上線和增加每個迭代的產出這兩個問題，我們嘗試對團隊正在執行的敏捷迭代過程進行改進，即使用交叉的雙迭代模型進行軟體開發。
先簡述一下我們在傳統迭代上的基本情況。
我們的團隊是乙個android客戶端開發團隊，團隊角色有產品經理、互動設計師、視覺設計師、開發工程師、測試工程師。各個角色的職責不再贅述。從迭代啟動會開始，至交付可上線版本為止，定義為乙個迭代，通常的週期是3周。在這個3周的迭代週期當中，前半段以新功能開發為主，後半段以優化和bug修復為主，通過頻繁的開發、測試直至產出可上線版本。
隨著產品的快速發展，我們的發布速度還需要進一步提高，理想情況是縮短到每2周能有乙個上線版本。當然，不能因為時間短了就減少產出數量，還是要保持每個上線版本有足夠多的新功能帶給使用者。也就是說我們既要減少上線間隔，又要保持以前的產能。
帶著這樣乙個「又想馬兒跑，又想馬兒不吃草」的挑戰，我們需要找出此前迭代中影響這兩個因素的問題，然後再嘗試進行針對性的調整。
在這樣乙個十多個人的團隊中，我們注意到溝通成本是非常高的，客戶端產品的快速變化需要資訊在各角色之間共享和互通，並且形成一致的理解。站會同步的更多是昨天完成的情況和今天將要進行的工作，但今天工作中的細節仍然佔據了大量的溝通時間。即使在開發工程師內部，也會由於介面變化、聯調、**檢查等花費很多時間。如何有效的減少溝通，此前其實已經採取了一些措施，比如訊息群、郵件組、提倡面對面溝通等。但還是常常能聽到各角色抱怨「白天淨說話了，只能晚上加班」的話，這樣不僅消耗了迭代時間，也對產出有負面影響。
降低溝通成本的方法之一是拆分團隊，將大團隊變小，減少溝通的參與者，這樣是可以提高開發效率的，能夠做到花同樣多的時間產出更多的**。
另一方面，如果為了每2周上線乙個版本而將迭代週期縮短到2周，人少了，時間短了，就會在產出上有降低的問題。為了保證產出，在人少了的同時如果把迭代週期延長為4周，就可以做更多的開發工作。如果我們再讓兩個小組交叉2周，就可以保證每2周有乙個交付版本。
通過前文的分析，我們形成了如圖1所示的交叉雙迭代模型。
圖 1交叉雙迭代模型
我們將乙個開發團隊分為兩個小組a和b，a組先啟動進行為期4周的乙個迭代，即圖中的乙個sprint。在迭代進行到一半的時候b組再啟動為期4周的迭代，每個組各自做迭代內容的開發，形成交叉的雙迭代節奏。這樣從巨集觀上看，產品由每個小組交替發布，發布的週期是2周，每個小組的迭代週期由原來的3周延長到4周。隨著時間的推移，重複這個迭代過程。
經過這樣的迭代調整，從模型上看雖然滿足了版本更快上線並且包含更多功能的需求，但在實際實施過程中，我們也遇到了很多問題。
首先就是**管理的問題。由於兩個團隊都在做開發，最大的風險就來自於**合併。對此，我們分析之前迭代中的特點發現，大量**往往在迭代的前半段時間裡產生，到後半段往往更多的是少量的修改。因此，我們採用了主幹開發分支上線的方式進行管理。即啟動迭代的團隊使用主幹開發，當開發過半時，另一團隊將完成上線的**合併到主幹，合併後當前團隊從主幹拉出分支進行分支開發和上線，讓出主幹給即將啟動下一迭代的團隊。如圖2所示，b組啟動時在主幹開發，當a組完成上線後將**合併到主幹，此時b組將合併後的**開出分支用於迭代後半段的開發和上線工作，a組啟動新的迭代並占用主幹繼續開發。如此交替使用主幹開發，分支上線。
圖 2**管理示意
在使用svn的時候我們一直採用這一方式進行**管理，換用git以後由於分支的成本更低，我們變化了一些管理方式，此處可以根據實際情況進行調整。
圖 3交駐雙迭代實施前後的效果
還有對需求的理解一致性問題。現實情況當中，很多bug和無用功**於對需求的理解不一致，在使用兩個團隊以後，也依然存在跨迭代也就是跨團隊的需求。所以需求評審會是要全部成員參加的，一定程式上可以保證長期的需求有一致性的理解，每個人都要為需求承擔責任。我們也用這一方式來解決設計方案一致性的問題。當然，僅這一項措施並不能完全保證這一點，我們也在不斷探索。
另外站會的組織也是個問題。我們嘗試過兩個小組各自開站會，也嘗試過合在一起開站會，最後我們採用的是分另開站會但是各角色的負責人同時參加兩個站會的方案。一方面保證站會在溝通上的作用和效果，另一方面對跨小組的工作由負責人進行判斷和統一協調。
其他的問題還有很多，比如某個迭代遺留的bug怎麼辦？小組如何分？小組成員是否允許動態調整？這些都需要根據具體情況加以處理，本文就不一一解答了。
當然，任何模型都有適用的條件，也有不適用的情況，該模型也同樣存在一些不足。例如迭代週期延長不利於快速響應變化，對人員素質和能力要求較高，每個人的工作量都更加飽滿，**合併會產生新的bug，bug要跨團隊維護，交付時間相互影響等。因此，是否採用還需要仔細斟酌，本文也是拋磚引玉，不是說這個模型就是好的，一切都要從團隊的具體情況出發，剪裁出適合團隊的過程模型才是我們最終追求的目標。
總結一下這種交叉雙迭代的敏捷實踐，之所以能成功實施，需要全體角色的齊心協力，具備全域性意識和高度的責任意識，並且敏捷教練和各角色負責人能夠對開發過程進行有效管理及迭代間的資源協調，更重要的是對個體能力有更高的要求。如果沒有這些保障，在單一的迭代過程中還有各種複雜的人際關係，那恐怕會受到很大的阻力。
通過過程模型打造高效團隊，不但需要選擇合適的模型，而且需要長期持續的過程改進，促進團隊節奏感的形成，路漫漫其修遠矣。
敏捷團隊章程的實踐精要
無規矩不成方圓。任何乙個團隊都要有大家共同遵守的做事規則，這些規則定義下來就成為了國家的大政方針與法律法規 組織的管理方針和流程 團隊的章程或工作協議。對於敏捷團隊而言，也是如此。需要在團隊組建的初期，大家共同制定團隊的做事規則，並協商一致，共同承諾。有了團隊章程，團隊才能統一思想 統一價值觀 統一...
簡析敏捷在分布式團隊中的實踐
簡而言之，敏捷是一種新的軟體開發的思想，通過迭代 結對程式設計 測試驅動等實踐逐步完善對軟體的開發，最終形成穩定的系統。與傳統的軟體開發相比，敏捷強調人與人之間的溝通，而不是通過文件。這兒可以用kent beck martin fowler等16位業內權威的軟體人士在幾年前所做的乙個敏捷宣言來解釋 ...
簡析敏捷在分布式團隊中的實踐
簡而言之，敏捷是一種新的軟體開發的思想，通過迭代 結對程式設計 測試驅動等實踐逐步完善對軟體的開發，最終形成穩定的系統。與傳統的軟體開發相比，敏捷強調人與人之間的溝通，而不是通過文件。這兒可以用kent beck martin fowler等16位業內權威的軟體人士在幾年前所做的乙個敏捷宣言來解釋 ...