小型化全功能团队建设及运作思考

所谓小型化全功能团队，其成员人数应该控制在10人左右。团队作为一个整体，可以完全端到端的完成一个特性需求或一个独立的业务逻辑单元，cover住端到端的开发流程。所以，这就要求团队内的成员技能全面。要求团队成员可以覆盖住开发、测试、环境管理、持续集成等环节的要求。同时，还需要具备1-2名专家，他们技术能力强，技术的知识深度厚。可以在团队遇到关键问题的时候，解决技术难题，带领团队前进，同时鼓舞团队士气。这就要求团队成员既要有深度的技术知识储备，也要求有相应广度的技术知识储备。通过成员组成，达到互补的作用，这就使得团队具备了端到端完整交付的能力。

 团队的主要组成应该包括：1个leader、1个架构设计人员、1个敏捷辅导员（可以多个团队共享）、8人左右的成员（1-2人偏重测试）。

团队成员中的角色要求：

1、leader：团队的带领着，思考团队的定位，可创造的价值。为团队的发展提供前进的目标，也是配合外部交互的主要责任人，第一入口。主要配合产品经理规划产品，负责构建有竞争力的产品。同时，负责团队的运作管理，保障团队高质量、高节奏的完成交付任务。

2、架构设计者：负责产品架构的合理性和可持续发展性，其所负责的架构设计要满足：

1）产品当前的需求；

2）产品未来演进的需求，主要考虑架构的兼容性，以及面对变化的容忍性；

3）产品DFx方面的需求；

4）负责产品架构的核心代码或框架的编码。

同时，需要及时的审视当前架构的代码，识别风险点。结合当前的需求和演进识别主要的矛盾点。及时有效的对架构进行重构，保证架构的持续发展。

3、辅导员：负责运作流程的顺畅运作，对整个团队的开发过程进行监控，确保团队在良好的流程下运作。

虽然强调了架构设计者对架构的重要性，但是我认为并不是意味着架构就是完全由架设构建。实际上，团队成员都对架构负有责任，同时共同国建架构。好的架构师团队交付成功的关键，架设只对架构负有首要责任，并且在具有争议的情况下进行技术的选择和实现方案的决策。因为，架构师多样性的。每个人对技术和需求的理解是不一样的。在这种情况下，通过团队全员参与，群策群力保障架构的完整性。架设就需要在这种情况下及时明确方案（抉择）。这样的方式，团队所有成员全部参与。作为团队，按照一个整体进行运作。

开发人员除了要具备开发的素质外，还需要具备环境管理、持续集成构建、测试的能力。在面对一个分解的任务时，首先可以做到对其的分析和设计。在此基础上，进行单元测试的设计和实现，最后才是真正的开发。同时，开发还需要配合测试提供相应的测试建议和测试用例建议和素材。

下面再来谈谈团队的运作方式。我曾经尝试团队使用Pipeline的方式来运作。

 所谓Pipeline，就是一个交付的管道。一个需求orTask任务经过分析后满足入口条件，即可放入一个交付Pipeline中。一个Pipeline可以分配相应的开发人员，同时，分配的人员数量也就决定了这个Pipeline可以承担的工作量。Pipeline的周期，建议在1-2个迭代，不建议太长。通过Pipeline的方式，将全体成员进行了划分。Pipeline分配的需求，可以由Pipeline来自己选择。一个成员在归属于一个Pipeline内，如果Pipeline到期，则Pipeline的人员自动释放。团队设置多少个Pipeline，Pipeline的性质都由leader根据当前团队的情况决定。通过Pipeline就可以对开发过程做到可视化、精细化管理。设计Pipeline对Leader来说，是一种挑战和考验。设置Pipeline就体现了Leader对当前团队工作重心的体现。例如，在产品开发的初期。团队需要集中精力完成新需求、新特性的开发。这个时候，就可以将所有Pipeline都设置为功能开发型：可以承担新的特性需求任务的开发。而随着迭代的不断演进，功能不断的被开发出来。不可避免的会产生问题，这个时候，为了解决问题同时兼顾功能开发。就可以设置一半的Pipeline为问题修复型，一半为功能开发型。再后来，问题大面积爆发。这时，leader需要首要保证问题的修复。因此可能只保留1个功能开发的Pipeline，其他的全部为问题修复的Pipeline。通过Pipeline的动态设置，来应对团队在不同阶段需要关注的主要矛盾点和问题点，集中进行解决。

下面再来聊聊迭代，一个迭代周期建议控制在1-2周，太长太短都不利于团队的稳定运作。太短，会发现团队实际用于聚焦主要职责工作的时间太少（开发面临着需求的传递澄清、环境的搭建、CI集成等事情）。而太长，则又不利于对团队工作细化的监管和把控。同时，迭代中承接的需求的量级要足够小，以便可以在一个迭代中完成。同时，还要考虑一个发布版本周期内，完成特性的完整性。

 

除了考虑需求的量级，还要考虑需求之间的关系。作为一个Pipeline的输入，可以合并需求为一个需求包。要求，这些需求必须是清晰的，可交付的，可验收的。举例来说：1、提供业务Case的管理能力。如果把这个作为一个需求，其范围就有点大。而且，描述也不够清晰。虽然，可以通过提供描述的方式来附加说明。但是，我认为一个需求如果可以通过一句话来描述清楚。就证明这个需求是足够小，也足够清晰的。上例就需要进行需求的拆分，这里我拆分如下：1.1 提供业务Case列表展示功能，以列表视图展示当前系统内的Case信息；1.2 业务Case具备在列表上维护的功能，要求有删除、新建、修改属性的视图和功能。通过这样的拆分，就可以确保需求的粒度和清晰性，并在一个迭代中完成。总结一下，一个需求是否需要拆分，主要可以从以下两点来分析：1、是否可以在1个迭代内完成；2、是否完整，且描述清晰（一句话描述）。以上可以由团队和产品经理一起共同完成分析和分解。分析和分解的过程就是一个产品需求讨论和传递的过程，当满足后，需求就可以纳入到Pipeline的需求包中。

可视化和精益管理

 Task统计分析