项目管理和团队建设

电玩女神 2022-07-12 03:56 285阅读 0赞

10、项目管理和团队建设

==前言：主要探讨移动项目管理、线上问题分析与解决、团队建设。

拆分需求若干次迭代、激励士气、控制风险。

==项目管理决定了开发速度

项目管理最忌讳的几件事：

1）：领导者高高在上，执行者欺上瞒下。

2）：理想美好但是不切实际。

3）：一次性改变太多，导致树敌太多。

无线项目的管理，与其他项目不同，它涉及到IOS、Android、Mobile API和QA团队的相互依赖、分工协作的事情。

(QA：质量保证，联系协调着：业务分析、开发人员、客户)

==项目管理中的三架马车

【

对于研发部门来说，一个完整的团队，应该包括产品经理、开发、测试这3个团队：其中

产品经理是三驾马车的灵魂。

开发团队是三驾马车的主力。

测试团队是三驾马车中的保证。

（互联网公司都走敏捷流程。）

】

==为什么不能没有测试团队

【

1）开发人员自测，只会按照自己编程的逻辑进行测试。

2）测试过多地占用了产品经理的精力。

3）测试工作不是产品经理的专长，有些情况测试不到。

4）产品经理对bug的关注度不够，反馈处理时效性不够。

=测试团队应该负担的工作如下：看，

\*全功能回归测试

\*探索性测试

\*渠道包测试

\*MobileAPI发布上线前的测试工作

\*压力测试

\*Monkey测试

\*客人投诉回访

==测试团队：一方面他们要对质量负责，另一方面，他们及时反馈迭代过程中发现的各种风险。

】

==产品经理应该做的事情

【

应该花80%的时间在需求上，以确保需求尽量清晰。

每日站例会

测试提出的bug，确定为产品问题，要重新定义逻辑或降低优先级，不予迭代。

验收需求

\-要突破成熟产品的借鉴，就需要在用户体验、运营策略上小功夫。

】

==开发人员的喜怒哀乐

【

开发人员，只有他们能把产品经理的想法或者尝试付诸实践，这才是其价值所在。

开发人员要想尽一切办法实现需求，而不是一天到晚发牢骚。

=开发人员抱怨最多的是:

1)一句话需求。

2)开发过程中，产品需求频繁变动。

3)产品经理搞不清楚业务逻辑。直到开发过程中才发现有问题。

4)UI设计图、切图、标注图不到位。

所有这一切，只能怪互联网公司节奏太快，不能像软件公司那样按部就班的工作。

】

==项目经理的职责

【

在敏捷流程中，项目经理也称Scrum Master：

1》项目经理不需要知道太多的业务逻辑，他只关心项目进度就够了。

2》一个团队是否高效，完全取决于项目经理的水平。

项目经理的事情非常琐碎，他不需要技术和业务知识，但是却一天到晚跟着项目进度走，和各个团队沟通，协调资源。几项职责入下:

1)搜集开发计划和测试计划。

2)主持每天的站例会，并发送会议记要。绝对禁止发送报喜不报忧的会议记要。

3)积极面对风险，及时调整计划，以减少风险。

4)及时解决各个地方的瓶颈。

5)推动bug的修复情况。

6)监督开发团队的冒烟测试、测试团队的探索性测试、产品经理的验收工作。

7)如果开发流程需要同步到jira，那么项目经理要负责创建Story和Task。同步项目进度。

】

==以上介绍了无线部门敏捷开发中各个团队的作用。

==优化团队结构，让敏捷流程跑的更快

【

应该不断地优化团队的结构和开发模式，不断尝试，发现好的地方要坚持，发现行不通，观察一两个迭代后果断撤回来，再去想别的办法。

1、平行模式还是垂直模式

==平行模式：就是Android、IOS和MobileAPI各自为一个独立的团队。在项目初期，团队间定制好MobileAPI接口的格式，约定好联调时间，就可以各自开工了。然后到了联调时间，再进行集成测试。

==垂直模式：就是按照模块，拆分出若干小的团队，比如说会员中心，就由一个小团队负责这个模块，有相应的Android、IOS和MobileAPI开发人员，以及产品经理和测试人员。

