高效能软件开发团队是任何组织能够持续交付价值的关键。 本书主要介绍了高效能团队模式——团队拓扑,为组织设计和团队交互提供了一种实用的、分步的、适应性的模型,将团队视为交付的基础,团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。 在本书中,IT顾问Matthew Skelton和Manuel Pais为读者展示了软件组织设计方面的重大进展。通过行业案例和专项研究,他们设计了一种良好定义的团队间交互和关联方式,这有助于软件架构更清晰、更持续,并将团队间的问题转化为有价值信号,为自治团队提供指导。
##讲团队如何拆分和协作。要考虑团队认知负荷,要控制团队间相互依赖,让每个团队保持高效。配上现在流行的中台,微服务,devops 还是很有启发的。流动团队,我理解是价值流动团队,其实是一个稳定的团队,能够持续自主的交付价值。
评分##no
评分##总结了一类最佳实践,有点啰嗦
评分##四种拓扑和三种交互在公司以前一个项目上全都体验过,这是一个高敏捷成熟度团队根据自己对于价值交付的理解而自发浮现出来的。 因为翻译要扣掉一星,stream-aligned team翻译成流动式团队太有误导性了,会让人觉得人员流动很大,而实际上人员的流动和随意组织恰恰是一种反模式。
评分##做软件的小伙伴都知道康威定律,即系统设计同设计它的组织的沟通结构保持一致。这本书更细致的分解了这个定律,结合邓巴数、团队产出来定义团队类型及沟通、交互。逆向思维:逆康威定律(Reverse Conway Maneuver):一个组织需要持续保持团队和组织结构的演进,从而实现理想的系统架构。 https://teamtopologies.com
评分##一般吧
评分##图形化表达很好看,也为未来这个方向演进做了铺垫工作。不过总的来说还是有点浅,从第8章开始,最后20%的内容才算是本书精华,一定程度上通过案例讲解了组织如何落实这些模型以及如何转变和演进的。
评分##四种团队拓扑结构: 流动式团队、赋能团队、复杂子系统团队、平台团队;三种交互模式: 协作、服务、赋能
评分##讲团队如何拆分和协作。要考虑团队认知负荷,要控制团队间相互依赖,让每个团队保持高效。配上现在流行的中台,微服务,devops 还是很有启发的。流动团队,我理解是价值流动团队,其实是一个稳定的团队,能够持续自主的交付价值。