本书由日本敏捷管理领军人物渡会 健先生，基于15年的敏捷实践经验撰写，聚焦敏捷开发痛点，提炼来自敏捷实践的144个提示，内容涵盖敏捷基础、团队沟通、角色分工、成果交付、实践方法到高阶实践，从基础操作到跨团队协作等难题的针对性解法，帮助敏捷从业者快速突破敏捷困境，引导敏捷项目走向成功。 本书分为5章，是全面且实用的敏捷开发指南，为敏捷项目管理赋能，适合敏捷开发的初学者、从业者及管理者阅读和借鉴。 第1章 你真的了解敏捷吗 介绍敏捷开发的基本概念、敏捷宣言及其背后的思考方式，纠正对敏捷的常见误解。 第2章 团队沟通和角色分工 探讨如何提升团队沟通效率，明确敏捷团队中各角色（如产品负责人、开发团队、Scrum Master等）的职责。 第3章 敏捷团队的成果 讲解如何创建和管理用户故事清单、待办事项清单，以及如何确保可交付成果的质量。 第4章 敏捷的实施方法 介绍敏捷开发的具体实施方法，包括迭代计划、每日站会、任务看板、燃尽图等工具的使用。 第5章 高级篇：如何使敏捷更加完善 探讨多个团队协作、DevOps实践、敏捷合同等高级主题，以及如何借助外部专家力量提升敏捷实践。

10分钟速读敏捷的概述
敏捷背后的思考方式——敏捷宣言
专栏 敏捷不仅仅是Scrum
第1章 你真的了解敏捷吗
提示001 你真的需要“敏捷”吗
提示002 当“敏捷”成为最大的目标时，敏捷就会失败
提示003 在欧美，“敏捷是主流”并不是事实
提示004 “敏捷开发方法源于欧美，不适合亚洲文化”是错误的说法
提示005 不要害怕敏捷开发方法，已有许多成功案例可供参考
提示006 敏捷开发方法不是万能的（“换一种管理方法就能成功” 是不切实际的）
提示007 灵活应变≠敏捷开发方法
提示008 开始使用敏捷开发方法时，需要的不是标准而是指南
提示009 接受变更≠工作量无限增加，这是需要达成共识的事情
提示010 以瀑布式方法引入敏捷的悲剧
提示011 不要随意混合瀑布式和敏捷，混合管理很困难，原因何在
提示012 让自己从“一旦决定就很难改变”的束缚中解脱出来
提示013 在大多数情况下，必须接受从第一个迭代开始成果无法按计划达成的事实，否则很容易一开始就失败
提示014 在敏捷管理中，“允许失败”是有很多“学问”的
提示015 完全交由乙方的敏捷，注定会失败
提示016 被动参与的敏捷和被迫参与的敏捷
提示017 不了解敏捷宣言的后果有哪些
提示018 对于敏捷，你也许会认为即使没有开发经验也可以成功，这很奇怪
提示019 对于不熟悉敏捷的人来说，和有经验的人一起工作是最快的捷径
提示020 将敏捷应用于确定性高的项目而导致的失败
第2章 团队沟通和角色分工
2-1 如何使团队沟通更为顺畅
提示021 沟通是语言的接力，而不是理论的碰撞
提示022 当团队内部的沟通停滞时，从“我觉得你说得对”这样的 认同开始
提示023 有意识地创造闲聊时间
提示024 “有意识地查看”与“无意识地输入”信息共享的巨大差异
提示025 在真正意义上，将看不见的“信息”替换为可见的“东西”
提示026 会议主持人不应固定由Scrum Master担任
提示027 团队规则（工作协议）的细化和遵守
提示028 让第三方公司打成一片
提示029 对客户保持信息公开，没有任何隐瞒
提示030 导入课题管理系统
提示031 开发团队内不创建次级团队的真正原因
提示032 促进可持续性开发，并不意味着不允许加班
提示033 学会活用会议的节奏
提示034 如何在远程办公中也能实现“在一起工作”
2-2 敏捷团队中各自的角色
2-2-1 产品负责人
提示035 产品负责人真的只能有一个吗？团队制也是一个选择
提示036 产品负责人不是“客户”，而是一起工作的同伴
2-2-2 开发团队
提示037 起用代理产品负责人，关键是要让他能完全代入产品负责人的角色来进行决策
提示038 敏捷开发团队有很多事情要做
提示039 开发团队不必一开始就是多面手，他们会随着团队的成熟而逐渐成长
提示040 开发团队人数限制的陷阱
2-2-3 Scrum Master
提示041 Scrum Master不应该是敏捷团队的主角
提示042 Scrum Master的真正职责是塑造一个即便没有他也能持续成长的团队
提示043 为什么让Scrum Master同时兼任产品负责人是不好的
提示044 Scrum Master应该由产品负责人公司还是开发团队公司的人来担任
提示045 以现有的角色直接代入敏捷团队是不可取的
2-2-4 传统开发中项目经理的角色应该由谁来扮演
提示046 为什么要在敏捷方法中将项目经理的角色进行分割
第3章 敏捷团队的成果
3-1 创建项目核心的用户故事清单
提示047 需求定义书与用户故事清单的决定性差别
提示048 不是优先级，而是优先顺序
提示049 调整用户故事颗粒度的精髓
提示050 用户故事中必须写的和不能写的内容
提示051 用户故事和INVEST的陷阱
提示052 从MECE（相互独立，完全穷尽）的束缚中摆脱出来
提示053 怎样对用户故事进行拆分
提示054 用横向切分的思维得出每个迭代的可交付成果
提示055 如果在迭代中没能按计划完成用户故事应该怎么办
3-2 待办事项清单要以迭代为单位进行创建和废弃
提示056 待办事项清单与WBS的区别
提示057 怎么让产品负责人参与待办事项清单的创建
提示058 待办事项清单中需要写哪些任务
提示059 进度管理和适当的任务颗粒度
提示060 怎么处理突发任务
3-3 可交付成果与其质量
提示061 始终保持只有一个最新的“可交付成果”
提示062 确保产品质量
提示063 在敏捷中如何实现“共通化”
提示064 只要出现Bug就立刻将其修复是否真的有价值
提示065 传统开发和敏捷开发是如何确保质量的
提示066 如何缩小理想化的测试驱动开发与团队能力之间的差距
3-4 让估算成为计划的参照
提示067 估算在敏捷开发方法中的作用
提示068 由谁进行估算，这很