篇首語：個人技術再高，不懂得團隊管理是白搭；管理理念再先進，沒有在一線技術崗位奮斗過，也是白搭。
這篇文章主要分為三部分：
1.移動團隊架構設計
2.敏捷開發流程優化
3.團隊實踐Tips
懇請各位技術大咖和管理大師批評拍磚，感激不盡。
一、移動團隊架構設計
1. 團隊構成
一個完整的移動團隊包含四個部分，團隊Leader（項目經理）、產品團隊、開發團隊、測試團隊。
1.1產品團隊
產品團隊的主要精力始終應當聚焦于需求，聚焦于產品本身。而非測試、進度管控、質量管控等。
產品團隊在整個隊伍中的工作職責包括：
（1）明晰需求和交互邏輯，并且有效地傳達至開發團隊和測試團隊。每天跟進開發人員，掌控哪些需求是“技術不友好”的，是否需要調整邏輯。關鍵詞，每天，謹防到了發版前幾天才驚覺需求存在邏輯問題或者開發人員做出了并非產品團隊想要的東西。
（2）處理需求Bug。這里著重說明是需求類Bug，而非承擔測試工作或處理其他類Bug。測試團隊提出的Bug，經過開發人員分析后，如果是產品需求類的Bug，產品團隊需要分析Bug，決定是否需要重新定義業務邏輯。
（3）需求評審，制定交互設計規范和UI規范。
（4）需求驗收。開發完成，測試接近尾聲后，驗證最終的開發功能是否與需求一致。
（5）發版驗收。根據本次迭代的需求清單、Bug清單以及開發和測試團隊的反饋，決定是否發版，如果存在需求問題或嚴重Bug問題，則需要提議延遲發版。
1.2測試團隊
為什么需要單獨的測試團隊？
（1）不可以過多依賴開發人員自測。開發人員自測很多時候是根據自己編碼的邏輯測試，需要測試人員從其他角度發現問題。
（2）不可以依賴產品經理進行測試。產品經理應當更多關注頁面轉化率、用戶體驗、交互邏輯等產品本身的特性，而且測試非其專長，測試人員的測試用例才是測試依據。
（3）需要測試團隊高關注Bug。測試團隊可以第一時間驗收發現Bug的修復情況，確保發版前已發現Bug修復完善。
一個移動開發團隊開發與測試的建議比例為6:1，2個Android開發，2個IOS開發，2個MobileAPI開發，1個測試。測試人員在團隊中的工作職責應當包括：
（1）需求（二次）評審（測試用例評審）。產品經理、開發團隊、測試團隊應對需求達成一致。
（2）手動測試，包括正常用戶邏輯操作測試與非邏輯測試，如邊界條件下的測試。
（3）全功能回歸測試、探索測試、渠道包測試、MobileAPI測試、壓力測試、Monkey測試。
（4）用戶Bug反饋及投訴跟進及處理。
當測試資源不足，應該提議那些未經完全測試的功能不要上線，為團隊明確本次發版的風險，要么延期發版，要么暫且砍掉未完全測試功能，禁止帶著嚴重Bug發版。
1.3開發團隊
開發團隊是互聯網團隊存在的基石。這里不累述。開發團隊最忌諱的幾點，希望其他團隊留意：
（1）一句話需求。一句話需求讓老子如何開發，自由發揮嗎？
（2）產品需求頻繁變動。再變需求試試，信不信老子明天帶刀上班？
（3）產品團隊業務邏輯不清晰。不能做就滾蛋，工資給我，老子又干產品又干開發！
（4）UI設計圖標注不清晰。設計圖不標注，到時候UI驗收的時候，就別給老子逼逼屏幕適配不當的問題！
1.4團隊Leader（項目經理）
項目經理不需要關心具體技術實現，只需要清楚業務總體邏輯和項目進度。同時，項目經理對團隊是否高效有直接影響。項目經理的工作職責包括：
（1）制定開發計劃與測試計劃，如果開發團隊和測試團隊沒有Leader，也需要分配開發任務和測試任務。協調產品團隊、開發團隊、測試團隊，盡可能安排進更多的需求。每次迭代初期，項目經理需要完成的任務計劃包括：
- 需求名稱
- 產品經理
- 需求描述
- UI人員
- 基礎UI提供時間
- 后續UI提供計劃
- MobileAPI開發
- MoblieAPI聯調時間點
- Androd開發人員
- Android開發周期
- Android關鍵時間點及任務
- IOS開發人員
- IOS開發周期
- IOS關鍵時間點及任務
- 測試人員
- 測試周期
- 測試關鍵時間點及任務
（2）根據項目風險，及時調整計劃，并著重解決產品、開發、測試三個方面存在的瓶頸問題。記錄項目每個需求的時間軸，按照敏捷開發流程，會有如下幾個階段：
- BackLog：代辦
- Doing：正在開發中
- CC：開發完成，等待測試
- Testing：測試中
- Done：測試完成
（3）監督產品團隊、開發團隊、測試團隊工作職責的履行及工期計劃的合規情況。
（4）項目完工后主持總結會議，去偽存真。
2.架構設計
2.1兩種模式
移動團隊的開發團隊包括Android、IOS和MobileAPI三個團隊組成，主要有兩種架構模式：平行模式和垂直模式。
平行模式：即Android、IOS、MobileAPI團隊各自作為獨立團隊。項目初期，團隊約定好MobileAPI接口格式和聯調時間，就可以各自開工，到了聯調時間，進行集成測試。產品團隊與測試團隊也保持獨立。
垂直模式：按照模塊，拆分團隊。如將教育APP拆分成題庫模塊、課程模塊、直播模塊等，每個模塊配置一個小團隊，包含Android、IOS、MobileAPI等更小的團隊。同時將產品團隊和測試團隊也進行拆分，分配到每個模塊中。
對比兩種模式，進行利弊分析：
（1）需要根據團隊規模決定采取哪種模式。團隊沒有成規模之前，不宜拆分，應當采用平行模式。垂直模式有助于每個模塊的成員專注于自己的業務模塊，提高開發效率，但是一旦發生人員流動，就需要有新成員加入，其熟悉業務模塊開始到實際產生開發能力為止，需要時間周期長，對于小團隊而言，反而降低了效率。
（2）大團隊也不是采取垂直模式就一定能提高效率，需要看團隊的主要工作偏向。當團隊主要處于開發階段，采用垂直模式有助于提高開發效率。但是當團隊主要處于重構階段，就會產生問題。當計劃重構項目的時候，每個模塊的進度不一致，有的有時間重構，有的在做需求，有的在測試，很難推行重構。
（3）總而言之，短期看，小團隊采用平行模式優勢比較大。從長期看，隨著業務規模擴大，按模塊拆分小團隊，小團隊內根據工作內容再拆分更小團隊的垂直模式是大勢所趨。
對于團隊領導而言，管理寬度不是越廣越好，超過6人會帶來管理效率的極大降低。
2.2垂直模式的模塊化分工
任何一個企業級App，都會包含很多模塊。一旦團隊滿足垂直模式變革的要求，就要逐漸轉變為垂直模式。團隊Leader要確保每一個模塊都有1-2個開發人員非常熟悉它的業務邏輯，長時間在該模塊開發和維護。被分配到某個模塊開發的開發人員，在熟悉該模塊業務邏輯的前提下，還要清晰知道這個模塊包含哪些View（Activity、Fragment）、Model（Bean、Entity）、Controller（Adapter）。當然，在模塊化分工的時候，有一些Tips：
（1）用戶中心。這種模塊包含個人信息、訂單、錢包、操作記錄、系統消息、積分等零零碎碎的功能，通常沒有太多技術含量，而且繁瑣。最好安排技術實力一般、吃苦耐勞的程序員，也適合新人了解項目時安排的模塊。
（2）核心業務模塊。這里應當匹配最多的資源，同時準備預備人員可以調動。通常每次迭代核心業務模塊需求增加最多，需要最踏實勤奮的開發人員（勤奮老牛），同時線上每次出現問題都能及時處理，有一定的加班強度。
（3）實驗性模塊。這個模塊是公司最先進的技術實力的提現，需要那些技術實力最強，探索欲望同樣強烈的人，也可以滿足他們內心自我實現的需求。
二、敏捷開發流程
敏捷迭代中的敏捷的含義就是按時交付，不斷調整策略，即時開發并發布，做到資源利用率最大化。理想中的最佳情況是，隨時開發測試完成，隨時提交到線上，而不借助發版，這就需要用到插件化編程和腳本編程，這是龐大的課題，如果技術強大到可以實現，就不會有迭代周期這個概念了。
通常情況下我們沒有這個技術實力，兩行哥也沒有，所以繼續聊聊迭代周期的事。常見的開發迭代周期有四周和兩周，App迭代更新，修復線上Bug，增加新功能，不僅能提高用戶體驗，還能增加App在用戶面前的曝光度。一個完整的迭代周期內需要完成的工作包括：需求準備、工期安排、需求開發、內測群測、版本發布。
1.四周迭代的節奏
1.1第一周
四周的第一周主要是用于修復上版Bug、需求準備、工期安排，說明如下：
（1）總結上次迭代出現的問題，同時修復上個版本遺留的Bug以及上個版本線上發現的Bug。之所以上版本遺留Bug，是因為上個迭代周期可能由于工期不足未能修復，或者為了防止修復此Bug造成更加嚴重的隱患，所以留到下次迭代來處理。
Tips：如果上期迭代發現了重大Bug，需要立刻停止其他需求的開發，全力修復Bug并立刻上線。上線完成后，應當調整本期迭代需求，適當減少新需求，防止本期迭代工期不足。不到萬不得已，不要版本回退。
（2）盡可能做一些代碼重構。根據包式法則，產品需求永遠為最高優先級任務目標，完成需求之后剩余的時間才可以進行代碼優化及重構。而且代碼重構放在每個迭代周期第一周來做，主要是保證穩定性，留有長達三周的時間去修復及驗證重構后帶來的隱藏問題。
（3）產品團隊在開發和測試團隊做上述兩點的同時，可以準備初步的需求文檔。一旦需求文檔到位，整個開發團隊可以共同參加需求確認會，將需求劃分至具體開發人員和測試人員，工期評估也同時進行。如果測試資源不足，那就需要砍掉一些需求，確保上線的功能都是經過足夠測試的。
（4）工期評估完成后，需要著手解決App開發會原型圖、MobileAPI的依賴。UI團隊和MobileAPI團隊可以先行一步。條件允許的話，UI團隊和MobileAPI團隊應當比App開發團隊優先一個迭代周期，避免App和MobileAPI開發并行的風險。如果MobileAPI進度落后，可以暫時提供假數據。
1.2第二周至第三周
這兩周主要全力開發及測試。隨著需求被一個一個開發完成，測試工作也隨后開展。第三周周五，所有需求應當開發完畢，就算沒有開發完畢，只要核心需求開發完畢，就應當停止新需求開發，剩余需求最好延期至下個迭代周期，這個時間點稱為CodeComplete。這樣做的目的是為了保證最后一周測試工期不被耽擱。對于新插入的需求，應當評估其緊急程度，緊急需求列入開發計劃，并將原計劃的需求中非核心需求延期至下一次迭代。測試團隊的測試用例評審應當在第三周內完成。
1.3第四周
第四周進入全面測試階段。開發人員在前兩天要把高優先級Bug全部修復，確保本周Bug日清。有條件的話，測試團隊可以用腳本跑Monkey，并將Crash日志進行分析歸類。周三開始測試包應當趨于穩定，所有開發人員應當全部參與測試工作。同時，公司內部測試開啟，所有公司其他成員參與測試。在公司內部測試前，需要測試團隊發布簡短說明，明確本期迭代新功能，如何區分“需求”與“BUG”，Bug提交規范。周四晚上CodeFreeze，周五進行全功能回歸測試。不要指望自動化測試，對于中小型互聯網企業，需求變動頻繁，一個測試用例往往一個版本迭代后就廢棄，不值得投入大量人力物力去做。
2.兩周迭代的節奏
2.1第一周
第一周產品團隊講解需求，分配工作任務。周一開發人員會比較空閑，用來修復線上Bug。周二開始至下周周三共計7天用于全力開發與測試。所有的需求必須在這7天內完成，MobileAPI聯調也需要在此期間完成。測試團隊需要在本周周四及周五完成測試用例編寫。
2.2第二周
開發及測試會持續到本周周三晚，此時間節點CodeComplete，不在增加新需求的代碼。未完成的需求全部推遲至下個版本迭代。周四開始所有測試人員和開發人員進入測試階段，Android和IOS交叉測試。周四下午產品團隊對產品進行驗收，并且周四開始Bug日清。周五進行全功能回歸測試，當天只修復高優先級Bug，其他Bug推遲至下個版本迭代修復。周五晚上封版CodeFreeze。
三、團隊實踐Tips
1.讓開發人員參與測試
當開發人員完成所有的需求后，接下的一段時間的主要工作形式為：測試人員提出Bug，開發人員修復Bug。這段時間開發人員相對比較空閑，而CodeComplete之后也不應當安排新的開發需求。這時候應當每天找一段時間，將開發人員集中起來，將App所有的功能測試一遍。
A開發人員測試B開發人員完成的功能邏輯，B開發人員測試A開發人員完成的功能邏輯；Android開發人員測試IOS版本的功能，IOS開發人員測試Android版本的功能。對于找出Bug的成員，獎勵一份免費晚餐或者晚餐加一根雞腿都可以。這種做法主要用來解決測試資源不足的問題及迭代周期中末期開發人員閑置的問題。
2.靜時
靜時是軟件公司術語。對于互聯網公司人員而言，開發人員的時間被嚴重碎片化，任何人都可以被干擾，其邏輯思路被打斷。比如線上突然發現一個需要修復的緊急Bug，比如產品團隊突然提出一個緊急需求。必須將碎片化的時間連續化才能提高效率。
具體的做法是：每周有幾個下午，產品團隊、開發團隊、測試團隊關掉所有通訊方式，包括公司QQ、微信、線上通訊工具，不在進行溝通與交流，全身心投入自己的工作中去。產品團隊、開發團隊、測試團隊每個團隊靜時的時間不同，比如周一下午是產品團隊的靜時，周三下午為開發團隊的靜時，周五下午為測試團隊的靜時。但是這樣也會導致其他問題，如果確實有緊急情況而缺乏專人處理就是比較嚴重的問題。這時應該由每個團隊輪流指派1-2名值守人員作為對外的統一窗口，處理各種情急情況，或將緊急情況記錄，靜時以后再轉告專人。每天下午下班前一個小時靜時結束，團隊之間恢復交流，處理靜時階段的各種問題。最后記得在靜時實行前通知其他團隊，如果有緊急事項，盡早處理。
