最近项目组在敏捷实践方面遇到了一些挑战，于是年前又重读了一下这本书，过完年终于又有时间把它总结出来，记于此。
前言一、敏捷宣言
说起敏捷，开篇便从《敏捷宣言》开始。敏捷是一种软件开发方法，是一种工作方式。他的价值观如下：个体和互动高于流程和文档；工作的软件高于详尽的设计；客户合作高于合同谈判（基于客户深度参与的统一团队）；响应变化高于遵循计划。敏捷开发的核心原则：价值驱动和软件卓越。敏捷开发管理体系可以分为需求管理（用户故事和用户故事地图）；技术管理（软件卓越）；质量管理（基于持续集成和测试前置的质量内建）和迭代管理（全功能团队和持续改进）。
前言二、瀑布式开发 VS 迭代式开发
瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整，对变化的响应很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发中，整个开发工作被组织为一系列短小的、固定长度的小项目，我们将其称为“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。
采用这种方法，开发工作可以在需求被完整地确定前启动，并在每次迭代中完成系统的一部分功能开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代。（想起了不确定性漏洞，把做决定的时刻延后有助于提升决定的正确性）
敏捷开发通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。比如，我们先从整体功能规划中定位出一小部分核心功能，打造能基本运转、对用户有价值的最小可用产品（Minimum Viable Product，MVP），然后迅速迭代开发，听取用户反馈，及时调整功能规划。
我曾在一次培训中听到同事谈到敏捷团队与西游团队的相似性，他认为唐僧师徒可以被看作敏捷中的全功能团队：团队有共同的目标——取到真经；他们历经了九九八十一难，好比九九八十一个迭代，每次打怪成功都是完成了一次交付；在不断迭代的过程中，这个团队不断地收集反馈、持续改进，一步步地完成了最后的目标。取到了真经，意味着完成了项目的交付，同时使得团队能力得到质的提升。
前言三、敏捷项目铁三角
项目成果的交付和团队能力的提升，这是项目经理在项目管理中最希望达成的目标。 传统项目管理的定义是：“在有限资源限定的条件下，实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角：需求是范围，资源包括时间和成本。
大家都看过电影《泰坦尼克号》，如果我们套用上面这个“范围、时间和成本”定义的框架，《泰坦尼克号》会被判断为一个失败的项目。为什么呢？这部电影在拍摄过程中多次延期，预算也超出很多，无论从成本还是时间来看，这都是一个失败的项目。可是我们都知道，《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。
由此可知，左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调，团队应得到来自市场的真实反馈，以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。
零、正文
Scrum是软件开发中实施敏捷的方法论，包括站会、sprint计划、sprint演示、回顾等团队项目组织管理方法，同时强调应该从团队/项目的具体情况出发持续改善找到最适合团队的方法集合。XP极限编程，包括结对编程、测试驱动开发、持续集成等编程实践。
本书主要从以下方面进行论述：1）产品backlog和故事，产品backlog里面是客户想要的东西，用客户的语言表述并拆分为故事。2）sprint计划，Scrum中把交付过程分为若干个sprint进行管理，一个典型的sprint时长为两到三周，sprint计划即sprint开始时的计划会议。3）sprint backlog的管理，sprint计划会议会产生sprint backlog，相对产品backlog，sprint backlog是该sprint中需要交付的部分。4）sprint过程中每天的站会、sprint结束时的演示和回顾。5）Scrum和XP；6）scrum团队中的测试先生；7）关于远程合作和离岸交付。
一、 产品backlog和故事story
产品backlog里是客户想要的东西，用客户的语言进行表述，通常用故事来表示。
接下来着重介绍故事的几个要素：
1）重要性：由产品负责人（PO：product owner）决定并用数值表示。推荐使用重要性而不是优先级，因为优先级往往用1代表最高优先级，那如果来了更高优先级的又如何设置呢？又或者像我的项目组用高/中/低表示优先级，那么若干个高或者中优先级的故事又要如何区分呢？用数值表示的重要性更加清晰，如重要性是100的故事比重要性50的故事优先级更高。
2）初始估算：故事估算是团队的开发团队独有的权利。书中建议用人天来估算。实际项目中，我用过两种方式，一种是基于工作量/复杂度/人天，另一种是基于业务价值。区别在于业务价值大的故事可能不需要太大工作量。两种方式各有利弊，基于工作量估算更有利于统计团队交付速度，进而更准确的估算交付时长等；基于业务价值则更符合精益中交付价值的观点，无论复杂度高低，创造价值的才是有意义的部分。建议团队通过全员讨论投票达成共识，并在项目交付过程中通过回顾不断找到最适合自己的方式，这也是scrum的重要点，没有规定的方式，只有最适合团队的方式。估算之所以重要是因为只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知， 才能做出明智的决定。
3）如何演示：这个是很重要的，敏捷中通常将交付过程分为若干迭代，通常一个迭代的长度不会超过1个月，我待过的项目组普遍使用两周作为一个迭代。并且在每个迭代的最后，我们希望将这个迭代完成的功能演示给产品负责人和相关利益者（stakeholder），并获取反馈。演示过程确保了我们交付的是符合客户需求的，有偏差的部分可以基于客户反馈及时进行修改。敏捷致力于缩短开发与上线之间的周期长度，希望尽快交付价值，因此演示是很重要的。
4）请求者：这个故事中的需求提出者是谁。这个信息方便我们在对需求产生疑问时找到需求提出者进行沟通。
5）识别故事之间的dependency等关联关系；以及是否需要外部团队的协作等。
书中有一个有趣的小故事：“如果产品负责人有技术背景，那他可能创建这样一个故 事：“给数据表添加索引”。他为啥要这么做？真正的潜在目标也许是“提高搜索表单的响应速度”。后面我们可能会发现：索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。对于这种面向技术的故事，我们需要一直问为什么，直到发现内在目标为止。然后再用真正的目标来改写这个故事（“提高搜索表单的响应速度”）。最开始的技术描述只会作为一个注解存在（“为数据表添加索引可能会解决这个问题”)。”
故事中有一个特例：技术故事，指的是需要完成但又不会给产品负责人带来直接价值。例如，搭建持续构建服务器，编写系统设计概览（虽说敏捷不喜欢文档，但团队仍然需要一个整体概况的文档，保证每个人对设计有相同的理解，避免写出不一致的代码），重构等。技术故事的尴尬之处在于缺乏显而易见等业务价值，产品负责人划分优先级时，往往会将技术故事设置一个低优先级。那我们如何解决呢？首先，避免技术故事，尽量转化为普通故事中的任务；如果无法转化，则通过投入程度和预估生产率这两个参数来说服产品负责人，比如把投入程度从100%降低到90%，同时承诺可以提升的生产率。
二、sprint计划
1. 会前准备
会前准备对于提高会议效率太重要了。在经历了多次混乱无序的会议之后，对此尤为感触。那么sprint计划需要哪些准备工作？
1）产品backlog：一个产品只用一个backlog和一个product owner。我做过一个backlog管理混乱的项目，一个项目，有若干个backlog，为什么说若干个，因为团队内每个成员的答案不一样，也就是说我知道backlog A和backlog B，另外一位团队成员知道backlog A和backlog C，非常痛苦😖。
2）确保产品负责人参加。这里又插入书中的小故事：“产品负责人有时不太情愿跟团队一起花时间制定 sprint计划。“嘿，我想要的东西已经列下来了，我没时间参加你们的计划会议。”这是个非常严重的问题。为什么整个团队和产品负责人都必须要参加 sprint 计划会议? 原因在于，每个故事都含有三个变量：范围，重要性和估算，它们两两之间都对彼此有着强烈依赖。范围和重要性由产品负责人设置；估算由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。会议中，产品负责人会先概述希望在这个 sprint达成的目标，还有他认为最重要的故事；接下来，团队从最重要的故事开始逐一讨论并估算时间。在这个过程中，他们会针对范围提出些重要问题: “‘删除用户’这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答案会让他们惊讶，促使他们调整估算。有时团队对故事做出的估算，跟产品负责人想得不太一样，这可能会让他调整故事的重要性，或者修改故事的范围，然后团队重新估算。这种直接的协作形式是 Scrum的基础，也是敏捷软件开发的基础。如果产品负责人无法参加，则建议选择团队中某个人作为代表，在会前与PO沟通并授权在会议上代替决定重要性和范围。
除了上面提到的故事的三个变量：范围，重要性和估算，其实还有另一个：质量；分为外部质量和内部质量。其中外部质量是用户感知的，例如运行缓慢的用户界面。内部质量一般指用户看不到，却对系统的可维护性有深远影响的，例如系统设计的一致性、测试覆盖率、代码可读性和重构等。外部质量可以理解为范围，比如我们第一次交付一个简陋的界面，然后在后续交付中进行优化。但是内部质量却应该做成一个常量。
3）明确定义“完成” （definition of done）。产品负责人和团队需要对完成有一致的定义。比如通过内部测试为完成，通过产品负责人的验收为完成等。Scrum和精益的要求都是把事情做完，达到可交付的状态。做了一半的事情价值为0，甚至是负数。
2. sprint会议
Sprint会议会做些什么呢？首先产品负责人确定这个sprint需要交付的需求，即sprint目标。团队选择要放入sprint的故事，基于团队交付速度确定交付量。因此，sprint计划的产出包括：sprint目标和sprint backlog，即这个sprint要做的故事。
此外，通过sprint会议的充分讨论，确保产品负责人和团队成员就故事内容达成共识。避免出现sprint结束后的演示会上，产品负责人认为团队演示的功能并不是他想要的。
3. 让sprint会议更高效的小技巧
1）时间盒（timebox）：Scrum 中的一切事情都有时间盒。为会议中的议程和每个话题讨论设置时间盒，可以防止讨论过度发散。
2）手写索引卡：sprint会议的时候需要对故事进行讨论，推荐的方式是手写索引卡。相比PPT，索引卡更有利于加强团队成员的参与感。并且sprint会议后我们可以直接把索引卡贴在墙上。使用索引卡，成员可以列出故事包含的任务，如下图中的sticker，从而更方便的估算故事。
3）估算纸牌。估算应该是整个团队的共识，但往往有人对某故事的理解更深入一些，因此最先发言，难免影响到他人的判断，估算纸牌就是用来解决这个问题的。
“估算故事时，每人都选出一张卡片表示他估算的故事点， 并正面朝下扣在桌上。所有人完成后再同时揭开。这样每人都会被迫进行自我思考，而不是依赖于他人估算的结果。如果估算存在巨大差异，团队就需要讨论并达成共识。”
之所以选用斐波那契数列，而不是线性数字序列来表示故事点，是因为要么选3，要么选5，没有中间地带来徘徊，以促进人们去做出辨识度高的决定。图中几个特殊的卡片，0表示这个故事已经完成没有工作量；？表示完全没有概念，无法估算。
估算完成后，如果你有很多1点的故事，那你恐怕会成为微观管理的受害者了。与之相反，40点的故事，到最后很可能只能部分完成，这样不会带来任何价值，只会增加管理成本。我们需要通过拆分和组合，尽量保证每个故事在1-5个点并且每个小故事依然可以交付业务价值。
4. 如何让别人了解我们的sprint
让别人知道我们在做什么也很重要。正如保持透明也是scrum的一大原则。
1）sprint信息页：sprint信息页往往简洁且直观。Sprint计划结束后，Scrum master会创建该信息页，并放到wiki上。他会发送邮件，并将打印版贴到团队墙上，这样路过的人都可以了解团队所做的事情。
三、sprint backlog
1）最佳实践：通常我们会用Jira或者墙上的任务板来保存sprint backlog。其中任务板被证明是更有效的方式。你需要团队附近的一面墙壁（白板有些浪费，可以用于其他需要频繁擦除修改的内容，比如讨论分享，设计草图等）然后像下图一样。
2）定制化但保持简单：你可以在上述版本另外添上许多列，比如“ready for test”。但是为了保持简单，我们需要仔细考虑，你要添上去的那一列真的是没它不行吗?
3）阻塞（block）标识：阻塞标识往往会用红色标示，这样可以清晰看到哪个故事被阻塞，并设法去除阻塞。
4）打印团队成员头像：把头像黏贴到成员正在做的卡上，这样可以清晰的看到谁在做哪个故事，还有如果一个人同时持有多个任务，也能轻易的辨识并设法优化。
5）燃尽图（burn down chart）：如上图所示，虚线表示总体趋势，我们会根据项目完成了多少点画到燃尽图中，并参照虚线查看当前进度是否健康。通常在横轴的天数中，我们不会包含周末，否则就会出现不具参考意义的横线。
四、团队风水之工作空间布局
1）任务板前的空地：任务板前保留一块空地可以方便团队成员站会讨论，随时查看sprint进度。之前我有一个项目就略显遗憾，虽然我们有任务板并且每天更新，但因为办公区域限制，任务板旁边就是桌子，空间狭小，站会时大家勉强站在任务板前面，无法像下图一样聚拢，每个人都能最佳效果地和他人沟通；也不利于大家随时查看任务板。
2）让团队坐在一起：这一点的重要性就不再赘述了。问题在于离岸交付团队往往存在分布式团队，因此需要更多的方法来解决让团队在一起的问题，如always-on TV等。
3）不要让产品负责人离团队太远：产品负责人不应该和团队在一起，那样会使他过度关注实现细节；同时，产品负责人要能让团队随时找到来确认业务需求。
4）经理和scrum教练也要避免离团队太近：否则会降低他们的自组织性，“老大来了，他会告诉我们应该干啥。让他说吧。”scrum教练也是，只需偶尔参加团队的sprint演示，看看任务板或者参加站会。如果发现可以改进的点，就把团队scrum master拽出来指导。
五、站会
1）理想的站会：站会一般在任务板前面进行，像上图一样，通常不超过15分钟，我们会在站会的时候更新任务板，并且在燃尽图上记录下当天的进度。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”，准备发言的人首先取得”令牌”，发言完成后将“令牌”传给下一个人。令牌要醒目，可以是毛绒玩具，也可以是一顶帽子)。
2）小插曲-迟到：迟到总是难以避免，可以规定迟到了就投入定额的钱到团队小钱箱，或者发微信红包给scrum master。没有人关心迟到的理由，即使你提前声明要迟到，也要遵守规矩。团队钱箱当然可以用于买奶茶等团队活动。
3）小插曲-没事做：站会的时候还会出现一种情况就是有成员今天没有事情做，不知道要做什么。这时我们记下哪些人没有事情做，同时继续站会。站会中会遍历sprint backlog，也许在这个过程中就找到事情了；如果还没有，可以考虑让他们和有挑战工作的同事去结对编程；如果还没有，就检视我们这个sprint目标达成了么，可以演示了么？如果结果是否定的，那么还有哪些事情需要做；最后可以把任务板中Next中的故事放进sprint backlog并通知产品负责人我们已经完成sprint目标并开始引入更多工作。
六、sprint演示
1）演示很重要：Sprint演示非常重要却常被忽略。“我们真的必须做演示么? 没啥能展示的！我们没时间准备！”为什么坚持所有的sprint都结束于演示？1⃣️团队成果得到认可，他们会感觉很好；2⃣️他人可以了解你的团队在做什么；3⃣️演示可以吸引相关干系人的注意，并得到重要反馈；4⃣️演示是一种社会活动，不同的团队可以在这里交流讨论各自的工作，这很有意义；5⃣️演示会迫使团队真正完成一些工作。如果没有演示，我们就会总得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。这比得到一堆貌似完成的工作要好得多。
2）如何做演示：1⃣️清晰阐述sprint目标；2⃣️关注业务价值而不是技术实现细节；3⃣️如果可能的话，让观众试用一下；4⃣️少演示细微特性和bugfix，避免混淆业务重点。
3）如何处理看似无法演示的工作：比如我们做的是性能优化，虽然没有网页界面可以进行直观的操作，但是可以通过性能测试报告来进行演示。
七、sprint回顾
1）如何做回顾：1⃣️发散：团队通过头脑风暴得出想法，包括做的好的，不好的，写在即时贴并贴在白板上；2⃣️收敛：对上述结果进行归纳，对讨论出下个sprint的改善方案；3⃣️投票：用“圆点投票”来决定下一个sprint着重进行哪些改进。
2）无招胜有招：并非所有不好的都需要改善措施。比如“团队交流太少，造成重复工作和冲突”，我们该怎么做呢? 引入每日会议? 引入有助于交流的新工具? 增加更多的wiki 页面? 不一定。很多时候，只要能清楚地指出问题所在，到了下一个sprint，问题也许就自行解决了。把sprint回顾结果贴在团队的墙上会更有效。在sprint中引入的每一点变化，都会让团队付出相应的代价；在引入变化前，可以先什么都不做，看问题能否自愈。
3）典型问题之“太多的外界干扰”：这是一个很常见的问题，之前的经验是让团队指定一个人充当“守门员”，所有的干扰都要经由他处理，其他人就可以把注意力保持在项目上。扮演者可以是 Scrum master，也可以大家轮流。
回顾的本意是通过种种沟通形式唤起大家对团队的集体意识。回顾的形式和方法非常多，耳熟能详的就有“Well & Less Well”、“红绿灯检查”、“心情曲线”等。 回顾的关注点也多种多样，除了“项目开发”之外，还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。
八、sprint之间的休整时刻
1）为什么需要休整时间：Sprint演示和回顾结束以后，团队和产品负责人都有一大堆信息需要消化。如果立刻计划下一个sprint，那就无法很好的消化现有的信息或是学到的经验。
2）“实验日”：在sprint之间安排一个实验日，比如把周四定为sprint结束日，周五定为实验日，而下周一作为下个sprint开始的日子。实验日的想法源自谷歌，开发人员可以做想做的事，比如研习最新的工具、准备认证、跟同事讨论、开发自己喜欢的项目等。这样既能得到休息，开发团队也能了解最前沿的知识。这也是一种能够吸引员工的福利。
九、组合使用XP和Scrum
Scrum 注重的是管理和组织实践，而XP关注的是编程实践。
1）结对编程：曾经sprint经理问我为什么结对，答案总结一波：1⃣️提高代码质量；2⃣️让团队的精力更集中（比如pair会提醒你，“这个东西真的是这个sprint必需的吗？”)。3⃣️结对并且时时更换结对可以增进团队间的知识传播，速度快到难以想象。如果条件不允许结对编程，代码审查也可作为替代方案。结对编程的两个人一个扮演领航员（不用键盘），一个扮演司机。领航员也应该有一台电脑：不是用来开发，而是在需要时做一些探索尝试、当司机遇到难题的时候查看文档等。
2）测试驱动开发(TDD)：测试驱动开发意味着先写自动测试，然后编写恰好够用的代码，让测试通过，接着重构代码，以提高可读性和消除重复。整理，继续。工具使得测试驱动开发更加简单：如jUnit，Mock，webdriver等框架，H2等内存型数据库，Jacoco等测试覆盖率度量工具。
3）增量设计：一开始就保持设计简单化，然后不断改进；而不是一开始努力保证设计的正确性，然后就冻结，不再改变。
4）持续集成：对于 “在我的电脑上没有问题”这一类老问题，持续集成是终极解决方案。用持续构建服务器充当“法官”，每次有人向版本控制系统提交代码，持续构建服务器就会在共享服务器上进行构建并运行测试。如果出现问题，它就会发送邮件告知大家构建失败，邮件中包括有哪些代码的变化导致构建失败，并提供指向测试报告的链接等。每天晚上，持续构建服务器都会构建产品，并向内部文档门户上发布二进制文件(ears，wars 等)、文档、测试报告、测试覆盖率报告和依赖性分析报告等。有些产品也会被自动部署到测试环境。搭建持续集成系统需要工作量，但付出物超所值。
5）代码集体所有权：高度的代码集体所有权意味着健壮的团队。比如即使某些关键人物生病了，当前的sprint也能继续运转。
6）可持续的开发速度/精充沛的工作：拒绝精疲力尽的开发。
十、Scrum团队中的测试先生
1）scrum团队是跨职能团队：测试人员确实在团队中有一个特定的角色，不过他仍然可以做其他工作，其他的团队成员也可以做他的工作。
2）测试人员在scrum团队中的首要职责是验收：检验功能是否按照期望完成，这也意味着他可以天然承担sprint演示的工作。
3）如果团队当前没有可以测试的东西：那么他可以做一些测试准备工作如编写测试规范，准备测试环境等；此外测试人员可以跟编写测试代码的开发人员一起结对编程，即使测试人员不会编程，他也可以想出多种不同类型的测试，让开发人员敲键盘实现。
4）如果测试先生成了瓶颈：假设在sprint的最后一天突然很多工作完成开发进入测试阶段，那么不妨把团队中的所有人都分配给测试先生当助手。他决定哪些事情自己做，把一些烦人的测试交给团队中的其他人来做。
十一、分布式团队
如果团队成员处于不同地理位置该怎么办？那就想尽办法来把物理位置上分散的团队成员之间的沟通带宽增至最大。列举一些典型措施作为参考：远距离结对编程，站会时借助视频面对面交流，Always on TV保证能够随时面对面交流，通过出差实现真正的面对面，团队对 sprint backlog、sprint 燃尽图、产品 backlog和其他信息传递设施有相同的理解。最后一条很重要，达成共识可以大大降低沟通成本。
十二、补充
而提升会议效率，降低会议对于沟通成本和研发效能的障碍，是所有敏捷方法所强调的重点（当然也是最容易被忽视的重点）。
