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