[
-
内容大纲
本书由日本敏捷管理领军人物渡会 健先生，基于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 由谁进行估算，这很重要
提示069 估算需要开发团队全员一起来做的理由
提示070 估算的基准是“过去的我们”
提示071 在敏捷中为什么广泛使用计划扑克
第4章 敏捷的实施方法
4-1 通过沟通和时间管理来促进团队运作
提示072 为什么越是生产效率高的团队，越会花时间进行沟通
提示073 如何确定最适合自己团队的迭代周期
提示074 并不是说因为是敏捷所以不按时完成也没关系。如果不进行反省和改进，那就只是单纯的拖延
提示075 迭代计划与日历之间的关联
4-2 迭代开始前需要做的事情
提示076 不做“迭代0”的敏捷在起步时就会遭遇困难
提示077 项目启动蓝图不是成果，而是让团队成员之间达成共识的工具
提示078 项目启动蓝图类似于项目计划书，但并不完全相等，并不是越详尽越好
提示079 项目启动蓝图不能做完后就搁置不管
4-3 对于敏捷来说，计划也很重要
提示080 迭代计划会议的规划
提示081 做迭代计划，等于在做群体设计
提示082 要记住在敏捷中，设计的时机和实施与传统方法有着根本的不同
提示083 不要把迭代计划会议分段执行
提示084 为什么与其他团队比较Velocity数字是没有意义的
提示085 价值实现效率大于开发效率
提示086 迭代计划并不是敏捷中唯一的计划，全体计划也很重要
提示087 对“如果不发生变化的话，会产生怎样的效果”进行持续展示的重要性
4-4 通过每日站会来找出变化
提示088 如果团队成员开始说“进度比计划的要慢”，那就是一种危险的信号
提示089 任务不应该靠“推”，而要去“拿”
提示090 “一直没有异常”本身就是一种异常 ，其原因是缺乏心理上的安全感
提示091 每日站会中的三个问题的利与弊
提示092 为了在每日站会中不错过变化，需要做什么
提示093 在迭代实施过程中，任务的增加真的是不可接受的吗
4-5 熟练应用任务看板
提示094 要注意任务看板上的优先顺序
提示095 迭代结束时如果任务看板总是呈现相同的状态的话，则是一种异常
提示096 在任务看板上，应该只在进行中的任务上注明其责任人
提示097 看得到进行中的任务状态的话，就能看到成员间的工作分布不均
4-6 燃尽图的具体改进方法
提示098 举例说明可以通过燃尽图发现的异常
提示099 燃尽图不仅仅是用来观察进度的
提示100 燃尽图的利与弊，以及如何活用燃起图
提示101 燃尽图的纵轴应该是任务数量还是估算点数
提示102 可以从微笑日历中获得的信息
4-7 关注任务的执行，以求能够确实地实现可交付成果
提示103 10分钟规则（有不明白的事，立刻向知道的人询问，要打造这样的文化）
提示104 在敏捷开发中如果不进行重构会怎么样
提示105 开发团队的效率提升取决于产品负责人是否能当机立断（即使决策错误，也可以在下一个迭代中修正）
提示106 不给成员选择的余地，强行推动配对工作或群体工作是危险的
提示107 只是导入敏捷工具、实践或活动的话，并不能实现真正的敏捷
提示108 配置管理是敏捷的基础
4-8 怎样的成果反馈能让可交付成果变得更好
提示109 成果反馈不是进度会议（只展示已经通过测试的内容）
提示110 当成果反馈变成由产品负责人或利益相关者进行的审查会时，该如何突围
提示111 成果反馈不是用来进行公开测试的，获得反馈才是真正的目的
提示112 在成果反馈中进行追责只能换来沉默的结果，试着传达一下感激之情吧
提示113 让产品负责人来担任成果反馈主持人的意义
提示114 要让全体成员都参加成果反馈
4-9 通过回顾促进团队成长
提示115 如果停止进行回顾的话，那么团队的成长也会一并停止
提示116 在微弱的声音中往往隐藏着对团队有帮助的意见
提示117 在回顾中要注意Try的欠债。在下一个迭代中确实能执行的，才算完成
提示118 一开始从个人层面出发即可，随着对回顾的熟练，再逐渐 过渡到团队层面
提示119 通过KPT确保心理上的安全感
提示120 为什么KPT模板在回顾中如此流行
提示125 精炼的结果不能只体现在团队内部，不能每次都与利益相关方分享的话就是失败的
第5章 高级篇 如何使敏捷更加完善
5-1 多个团队共同创建一个产品
提示126 在团队划分上的反面教材
提示127 成果反馈和回顾应该共同进行
提示128 专家应该与开发团队一起参加活动
提示129 小型产品的开发可以考虑组建联合团队
5-2 开发和运维都让同一团队负责
提示130 为了实现产品管理目的而进行的DevOps
提示131 如何保持开发和运维的平衡
提示132 为传统的运维团队导入敏捷，以实现工作方式改革
5-3 敏捷与合同
提示133 为什么敏捷合同基本上采用准委任的方式
提示134 学会利用个别合同实现敏捷
提示135 如果甲方和乙方的关系是对等的话，就不会被视为虚假承包
5-4 敏捷的理想与现实的解决方案
提示136 发布迭代的利与弊
提示137 Velocity数字应该保持稳定还是继续增加
提示138 敏捷中的KPI是Scrum Master能够体现价值的地方
提示139 应该专注于什么才能高效地推进（资源效率与流程效率）
提示140 守破离的误用。为了不让打破常规变成不伦不类，我们应该怎么做
5-5 借助外部专家的力量
提示141 敏捷教练能为我们做什么
提示142 引入和利用A-CoE
提示143 敏捷启动指南的思路
提示144 如何巧妙地利用敏捷培训
写在最后
同类热销排行榜
[an error occurred while processing this directive]推荐书目
-
孩子你慢慢来/人生三书 华人世界率性犀利的一枝笔，龙应台独家授权《孩子你慢慢来》20周年经典新版。她的《...
-
时间简史(插图版) 相对论、黑洞、弯曲空间……这些词给我们的感觉是艰深、晦涩、难以理解而且与我们的...
-
本质(精) 改革开放40年，恰如一部四部曲的年代大戏。技术突变、产品迭代、产业升级、资本对接...