前言
本读书笔记分两部分。
第一部分探讨传统软件开发方式和敏捷开发的区别。
第二部分探讨敏捷开发方法论之一的Scrum方法。根据《Scrum要素》中的周记，结合《Scrum权威指南》，讨论Scrum的主要内容。
敏捷力介绍
瀑布模型
瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段：
- 需求收集
- 设计
- 编码
- 测试
在瀑布流程中，每一步骤都必须等待前一步骤结束后才能继续，也只有等待所有步骤都结束后才有可能向客户交付价值。人们往往会认为“完美化”设计能够作为该模型的理论支持：能够早点捕获错误和缺陷，从而降低项目全过程成本。然而美中不足之处就在于“完美化”太不现实了，软件产品是复杂系统，而不是静态物件，毫无经验数据只能设计出致命的烂系统，在出问题前把事情搞得一团糟。
迭代式方法
敏捷团队做的开发工作和瀑布团队一模一样，但他们的做事方式很不一样。敏捷开发周期使用的职能和瀑布方法一样：需求收集、设计、编码和测试，差别在于：敏捷团队会做一点点需求收集，一点点设计、编码和测试，最后交付一点点价值给客户。接着团队再重复此过程，周而复始，工作推进过程中不断改善、调整流程，一直到项目完成为止。
Scrum
初读《Scrum权威指南》，该书精练准确地定义了Scrum框架，包括Scrum理论、价值观、团队、事件、工件等内容，而在《Scrum要素》的开篇，作者以讲故事的手法叙述了一篇《Scrum团队周记》，形象生动地将Scrum框架主要内容介绍给读者。
角色
在《Scrum团队周记》中，这支高绩效的scrum团队由九个人组成，Brad是产品负责人，Frank是团队的scrum master，剩下七名均为团队成员，他们来自传统领域，头衔可能各不相同，例如架构师、业务分析师、设计师、软件开发者、测试人员、产品经理等，但scrum只承认三个互不相同的角色，即产品负责人、scrum master和团队成员，团队规模在5-9人。
Brad —— 产品负责人
Brad有一张工作项的候选列表，新特性和错误修复的工作都有，他认为这些都是项目上最重要的待办事项。这些待办事项源自于一个按优先级排序地清单，将它们挑选出来是Brad作为产品负责人职责地一部分。
选定范围后，Brad会用文摘卡记录下这些特性。
这些故事都是Brad、业务和客户想要的东西：故事是有商业价值的。
团队成员们和Brad逐一讨论这些用户故事，明确其验收标准，或者更确切地说，就是Brad心目中已经完成故事地模样。
有个故事大家理解得还不够，没有想象中地好，他们要求Brad再去向某个关键客户多要些信息回来。
我们可以看出产品负责人的工作职责有哪些：
- 清晰地表述产品待办列表项，并对产品列表项进行排序，使其最好地实现目标和使命
- 确保产品待办列表对所有人是可见、透明和清晰地，同时显示Scrum团队下一步要做地工作，以及确保开发团队对产品待办列表项有足够深地了解。
- 优化开发团队所执行工作地价值
Frank —— Scrum Master
Frank是团队地scrum master，他早已把房间布置得妥妥当当，就等会议开始
Frank开始带着大家做“估算游戏”，跟扑克牌游戏很像，能够帮助团队快速达成共识
我们可以看到，scrum master担当教练角色，引领团队达到更高级地凝聚力、自组织和表现。他们密切注意流程和进度地情况，献言献策帮助团队解决小问题，有需要时还会扮演回音板角色。
- 服务于产品负责人，确保团队中每个人都尽可能地理解目标、范围和产品域等
- 服务于开发团队，移除开发团队工作进展中地障碍，帮助开发团队创造高价值地产品，引导scrum事件
- 服务于组织，在组织范围内规划Scrum的实施，帮助员工和利益攸关者理解并实施Scrum和经验导向的产品开发
团队成员
剩下的所有开发人员，负责在每个Sprint结束时交付潜在可发布并且完成的产品增量。
- 他们是自组织的，没有人有权告诉开发团队应该如何把产品代办列表变成潜在可发布的功能增量
- 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能
- 开发团队中的每个成员也许有特长和专注地领域，但是责任属于整个开发团队
事件
Sprint周期是scrum过程地基本节奏，这是敏捷方法论的一个共同点，以迭代方式完成工作，在《周记》中，Sprint周期长度为一周，一周内出现Sprint事件如图所示
Sprint计划会议
Brad开始讲话：“大家平均每个Sprint能够完成相当于40个故事点的工作量。我已经从产品里选出了最前面8个故事，加起来正好40个点的大小，我想知道团队会不会承诺这些故事”
团队成员们和Brad逐一讨论这些用户故事，明确其验收标准，或者更确切地说，就是Brad心目中已经完成故事地模样。团队成员会继续讨论实现这些故事要做地工作，有哪些类型，有多少工作量。
团队开始把用户故事分解成任务，团队一起上，要找到办法对这些故事进行设计、编码以及测试，在此过程中，他们会用便利贴把所有的任务记录下来。
Sprint计划会议要回答以下问题：
- 接下来地Sprint交付的增量中要包含什么内容？
- 要如何完成交付增量所需的工作？
开发团队预测在这次Sprint中要开发的功能，产品负责人讲解Sprint的目标以及达成该目标所需完成的待办列表项，整个Scrum团队协同工作来理解Sprint的工作。
在设定了Sprint目标后并选出这个Sprint要完成的产品待办列表项后，开发团队将决定如何在Sprint中把这些功能构建成完成的产品增量。开发团队通常从设计整个系统开始，到如何将产品待办列表列表转化成可工作的产品增量所需要的工作。
每日站会
scrum日会是一种短会，用于团结和协调团队。为了鼓励大家都简洁点，这个会是站着开的，它也因此而得名“每日站会”。
团队成员轮流分享信息：前一天完成了什么任务，明天的scrum日会前打算做哪个任务；有没有碰到什么障碍或者是受到了什么拖累
开发团队或者开发团队成员通常会在每日Scrum站会后立即聚到一起进行更详细的讨论，或者为Sprint中剩余的工作进行调整或重新计划。
Scrum master确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum master教导开发团队将每日Scrum会议时间控制在15分钟内。每日Scrum站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视和适应的关键会议
评审会议
午饭后进行当前Sprint的公开收尾，团队成员们都来了，这一事件就是Sprint评审会议。整个团队都在场，还向所有干系人发出了参会邀请。
团队先是宣布他们完成了这个Sprint承诺过的所有故事。接着就直接开始演示他们为故事所开发的这个软件功能。
演示结束后，团队邀请参会者亲身体验新功能，问他们有没有疑问或者建议，Brad小心记录下不同干系人对于当前产品的看法，以及他们希望在下一次发布时看到的变化。
我们可以看到，一次Sprint评审会议包含以下内容：
- 参会者包括Scrum团队和产品负责人邀请的主要利益攸关者
- 产品负责人说明哪些产品待办列表项已经完成和哪些没有完成
- 开发团队讨论在Sprint期间哪些工作做的好，遭遇到说明问题以及问题是如何解决的
- 开发团队演示完成的工作并解答关于所交付增量的问题
- 参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下来的Sprint计划会议提供有价值的输入信息
- 评审市场或潜在的产品使用方式所带来的家下来要做的最有价值的东西转变，同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场
回顾会议
回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。
目的在于：检视前一个Sprint中关于人、关系、过程和工具的情况如何；找出并加以排序做得好的和潜在需要改进的主要方面，同时制定改进Scrum团队工作方式的计划。
回顾会议帮助我们把握时机，在消极模式尚未根深蒂固时，趁着记忆还很清晰，多捕获一些认识和见解，找到一些可改进的事实，制定行动计划，实现这些改变。
三大支柱
Scrum基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。Scrum采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。
透明
过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对视察到的事物有统一的理解
检视
Scrum的使用者必须经常检视Scrum的工件和完成Sprint目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最好
适应
如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或者过程化的内容加以调整，调整工作必须尽快执行如此才能最小化进一步的偏离