敏捷 - 快速指南
敏捷 - 入门
敏捷是一种软件开发方法，使用 1 到 4 周的短迭代逐步构建软件，以便开发过程与不断变化的业务需求保持一致。敏捷采用频繁反馈的流程，在 1 到 4 周的迭代后交付可行的产品，而不是 6 到 18 个月的一次性开发，其中所有要求和风险都是预先预测的。
敏捷中的角色
Scrum Master
Scrum Master 是团队领导者和推动者，帮助团队成员遵循敏捷实践，以便他们能够履行承诺。 Scrum Master 的职责如下 −
促进所有角色和职能之间的密切合作。
消除任何障碍。
保护团队免受任何干扰。
与组织合作，跟踪公司的进度和流程。
确保 Agile Inspect &适当利用 Adapt 流程，包括
- 每日站立会议，
- 计划会议，
- 演示，
- 审查，
- 回顾会议，以及
- 促进团队会议和决策过程。
产品负责人
产品负责人是从业务角度推动产品的人。产品负责人的职责如下 −
- 定义需求并确定其价值的优先级。
- 确定发布日期和内容。
- 积极参与迭代规划和发布规划会议。
- 确保团队正在处理最有价值的需求。
- 代表客户的声音。
- 接受符合完成定义和定义的验收标准的用户故事。
跨职能团队
每个敏捷团队都应该是一个自给自足的团队，拥有 5 到 9 名团队成员，平均经验为 6 到 10 年。通常，敏捷团队由 3 到 4 名开发人员、1 名测试人员、1 名技术主管、1 名产品负责人和 1 名 Scrum 主管组成。
产品负责人和 Scrum 主管被视为团队接口的一部分，而其他成员则属于技术接口。
敏捷团队如何规划其工作?
敏捷团队以迭代方式交付用户故事，每次迭代持续 10 到 15 天。每个用户故事都根据其积压优先级和大小进行规划。团队使用其能力减去团队可用于完成任务的小时数减去来决定他们有多少计划空间。
点
点定义团队可以投入多少。点通常指 8 小时。每个故事都以点为单位进行估算。
容量
容量定义个人可以投入多少。容量以小时为单位进行估算。
什么是用户故事?
用户故事是一种需求，它定义了用户需要什么功能。用户故事可以有两种形式 −
- 作为 <用户角色>，我想要 <功能>，以便 <商业价值>
- 为了作为 <用户角色> 实现 <商业价值>我想要<功能>
在发布计划期间，使用相对比例作为点对用户故事进行粗略估计。在迭代计划期间，故事被分解为任务。
用户故事和任务的关系
- 用户故事谈论要做什么。它定义了用户需要什么。
- 任务谈论如何完成。它定义了如何实现功能。
- 故事由任务实现。每个故事都是一组任务。
- 在当前迭代中计划用户故事时，会将其分为多个任务。
- 任务以小时为单位估算，通常为 2 到 12 小时。
- 故事通过验收测试进行验证。
故事完成时
团队决定完成的含义。标准可能是 −
- 所有任务(开发、测试)均已完成。
- 所有验收测试均已运行并通过。
- 无缺陷。
- 产品所有者已接受该故事。
- 可交付给最终用户。
什么是验收标准?
标准定义了功能所需的功能、行为和性能，以便产品所有者可以接受它。它定义了要做什么，以便开发人员知道用户故事何时完成。
如何定义需求?
需求定义为
- 用户故事，
- 带有验收标准，以及
- 实现故事的任务。
敏捷 - 宣言
2001 年 2 月，在犹他州的 Snowbird 度假村，17 位软件开发人员开会讨论轻量级开发方法。他们会议的成果是以下软件开发敏捷宣言 −
我们通过实践和帮助他人实践来发现更好的软件开发方法。通过这项工作，我们开始重视 −
- 个人和互动高于流程和工具
- 可工作的软件高于全面的文档
- 客户协作高于合同谈判
- 响应变化高于遵循计划
也就是说，虽然右边的项目有价值，但我们更重视左边的项目。
敏捷宣言的十二项原则
客户满意度 − 通过尽早和持续交付有价值的软件，将满足客户需求作为最高优先级。
欢迎变化 − 在软件开发过程中，变化是不可避免的。即使在开发阶段的后期，也应该欢迎不断变化的需求。敏捷流程应致力于提高客户的竞争优势。
交付可工作的软件 − 考虑到较短的时间尺度，应经常交付可工作的软件，从几周到几个月不等。
协作 − 业务人员和开发人员必须在项目的整个生命周期内共同努力。
激励 − 项目应围绕积极主动的个人建立。提供一个环境来支持每个团队成员并信任他们，以使他们感到有责任完成工作。
面对面交谈 − 面对面交谈是向开发团队传达信息的最有效方法。
根据可工作的软件衡量进度 −可工作的软件是关键，它应该是进度的主要衡量标准。
保持恒定的步伐 − 敏捷流程旨在实现可持续发展。业务、开发人员和用户应该能够与项目保持恒定的步伐。
监控 − 定期关注技术卓越性和良好的设计以提高敏捷性。
简单 − 保持简单，使用简单的术语来衡量未完成的工作。
自组织团队 − 敏捷团队应该是自组织的，不应该过度依赖其他团队，因为最好的架构、需求和设计都来自自组织团队。
定期审查工作 −定期审查已完成的工作，以便团队可以反思如何提高效率并相应地调整其行为。
敏捷 - 特征
迭代/增量和随时可演进
大多数敏捷开发方法将问题分解为较小的任务。没有针对任何需求的直接长期规划。通常，迭代计划的时间很短，例如 1 到 4 周。每次迭代都会创建一个跨职能团队，该团队负责软件开发的所有功能，如规划、需求分析、设计、编码、单元测试和验收测试。迭代结束时的结果是一个工作产品，并在迭代结束时向利益相关者展示。
演示后，会记录评论，并计划根据需要将其纳入工作软件中。
面对面交流
每个敏捷团队都应该有一个客户代表，例如 Scrum 方法中的产品负责人。该代表有权代表利益相关者行事，并可以在迭代之间回答开发人员的疑问。
信息辐射器(物理显示器)通常位于办公室的显眼位置，路人可以看到敏捷团队的进展。此信息辐射器显示项目状态的最新摘要。
反馈循环
每日站立会议是任何敏捷开发的共同文化;它也被称为每日站会。这是一种简短的会议，每个团队成员都会向彼此报告他们所做工作的状态、下一步要做什么以及他们面临的任何问题。
敏捷 - 每日站立会议
顾名思义，每日站立会议是敏捷团队所有成员之间的每日状态会议。它不仅提供了一个定期更新的论坛，而且还将团队成员的问题集中起来，以便快速解决。无论敏捷团队如何建立，无论其办公地点在哪里，每日站立会议都是必须进行的做法。
什么是每日站立会议?
每日站立会议是所有团队成员之间的每日状态会议，大约持续 15 分钟。
每个成员都必须回答三个重要问题 −
- 我昨天做了什么?
- 我今天要做什么?
- 我面临的任何障碍.../我因...而被阻止
每日站立会议用于状态更新，而不是任何讨论。为了进行讨论，团队成员应该在不同的时间安排另一次会议。
参与者通常站着而不是坐着，这样会议就可以很快结束。
为什么站立很重要?
在敏捷中每天站立的好处如下 −
- 团队可以每天评估进度，看看他们是否能按照迭代计划交付。
- 每个团队成员都要告知他/她当天的承诺。
- 它让团队能够看到任何延迟或障碍。
谁参加站立?
Scrum 主管、产品负责人和交付团队应该每天参加站立基础。
鼓励利益相关者和客户参加会议，他们可以作为观察员，但他们不应该参加站立会议。
Scrum 主管有责任记录每个团队成员的疑问和他们面临的问题。
地理分散的团队
站立会议可以通过多种方式进行，以防敏捷团队成员来自不同的时区 −
轮流选择一名成员，该成员可以参加位于不同时区的团队的站立会议。
每个团队单独召开一次站立会议，使用 Rally、SharePoint、Wikis 等工具更新站立会议的状态。
准备好各种通信工具，如电话会议、视频会议、即时通讯工具或任何其他第三方知识共享工具。
敏捷 - 完成的定义
用户故事、迭代和发布的完成的定义如下。
用户故事
用户故事是用用户的日常语言用几句话表述的需求，应该在迭代中完成。当满足以下条件时，用户故事就完成了:
- 所有相关代码都已签入。
- 所有单元测试用例都已通过。
- 所有验收测试用例都已通过。
- 帮助文本已编写。
- 产品负责人已接受故事。
迭代
迭代是产品发布期间要处理和接受的用户故事/缺陷的时间限制集合。迭代在迭代规划会议期间定义，并通过迭代演示和审查会议完成。迭代也称为冲刺。当满足以下条件时，迭代就完成了:
- 产品备份已完成。
- 性能已测试。
- 用户故事已被接受或移至下一次迭代。
- 缺陷已修复或推迟到下一次迭代。
发布
发布是一个重要的里程碑，代表产品/系统的工作和测试版本的内部或外部交付。当满足以下条件时，迭代就完成了:
- 系统经过压力测试。
- 性能已调整。
- 已执行安全验证。
- 已测试灾难恢复计划。
敏捷 - 发布计划
发布计划的目的是制定计划以向产品提供增量。每 2 至 3 个月进行一次。
谁参与?
Scrum Master − Scrum Master 充当敏捷交付团队的推动者。
产品负责人 − 产品负责人代表产品待办事项的总体视图。
敏捷团队 − 敏捷交付团队提供有关技术可行性或任何依赖关系的见解。
利益相关者 −客户、项目经理、主题专家等利益相关者在围绕发布计划做出决策时充当顾问。
规划的先决条件
发布计划的先决条件如下 −
由产品负责人管理的经过排序的产品待办事项。通常，产品所有者会选择 5 到 10 个特性，这些特性可以包含在发布中
团队对功能、已知速度或任何技术挑战的意见
高层次愿景
市场和业务目标
确认是否需要新产品待办事项
所需材料
发布计划所需的材料清单如下 −
- 已发布的议程、目的
- 活动挂图、白板、记号笔
- 投影仪、共享计算机的方式，其中包含计划会议期间所需的数据/工具
- 规划数据
规划数据
进行发布计划所需的数据清单是如下 −
- 之前的迭代或发布计划结果
- 来自各个利益相关者对产品、市场条件和截止日期的反馈
- 之前版本/迭代的行动计划
- 要考虑的功能或缺陷
- 来自之前版本/估计的速度。
- 组织和个人日历
- 来自其他团队和主题专家的输入，以管理任何依赖关系
输出
发布计划的输出可以是以下内容 −
- 发布计划
- 承诺
- 要监控的问题、关注点、依赖关系和假设
- 改进未来发布的建议计划
议程
发布计划的议程可以是 −
开幕式 − 欢迎词、回顾目的和议程、组织工具以及向业务赞助商介绍。
产品愿景、路线图 − 展示产品的全貌。
回顾以前的版本 − 讨论任何可能影响计划的项目。
发布名称/主题 − 检查路线图主题的当前状态并进行必要的调整(如果有)。
速度 − 展示当前版本和以前版本的速度。
发布时间表 −审查关键里程碑并决定发布和发布内迭代的时间范围。
问题和顾虑 − 检查任何顾虑或问题并记录下来。
审查和更新完成的定义 − 审查完成的定义并根据自上次迭代/发布以来的技术、技能或团队成员的变化进行适当更改。
要考虑的故事和项目 − 介绍产品待办事项中要考虑在当前发布中进行安排的用户故事和功能。
确定大小值 − 如果速度未知，则规划要在发布计划中使用的大小值。
粗略确定故事的大小 −交付团队确定所考虑故事的适当大小，如果故事太大，则将故事拆分为多个迭代。产品所有者和主题专家澄清疑问，阐述验收标准，并进行适当的故事拆分。Scrum 主管促进协作。
将故事映射到迭代 − 交付团队和产品所有者根据大小和速度在迭代中移动故事/缺陷。Scrum 主管促进协作。
新的关注点或问题 − 根据以前的经验检查任何新问题并记录下来。
依赖关系和假设 − 检查发布计划期间计划的任何依赖关系/假设。
提交 − Scrum 主管要求进行计划。交付团队和产品负责人将其标记为最佳计划，然后承诺进入下一个规划级别，即迭代规划。
沟通和物流规划 − 审查/更新发布的沟通和物流规划。
停车场 − 流程停车场意味着所有项目都应得到解决或设置为行动项目。
分发行动项目和行动计划 − 将行动项目分发给其所有者，处理行动计划。
回顾 − 征求参与者的反馈意见，使会议取得成功。
关闭 −庆祝成功。
敏捷 - 迭代规划
迭代规划的目的是让团队完成一组排名靠前的产品待办事项。此承诺的时间范围基于迭代长度和团队速度。
谁参与?
Scrum Master − Scrum Master 充当敏捷交付团队的推动者。
产品负责人 − 产品负责人处理产品待办事项的详细视图及其验收标准。
敏捷团队 −敏捷交付定义了他们的任务并设定了履行承诺所需的工作量估计。
规划的先决条件
- 产品待办事项中的项目已确定大小并分配了相对故事点。
- 产品所有者已对投资组合项目进行了排名。
- 已明确说明每个投资组合项目的验收标准。
规划过程
以下是迭代规划所涉及的步骤 −
- 确定一次迭代中可以容纳多少个故事。
- 将这些故事分解为任务，并将每个任务分配给其所有者。
- 每个任务都以小时为单位给出估计时间。
- 这些估计时间可帮助团队成员检查每个成员在迭代中有多少任务小时数。
- 根据团队成员的速度或能力为他们分配任务，以免他们负担过重。
速度计算
敏捷团队根据过去的迭代计算速度。速度是在一次迭代中完成用户故事所需的平均单位数。例如，如果一个团队在过去三次迭代中每次迭代分别获得 12、14、10 个故事点，那么该团队可以在下一次迭代中将 12 作为速度。
计划速度告诉团队在当前迭代中可以完成多少个用户故事。如果团队快速完成分配的任务，则可以引入更多用户故事。否则，故事也可以移出到下一个迭代。
任务容量
团队的容量来自以下三个事实 −
- 一天中理想的工作小时数
- 迭代中人员的可用天数
- 成员专门为团队可用的时间百分比。
假设一个团队有 5 名成员，承诺全职(每天 8 小时)从事一个项目，并且在迭代期间没有人休假，那么两周迭代的任务容量将是 −
5 × 8 × 10 = 400 小时
规划步骤
- 产品负责人描述产品待办事项中排名最高的项目。
- 团队描述完成该项目所需的任务。
- 团队成员负责这些任务。
- 团队成员估计完成每项任务的时间。
- 这些步骤针对迭代中的所有项目重复执行。
- 如果任何个人的任务负担过重，那么他的/她的任务将分配给其他团队成员。
敏捷 - 产品待办事项
产品待办事项是待完成项目的列表。项目按功能描述进行排名。在理想情况下，项目应分解为用户故事。
为什么产品待办事项很重要?
- 它经过准备，可以对每个功能进行估算。
- 它有助于规划产品路线图。
- 它有助于重新排列功能，以便为产品增加更多价值。
- 它有助于确定优先考虑的事项。团队对项目进行排名，然后建立价值。
产品待办事项的特征
每个产品都应该有一个产品待办事项，其中可以包含一组大到非常大的功能。
多个团队可以处理一个产品待办事项。
功能的排名基于业务价值、技术价值、风险管理或战略适应性。
在发布计划期间，排名最高的项目会分解为较小的故事，以便在未来的迭代中完成。
敏捷 - 有用的术语
验收标准
这是产品所有者或客户为接受功能有效并符合其要求而设置的条件。
待办事项整理
这是一个持续的过程，产品经理或客户通过从敏捷团队获得反馈来管理产品待办事项。此过程包括对投资组合项目进行优先排序、将其分解为较小的项目、为未来迭代规划、创建新的故事、更新验收标准或详细阐述验收标准。
容量
这是团队在一次迭代中可以完成的工作量。
功能
对产品或对利益相关者有价值的能力所做的改进，可以在发布中开发。
迭代
基于主题的工作项，可以在时间框内完成并在产品发布期间接受。迭代工作在迭代规划期间定义，并以演示和评审会议结束。它也被称为 Sprint。
增量
增量是产品在逐步开发过程中状态的变化。它通常由里程碑或固定迭代次数表示。
产品负责人
产品负责人是敏捷交付团队的成员，负责收集和排列产品待办事项中的业务需求。产品负责人传达在发布/迭代中要做什么。他/她设定承诺并负责保护团队免受迭代期间需求变化的影响。
产品待办事项
功能性和非功能性产品需求集。
产品待办事项项目
可能是敏捷团队要开发的用户故事、缺陷、功能。
点
用于设置用户故事、功能或任何其他投资组合项目的相对大小的通用单位。
发布
一个时间框，在此时间内完成工作以支持向软件交付可测试的增量。在 Scrum 中，发布由多个迭代组成。
要求
软件产品的规范，以满足规定的合同或功能。用户故事和项目组合项是需求的类型。
故事点
敏捷团队用来估计用户故事和特性相对大小的单位。
冲刺
与迭代相同。
时间盒
开发可交付成果的固定持续时间。通常，除了固定时间盒的开始和结束日期外，资源数量也是固定的。
任务
它是一个工作单元，有助于在迭代内完成用户故事。用户故事分解为多个任务，每个任务都可以分配给团队成员，并将他们标记为任务的所有者。团队成员可以根据需要负责每项任务、更新估计、记录已完成的工作或待办事项。
用户故事
列出的验收标准以满足用户的某些要求。它通常是从最终用户的角度编写的。
速度
衡量迭代或时间框中接受的工作的权重。通常它是迭代中接受的故事点的总和。
