书籍介绍
高效能软件开发团队是任何组织能够持续交付价值的关键。 本书主要介绍了高效能团队模式——团队拓扑，为组织设计和团队交互提供了一种实用的、分步的、适应性的模型，将团队视为交付的基础，团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。 在本书中，IT顾问Matthew Skelton和Manuel Pais为读者展示了软件组织设计方面的重大进展。通过行业案例和专项研究，他们设计了一种良好定义的团队间交互和关联方式，这有助于软件架构更清晰、更持续，并将团队间的问题转化为有价值信号，为自治团队提供指导。
目录
用户评论
浅了，回避问题了
近期读过的非常不错一本书。它系统介绍了一套划分团队和团队业务边界的方法（Team Topologies团队拓扑）：第一，指导思想：康威（逆康威）定律、邓巴数字；第二，方法论：团队优先、四类基本团队类型、三种团队交互模式以及DDD；通过这个方法使得团队交互趋于良性，并确保了软件架构的可持续发展。最后，本书还援引了很多案例、论文进行背书和解释，使得组织架构这种容易抽象（虚）的话题变得更加生动、落地。我个人认为，如果敏捷方法是为小型团队和个人设计，那么团队拓扑就很好的回答了大型组织如何变得“敏捷”。推荐。
一般吧
这本书介绍了团队拓扑的概念，围绕4种团队类型和3种交互模式，目的是帮助组织打造高效能的团队。这个4+3就像E=mc2一样简洁，不同的是它不用推算就会让你觉得就这么简单的道理？
简洁并不是容易，不用怀疑它的能量。困难的是能够意识到什么时候该改变团队结构了。强有力的技术领导者，能够通过改变团队的交互模式来倒逼交付能力发生根本性变化。
陆止于此，海始于斯，大航海时代;
将认知负荷明确作为团队规模、分配职责和建立团队边界的有力工具。
团队之间沟通的健康度：“这种架构是否最小化了团队间的沟通路径？这种架构是否鼓励团队进行沟通？”
除了团队认知负荷的管理颇有意义，其他的不过是康威定律的展开而已，能洋洋洒洒四五百页也是不易，需要动态流式的管理团队拓扑和交互方式。
这本书能够引发我们的思考，对于一个研发系统，组织架构的设计准则是什么？ 如何能影响我们的产品交付。
书中基于康威定律说明了一个道理： 组织结构决定了其所开发的系统的架构。 醍醐灌顶，由此我们才终于明白我们在设计中的种种妥协，在交互沟通中的种种阻碍，根本原因取决于组织结构设计。
而组织结构设计也跟软件设计的准则高度相似， 高内聚，松耦合，并且团队遵循单一指责，避免复杂依赖。 我们可以把组织看成一个单体软件系统，那么组织结构的设计也就如同软件架构设计这般了。
团队目标和业务与产品当前所在阶段的外部环境，决定了团队需要动态地适应不同不同状态并由此调整团队结构与协作方式，来完成更高效的交付
个人感受内容一般，书中内容没什么真知灼见，应该稍大点的公司都已实践这些玩意，其实结果并不理想。
引用巨多，结论多，深入思考的内容确很少，组织问题还是需要社会学，心理学，经济学，哲学等深入柔和分析其本质才更有质量，当然内容实际价值不大。
另外翻译也不好读起来很费力
挺不错的，加深对康威理论的理解。四种基本团队拓扑组合，三种团队交互模式。
非常好，值得在实践中使用之后再读再去实践...
电子工业出版社的其他书籍查看全部
Z-Library
收藏