高效能团队模式

https://weread.qq.com/web/reader/366323e0725a692a3666f4209-11

飞机上翻完。全是废话，车轱辘话来回说，翻译也极其拉胯。02-24

大多数组织都被软件交付问题困扰了多年，也就是新技术预期能解决问题但很少（或者从来没有）真正做到。这些问题包括游离的团队、技术和市场方面数不清的变化所带来的惊喜、与康威定律背道而驰、软件成长超出团队能力范围、说不清的组织设计选项和交付框架、团队牵扯进太多方向、几年一次的痛苦重组，以及落后的变更流程。《高效能团队模式》通过在软件交付方面推进团队优先方法，并且以四类基本团队类型、三种团队交互模式、交付过程中的应用之道来增强组织对周边的感知，这样有助于解决以上提及的问题。实际上，《高效能团队模式》呈现了一套良好定义的团队间交互方法，帮助软件架构变得清晰和更持续，将团队间存在的问题转化为有价值的信号，从而驱动自组织企业。08-03

康威定律：有什么样的组织架构，就会有什么样的软件架构。把一个软件交给四个团队合作开发，这个软件就会有四个模块。08-26

讲团队如何拆分和协作。要考虑团队认知负荷，要控制团队间相互依赖，让每个团队保持高效。配上现在流行的中台，微服务，devops 还是很有启发的。流动团队，我理解是价值流动团队，其实是一个稳定的团队，能够持续自主的交付价值。08-14

团队作为调配基础；康威定律；四种团队模式；三种团队配合方式；11-30

图形化表达很好看，也为未来这个方向演进做了铺垫工作。不过总的来说还是有点浅，从第8章开始，最后20%的内容才算是本书精华，一定程度上通过案例讲解了组织如何落实这些模型以及如何转变和演进的。10-21

行文和翻译都很流畅，很多案例。在经历过很多团队，需要理解团队、组织和软件交付的关系以及如何高效时很有帮助，尤其不能轻视的是平台团队、赋能团队如何与流式团队交互，以及如何组织或拆分这些团队。边界的划分和沟通效率很重要，及时察觉和调整演进也很重要。11-02

团队是交付的主体，对于复杂产品，高内聚低耦合的要求不仅针对软件架构，也是对组织的要求。04-30

有效的团队由7-9人组成，15人是一个人信任的极限。10-05

基于康威定律对架构的影响，总结介绍了四种团队类型、三种团队间典型沟通交互的模式，为团队组织设计提供了抽象模型和理论基础。总体来说来说值得一读。架构师和管理者的异同点引人深思，架构不再仅仅是技术上的事，团队组织结构将深深影响最终的宏观架构，想要做好大型系统的架构师，最终也必定需要组织和团队的管理设计能力。只有好的管理者，才能成为好的架构师。10-06

总结了一类最佳实践，有点啰嗦05-21

四种拓扑和三种交互在公司以前一个项目上全都体验过，这是一个高敏捷成熟度团队根据自己对于价值交付的理解而自发浮现出来的。因为翻译要扣掉一星，stream-aligned team翻译成流动式团队太有误导性了，会让人觉得人员流动很大，而实际上人员的流动和随意组织恰恰是一种反模式。10-27

四种团队拓扑结构: 流动式团队、赋能团队、复杂子系统团队、平台团队；三种交互模式: 协作、服务、赋能11-27

这段时间在思考什么样的团队模式对于我们部门才是合理的，前段时间读了两本偏通用型的管理学书籍，有些屠龙之技，并不能解决我们面临的困境：一方面大量的交付物要处理，同时要承担一些本部安排的开拓任务。如果两方面任务都要完美完成，那团队的规模势必要超过邓巴数字，如果拆分团队，则不满足公司的组织要求，如果只承担一方面工作，这对团队成员的成长是不利的。尝试着读了下这本针对软件开发团队的书籍，感觉和设计院的图纸交付有相似之处，有诸多可参照学习。11-13

团队目标和业务与产品当前所在阶段的外部环境，决定了团队需要动态地适应不同不同状态并由此调整团队结构与协作方式，来完成更高效的交付 02-13

挺不错的，加深对康威理论的理解。四种基本团队拓扑组合，三种团队交互模式。02-05