的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁平化、网络化的特征。
然而重新思考图6-16所示的全功能团队，你会发现，在很多情况下，在最低层级组建上图所示的全功能团队并不现实（什么是最低层级？意思是该单位不会再有下级单位），出于沟通效率的考虑，一个单位的成员不能够无限扩大，在传统的管理书籍中（法约尔），这个约束甚至被建议为5人。在很多制造型企业里，这个人数实际上是大大超出这个限制的，原因就在于标准化。然而，在知识密集型企业里，因为并没有一致的标准能够遵循，单位成员之间必须面对面沟通以协调彼此的工作，那么单位规模必须足够小，小到便于所有成员能够做到适宜、频繁和非正式的沟通。所以，对于一个软件项目而言，一个小于10人的全功能团队是最适合的，一旦团队规模超过20人，那么就必须进行再分组。对很多软件开发而言，他们需要的人数远超20人，那么这种最低层级上的全功能团队就不再适用。
如果工作流程上的各个单位构成顺序依赖的关系，则是次优解。在这种情况下，每个单位仅仅对其上一个单位产生依赖，单位之间的协调较少。如图6-17所示，可以看出这是一个典型的以职能进行分组的组织，这样的分组至少看上去并不坏，但是现实却是：这是一个相当没效率的分组。原因就在于该分组基于一个重要的假设：开发流程中的任务是可以分阶段完成的即瀑布开发模型。现实中，这个假设却是完全不成立的，这些任务联系的如此之紧密，以致于在这些单位之间不得不时时发生大量的协调。于是该分组实际是下图6-18的样子，最差解！
如果工作流程上的各个任务需要跨越多个单位进行反复协调沟通，那么则是最差解，称之为交互式相依。在我观察过的一个组织里边，测试人员发现软件缺陷后的第一反应不是走过仅仅一屏风之隔的开发小组里进行沟通，而是先填写在线的缺陷跟踪系统，然后再打开即时消息工具，给开发人员发消息：有缺陷，缺陷号是xxx。组织在进行分组时，必须寻求将协调和沟通的成本降至最低。
工作方法相依性。
即使用相同工作方法的人员分到一个单位，通常也就是职能分组。这种分组的好处在于能够激发方法的互相交流，也就是专业性，同类专家分到一起之后，他们能够互相交流，提高各自的专业水平。在现在公司里，经常能够看到不同团队成员之间的非正式交流，这里，其实是公司整体的文化氛围为这种交流提供了便利。实际分组时，需要在工作流相依性和工作方法相依性间做出权衡。
规模相依性。
第三个标准与经济规模有关。考虑这样一个例子，软件的测试需要真实的硬件环境进行模拟，而这些硬件比较昂贵，那么一个最经济的方式就是成立专门的测试部，统一购买一批硬件，统一对所有的软件进行上线前测试。同理，由于DBA比较昂贵，公司不可能为每个团队都配备一名，所以DBA不属于任何团队，其是共享的。
社会相依性。
第四个标准与具体的工作没有关系，与人的社会性有关系。如果领导没有头晕，他是绝对不可能将两个水火不容的人放置到一个单位内的（帝王除外，那叫帝王术）。
以上就是组织进行分组的四种标准。归纳一下：如果工作流相依性意义重大而又难以纳入标准的话，那么组织就应该尝试以市场（项目）为基础进行分组，这样便于相互调节和直接监督；如果工作流不规则，标准化能够涵盖工作流相依性，如果方法和规模相依性意义重大，那么组织应该积极寻求专业化，以职能进行分组。
最后，我们讨论一下大规模软件团队的分组，在上面我们提到，一旦人员规模超