第十章 移动端项目组管理

本文一部分书里面经验，一部分个人经验和见解：

人员配置

1. 产品经理；
2. 开发人员；
3. 测试。

一个测试对应2个ios开发对应2个android开发对应2个mobile api开发（我认为android至少应该比ios多一个研发人员，毕竟ios开发速度相对比较快，不用考虑各种兼容性问题）

测试的任务：

1. 召开测试用例评审会：我们以前是由产品，测试，开发老大来对需求进行统一。
2. 手动测试。
3. 功能回归测试。
4. 探索测试。
5. 渠道包测试。
6. MobileAPI发布前测试。
7. Monkey测试。
8. 客人投诉测试。

　　我认为即使公司再怎么不正规，流程不规范，至少1->6的流程是必须要走的。

　　测试组在上线前应该反馈项目测试的情况能否上线，不要将严重bug留到线上去。

产品经理的职责和任务：

　　书里面讲的比较模糊，就我个人认为

1. 要对要做的产品有深刻的理解。
2. 一定做好对应的原型设计。
3. 一定要出相关需求说明书，将产品的逻辑思路将清楚，帮助UI和开发在设计和编码过程中能够充分理解逻辑走向。

　　其实2,3点在我当前公司做的并不怎么好，但是上家公司做的很规范，开发和UI,以及测试都能根据相关原型对产品有比较深刻的理解，并减少不必要的误解（需求），减少不必要的沟通。

开发模式：

　　1，平行模式

　　　　团队分为android组,ios组,MobileApi接口开发人员组

　　2，垂直模式

　　　　团队是按照业务模块来分组，一个模块对应相关的产品，测试，MobileApi开发人员，移动端开发人员，好处是从前到后可以跟踪一个业务。

html5或者微信公众号优先app开发（我司开发现在就是这种模式）

模块化划分

　　讲讲我个人观点：

1. 技术能力强，效率高的负责基础架构的搭建
2. 一般模块开发人员定下来后，后期维护，迭代由该人负责，不要交给其他模块的开发人员
3. 负责某模块的开发人员应该协调mobile api设计，产品需求，bug解决等任务

　

---

移动端敏捷开发：

敏捷开发相对瀑布流模式来说是更加适合移动端的快速迭代和快速试错。开发周期相对比较端，一般在2周到1个月之间，小版本迭代开发周期为2,3周，大版本迭代在1个月到一个半月时间。（个人认为）

前期准备：

总结上次迭代的问题，可以说是项目的反思会议吧，以前经历过，主要针对上次迭代过程中出现的问题，包括沟通，包括协调，包括代码方面的反思吧，每人都反思出现的问题，然后提出必要的合理的方案措施避免下次迭代出现这类问题。

1. 修复线上bug(主要指的是类似umeng,bugly这类平台统计的bug),以及上次迭代预留在bugfree,jira或者其他测试提交的bug管理工具上面的bug清理。
2. 项目重构，我认为这个事情得看项目的紧急程度吧，如果项目时间比较充裕，或者一个大版本迭代完毕，有充分的时间的话，可以进行局部的项目重构，但是要注意新的bug的引入。
3. 需求讨论和项目开发周期，测试周期，ui出图周期的评估：(1)、大的需求讨论必须是在项目经理，产品经理讨论差不多的情况下才会召开需求评审会议的，(2)、需求评审需要产品讲解整个设计的思路和为了解决什么问题这么设计，并且应该针对不同的平台进行差异化的原型设计，不要将pc端或者微信公众号的原型设计思路带到移动端，导致不同平台的使用习惯上很糟糕的体验，当然在评审过程中mobile api设计可以从接口设计角度，后台开发人员可以从后台设计角度，ui从界面设计角度，移动端从用户体验以及应用逻辑方面提出个人观点进行讨论。(3)如果需求评审结束，是会存在部分未解决的问题的，这时候大的方向定了，小的细节可以由项目经理（移动端技术总监）和产品来进行局部的讨论。(4)开发周期的评估，一定要等UI出图以后再进行时间上面的评估，否则就是给开发人员留大坑，UI出来后，先定大的deadline,然后列excel文档，针对各个功能点进行拆分，由接口设计，后台开发，出图，开发时间评估，测试时间评估（我认为相对比较合理的），针对不合理的时间评估要尽可能的挤出不必要的水分，如果时间确实不充裕，可以将一部分不重要的需求放到下个版本进行迭代。
4. 开发中一般第一个版本是在svn或者git的主分支进行开发，如果进行版本迭代的话，上一个版本完成后要对主分支打tag并建立新的分支进行新的需求开发，等项目完成并测试可上线后合并到主分支上去。
5. 项目开发过程中插入的新需求，需要项目管理者针对需求的严重程度和优先级进行筛选，将比较紧急的   需求可以本版本开发，将优先级不怎么高的放到下个版本进行开发，避免新需求影响项目的开发进度和整体的产品设计。

项目经理的任务评估表

-_-!还没做到这个岗位，只能看看书里面的内容，做做总结：

主要是项目涉及到的人员的时间评估：

评估表里面设计内容：

1. 需求名称
2. 产品经理
3. 需求地址（wiki,pdf ,word）
4. 设计师
5. UI出图时间表
6. 移动端接口负责人
7. 接口联调时间
8. android开发人员
9. android开发工时
10. android开发周期
11. 测试人员
12. 测试工时
13. 测试工期

敏捷白板

 上家公司搞敏捷开发，弄过敏捷白板，这种适合所有相关人员在一个大的办公室比较好操作，如果分割在不同的办公区就不好操作：

小纸条内容：

需求标题，开发人员，工时，工期，测试人员

白板对应的列：

backLog :待办列表；

Doing:开发进行中；

CC:开发完成；

Testing:正在测试中；

Done:测试完成；

 除了实体白板其实也有不错的在线的工具提供类似服务：

风车：https://fengche.co/

worktile：https://worktile.com/search

---

还没完，明天继续

 敏捷开发会议纪要

• 站例会邮件。
  • 开发人员进度；
  • 提测功能；
  • ui以及接口的进度情况；
  • 发现的问题；
  • 风险评估，需求，bug，人员变动等风险。
• 测试团队邮件(小公司感觉没必要，反而显得有点过了，bug的情况以及数量可以在bugfree，jira等工具里面体现出来)。
• 分析monkey邮件。(小公司很少做monkey测试，建议用在线测试平台进行测试)
• 项目总结邮件。(有必要，是个反省的工程，避免重复踩坑)

开例会的技巧

• 其实就是了解项目成员的进度，可有可无的会议，看情况吧，晚上下班前或者早上来进行进度的了解，但是不建议每天开会，对于开发人员来说，真的是很超级烦这类会议，可以通过qq，或者公司内部聊天工具来了解项目成员的进度情况。
• 如果要开这类会议，书里面说是项目相关所有人员参加，我感觉没必要，应该是局部的例会比较好点，或者各个小组内部小例会，然后进行汇总。
• 当然同意例会时间不要太长，以免占用项目人员的工作时间。