敏捷漫画#认知负荷与团队拓扑

 

漫画翻译自Comic Agilé，已获得原作者翻译授权！

拥有定义明确、架构良好的产品，是为客户提供端到端价值的载体。对于许多组织来说，拥有一个可以开发每个产品而又对其他产品没有任何强依赖的团队，都是一个非常有吸引力的目标。

然而，在构建这些产品和产品团队之前，要考虑到市场对特定产品需求增加的概率和后果。问问自己，让更多的团队参与到某个产品的开发需要多大的投资。也许这是一笔很大的投资，也许只是一笔很小的投资，这取决于技术（technology）、能力（competency）、认知负荷（cognitive load）等，建议你在创建产品团队之前，做一下这样的讨论。

译者注：

作者谈到了在构建产品团队时要考虑三个要素：技术、能力、认知负荷，很多人对前两个要素是非常认同的，也是比较重视的，但是对于第三个要素“认知负荷”，却很少关注。

1988年，心理学家John Sweller将“认知负荷”定义为“工作记忆中使用的脑力劳动总量”。Sweller定义了三种不同的认知负荷：

1. 固有认知负荷，与问题领域的基本任务相关，比如：Java类的结构是什么样的？我要如何创建一个新方法？

2. 额外认知负荷，与任务处理的环境相关，比如：我要如何重新部署这个组件？我要如何配置这个服务？

3. 相关认知负荷，与那些需要格外关注学习和高性能方面的任务相关，比如：这个服务是如何与ABC服务进行交互的？

举例来说，开发人员对一个Web应用的固有认知负荷可能是所使用的计算机语言知识（如Java，C++等）；额外认知负荷可能是实例化一个动态测试环境的详细命令，这些命令存在多条并且难以记忆；而相关认知负荷可能是应用开发人员所关联的特定业务领域，比如发票系统或视频处理算法等。

一般来说，为了高效地交付和运维现代软件系统，组织应该试图最小化固有认知负荷，比如通过培训、良好的技术选型、招聘合适人员、结对编程等方式来实现。同时，要尽量消除额外认知负荷，尤其是那些没有意义的、冗余的任务和命令，这些保留在工作记忆中没有太大价值，并且通常可以被自动化任务取代。最后，为相关认知负荷预留更多的空间，这也就是“增值”思维的所在。

译者注：

作者谈到了在构建产品团队时要考虑三个要素：技术、能力、认知负荷，很多人对前两个要素是非常认同的，也是比较重视的，但是对于第三个要素“认知负荷”，却很少关注。

1988年，心理学家John Sweller将“认知负荷”定义为“工作记忆中使用的脑力劳动总量”。Sweller定义了三种不同的认知负荷：

1. 固有认知负荷，与问题领域的基本任务相关，比如：Java类的结构是什么样的？我要如何创建一个新方法？

2. 额外认知负荷，与任务处理的环境相关，比如：我要如何重新部署这个组件？我要如何配置这个服务？

3. 相关认知负荷，与那些需要格外关注学习和高性能方面的任务相关，比如：这个服务是如何与ABC服务进行交互的？

举例来说，开发人员对一个Web应用的固有认知负荷可能是所使用的计算机语言知识（如Java，C++等）；额外认知负荷可能是实例化一个动态测试环境的详细命令，这些命令存在多条并且难以记忆；而相关认知负荷可能是应用开发人员所关联的特定业务领域，比如发票系统或视频处理算法等。

一般来说，为了高效地交付和运维现代软件系统，组织应该试图最小化固有认知负荷，比如通过培训、良好的技术选型、招聘合适人员、结对编程等方式来实现。同时，要尽量消除额外认知负荷，尤其是那些没有意义的、冗余的任务和命令，这些保留在工作记忆中没有太大价值，并且通常可以被自动化任务取代。最后，为相关认知负荷预留更多的空间，这也就是“增值”思维的所在。

4种团队类型的关系

END

在大型企业实践敏捷转型的场景下，无论是敏捷的端到端产业研协同、产品边界划分，还是更好地理解团队构建、测试和维护其服务的难易程度，都没有办法回避团队的交互关系。团队的互动是影响团队向客户交付价值的速度和容易程度的重要因素。我们通过衡量团队的认知负载 ，帮助他们改变团队架构，改进团队的互动方式。团队认知负载这个概念给我们打开了一扇窗，通过团队拓扑的方法，在组织层面解决了以往单靠工程技术无法解决的深层次问题。

7月20日晚八点，来自顺丰科技的敏捷大咖邀您共话【认知负载与团队拓扑的应用实践】，感兴趣的同学赶快扫码预约观看吧！