初学者简易Scrum教程

Agile是一种软件开发方法，可使用1至4周的短迭代逐步构建软件，以便开发过程与不断变化的业务需求保持一致。而不是预先预测全部要求和风险的6到18个月的单程开发，敏捷采用频繁反馈的过程，其中在1到4周的迭代后交付可行的产品。

敏捷中的角色

Scrum Master

Scrum Master是团队领导者和推进者，帮助团队成员遵循敏捷实践，以便他们可以履行承诺。Scrum master的职责以下 -

• 实现全部角色和功能之间的紧密合做。
• 删除任何块。
• 保护团队免受任何干扰。
• 与组织合做以跟踪公司的进度和流程。

• 确保Agile Inspect＆Adapt流程获得适当利用，包括

  • 每日站立，
  • 计划会议，
  • 演示，
  • 评论，
  • 回顾会议，和
  • 促进团队会议和决策过程。

产品拥有者

产品负责人是从业务角度推进产品的人。职责或产品负责人以下 -

• 定义需求并肯定其值的优先级。
• 肯定发布日期和内容。
• 在迭代计划和发布计划会议中发挥积极做用。
• 确保团队致力于最有价值的要求。
• 表明客户的声音。
• 接受符合完成和已定义验收标准定义的用户故事。

跨职能团队

每一个敏捷团队都应该是一个自给自足的团队，拥有5到9名团队成员，平均经验为6到10年。一般，敏捷团队由3到4名开发人员，1名测试人员，1名技术主管，1名产品全部者和1名Scrum主人组成。

产品负责人和Scrum master被认为是Team Interface的一部分，而其余成员则是Technical Interface的一部分。

敏捷团队如何规划其工做？

敏捷团队在迭代中工做，以提供每次迭代为10到15天的用户故事。每一个用户故事都是根据其积压优先级和大小来规划的。团队使用其能力 - 团队可使用多少小时来完成任务 - 来决定他们计划的范围。

Story Point 点

Point定义了团队能够提交多少。一点一般指8小时。每一个故事都以分数估算。

容量

容量定义了我的能够提交多少。容量估计为小时。

什么是用户故事？

用户故事是定义用户须要什么做为功能的要求。用户故事能够有两种形式 -

• 做为<用户角色>我想要<功能>以便<业务价值>
• 为了<业务价值>做为<用户角色>我想要<功能>

在发布计划期间，使用相对比例做为点对用户故事进行粗略估计。在迭代计划期间，故事被分解为任务。

用户故事与任务的关系

• 用户故事讲述了要作什么。它定义了用户须要的内容。
• 任务谈论如何完成。它定义了如何实现功能。
• 故事由任务实现。每一个故事都是一系列任务。
• 用户故事在当前迭代中计划时分为任务。
• 任务以小时计算，一般为2至12小时。
• 使用验收测试验证故事。

当一个故事完成

团队决定作什么意味着什么。标准多是 -

• 全部任务（开发，测试）都已完成。
• 全部验收测试都在运行并经过。
• 没有缺陷是开放的。
• 产品全部者已经接受了这个故事
• 可交付给最终用户。

什么是验收标准？

Criteria定义功能所需的功能，行为和性能，以便产品全部者能够接受。它定义了要作什么，以便开发人员知道用户故事什么时候完成。

如何定义需求？

要求定义为

• 用户故事，
• 有了验收标准，和
• 实现故事的任务。

敏捷 - 宣言

2001年2月，在犹他州的Snowbird度假村，17位软件开发人员开会讨论轻量级开发方法。他们会议的结果是如下用于软件开发的敏捷宣言 -

咱们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此咱们创建了以下价值观： -

• 个体和互动 高于 流程和工具
• 工做的软件 高于 详尽的文档
• 客户合做 高于 合同谈判
• 响应变化 高于 遵循计划

也就是说，尽管右项有其价值，咱们更重视左项的价值。

敏捷宣言的十二项原则