==运用垂直模式：垂直模式的开发模式使得这支团队非常高效。当App开发人员发现有个MobileAPI接口不能使用时，立马会与后台人员联调，测试人员发现问题，会跟踪问题从前端到后台，直到问题解决。所有人都对一个团队负责，为一个目标而努力。

==运用平行模式：拆分成若干个独立小团队的开发模式。并不能确保每个人都是熟悉所分到的模块；想做重构的时候，并不能确保每个小组进度一样。

教训：在团队没有成规模之前，不宜拆分。人多点即使要才分，也要一步步进行。

总结：从短期看，人少的时候，平行模式比较有优势；从长期看，随着业务规模的扩大，垂直模式是大势所趋。毕竟，对于Team Leader而言，手下超过6个人就会有管理上的问题。

2、让HTML5站点和MobileAPI的进度提前一个迭代

做了这几年的迭代，切身感受是，一个功能点，只要是MobileAPI和App同时开发，就会延期。而那些现成的MobileAPI接口，App开发人员可以直接拿来使用，一般不会延期。

可以尝试让HTML5网站先行，请他们去扫雷，回和MobileAPI早一个迭代把这个功能在HTML5站点实现了，下一个迭代再接入App。HTML5网站的特点是开发周期短，往往一个页面App需要1天，二HTML5页面一个小时就做好了。

3、如何进行模块化分工

模块化分工是一个需要长时间磨合、调整的过程。要确保"让合适的人做合适的事"

\--没太多技术含量的活，需要一个沙僧型任劳任怨的开发人员来负责。

\--重要的业务模块，要踏实勤奋的开发人员，确保质量并按时完成开发任务。

\--技术能力强的人，效率高，做有挑战的工作任务，比如说Monkey日志分析，线上Crash分析并修复。

\--沟通能力强的人，适合每天解决每天的用户投诉，从而准确定位问题。

】

==App敏捷开发流程

【

每个公司都有自己的开发迭代周期，有4周的，有2周的，也有1周的。

1、四周时间的开发流程

==巧妙安排迭代间隙

（敏捷开发的周期，包括从需求准备、排期、开发、测试到上线、发版，可长可短。

==需要做：

1)：总结上次迭代的若干问题。

2)：修复上次迭代来不及处理的Bug。

3)：做一些代码上的重构工作。

4)：讨论新需求，划分到具体的开发人员和测试人员，评估出工时和工期。这时要求产品经理的需求文档已经到位。

项目管理者需要去协调沟通的:

\--有些需求要求美工给出原型图和切图。

\--有些需求需要后端MobileAPI提供数据。

\--如果MobileAPI的进度比App的进度能提前一个迭代周期，那么就能避免App和MobileAPI并行开发所带来的风险。

5)：在迭代正式开始的前一天，开一个冲刺会，标志着本次迭代正式开始。

==控制4周迭代的节奏

1)：开始2周，是开发时间

==在开发时间内可能遇到额外的问题:

1》上一个版本发现了重大bug，要紧急修复并发版。

2》陆陆续续发现一些线上的bug，虽然不是很严重，但要放到本次迭代内修复。

3》产品经理经常插入一些紧急需求。

4》一些需求，临时决定本次迭代不做。

第二周周五，所有功能都已经开发完成了，也就是所谓的Code Complete.

2）：第三周，测试工作进入全面测试阶段，。

3）：第四周，这周主要是测试人员进行集中测试、探索性测试和全功能回归测试。

）

2、两周时间的开发流程

==迭代第1周：(周一：修复线上Crash 周一：需求确认会 周四：测试用例评审会)

==迭代第2周：(周三，Code Complete 周四，产品经理验收 周四，Bug日清 周五晚上，Code Freeze 周五晚上，小流量包)

3、一周时间的开发流程

4、即时更新策略

随时更新就要用到插件化编程和脚本技术了。插件化编程仅限于Android，这是一个庞大的主题。脚本编程就同时适用于Android和IOS了。目前业界普遍使用Lua，以手机行业用得最多。真正实现哪个做完发布哪个版本。

】

==项目经理的百宝箱

