一个小团队分组的案例分析

某团队随着规模的扩大,人数接近了20人。现在想拆分成小团队,但是,不知道是把安卓(Android,谷歌的移动平台操作系统)和iOS (苹果手机、平板的操作系统)放一起还是分开?分开的话就变成了一个PO(Product Owner,产品负责人,可简单理解为产品经理)对应两个开发团队,所以倾向于放在一起。作为敏捷老司机,你怎么看?该给团队的领导提出什么样的合理建议?

有人说,建议分开,就算不分开也建议用不同的泳道。

有人说,我觉得可以分开啊,一个PO对两个团队,没啥问题啊。每个团队6到8个人,规模不大不小,觉得不错。平时带领的两个团队的早会,都是5个人到7个人,效率很高。

有人表示,一个PO对两个开发团队,完全没有问题。

一个PO对两个团队的话,就需要考虑,planning meeting要一起开吗?Product Backlog需要放一起还是分开?这又牵扯到了另外一个问题,他们做的功能一样吗?安卓平台的功能和iOS平台的功能要完全一样吗?

如果Planning meeting分开开,那Product Backlog也要分开。很多人觉得,Android跟iOS明明就是两个东西,两个团队,多亿建议按功能拆分,每个团队各个人都有。

但是,分开有分开的好处,也有不便之处。比如,如果功能完全一样,只是系统不同,那PO不是同一套东西要讲两遍?

所以又有人建议,按功能拆分团队,而不是按平台。如果功能没有那么大的不同,还要按着平台拆分,就没那个必要。按功能拆分团队,这样,一个团队里面,既有Android,又有iOS,还有后端,可以做到端到端的交付。但是,就算是做同样的功能,实现起来也不同,所以分拆出来的卡片必定不同。目前,团队做同样的东西,只是分iOS和安卓。

或许,可以同功能的应该放一起,或者同业务线的放一起,或者planning meeting 可以分上下半场。上半场由PO介绍功能,下半场各子团队分拆任务。这就带来了另一个问题,这个会要开多久呢?起码半天?

所以,物理上,分两个团队。对于非常类似的US, 可以两个团队一起开Planning meeting,譬如一起进行grooming(需求梳理)。

还有人认为,而且一般 Native 和 后端不会在一起, 后端和Native规定好协议模式,可以独立。通常后端团队都是分开的,定好API即可。这样就变成了,Android平台一个团队,iOS平台1个团队,后端开发1个团队。目前国内的一般创业团队标配都是这样。或者,20个人,一个团队7个人干活,  前端,后端,app端,测试等全包。大家共享资源做事情。

而事实上,20个人的团队在工作中,一般会有不同小团队合作得更加紧密。分2个团队,团队内部技能差不多匹配,联调就好很多。而且,现在就是里面又有前端、后端、测试等小团队。后端和前段的联调,如果api已经订好的话,也简单。

不过从敏捷和精益的角度看,团队的最小需求是团队能独立交付功能。如果Android和iOS要一起交付,那就需要把这两个平台的开发人员放在一个团队。能独立交付就可以组一个团队了。

团队之间的配合,那就是另外的问题了,共享Product Backlog、共享看板、接口挡板、物理纸条板等工具和方法都可提供帮助。

当然,要想敏捷,就得Just do it。先按功能分开试试,直接实验两个迭代周期,然后评估一下效果。如果效果不佳,可以果断调整为按平台分组,再尝试一下,实验2个迭代。直接试一下,两个迭代下来,再看看有什么问题。

还有,团队应该不是固定不变的,应该根据具体的需求、市场要求、交付要求等情况,动态地调整团队的分组、规模、人员配置、技能安排等。业界就有很多团队经常这样,一会拆分成小团队,一段时间后觉得做的东西需要多合作的时候又合并。就算是一个团队,有的时候进行回顾后,还要拆分成不同小组。反复进行,动态调整。

还有,上升到较高层面上,产品的策略是什么?组织的管理测试是什么?安卓和iOS的功能是不是一直都要完全一样?还是各自走原生尽可能利用各自系统的优势?都可以考虑。

总而言之,一切都要以目前市场、团队、产品的交付要求为准,快速、灵活、机动地调整团队的规模、人员安排、技能和需求。不应该一成不变地分组。

如此,才是真正的敏捷。

———— 全文完 ————