• 客户满意度 - 经过早期和持续交付有价值的软件，最高优先级知足客户的要求。
• 欢迎变革 - 软件开发过程当中不可避免的变化。即便在开发阶段的后期，也应该欢迎不断变化的要求。敏捷流程应该有助于提升客户的竞争优点。
• 提供可运行的软件 - 考虑到更短的时间尺度，常常提供一个工做软件，范围从几周到几个月不等。
• 协做 - 业务人员和开发人员必须在项目的整个生命周期中协同工做。
• 动机 - 项目应围绕有动力的我的创建。提供一个支持我的团队成员并信任他们的环境，使他们对完成工做感到负责。
• 面对面交谈 - 面对面交谈是向开发团队内部和内部传达信息的最有效和最有效的方法。
• 根据工做软件衡量进度 - 工做软件是关键，它应该是进步的主要衡量标准。
• 保持不变的步伐 - 敏捷流程旨在实现可持续发展。业务，开发人员和用户应该可以与项目保持一致的步伐。
• 监控 - 按期关注技术卓越和良好的设计，以提升灵活性。
• 简单 - 保持简单，并使用简单的术语来衡量未完成的工做。
• 自组织团队 - 敏捷团队应该是自我组织的，不该该严重依赖其余团队，由于最好的架构，要求和设计来自自组织团队。
• 按期审查工做 - 按期审查工做，以便团队能够反思如何提升效率并相应地调整其行为。

敏捷 - 特征

迭代/增量和准备进化

大多数敏捷开发方法都将问题分解为较小的任务。任何要求都没有直接的长期规划。一般，计划的迭代具备变化的短期段，例如1至4周。为每一个迭代建立一个跨职能团队，该团队适用于软件开发的全部功能，如规划，需求分析，设计，编码，单元测试和验收测试。迭代结束时的结果是一个工做产品，它在迭代结束时向利益相关者展现。

演示以后，将审核评论并计划根据须要合并到工做软件中。

面对面交流

每一个敏捷团队都应该有一个客户表明，例如scrum方法中的产品全部者。该表明被受权表明利益相关者行事，他能够在迭代之间回答开发人员的查询。

信息辐射器（物理显示器）一般位于办公室的显眼位置，路人能够看到敏捷团队的进度。此信息散热器显示项目状态的最新摘要。

反馈回路

每日站立是任何敏捷开发的共同文化; 它也被称为每日Scrum。这是一种简短的会话，每一个团队成员互相报告他们所作的事情，下一步该作什么以及他们面临的任何问题。

敏捷 - 每日站立

顾名思义，每日站立是敏捷团队全部成员之间的每日状态会议。它不只提供按期更新的论坛，并且还将团队成员的问题集中在一块儿，以便快速解决。不管办公地点如何，不管如何创建敏捷团队，每日站立都是必须的作法。

什么是每日站立？

• 每日站立是全部团队成员之间的每日状态会议，大约持续15分钟。

• 每一个成员都必须回答三个重要问题 -

  • 我昨天作了什么？
  • 我今天要作什么？
  • 我面临的任何障碍...... /我因......而被封锁
• 每日站立是为了状态更新，而不是任何讨论。对于讨论，团队成员应该在不一样的时间安排另外一次会议。
• 参与者一般站立而不是坐着，以便会议快速结束。

为何站立是重要的？

每日站立敏捷的好处以下 -

• 团队能够天天评估进度，看看他们是否能够按照迭代计划进行交付。
• 每一个团队成员都会告知他/她当天的承诺。
• 它可让团队了解任何延迟或障碍。

谁出席了站立？

• Scrum主管，产品全部者和交付团队应天天参加站立。
• 鼓励利益相关者和客户参加会议，他们能够做为观察员，但他们不该该参加站立。
• Scrum主管有责任记录每一个团队成员的疑问及他们面临的问题。

地理位置分散的团队

若是敏捷团队成员在不一样的时区运营，能够经过多种方式进行站立 -

• 轮流选择会员，谁能够参加位于不一样时区的团队的站立会议。
• 每一个团队单独站立，在Rally，SharePoint，Wikis等工具中更新站立状态。
• 拥有各类各样的通讯工具，如电话会议，视频会议，即时消息或任何其余第三方知识共享工具。

敏捷 - 完成的定义

用户故事，迭代和发布的完成定义以下。

用户故事

用户故事是在用户的平常用语中用几句话表达的要求，而且应该在迭代内完成。用户故事在什么时候完成

• 全部相关代码都已签入。
• 全部单元测试用例都已经过。
• 全部验收测试用例均已经过。
• 帮助文本已写入。
• 产品负责人接受了这个故事。

迭代

迭代是在产品发布中处理和接受的用户故事/缺陷的时间盒装集合。迭代在迭代计划会议期间定义，并经过迭代演示和审阅会议完成。迭代也称为冲刺。迭代完成时

• 产品备份完成。
• 性能已通过测试。
• 用户故事已被接受或移至下一次迭代。
• 缺陷已被修复或推迟到下一次迭代。

发布

版本是一个重要的里程碑，表明产品/系统的工做，测试版本的内部或外部交付。发布时就完成了

