软件摩尔定律背后的几个常识（下）

减少信息传递过程中的偏差和损耗

有段时间“高中生编码”的说法甚嚣尘上。单纯从写代码的要求看，高中生也未必是不行，但有两个前提：

1、       前端的需求分析、架构设计和模块设计都是正确的，不需要返工，否则要等几个月甚至大半年，从后端发现问题再去修正，成本就高了；

2、       从分析、设计到编码，每个环节的信息传递都没有偏差和损耗。

可以说，这两点都不符合软件的生产客观规律。前端的分析和设计一定会存在错误，不同环节人和人之间信息的传递，一定会有偏差和损耗。全功能团队，就是减少这个偏差和损耗。

全功能团队有两层含义：

1、       可以做到独立交付，问题快速闭环，充分发挥团队的选择权（人、架构甚至编程语言等）和创造力；

2、       原有的角色分工，SE负责设计，MDE/SWE负责编码，TE负责测试。分工细化有利于专业化运作，各领域深耕。但也不可避免地带来扯皮、交接损耗，前期埋下的问题也得不到及时的发现和纠正。全功能团队打破这个分工，SE 负责价值分析和架构设计，特性模块级设计、编码、功能级验证都由MDE/SWE完成，TE 负责面向商用场景和客户的系统级验证。特性端到端负责，减少不同环节之间信息传递的损耗和偏差，减少浪费。

全功能团队的前提是特性解耦，不但是开发态的解耦，而且是运行态的解耦，解耦减少开发团队之间的等待和依赖。角色分工优化是减少开发团队内部的等待和依赖，还减少开发人员之间信息传递的偏差和损耗。全功能团队E2E 地负责需求分析、设计、开发、测试、交付，在全功能团队之外，还可以有个集中的架构师团队（AM），负责核心架构、运维框架、安全框架、分布式仓库等公共设计的编码，看护好全系统。

如果说服务化开发模式是从横向减少了开发者之间的依赖，那么全功能团队就是从纵向减少SE、开发、测试之间相互传递的依赖。早期推行全功能团队，困难重重。因为在传统敏捷开发模式下，难以做到运行态解耦，每个开发团队都要集成整个版本后才能验证自己的特性，从某种程度上是降低了效率。服务化开发模式，让开发团队的验证范围聚焦在自己负责的特性，极大降低了集成和验证的工作量，释放了真正的全功能团队的生产力。

减少对开发人员的干扰，让开发人员聚焦在编码

分时多任务并行处理是软件技术发展史上的一个革命，但对于软件开发人员来说，多任务并行处理不是一件好事。微软曾针对“工作打断”做过调查，一个人平均每小时有4次被中断，就会产生厌恶情绪，当中断超过3-5分钟后，需要花费23分钟把注意力重新调整已经分配好的任务上来。

为什么有那么多被中断？主要是几个原因：

1、       由于特性和架构的不解耦，开发人员在周边的协作、支撑和扯皮工作占比非常高。有统计说开发人员只有30%的时间在编码，70%的时间在忙于扯淡。电话、邮件、eSpace、线上会议等的便捷也让“中断”更加随意和低成本，但结果却是高成本；

2、       开发过程流的信息不自动，不透明，获取不方便，PL项目管理靠“肩挑手扛”，耗时耗力，在事务管理上的投入过多。PL 不编码，同时对员工的干扰也增加；

3、       精兵滥用。精兵因为优秀，处理各种事务都比较擅长，经常被滥用。各种攻关、定位、扯皮的事情占据了大部分时间，而让精兵真正投入特性开发的时间反而很少。

为减少被中断，架构上解耦是根本，但在解耦的过程中，有些管理手段也可以使用。比如：

1、       设置静默时间。静默时间内，UnPlug，不处理电话、邮件、eSpace、线上会议，不干扰开发人员，让开发人员每天3-5小时集中的核心编码时间；

2、       建立项目团队精益看板，实现团队所有任务的可视化管理、流动性管理、并拉动式开发。这样在计划制定时，不必是传统的任务分配式计划制定，而是根据价值优先进行拉动式开发；在项目任务跟踪管理时，也不必是传统的“盯人盯任务”管理，只需要通过可视化的看板，了解整体的特性/需求的进展情况即可；

3、       成立微战队，通过架构松耦合，组织适配，协作分工，把技术讨论和问题在更小的循环闭环，更快速有效。