第三部分 主要讲述了 项目进度的控制，日常工作中的问题解决、无线团队的组建与管理。

3.1 团队结构是平行模式好，还是垂直模式好

       垂直模式就是按照模块，拆分出若干小的团队，每个团队有自己的android、ios、api、测试组成，这种模式的好处是沟通效率比较高，app开发人员发现接口有问题，可以直接坐到api开发人员旁边进行联调，测试人发现前端bug,可以从app一路查到接口api，所有人都在一个团队中，对这个团队负责。

     平行模式就是按技能，将团队分为android组、ios组，api开发组。

     垂直模式对有些公司行不通，在垂直模式下，可能会造成人员分散，战斗力下降，还有个别组骨干离职，使得模式走不下去，而且因为android，ios人员分布到不同的组，无法有效组成代码重构。因此在开发团队没有成规模之前，不宜拆分，技术拆分，也要循序渐进，一次拆出1~2个人。

3.2  部分环节提前迭代

    app开发依赖产品需求、UI设计、接口api，如果并行，可能经常会造成项目延期。之前一家公司开始就遇到这种情况，都是同期开始开发，需求延期，造成UI延期，UI延期造成app 开发时间缩短，导致app不得不加班或者延期，结果可能又会导致测试组延期或者测试不充分。通常需求提前2个周期，UI、api提前一个周期，这样到了 真正app开发周期就可以直接拿到现成的接口及UI,一般都不会延期。

3.3 敏捷开发

   移动开发不同于传统软件开发，在每个开发周期中既要开发新任务，又要修复以往版本bug,或者处理临时需求变化，还有可能要做些项目重构工作，因为作为项目管理者要合理控制项目进度，把握开发节奏，减少不必要的加班。书中作者针对四周迭代节奏和两周迭代节奏如何实施及途中可能遇到的问题进行了详细的介绍。

   四周迭代周期如下图：

   

 在开发周期中可能会遇到一些问题：

1.上一版本发现重大bug，需要紧急处理。对策：调整一个低优先级的task到下个周期，解决开发时间和经历不足。

2. 陆续发现bug，不严重，但需在本次迭代内修复。对策：根据bug情况，对一般bug，本迭代期内修复，架构上的问题导致的bug排到下一期。

3.产品经理经常插入一些紧急的需求。对策：如果开发和测试团队都能消化这类需求，就本迭代期内完成，如测试团队时间不足，开发就开发新分支完成，下个迭代期合并进来。如果开发团队时间不够，消化不了，就可采取1中的方式。

4.一些需求，临时决定本次迭代不做。对策：这样开发人员就有了额外的时间，可以安排他们做之前拖欠的task，或者做些重构工作，但当测试资源不足时，重构工作开新分支，下个迭代周期在合并进来进行测试。

  如果想进一步的加快迭代周期，作者给出了两周迭代开发流程，如下图：

个人认为两周开发，版本迭代节奏过快，频繁的版本更新，对用户来说也不是好的体验。

3.4 日常问题的解决.

   1 使用二分法排查问题，作者举了个例子，android包某个功能6月30号突然不能用了，采用二分法，查看6月15号的包是不是好的，如果6月15号是好的，那就是15号30号某天出现问题，如果15号是坏的，可能115号某天出现问题，以此使用二分法查下去。

  2 找到能稳定重现问题的人。因为app 因机型或者网络状态、操作步骤不同可能会出现一些特定的bug,因此找到稳定重现问题的人对快速定位解决bug很有帮助。

  3 小流量包发布。作用可尽快收集用户反馈，减少发版频繁影响用户体验。

3.5 Gode-Review

 项目可以通过搭建Gerrit服务器进行代码Review，但移动开发周期过短，开发人员都疲于开发需求，没有时间去审核别人的代码，会出现以下情况：

  1 技术能力强且责任心强的开发人员，一天80%时间用于审核别人的代码

  2 技术能力强但是责任心差的开发人员，代码看都不看直接就审核过了。

  3 技术能力弱的开发人员，看不出代码问题。

  4 每次请别人Review都要等，这样开发人员倾向于每天下班前一次性提交所有改动，审核代码的人就更辛苦了。

 作者给出的解决方案是 

  1 老员工不进行代码审核

  2 对新员工和实习生 ，至少3个月内，对他们的代码进行Code-Review.

  3 定期找出有问题的代码大家共同解决和讨论。

3.5 其他：