• 系统通过压力测试。
• 性能获得了调整。
• 进行安全验证。
• 灾难恢复计划已通过测试。

敏捷 - 发布计划

发布计划的目的是建立一个计划，以便为产品提供增量。每2至3个月完成一次。

![图片上传中...]
)

谁参与了？

• Scrum Master - Scrum master是敏捷交付团队的推进者。
• 产品负责人 - 产品负责人表明产品待办事项的通常视图。
• 敏捷团队 - 敏捷交付团队提供有关技术可行性或任何依赖关系的看法。
• 利益相关者 - 像客户，项目经理，主题专家这样的利益相关者担任顾问，由于决策是围绕发布计划作出的。

规划的先决条件

发布计划的先决条件以下 -

• 由产品负责人管理的排名产品积压。一般采用五到十个特征，产品全部者认为能够包含在版本中
• 团队关于能力，已知速度或任何技术挑战的意见
• 高层愿景
• 市场和业务目标
• 确认是否须要新产品积压项目

所需材料

发布计划所需的材料清单以下 -

• 发表议程，目的
• 翻转图表，白板，标记
• 投影仪，在计划会议期间共享具备所需数据/工具的计算机的方式
• 规划数据

规划数据

进行发布计划所需的数据列表以下 -

• 之前的迭代或发布计划结果
• 各利益相关方对产品，市场情况和截止日期的反馈
• 先前版本/迭代的行动计划
• 要考虑的特征或缺陷
• 先前版本/估计的速度。
• 组织和我的日历
• 来自其余团队和主题专家的输入，以管理任何依赖关系

产量

发布计划的输出能够是如下 -

• 发布计划
• 承诺
• 要监控的问题，顾虑，依赖关系和假设
• 建议改进将来的发布计划

议程

发布计划的议程能够是 -

• 开幕式 - 欢迎辞，审查目的和议程，组织工具和商业赞助商介绍。
• 产品愿景，路线图 - 展现产品的大图。
• 查看之前的版本 - 讨论可能影响计划的任何项目。
• 发布名称/主题 - 检查路线图主题的当前状态并执行所需的调整（若是有）。
• 速度 - 显示当前版本和先前版本的速度。
• 发布计划 - 审核关键里程碑并决定发布时的发布和迭代时间框。
• 问题和顾虑 - 检查任何问题或问题并记录下来。
• 回顾和更新所作的定义 -回顾的定义完成，并根据技术，技能或团队成员自上次迭代/释放变化做适当的改变。
• 要考虑的故事和项目 - 显示产品待办事项中的用户故事和功能，以便在当前版本中进行安排。
• 肯定大小调整值 - 若是速度未知，则计划要在发布计划中使用的大小调整值。
• 粗略的故事大小 - 交付团队肯定所考虑故事的适当大小，并在故事太大时将故事分红多个迭代。产品全部者和主题专家澄清疑虑，详细说明验收标准，并进行适当的故事分割。Scrum master促进了协做。
• 将故事映射到迭代 - 交付团队和产品全部者根据大小和速度移动迭代中的故事/缺陷。Scrum master促进了协做。
• 新的顾虑或问题 - 根据以往的经验检查任何新问题并记录相同的问题。
• 依赖关系和假设 - 检查在发布计划期间计划的任何依赖关系/假设。
• 提交 - Scrum master要求进行规划。交付团队和产品负责人将其视为最佳计划，而后承诺进入下一级计划，即迭代计划。
• 沟通和物流规划 - 审核/更新发布的沟通和后勤规划。
• 停车场 - 处理停车场意味着全部项目都应该被解决或设置为行动项目。
• 分发行动项目和行动计划 - 在其全部者之间分配行动项目，处理行动计划。
• 回顾 - 征求参与者的反馈意见，使会议取得成功。
• 关闭 - 庆祝成功。

敏捷 - 迭代计划

迭代计划的目的是让团队完成一系列排名靠前的产品积压项目。此承诺是基于迭代长度和团队速度的时间框。

谁参与了？

• Scrum Master - Scrum master是敏捷交付团队的推进者。
• 产品负责人 - 产品负责人处理产品待办事项的详细视图及其验收标准。
• 敏捷团队 - 敏捷交付定义了他们的任务，并设置了履行承诺所需的工做量估算。

规划的先决条件

• 产品待办事项中的项目已调整大小并分配了相对故事点。
• 产品全部者已对产品组合项进行了排名。
• 已为每一个项目组合项目明确说明了接受标准。

规划过程

如下是迭代计划中涉及的步骤 -

