作品简介

高效能软件开发团队是任何组织能够持续交付价值的关键。本书主要介绍了高效能团队模式——团队拓扑,为组织设计和团队交互提供了一种实用的、分步的、适应性的模型,将团队视为交付的基础,团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。在本书中,IT顾问Matthew Skelton和Manuel Pais为读者展示了软件组织设计方面的重大进展。通过行业案例和专项研究,他们设计了一种良好定义的团队间交互和关联方式,这有助于软件架构更清晰、更持续,并将团队间的问题转化为有价值信号,为自治团队提供指导。

Matthew Skelton,从1998年开始开发、部署和运维商业软件系统,他曾就职于伦敦证券交易所、GlaxoSmithKline、FT.com、LexisNexis及伦敦政府。作为Conflux的首席咨询师,Matthew是2016年出版的Continuous Delivery with Windows and .NET和Team Guide to Software Operability两本书的合著者。Matthew拥有雷丁大学计算机和控制学专业的学士学位,以及牛津大学神经系统科学专业的硕士学位,并且他也是开放大学的音乐文学硕士,还是英国特许工程师(CEng)。在业余时间,他的兴趣是吹小号、参与唱诗班、作曲及越野跑。

Manuel Pais,是DevOps和持续交付领域的一位独立咨询师,专注于团队设计、实践和流程方面。他通过策略评估、实践工作坊和教练服务来帮助组织定义和实践DevOps与持续交付(包括技术方面和人员方面)。他是2018年出版的Team Guide to Software Releasability一书的合著者。

作品目录

  • 中文版推荐序
  • 推荐语
  • 译者序
  • 序言
  • 前言
  • 第Ⅰ部分 团队即交付
  • 第1章 组织结构的陷阱
  • 组织的沟通结构
  • 团队拓扑:一种全新的团队思维方式
  • 康威定律的复苏
  • 认知负荷和瓶颈
  • 总结:重新思考团队的结构、目标和交互方式
  • 第2章 康威定律为何如此重要
  • 理解并使用康威定律
  • 逆康威定律
  • 有利于团队协作流程的软件架构
  • 组织设计依赖于技术专家
  • 限制非必要沟通
  • 小心那些流于表面的康威定律
  • 总结:康威定律对于有效的技术团队设计至关重要
  • 第3章 团队优先的思维方式
  • 让小而美的长期团队成为标准
  • 良好设计的边界可以最小化认知负荷
  • 设计“团队API”和促进团队交互
  • 警告:工程实践是基础
  • 总结:控制团队认知负荷并促进团队交互来实现快速交付
  • 第Ⅱ部分 围绕工作流设计团队拓扑
  • 第4章 静态团队拓扑
  • 团队反模式
  • 为变更的流动而设计
  • DevOps和DevOps拓扑
  • 成功的团队模式
  • 选择团队拓扑需要考虑的因素
  • 使用DevOps拓扑促进组织发展
  • 总结:根据现状选择团队拓扑并持续演进
  • 第5章 四类基本团队拓扑
  • 流动式团队
  • 赋能团队
  • 复杂子系统团队
  • 平台团队
  • 避免变更流程中的团队竖井
  • 一个优秀的平台应该“够用就好”
  • 将常见的团队类型转换为基本团队拓扑
  • 总结:采用松耦合、模块化的四类特定团队类型
  • 第6章 选择团队优先的边界策略
  • 软件职责和边界中的团队优先方法
  • 不可见的单体和耦合
  • 软件边界或“破裂面”
  • 一个来自生产制造的真实案例
  • 总结:根据团队认知负荷来确定软件边界
  • 第Ⅲ部分 改进团队交互来促进创新和快速交付
  • 第7章 团队交互模式
  • 良好定义的交互模式是高效能团队的关键
  • 团队交互的三种核心模式
  • 每种交互模式下团队的行为特征
  • 选择合适的团队交互模式
  • 选择基本团队结构
  • 选择团队交互模式来降低不确定性并增加流动性
  • 总结:三种良好定义的团队交互模式
  • 第8章 根据组织感知进化团队结构
  • 什么样的团队交互是合适的
  • 加速新实践的落地和学习
  • 团队拓扑结构的不断演进
  • 组合团队拓扑追求更高效
  • 团队拓扑演进的触发器
  • 自组织设计与开发
  • 总结:持续进化团队拓扑
  • 结论 下一代数字化运营模型
  • 四类团队类型和三种交互模式
  • 团队优先思维方式:认知负荷、团队API、团队规模架构
  • 康威定律的策略应用
  • 进化组织设计以提升适应性和感知
  • 团队拓扑并非IT效能的全部
  • 下一步:如何上手团队拓扑
  • 专业术语
  • 推荐阅读
  • 致谢
展开全部