【

\--项目经理的任务评估表

（\*汇总产品经理的需求，形成一个excel。：需求名称、产品经理、需求地址、设计师、UI提供时间、MobileAPI接口负责人、MobileAPI联调时间、Android开发人员、Android工时、Android工期、测试人员、测试工时、测试工期

\*召开需求确认会，请产品经理为开发人员和测试人员讲解需求

\*搜集各个团队每个需求的负责人和工时、工期。

\*把每个Tesk都写到小纸条上，贴到敏捷白板上。

\*有些公司倾向于把所有Task都用Jira来管理，这就需要额外花一些时间去维护Jira。）

\--贴小纸条的艺术

（开工前几项内容：需求标题、开发人员、工时、工期、测试人员。

开发时间轴：BackLog：代办列表、Doing：开发进行中、CC：开发完成，等待测试、Testing：测试中、Done：测试完成。

）

】

==敏捷迭代中的会议纪要

【

敏捷开发过程中的四种必不可少的会议纪要及邮件：

\--第一种：站例会邮件

（1)：每个开发人员进度。

2)：提测功能，当天新提测的功能要用红色高亮显示，以区分之前提测的那些功能。

3)：UI和MobileAPI进度，列出目前还没有提供的UI和MobileAPI接口

4)：发现问题，包括新增需求、变更需求、开发计划调整，都应该在这里列举出来。

5)：风险评估，任何风吹草动，都要反映在风险评估中。

）

\--第二种：测试团队邮件

（测试进度和Bug情况：每个开发人员当天的剩余bug数量，每个测试人员目前还没有验收的bug数量。）

\--第三种：分析Monkey邮件

（每天下班前，开发团队和测试团队要执行Monkey测试，跑一个通宵。Monkey日志，尤其是崩溃，开发人员去修复。）

\--第四种：项目总结邮件

（每次迭代结束后，都要举行项目总结会议，请每个团队成员给出本次迭代做的好的和不好的地方各3点。）

】

==开站例会的技巧

【

1、早上开会效果会更好。

2、务必全员准时参加。

3、站例会控制在15分钟。

】

==如何确保项目不延期

【

过失延期有如下原因：

1）：估算工时过于乐观。

2）：中途事件突发，影响士气。

3）：新项目功能过多，近两个月的工时一次性评估风险很大。

对于开发周期过长的项目，做功能需求的拆分，多做几次产品的迭代，每个迭代都非常明确地完成一个固定的功能。

】

==迭代风险管理

【

举例：两周迭代开发，第二周的周三晚上，应完成所有的功能，称为Code Complete。如果这个点踩不到，就会延期。延期一般发生在MobileAPI。他们只是一个中间层，问题出在底层的系统上，包括搜索、产品搜索、产品信息、支付系统、会员体系等等，传统互联网公司的这些系统原型都是为网站服务的，不能直接搬到移动互联网上。

避免延期解决方案有：

\-1）：让MobileAPI的进度提前两周(一个迭代)。

\-2）：让HTML5网站先行，App下个迭代后续跟进。(前去"趟雷"，以确保App开发少走弯路。)

\-3）：MobileAPI还是要和App一起开发。那么MobileAPI一定要在开工前做好技术调研，需要提供哪些接口，用到底层哪些功能。

第二周的周四：做到bug日清，如果达不到，说明有风险。

第二周的周五：即最后一天，全功能回归测试及发版。

】

==迭代中的测试工作

【

不光是测试人员的日常测试工作，还包括开发人员组织的自测工作。

1、冒烟测试(真正的冒烟测试，是针对修复了一个bug而进行的一系列专门的测试。在开发人员空闲的情况下，把他们集中起来，围坐在一张圆桌上，把App的所有功能都测一遍，我们称之为“冒烟测试”。“冒烟测试”主要是解决测试人力不足、覆盖场景不全的问题。)。

新进的开发人员，无文档可供参考，让他们一起参加冒烟测试，每测到一个模块，就请该模块的负责人把业务逻辑讲一下。不光是培养了新人，对于长期做某个模块的开发人员，也是需要了解其他业务模块，而冒烟测试是最好的培训课。