Question

对于无线研发部门而言，一个完整的团队，应该包括产品经理、开发、测试这3个团队，我们称之为“三驾马车”。其中，

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

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

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

要想项目跑得快，一定要搞好三驾马车之间的关系。团队之间越默契，效率越高，质量越高。

我们需要为三驾马车配备一个驾驶员，也就是项目经理。因为现在互联网公司都走敏捷流程，所以又称这个角色为Scrum Master，他负责把三驾马车快速而平稳地驾驶到终点。

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

我见过有些公司没有测试团队，而是让开发人员自测，产品经理验收。这是一件非常不靠谱的事情，原因如下：

1）开发人员自测，只会按照自己编程的逻辑进行测试，很多时候，局外人——也就是测试人员，因看事情的角度不同，才能发现更多的问题。

2）测试过多地占用了产品经理的精力。产品经理应该更多地关注产品本身，包括页面转化率、用户体验，等等。其实他们只要在发版前验收一下需求（逻辑、UI）是他们想要的就可以了。而测试人员的工作就是一天到晚执行测试用例，想方设法发现bug。

3）测试工作不是产品经理的专长，很多情况，比如边界条件，就是产品经理测不到的地方。试想一个登录功能，产品经理的验收标准仅仅是点击登录按钮能进入个人中心就够了，而测试人员的测试用例却有50多个。

4）产品经理对bug的关注度不够，于是经常出现开发人员修复一个bug，但是产品经理几天后才会验收的情况——他们常常是把bug积压到一定数量后才批量处理，这样比较省事，殊不知这样的风险很大，如果最后才发现有bug并没有完全修复而此时又临近发版，那么就只能是项目延期或者忍痛屏蔽该功能了。

以上4点，是我这几年来作为项目管理者所观察到的情况，由此而验证测试团队在敏捷开发流程中不可或缺的地位。

一个好的移动团队，至少要有2名测试人员，开发和测试比大约是6:1。也就是说，1个测试人员对2个iOS开发人员+2个Android开发人员+2个MobileAPI开发人员。测试团队应该担负的工作如下：

·召开测试用例评审会——相当于需求二次评审。测试人员、开发人员、产品经理在会议上对需求达成一致。

·手动测试。

·全功能回归测试。

·探索性测试。

·渠道包测试。

·MobileAPI发布上线前的测试工作。

·压力测试。

·Monkey测试。

·客人投诉回访。

在很多公司里，因为过度强调开发团队的重要性，测试团队往往沦为附庸。于是，测试团队往往是被项目经理安排去做某项工作，而不是自主选择该去做什么事情。被动的久了，自然就形成鸡肋了。

测试团队应该在项目中有自己的话语权，一方面他们要对质量负责，另一方面，他们要及时反馈迭代过程中发现的各种风险，比如：

·当测试资源不足时，应该告诉项目经理哪些功能因为没有测试资源是不能上线的。

·在发版前如果发现bug很多，应该通知项目经理这次迭代的风险。要么延期，要么砍功能。但是决不能带着严重的bug上线。

10.1.2　产品经理应做的事

当产品经理不再承担测试的工作时，就应该把更多精力放在需求本身了。他们应该花80%时间在需求上，以确保需求尽量清晰，至少自己想明白了，才能让开发人员和测试人员也明白。

另外20%时间干什么呢？

首先他要参加开发和测试人员的每日站例会，这样才会知道开发人员在哪些需求上遇到了逻辑问题，从而及时做出调整。这个站例会很重要，如果产品经理不能保证每天都参加，有可能直到最后一天才告诉团队这不是他想要的产品。

其次，测试团队提的bug，经过开发人员分析后，发现是产品需求的问题，会将bug转给产品经理。产品经理每天都要检查分配给自己的bug，要么重新定义业务逻辑，让开发人员照此修改；要么降低bug优先级，本期迭代不修复。

验收需求。在开发工作结束、测试工作接近尾声时，产品经理要安装一个开发版App，验证实际开发出来的功能是否与他的需求一致。

最后，也就是发版前，产品经理要根据本次迭代的bug清单，根据测试团队的反馈，决定是否发版——bug太多可能会延期。

产品经理在项目中的职责很简单，就是定义什么是对的，然而很多公司为其赋予了太多的责任，比如他们要对项目进度负责，所以每天要组织站例会，他们要对项目质量负责，所以每天要进行测试。请问，这样的产品经理还会有什么天马行空的想法呢？用我老板的话讲，把产品经理当牲口使。

很多互联网公司在设计App时，都是把网站上的成熟产品搬到App上，这不需要太多的产品设计，所以把产品经理当牲口使这种策略一度是可行的。但随着网站内容和App内容渐趋一致后，如果还想在App上有所突破，比如App上的订单超过网站上的订单，这就需要在用户体验、运营策略上下功夫了。

10.1.3　开发人员的喜怒哀乐

我是程序员出身，也曾过着上班时穿拖鞋短裤的IT男生活。我深知技术男喜欢什么，不喜欢什么。

一个软件/互联网公司的成功与否，很大程度上取决于这些技术男也就是开发人员的存在，只有他们能把产品经理的想法或者尝试付诸实践，这才是其价值所在。

开发人员要想尽一切办法实现需求，而不是一天到晚发牢骚，说这个需求做不了那个需求做了也没用。值得欣慰的是，牢骚归牢骚，再苦再累，绝大多数一线开发人员还是会咬着牙把需求按时做完，诚然，熬夜加班是必须的。

这众多的牢骚之中，我听到抱怨的最多是：

1）一句话需求。

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

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

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

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

我在接下来的章节，就是要想尽各种办法，来解决这些问题。

10.1.4　项目经理的职责

在敏捷流程中，项目经理也称为Scrum Master。根据我多年做Scrum Master的经验，我的切身体会是：

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

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

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

1）搜集开发计划和测试计划。分配开发任务和测试任务是开发和测试团队各自的Team Leader的工作。他们会把工时汇总给项目经理和产品经理，然后由项目经理协调三驾马车，在规定的期限内，尽可能多的排进更多的需求。

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

3）积极面对风险，及时调整计划，以减少风险。这句话说起来简单，实际操作起来绝非易事，很大程度上取决于项目经理的经验。

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

5）推动bug的修复情况。

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

7）如果开发流程需要同步到jira，那么项目经理要负责创建Story和Task。为了提高开发人员的工作效率，项目经理可以在每天开完站例会，了解完所有人员的进度后，根据会议记要，帮助开发人员在jira上同步进度。

我个人是不喜欢jira的，因为操作起来太麻烦，不如Excel简单明了。不同项目经理有各自使用顺手的工具，半个小时内能完成同步进度的工具都是好工具。

8）项目结束后，召开总结会，好的地方继续保持，做的不好的地方，集思广益想办法解决。

以上介绍了无线部门敏捷开发中各个团队的作用，接下来介绍如何搞敏捷开发。