特性团队实施迭代开发已经3年。中间经历了人员变动，各种集采，交付，项目认证等活动。现在团队已具备了快速交付的能力，但在成长的同时也遇到了一些问题，主要有这几个。
1.职责细分，入职门槛降低，但缺乏整体观，故障不断
现在一个需求的处理流程如图1所示:(待补充)
1)型号负责人输入需求，2)团队PO梳理修改点，3)DEV和TSE分析需求，4)TSE编写测试用例，DEV编写代码，5)QA做集成测试，6)特性团队向系统测试团队交付包含此需求的系统测试版本。至此，一个需求在团队内的迭代交付结束。
职责细分，让岗位门槛变低，也让每个环节变得可控。只要确定了每个角色的职责，人员能很快地胜任职位要求。这是管理带来的收益。但凡事有利有弊，每个角色像是流水线上的工人，来什么料，加什么样的工。每个环节只需要少量思考就可以完成，但也极度依赖上游工序的分析结果，只要上游环节出了问题，连锁反应会波及很远。
如果想要解决这样的问题，一是可以研发自动化生产工具和检查工具。将低智力、重复性工序交给机器完成。二是赋能和追责。三是成立设计师团队，负责设计。
2.管理成本高
团队人员组成主要是这样的:sm，po，ba，dev，qa,tse，ts，tpo。纯管理角色有:sm，po，ba。dev是直接产出代码的角色。tpo,tse,qa这些测试角色虽然很重要，但如果测不出bug，仅是验证性测试，产生的价值究竟有多少。
目前我们团队各种角色的人员占比是这样的:纯管理类5/25,dev9/25,测试11/25。
站在更高的角度看，项目组织架构是这样的:产品团队，开发测试团队，售后团队。
3.代码管理带来的困扰
因为几个团队产品相似，代码相似，因此考虑代码合并。现在一个团队的代码结构是如下图这样的。
(待补充)
为了和当前的组织架构一致，便于管理，我们采用的策略是拆库和共库。
1).把大库按组件划分拆成小库。
2).不同团队交付的产品，对相似度高的代码模块，如果是由组件团队维护的，则代码合并成一份，由功能宏控制。
这样操作的目的是为了减少代码量，减少团队之间的相似代码。遇到的问题是1)库太小，下代码繁琐。2)共库代码的管理，比如A团队改了代码，如何通知到B团队，并正确评估影响范围。
网友评论