篇首语：个人技术再高，不懂得团队管理是白搭；管理理念再先进，没有在一线技术岗位奋斗过，也是白搭。
这篇文章主要分为三部分：
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名值守人员作为对外的统一窗口，处理各种情急情况，或将紧急情况记录，静时以后再转告专人。每天下午下班前一个小时静时结束，团队之间恢复交流，处理静时阶段的各种问题。最后记得在静时实行前通知其他团队，如果有紧急事项，尽早处理。