• 肯定迭代中能够容纳多少个故事。
• 将这些故事分解为任务并将每一个任务分配给其全部者。
• 每项任务都以小时为单位进行估算。
• 这些估计值可帮助团队成员检查每一个成员为迭代执行的任务小时数。
• 考虑到团队成员的速度或能力，他们会被分配任务，以避免他们负担太重。

速度计算

敏捷团队根据过去的迭代计算速度。Velocity是在迭代中完成用户故事所需的平均单位数。例如，若是团队在最后三次迭代中在每次迭代中花费了12,14,10个故事点，则团队能够将12做为下一次迭代的速度。

计划速度告诉团队在当前迭代中能够完成多少用户故事。若是团队快速完成分配的任务，则能够提取更多用户故事。不然，故事也能够移出到下一次迭代。

任务能力

团队的能力来自如下三个事实 -

• 一天中理想的工做时数
• 迭代中的人的可用天数
• 成员专门为团队提供的时间百分比。

假设一个团队有5名成员，他们致力于在项目中全职工做（天天8小时），而且在迭代期间没有人休假，那么两周迭代的任务能力将是 -

5×8×10 = 400小时

规划步骤

• 产品负责人描述了排名最高的产品待办事项。
• 团队描述完成项目所需的任务。
• 团队成员拥有这些任务。
• 团队成员估计完成每项任务的时间。
• 对迭代中的全部项重复这些步骤。
• 若是任何我的的任务过载，那么他/她的任务将分配给其余团队成员。

敏捷 - 产品Backlog

产品待办事项是要完成的项目列表。项目按功能描述排名。在理想状况下，项目应分解为用户故事。

产品Backlog为什么重要？

• 它是通过准备的，能够对每一个特征进行估算。
• 它有助于规划产品的路线图。
• 它有助于对功能进行从新排名，从而能够为产品添加更多价值。
• 它有助于肯定优先排序的内容。团队对项目进行排名，而后创建价值。

产品积压的特征

• 每一个产品应该有一个产品积压，能够有一组大到大的功能。
• 多个团队能够处理单个产品待办事项。
• 功能排名基于业务价值，技术价值，风险管理或战略适应性。
• 在发布计划期间，排名最高的项目会被分解为较小的故事，以便在未来的迭代中完成。

敏捷 - 实用术语

验收标准

这是产品全部者或客户设定的条件，以便接受有效且符合其要求的功能。

积压修饰

这是一个持续的过程，产品经理或客户经过从敏捷团队得到反馈来管理产品待办事项。这个过程包括对项目组合项目进行优先排序，将它们分解为较小的项目，为未来的迭代计划它们，建立新的故事，更新验收标准或详细阐述验收标准。

容量

这是团队在一次迭代中完成的工做量。

特征

对产品或对利益相关者有价值的能力的改进，能够在发布中开发。

迭代

基于主题的工做项，可在时间框内完成，并在产品发布中接受。迭代工做在迭代计划期间定义，并经过演示和审阅会议结束。它也被称为Sprint。

增量

增量是产品在逐渐发展时的变化状态。它一般由里程碑或固定迭代次数表示。

产品拥有者

产品全部者是敏捷交付团队的成员，负责收集产品待办事项中的业务需求并对其进行排名。产品全部者在发布/迭代中传达要执行的操做。他/她设定承诺并负责保护团队在迭代期间不受任何需求变化的影响。

产品积压

一套功能性和非功能性产品要求。

产品待办事项

多是敏捷团队要开发的用户故事，缺陷和功能。

点

用于设置用户故事，功能或任何其余项目组合项的相对大小的经常使用单位。

发布

一个时间框，用于完成工做以支持向软件提供可测试的增量。在scrum中，发布包含屡次迭代。

需求

知足所述合同或功能的软件产品规范。用户故事和项目组合项目是需求类型。

故事点

敏捷团队用于估计用户故事和功能的相对大小的单元。

短跑

与迭代相同。

时间盒

肯定可交付成果的固定持续时间。一般，随着时间框的修复开始和结束日期，资源的数量也是固定的。

任务

它是一个工做单元，有助于在迭代中完成用户故事。用户故事被分解为多个任务，每一个任务能够在团队成员之间划分，并将其标记为任务的全部者。团队成员能够根据须要负责每项任务，更新估算，记录已完成的工做或待办事项。

用户故事

列出的验收标准，以知足用户的某些要求。它一般是从最终用户的角度编写的。

速度

在迭代或时间框中对接受的工做进行加权的度量。一般它是迭代中接受的故事点的总和。