项目管理和团队建设

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的所有功能都测一遍，我们称之为“冒烟测试”。“冒烟测试”主要是解决测试人力不足、覆盖场景不全的问题。)。

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

     第一个迭代，冒烟测试差不多5次就够了，每天一个小时测试一个模块，保证了稳定性和保证iPhone和Android的数据展示和业务也基本一致了。

--会遭到质疑：开发人员更多的不是开发吗，怎么来测试了？

     1）：测试团队经常面临资源不足的情况，尤其是Android 和iPhone同时发版。

     2）：开发团队没有那么多的开发工作要做，因为产品团队经常会没有太多的需求。

     3）：App不同于MobileAPI开发。MobileAPI开发可以使用单元测试来保证质量，但App就很难做单元测试了。

     4）：App自动化测试就别指望了，那是大公司才愿烧钱去做的事。

2、探索性测试

（测试团队在新功能测试结束后，应该做一轮探索性测试。把所有测试人员组织在一起，逐个模块进行测试，可以每天一小时，分为3-4天进行。此外，测试团队所有成员都参与，可以保证每个测试人员对每个模块都熟悉，而不是长期只负责自己那个模块。）

3、Monkey测试

（Android项目每天下班前都要跑Monkey，然后每天会有专人分析Crash日志。Crash一般分为三种：

     1）：系统逻辑上的空指针。

     2）：系统问题，比如说不同手机ROM，问题也不太一样。

     3）：ANR。页面占用资源过多。（要把App中的电话拨打按钮都禁止、要确保Monkey能进入到App的所有页面、有很多页面需要用户登录才能进入、要把涉及支付的按钮都禁止，以防止在线上下单而造成的各种纠纷。）

）

】

==高层对敏捷流程的干预

【

     一般而言，一个敏捷流程是不需要总监级别的高层直接参与的。但是总监应该对敏捷流程适当干预，一方面要把握重构和产品的平衡，以确保一个“度”，另一方面则是要提高人力的利用率，可以从开发效率、座位安排、静时这些点入手，从而让团队始终有高产出。在

1、重构与产品需求的平衡

（一般会在两次迭代的间隙，来进行重构。另外，在迭代过程中，会有需求被砍掉或者弱化的时候，剩下的时间是来做重构的。

每次重构都要事先规划好：解决方案、工时、影响范围、测试方案

     好的重构方法是，拆分重构工作，循序渐进，每次做一点。这样既可以尽可能的完成需求，也可以降低重构的风险。）

2、提高效率，拒绝6*12

（疲劳作战后的表现为：战斗力急剧下降、质量下降，bug激增、脾气开始变得暴躁，容易发生冲突、每天就是在耗时间、上班越来越晚，午休时间变长。

     6*12适合于搞突击，但时间应该控制在3周以内。想提高开发人员的效率，还是想别的办法。

     8小时上班，除去其他时间，6小时是极限：

     -上班整理工位、吃早饭的时间

     -WC时间

     -饭后散步时间

     -午休时间

     -QQ闲聊时间

     -淘宝购物时间

     -各种被打扰时间

=作为负责人或项目经理应该注意以下几点：

     -要减少团队在QQ闲聊和淘宝购物上花费的时间，充分利用好这实打实的6个小时。

     -控制每个Task的工时，精细到0.5天。

     -减少被打扰时间。--静时。

）

3、无线部门的座位安排

4、静时，开发人员的时间被严重碎片化了。任何人都可能来打扰他们，比如说发现线上bug，比如说客人投诉、产品经理临时修改需求、领导视察等。屏蔽一切干扰，每周三下午的效率是最高的。

】

==总结--敏捷开发中的项目管理

【

管理学分两种：团队管理和项目管理。

--团队管理我推崇弱管理，别给团队成员加诸多的条条框框，给他们一个主题，让他们自由发挥。别让他们去做太多不擅长的事情。

--而项目管理我执行强管理，要清楚知道每个人每天的进度，以免劳动力的荒废。这时候需要一个强有力的项目经理来推进，以确保每次迭代能最大程度的完成需求，及时汇报剩余工时用于重构工作。

】