内容简介

本书总结了作者15年、参与近百个敏捷项目的经验，以及从项目管理经验中获得的"以管理视角看敏捷”的见解，共144个提示。每个提示都是作者亲身实践的宝贵经验，涵盖了从项目管理到团队协作、品质保障等多个方面。 本书深入剖析敏捷管理方法论，旨在帮助读者纠正对敏捷的误解，并提供实践指导。从敏捷的基本概念、团队沟通与角色分工，到产出物构建与敏捷管理实施方法，本书全面系统地展示了敏捷实践的框架。 本书分为五大章节，是全面且实用的敏捷开发指南，为敏捷项目管理赋能。

目录

10分钟速读敏捷的概述  001  

敏捷背后的思考方式——敏捷宣言  013  

专栏　敏捷不仅仅是Scrum  022

第１章　你真的了解敏捷吗  02

001　你真的需要“敏捷”吗 028

002　当“敏捷”成为最大的目标时，敏捷就会失败 028

003　在欧美，“敏捷是主流”并不是事实 029

004　“敏捷开发方法源于欧美，不适合亚洲文化”是错误 

的说法 030

005　不要害怕敏捷开发方法，已有许多成功案例可供参考 031

006　敏捷开发方法不是万能的（“换一种管理方法就能成功” 是不切实际的） 032

007　灵活应变≠敏捷开发方法 033

008　开始使用敏捷开发方法时，需要的不是标准而是指南 034

009　接受变更≠工作量无限增加，这是需要达成共识的事情 035

010　以瀑布式方法引入敏捷的悲剧 038

011　不要随意混合瀑布式和敏捷，混合管理很困难，原因何在 038

012　让自己从“一旦决定就很难改变”的束缚中解脱出来 040

013　在大多数情况下，必须接受从第一个迭代开始成果无法按

计划达成的事实，否则很容易一开始就失败 041

014　在敏捷管理中，“允许失败”是有很多“学问”的 042

015　完全交由乙方的敏捷，注定会失败 043

016　被动参与的敏捷和被迫参与的敏捷 043

017　不了解敏捷宣言的后果有哪些 044

018　对于敏捷，你也许会认为即使没有开发经验也可以成功，这很奇怪 045

019　对于不熟悉敏捷的人来说，和有经验的人一起工作是最快的捷径 046

020　将敏捷应用于确定性高的项目而导致的失败 047  

第２章　团队沟通和角色分工  049

2-1　如何使团队沟通更为顺畅  050

021　沟通是语言的接力，而不是理论的碰撞 050

022　当团队内部的沟通停滞时，从“我觉得你说得对”这样的 认同开始 051

023　有意识地创造闲聊时间 052

024　“有意识地查看”与“无意识地输入”信息共享的巨大差异 053

025　在真正意义上，将看不见的“信息”替换为可见的“东西” 055

026　会议主持人不应固定由Scrum Master担任 055

027　团队规则（工作协议）的细化和遵守 056

028　让第三方公司打成一片 057

029　对客户保持信息公开，没有任何隐瞒 058

030　导入课题管理系统 059

031　开发团队内不创建次级团队的真正原因 059

032　促进可持续性开发，并不意味着不允许加班 060

033　学会活用会议的节奏 060

034　如何在远程办公中也能实现“在一起工作” 061 

2-2　敏捷团队中各自的角色  062

2-2-1　产品负责人  062

035　产品负责人真的只能有一个吗？团队制也是一个选择 062

036　产品负责人不是“客户”，而是一起工作的同伴 064 

2-2-2　开发团队  065

037　起用代理产品负责人，关键是要让他能完全代入产品负责人的角色来进行决策 065

038　敏捷开发团队有很多事情要做 066

039　开发团队不必一开始就是多面手，他们会随着团队的成熟而逐渐成长 067

040　开发团队人数限制的陷阱 068 

2-2-3　Scrum Master  069

041　Scrum Master不应该是敏捷团队的主角 070

042　Scrum Master的真正职责是塑造一个即便没有他也能持续成长的团队 072

043　为什么让Scrum Master同时兼任产品负责人是不好的 072

044　Scrum Master应该由产品负责人公司还是开发团队公司的人来担任 073

045　以现有的角色直接代入敏捷团队是不可取的 074

2-2-4　传统开发中项目经理的角色应该由谁来扮演  074

046　为什么要在敏捷方法中将项目经理的角色进行分割 075 

第３章　敏捷团队的成果  077

3-1　创建项目核心的用户故事清单  078

047　需求定义书与用户故事清单的决定性差别 078

048　不是优先级，而是优先顺序 080

049　调整用户故事颗粒度的精髓 081

050　用户故事中必须写的和不能写的内容 082

051　用户故事和INVEST的陷阱 084

052　从MECE（相互独立，完全穷尽）的束缚中摆脱出来 085

053　怎样对用户故事进行拆分 086

054　用横向切分的思维得出每个迭代的可交付成果 088

055　如果在迭代中没能按计划完成用户故事应该怎么办 089

3-2　待办事项清单要以迭代为单位进行创建和废弃  090

056　待办事项清单与WBS的区别 090

057　怎么让产品负责人参与待办事项清单的创建 091

058　待办事项清