Question

敏捷流程中，切忌僵化的团队组织结构。为了让敏捷流程跑得更快，我们应该不断地优化团队的结构和开发模式，不断地尝试，发现好的地方要坚持，发现行不通，观察一两个迭代后果断撤回来，再去想别的办法。本节我将介绍敏捷过程中的一些优化方案。

10.2.1　平行模式还是垂直模式

由于移动互联网的开发模式有别于传统互联网——它是由Android、iOS和MobileAPI三个团队组成的，所以选择什么样的开发模式是很有讲究的：

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

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

这两种模式我都尝试过，分别介绍如下：

1.垂直开发模式

我曾经做过一个B2C项目，使用的就是垂直模式。团队10个人，其中：

·1个产品经理。

·1个项目经理。

·2个Android开发人员。

·2个iOS开发人员。

·2个MobileAPI开发人员。

·2个测试人员。

这个项目做了2个月，延期4天上线，排除掉过程中遇到的很多不可抗因素（比如公司的新人培训、测试环境的不稳定性，等等），算是一个比较成功的项目。

我一直在思考这个项目成功的原因，因为之前做的很多项目都要延期很久，其中有一点非常关键：垂直模式的开发模式使得这只团队非常高效。当App开发人员发现有个MobileAPI接口不能使用时，他会抱着笔记本坐到MobileAPI开发人员旁边的座位上，一起联调，直到解决问题。测试人员从前端发现bug，会从App往下一路查到MobileAPI，直到bug修复。所有人都在对一个团队负责，为一个目标而努力。

2.平行开发模式

仍然是上述这种拆分成若干独立小团队的开发模式，在其他公司却行不通。我们虽然将开发团队按照业务模块拆分为若干个独立小团队了，但是战斗力并没有得到加强，因为拆分前并没有确保每个开发人员都熟悉自己所负责的模块。后来，有开发人员离职，随着2~3名技术骨干的离开，这种模式就走不下去了。有些组只剩下一些实习生，难以维持下去，只能合并到其他组。

另一方面，由于Android和iOS开发人员被分散到各个组，以至于我想做重构的时候，每个组的进度不一致，有的组有时间，有的组还在做需求，导致重构的事情推不下去。

于是，我们又退回到平行模式，重新把团队按照技能划分为Android、iOS和MobileAPI团队。

由此而吸取的教训是，在团队没有成规模之前，不宜拆分。这就好比一只手有五根手指，攥成拳头打出去才有力量。另一方面，即使是要做拆分，比如一支10人的Android技术团队，也是每次拆分出2个人，一步步的进行，而不是一下子就把10个人拆成5支2人团队了。

每次拆分出的这2个人，就雷打不动做这个模块了。不能说哪天其他模块没人了，把他们调回去，临时支援1~2周，这是不行的。必须把人固定在模块上，才能培养出这2个人的业务知识。

介绍完上述两种开发模式，可以观察到适用于无线开发团队的开发模式。从短期看，人少的时候，平行模式比较有优势；从长期看，随着业务规模的扩大，垂直开发模式是大势所趋。毕竟，对于Team Leader而言，手下超过6个人就会有管理上的问题。

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

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

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

10.2.3　如何进行模块化分工

任何一个企业级App，都是由若干个业务模块组成，比如说会员中心、美食、电影等等。我们要确保每一个模块都有1~2个开发人员非常熟悉它的业务逻辑，长时间在该模块上开发和维护。

我见过10人的Android开发团队，因为没有明确的业务模块分工，导致每次迭代，负责开发某个功能的开发人员额外还需要1~2天熟悉代码和业务的时间，直接导致了开发效率的下降。

当模块化工作落实到每一个开发人员身上时，你会发现，每当产品经理提一个需求，比如说美食模块，那么Android开发、iOS开发、MobileAPI开发、产品经理、测试人员会自发组建一个QQ群，在里面讨论、沟通该功能点的所有事情，直到开发完成、测试人员和产品经理验收通过。他们会协调时间，以确保该需求准时完成。

在模块化的实际操作中，被划分到某个模块的开发人员，不仅仅要熟悉该模块的业务逻辑，从代码角度来说，还要清晰地知道该模块包括哪些Activity、Adapter、Entity和其他一些类。我们在第1章1.1节介绍过，要对项目进行重构，把项目按照业务模块进行组织，也是基于这个目的。

模块化分工是一个需要长时间磨合、调整的过程。我的切身体会是，要确保“让合适的人做合适的事”，比如说：

·并不是每个人都能接手“会员中心”这个模块的，这个模块包括个人信息、各种订单信息、消息盒子、充值、红包、积分等等很零碎的功能，通常没有太多的技术含量，而大多是脏活累活，所以需要一个沙僧型任劳任怨的开发人员来负责。

·对于公司最重要的业务模块，要委派踏实勤奋的开发人员，踏实是确保质量高，不会犯愚蠢的错误以至于影响公司生意，勤奋是确保任务做不完时能加班。因为往往这块业务每次迭代都有大量的需求，所以还要配备候补开发人员，以备不时之需，从而才能消化所有的需求。

·技术能力强的人往往效率要高于其他开发人员，所以要经常把有挑战的工作交给他们去做，比如说Monkey日志分析，比如说线上Crash分析并修复。

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