附录B:使用 GitHub 项目进行敏捷管理

GitHub 是一个代码托管服务，在过去十年中已经在开发界占据了主导地位，成为托管软件产品的事实标准平台。虽然 GitHub 革新了开发者在代码协作的方式，但直到 2021 年 GitHub Projects 的推出，它才拥有了一个正式的内建项目管理工具。与传统的项目管理工具（这些工具通常与代码库分离）不同，GitHub Projects 与 GitHub Issues 无缝集成，使开发者能够轻松地跟踪任务和软件项目的整体进度。GitHub Projects 使团队能够创建一个灵活的 电子表格、任务看板 和 路线图，涵盖现有的 Issues 和 Pull Requests。GitHub Projects 并非为了特定的管理方法而设计，提供了高度的灵活性和可定制性。在本学习模块的这一部分，我们将学习如何使用 GitHub Projects 进行敏捷软件开发。我们将学习如何在 GitHub Projects 中创建一个敏捷看板，以及 如何在电子表格中筛选和分组用户故事。最后，我们将学习 如何使用 GitHub Projects 的路线图功能规划迭代。

创建标签(label)

我们将首先创建一个 “用户故事(user story)” 标签，用于标记在我们仓库中表示用户故事的问题。

您可以为单个仓库创建标签，也可以将它们添加到组织的默认标签中，以便它们自动添加到该组织中所有未来创建的仓库。

为单个仓库添加标签：

导航到一个现有的 GitHub 仓库，或为本学习模块创建一个新的仓库。
点击导航栏中的 Issues 按钮。
然后点击右上角的 Labels 按钮。

为组织添加默认标签：

在 GitHub.com 右上角，点击您的头像，然后点击 Your organizations。
在相应的组织旁边，点击 Settings。
在侧边栏的 “Code, planning, and automation” 部分，选择 Repository，然后点击 Repository defaults。
点击 New label 按钮来创建一个新标签，并按照以下字段填写：
- Label name: user story
- Description: 一个标记问题为有效 用户故事 的标签
- Color: 任何未被其他标签使用的颜色
- 点击 Create label 按钮创建新标签。

重复上述步骤以创建 task 和 spike 标签：

任务标签：
- Label name: task
- Description: 一个标记问题为任务的标签
- Color: 任何未被其他标签使用的颜色
探索性任务的标签：
- Label name: spike
- Description: 一个标记问题为 探索性任务 的标签
- Color: 任何未被其他标签使用的颜色

重复上述步骤创建 4 个新标签，标记 MoSCoW 模型中的不同优先级水平，如下所示：

必须有：
- Label name: must have
- Description: 用于标记 “必须有” 用户故事的标签
- Color: 任何未被其他标签使用的颜色
应该有：
- Label name: should have
- Description: 用于标记 “应该有” 用户故事的标签
- Color: 任何未被其他标签使用的颜色
可以有：
- Label name: could have
- Description: 用于标记 “可以有” 用户故事的标签
- Color: 任何未被其他标签使用的颜色
不会有：
- Label name: won’t have
- Description: 用于标记 “不会有” 用户故事的标签
- Color: 任何未被其他标签使用的颜色

创建里程碑(milestone)

我们现在将为我们的项目添加一个里程碑，代表第一个同步点。

导航到一个现有的 GitHub 仓库，或为本学习模块创建一个新的仓库。
点击导航栏中的 Issues 按钮。
然后点击右上角的 Milestones 按钮。
点击 New milestone 按钮来创建一个新的里程碑，并填写以下字段：
- Title: v1.0.0
- Due date: 暂时留空
- Description: 本项目中的第一个里程碑，代表第一个稳定版本。
最后，点击 Create milestone 创建里程碑。

创建模板(template)

我们现在将创建一个用于表示 用户故事的 issue 模板，在我们的仓库中使用。

点击导航栏中的 Settings 按钮，查看仓库设置。
向下滚动，点击位于 Issues 部分下 Set up templates 按钮。
点击 Add template，然后从下拉菜单中选择 Custom Template。
接下来，点击您刚才创建的自定义模板旁边的 Preview and edit 按钮。
点击模板标题旁边的铅笔图标(pencil icon)来编辑模板字段。

填写如下字段：

Template name: User Story
About: 用于在 GitHub Issues 中创建用户故事的模板。

Description:

# User Story
- 提供一个从客户角度出发的用户故事的高层次描述。请勿在此部分包含实现细节。描述该功能、其行为以及它将帮助用户实现的目标。
- 回答以下问题：
    - 我们为谁构建这个功能？
    - 他们想要实现什么？
    - 他们试图实现的整体利益是什么？它如何契合更大的目标？
- 您可以使用以下格式来描述用户故事：“作为一个 <用户类型>，我希望 <执行某个任务>，以便我可以 <实现某个目标>。”

# Linked Tasks
- 在此输入关联任务，使用 # 符号进行链接。

# Estimation of Effort
- 提供此用户故事完成并成功实现所需工作量的估算，使用以下估算等级：
    - Not Specified
    - Trivial
    - Easy
    - Normal
    - Hard
- 尽量避免过度思考此过程或花费太多时间进行估算。
- 默认选项是 “Not Specified”，如果不确定，可以保留此项。

# Acceptance Criteria
- 描述必须满足的条件，才能被用户、客户或其他相关方接受。
- 验收标准应该是可测试的，并为开发人员提供测试指南。
- 验收标准应使用以下格式：“Given（如何开始），when（采取的行动），then（采取行动后的结果）。”

Labels: user story

填写完毕后，点击 Close preview 按钮以关闭预览。
最后，点击 Propose changes，然后点击 Commit changes 保存新的用户故事模板。

重复上述步骤，创建任务模板，填写以下信息：

Template name: Task
About: 用于在 GitHub Issues 中创建任务的模板。

Description:

# Task Description
- 描述需要完成的新功能或技术工作。

# Linked User Story (-ies)
- 在此链接与该任务关联的用户故事。

# Subtasks
- [ ] 在此列出子任务。
- [ ] 使用复选框方便进度跟踪。

Label: task

最后，重复此过程创建 Spike 模板，填写以下信息：

Template name: Spike
About: 用于在 GitHub Issues 中创建 Spike 的模板。

Description:

# Spike Description
- 描述您想要探索的工具、库、框架等，并解释为什么它对项目是必需的。

# Linked User Story (-ies)
- 在此链接与该 Spike 关联的用户故事。

# Subtasks
- [ ] 在此列出子任务。
- [ ] 使用复选框方便进度跟踪。

Label: spike

创建拉取请求模板(pull request template)

我们现在将为功能拉取请求和 bug 修复拉取请求创建模板：

导航到您 GitHub 仓库的 Code 标签页。
点击 Add file 按钮，然后选择 Create new file。
在文件名字段中输入 .github/PULL_REQUEST_TEMPLATE/feature_pr_template.md。

在文件中添加以下内容：

### Feature Description
- 在此描述新功能。

### Expected Behavior
- 描述预期行为。

### Test Cases
- [ ] 详细说明您使用的测试用例。
- [ ] 使用复选框帮助进行测试的开发人员跟踪进度。

### Additional Information
- 描述您所做的附加更改/步骤，例如用于在数据库表中添加列的 SQL 命令。

点击 Commit changes 以保存文件。

重复上述过程，使用以下信息创建 bug 修复拉取请求模板：

文件名: .github/PULL_REQUEST_TEMPLATE/bugfix_pr_template.md

文件内容:

# Bug Fix Title

### Issue Description
- 描述此问题。

### Steps to Reproduce
- 提供逐步重现此问题的指南。

### Expected Behavior
- 描述预期行为。

### Solution/Fix Description
- 描述解决/缓解该问题所采取的方法。

### Test Cases
- [ ] 详细说明您使用的测试用例。
- [ ] 使用复选框帮助进行测试的开发人员跟踪进度。

### Additional Information
- 描述您所做的附加更改/步骤，例如用于在数据库表中添加列的 SQL 命令。

当您创建拉取请求时，可以在 URL 中添加以下查询参数，来使用上述的模板之一：
- ?template=feature_pr_template.md
- ?template=bugfix_pr_template.md

创建新项目

现在我们已经创建了用户故事标签和模板，我们可以继续在 GitHub Projects 中创建一个新项目。

在您的仓库中，点击导航栏的 Projects 按钮，然后点击 Link a project 旁边的下拉箭头，选择 New project。
Link a project 按钮将变成 New project，点击 New project 按钮。
在弹出窗口中，从左侧面板选择 Board，为您的项目输入一个名称，然后点击 Create。
您的项目面板已创建。确保将 View 1 重命名为 Board。

GitHub Projects 中的默认项目面板将包含三个容器：Todo、In Progress 和 Done。

添加新容器

如前所述，Agile Board 应该有 7 个容器：Product Backlog、Sprint Backlog、Icebox、Todo、In Progress、Awaiting Review 和 Done。

点击 Done 容器旁边的 + 按钮以创建一个新容器。
接下来，点击 New Column 并在弹出窗口中填写表单。首先，我们将创建 Product Backlog 容器。您可能希望在容器名称后面括号中包含每个容器中应包含的项目类型，以帮助团队成员区分不同的容器。
如果要修改现有容器，点击容器右上角的三个点（省略号），然后从下拉菜单中选择 Edit details。
按照以下步骤为每个容器重复创建过程，并输入以下信息：
- Product Backlog
  - Label text: Product Backlog (User Stories)
  - Color: Red
  - Description: Contains user stories that have not been assigned to a sprint backlog.
- Sprint Backlog
  - Label text: Sprint Backlog (User Stories)
  - Color: Orange
  - Description: Contains user stories that are part of the current sprint.
- Todo
  - Label text: Todo (Tasks or Spikes)
  - Color: Green
  - Description: These tasks haven’t been started.
- In Progress
  - Label text: In Progress (Tasks or Spikes)
  - Color: Yellow
  - Description: These tasks are actively being worked on.
- Awaiting Review
  - Label text: Awaiting Review (Tasks or Spikes)
  - Color: Pink
  - Description: These tasks are complete but have yet to be reviewed.
- Done
  - Label text: Done (Tasks or Spikes)
  - Color: Purple
  - Description: These tasks have been completed.
- Icebox
  - Label text: Icebox (Tasks or Spikes)
  - Color: Blue
  - Description: Contains “frozen” user stories that may or may not be addressed in the future.
您可以点击一个容器并拖动它来重新排列容器的顺序。您的最终 Agile Board 应该类似于如下图所示的布局：

（可选）添加 Completed 容器

GitHub Projects 提供了一个 “洞察(Insights)” 功能，允许用户创建报告和图表。默认报告包括 “燃尽图” 报告，它展示了项目项随时间的进展。这个图表可以用来查看进度、发现趋势和识别瓶颈，从而帮助推动项目向前发展。您可以自定义这个图表来计算用户故事的燃尽速率。然而，“洞察” 报告不包括归档的项目。因此，如果您计划使用此功能，您不应归档已完成的用户故事。相反，您可以创建一个新的 “Completed（用户故事）” 容器，用于存放已关闭的用户故事。

要创建 “Completed” 容器：

点击 “Icebox” 容器旁边的 + 按钮来创建一个新容器。
接下来，点击弹出窗口中的 “新建列” 并填写表单：
- 标签文本：已完成（用户故事）
- 颜色：灰色
- 描述：包含已完成的用户故事。
最后，点击 “保存” 按钮。

做出此更改后，您将能够在每个迭代结束时将已完成和已关闭的用户故事移动到该容器，而不是归档(archive)它们。请注意，您仍然可以归档已完成的任务或探索(spike)项。

添加路线图(roadmap)

现在我们的看板已经准备好，我们将在 GitHub Projects 中为我们的路线图创建一个备用视图。点击 “看板” 标签旁的 “新建视图” 按钮，并从下拉菜单中选择 “路线图”。

将新视图重命名为 “路线图”。接下来，点击新视图右上角的 “日期字段” 按钮，然后选择 “新建字段”。在字段名称框中输入 “迭代”，并选择 “迭代” 作为字段类型。选择迭代应开始的日期以及其持续时间（以周为单位）。最后，点击 “保存并创建”。

现在，您需要点击 “日期字段”，分别选择 “迭代开始” 和 “迭代结束” 作为开始日期和目标日期，然后点击 “保存”。

添加表格

我们现在将创建最终的视图，该视图包含一个类似电子表格的表格。点击 “Board” 标签旁边的 “New View” 按钮，然后从下拉菜单中选择 “Table”。

将新视图重命名为 “Table”。点击 “Status” 列旁边的 “+” 按钮，勾选 “Labels”，“Milestone” 和 “Iteration” 以显示这些隐藏字段，然后点击 “Save”。

您可以根据需要在未来显示或隐藏字段。

禁用 "Item Closed" 工作流

GitHub Projects 中的默认工作流会自动将已关闭的 issue 移动到 “Done” 容器。虽然这对于已关闭的任务可能有用，但已关闭的用户故事应该保留在您的 Sprint Backlog 中，直到迭代结束。因此，禁用 “Item Closed” 工作流是有意义的。

在您的项目的右上角，点击省略号按钮打开菜单。
从下拉菜单中选择 “Workflows”。
在 “Default workflows” 下，选择 “Item closed”。
点击右上角的蓝色切换按钮将其关闭。

将项目保存为模板

现在我们已经完成了 GitHub 项目的设置，我们将其保存为模板，以便在未来的项目中重复使用。

通过点击右上角的三个省略号打开项目设置页面，并从下拉菜单中选择 “Settings”。

在 “Templates” 类别下，点击 “Copy as template” 按钮。

在弹出的窗口中，选择所有者，输入项目名称，然后点击 “Copy as template”。

您的模板现在已作为独立的项目保存。请勿将此模板项目作为实际项目使用。保持它在此状态，这样您就可以始终复制它并将其作为未来项目的起点。

请注意，未来使用此模板的项目可能需要更新迭代字段，选择不同的开始日期或持续时间。

要编辑未来使用此模板的项目中的迭代：

导航到您的项目。
在右上角，点击三个省略号以打开下拉菜单。
在菜单中，点击 “Settings” 进入项目设置。
在左侧列表中，点击您想要调整的迭代字段名称。
在此页面中，您可以根据需要添加或移除迭代。

创建示例用户故事

现在我们的模板已经准备好，我们将解释如何根据之前制定的敏捷工作流程来使用它。

在与您的客户和/或利益相关者会面并收集用户故事和史诗之后，您需要将收集到的用户故事以 issue 的形式输入 GitHub，并使用我们之前创建的模板。

您可以通过以下两种方式创建新问题(issue)：

导航到 GitHub 仓库的 Issues 标签页，点击 New Issue，然后点击 User Story 模板旁边的 Get started 按钮。
从敏捷看板中，点击 Product Backlog 容器底部的 Add Item 按钮，然后输入井号（#）并选择您的 GitHub 仓库。您将看到 Create new issue 选项，点击该按钮后会弹出新窗口，点击 User Story 模板旁边的 Choose 按钮。

接下来，我们将创建一个示例用户故事。为了本学习模块的目的，我们将创建一个与使用 MacID 凭证添加单点登录（SSO）相关的用户故事。

用户故事的标题遵循之前章节中提出的格式：“作为内部用户，我希望使用我的 MacID 登录，这样我就不必创建一个单独的账户。”

接下来，填写用户故事的正文。以下是该部分应包含的信息示例：

# 用户故事
- 该用户故事面向内部客户。
- 内部客户希望使用现有的 MacID 凭证登录到 Web 应用程序。
- 该用户故事的主要好处是，内部客户无需创建新账户或记住新的凭证来使用 Web 应用程序。这也将降低 Web 应用程序的使用门槛，并使登录过程对内部用户更加顺畅。

# 关联任务
- 待定(TBD)

# 努力估算
- 普通(Normal)

# 验收标准
- 假设我是内部客户，当我点击 “登录” 按钮时，我应该能够选择使用我的 MacID 和密码登录。
- 假设我是内部客户，当我输入有效的 MacID 和密码凭证时，我应该成功登录应用程序，并进入主页面。
- 假设我是已经登录的内部客户，当我关闭浏览器标签并在新标签页中打开 Web 应用程序时，Web 应用程序应该要求我重新登录。

在 “用户故事” 部分，我们回答了模板中列出的主要问题，同时还提供了基本的努力估算以及验收标准。

确保为该问题添加 “user story” 标签。此外，鉴于此用户故事直接与我们的 Web 应用程序的安全性相关，且我们无法发布不符合最低安全要求的 Web 应用程序，因此我们将此用户故事分类为 “Must Have” 标签。

该用户故事代表一个功能，应包含在第一次稳定发布中，点击右侧边栏的 Milestone 并选择 v1.0.0。

我们的用户故事是一个更大史诗的一部分，该史诗围绕为内部和外部用户提供多种登录选项展开。该史诗在一个外部 Word 文档中定义，如下所示：

接下来，我们将为此特定的史诗创建一个标签。我们建议为所有史诗标签使用相同的颜色，并保持名称相对简短。我们还鼓励开发人员使用以下命名约定来为史诗标签命名：epic: <title>。

要从用户故事页面创建其他标签，请点击右侧的 齿轮图标，然后从下拉菜单中选择“Edit labels”，接着点击 “New label” 并填写名称、描述和颜色字段。

我们为史诗输入了以下信息：

标签名称：epic: sign in options
描述：为用户提供多种登录选项
颜色：#6D258D

输入标签信息后，点击 “Create label”。

最后，返回到用户故事页面并添加新创建的史诗标签。

添加另一个用户故事

按照上述步骤，创建另一个用户故事，内容围绕为外部用户提供使用其 Google 账户登录 Web 应用程序的功能。

我们建议使用以下标题：“作为外部用户，我希望使用我的 Google 账户登录，这样我就不必创建一个新账户。”

将以下描述添加到用户故事的正文中：

# 用户故事
- 该用户故事面向外部客户。
- 外部客户希望使用现有的 Google 账户凭证登录到 Web 应用程序。
- 该用户故事的主要好处是，外部客户无需创建新账户或记住新的凭证来使用 Web 应用程序。这也将降低 Web 应用程序的使用门槛，并使登录过程对外部用户更加顺畅。

# 关联任务
- 待定(TBD)

# 努力估算
- 普通(Normal)

# 验收标准
- 假设我是外部客户，当我点击“登录”按钮时，我应该能够选择使用我的 Google 账户登录。
- 假设我是外部客户，当我输入有效的 Google 账户和密码凭证时，我应该成功登录应用程序，并进入主页面。
- 假设我是已经登录的外部客户，当我关闭浏览器标签并在新标签页中打开 Web 应用程序时，Web 应用程序应该要求我重新登录。

确保为该用户故事添加 “user story”，“must have” 和 “epic: sign in options” 标签，并选择 v1.0.0 作为里程碑。

将用户故事添加到敏捷看板

打开你的 GitHub 项目，点击 “产品待办(Product Backlog)” 容器底部的 “添加条目” 按钮。接下来，输入井号（#）并选择你的 GitHub 仓库，从菜单中选择我们刚刚创建的两个用户故事。

你的 “产品待办(Product Backlog)” 容器现在应该是这样的：

填充冲刺待办事项(sprint backlog)

当你准备开始开发项目时，你需要选择一组用户故事来进行第一次迭代开发。通常建议从高优先级（即 “必须有(Must Have)”）的用户故事开始，但你也应该考虑不同用户故事之间的依赖关系。例如，如果完成某个用户故事是其他用户故事的瓶颈，那么先完成该用户故事可能会有利，以便在未来的迭代中处理其他依赖的用户故事。如果在这个评估过程中遇到你想要冻结的问题，确保将其移到 “Icebox” 容器中。

我们当前的产品待办事项非常简单，所以我们将首先通过将 “MacID 单点登录” 用户故事拖动到 “迭代待办(Spring Backlog)” 容器来开始。

你可以点击迭代待办中的用户故事，并为其分配开发人员和迭代（即冲刺）。

从用户故事创建任务/子任务

开发人员应为当前冲刺待办事项中的每个用户故事创建任务和/或子任务。然后，任务可以转换为问题，随后提交拉取请求，在准备好后进行审查并合并。请注意，并非每个任务或子任务都需要转换为问题。通常可以使用一个全面的任务，将其转换为问题，然后提交拉取请求，并附带若干相关的子任务。我们现在将以拆分 MacID 单点登录用户故事为任务和子任务为例进行详细说明。

点击 Todo 容器底部的 Add item 按钮，添加以下任务（不使用 # 符号选择仓库）：“Add MacID SSO using MS Azure and the msal-react library”。请注意，任务可以使用技术术语，并且不需要从客户的角度编写。
现在我们将把主要任务转换为问题，方法是将鼠标悬停在任务卡上，点击右上角的三个点按钮，从下拉菜单中选择 “Convert to issue”，然后选择适当的仓库。
接下来，点击容器中的任务卡并为其分配开发人员和迭代。点击 编辑按钮，在出现的文本框中输入 /（斜杠）。
从下拉菜单中选择 “Templates”。
从下拉菜单中选择 “Task” 以加载任务模板。

更新任务正文，填写以下信息：

# Task Description
- Add the ability to sign into the web application using valid MacID credentials
- We will be using the `msal-react` library to enable SSO using MS Azure

# Linked User Story (-ies)
- #1

# Subtasks
- Register SPA in MS Azure AD
- Create environment and authentication configuration files
- Wrap template in `MsalProvider` component
- Create `SignInButton` and `SignOutButton` components
- Create `PermissionGate` component to check if a user is signed in or not
- Create the Microsoft Graph client helper
- Update existing pages to be restricted unless a user is logged in

注意，我们通过输入 “#” 符号并从下拉菜单中选择用户故事来链接用户故事。用户故事的编号可能与你不同。
确保为问题打上我们之前创建的任务标签。
记得回到用户故事页面，并更新 “Linked Tasks” 部分，如下所示：

在容器中移动任务

一旦开发人员开始处理一个任务，他们将创建一个包含所需更改的分支。

该任务应根据以下进度轨迹在容器之间移动：

当开发人员开始处理任务时，应将任务卡片移动到 “In Progress”（进行中）容器中。
当开发人员完成任务时，他们应创建一个拉取请求：
- 进入仓库的 “Pull Request” 选项卡，点击 “New pull request”。
- 选择源分支。
- 在 URL 中添加 ?template=feature_pr_template.md 或 ?template=bugfix_pr_template.md，然后按 Enter 键重新加载页面。
- 点击 “Create pull request”。
- 填写拉取请求的标题和正文。
- 点击 “Create Pull Request”。
通过打开拉取请求并点击侧边栏中的 “Development”，然后选择任务，将拉取请求与任务关联。
为拉取请求添加审阅人(Reviewers)和负责人(Assignees)。
将任务卡片移到 “Awaiting Review”（等待审核）容器中。
当拉取请求经过测试并获得批准时，任务卡片应移到 “Done”（完成）容器中，负责该任务的开发人员也应关闭任务（即在 GitHub 中关闭问题）。
一旦所有与某个用户故事相关的任务完成，用户故事的问题也应被关闭。

使用路线图视图(Roadmap View)

“Roadmap” 视图允许你以日历视图查看当前迭代中的用户故事(user stories)和任务(tasks)。

使用表格视图

“表格” 视图类似于电子表格，允许根据不同的属性（如当前状态、标签、里程碑等）搜索特定的用户故事和任务，或进行筛选。

你可以使用表格右上角的 + 按钮来添加或移除字段。

此外，你还可以使用表格上方的搜索框来查找特定的用户故事或任务。例如，下面的查询将返回所有位于 “产品待办(Product Backlog)” 中的 “必须完成(Must Have)” 的用户故事。

完成一次迭代

一个迭代在分配的持续时间结束并且所有 “冲刺待办(Sprint Backlog)” 中的用户故事都关闭后即完成。请注意，您可以通过点击用户故事并选择 “关闭问题(Close Issue)” 按钮来关闭一个用户故事，确保从下拉菜单中选择 “关闭为已完成(Close as completed)”。

如果您不打算使用 “Insights” 功能（因此没有创建 “已完成” 容器），可以通过点击用户故事标题和编号旁边的三个点，选择下拉菜单中的 “归档(Archive)” 来归档一个用户故事。

如果 “冲刺待办(Sprint Backlog)” 中的所有用户故事都已完成，您可以通过点击 “冲刺待办” 容器右上角的三个点按钮并选择 “归档所有” 来归档所有用户故事。

或者，如果您有一个 “已完成(Completed)” 容器，您可以通过拖放或者点击用户故事标题和编号旁边的三个点，选择 “移动到列” 并从列表中选择 “已完成（用户故事）” 将已完成的用户故事移动到该容器。

在一个迭代结束时，团队应该召开会议，评估当前迭代中完成的工作。理想情况下，当前 “冲刺待办(Sprint Backlog)” 中的所有用户故事此时应该都已完成。然而，如果团队还有未完成的用户故事，它们可以在下一个迭代中解决，或者如果用户需求发生变化，也可以移回 “产品待办(Product Backlog)” 或 “冰箱(Icebox)” 容器。

迭代结束时的会议也是团队评估项目进展的好机会，可以识别出项目中的薄弱环节，并相应地修改工作方法或策略。

见解(Insight)

GitHub Projects 提供了一个 “Insight” 功能，允许用户生成有用的报告和图表。

要访问 Insight 页面，请点击项目右上角的 “前往洞察” 按钮。

洞察页面默认包含 “燃尽图”。默认情况下，这个图表包括所有项目（即用户故事、任务和冲刺）。如果您只想查看用户故事的燃尽图，只需在 “按关键字或字段过滤” 框中添加以下查询：is:issue label:"user story"。上述查询会将图表限制为标记为 “用户故事(user story)” 标签的问题。

结论

在本学习模块中，我们了解了敏捷方法论的基础知识，包括其历史、支柱、原则和关键组件。我们还将敏捷与传统的瀑布式软件开发方法进行了比较，展示了采用敏捷的好处。以下是有关敏捷的关键点总结：

敏捷是一种软件开发方法论，强调通过增量和迭代的步骤来创建软件程序。
开发者将通过增量构建他们的软件项目，使用的迭代周期长度和工作量不同，称为“冲刺”（Sprints）。
敏捷强调开发者与客户或利益相关者之间的持续沟通，并鼓励对需求变化保持开放态度。
在敏捷中，工作软件 是唯一的进度衡量标准，因此开发者不应在估算或不必要的规划上花费过多时间。
用户故事 是从客户的角度出发，描述功能需求或要求的高层次说明。
史诗是由多个用户故事组成的集合，形成一个较长的整体用户需求。
任务是从用户故事中创建的技术性待办项，帮助开发者组织工作。较大的任务可以被拆解为更小的子任务。
Spikes 是关于学习某个框架或工具的待办项，通常出现在任务之前。
同步点 是开发者聚集在一起的机会，评估整体进展并根据反馈更新工作流程或需求。
敏捷看板 是一个帮助开发者跟踪用户故事和任务的工具，通常包含多个列或容器，包括产品待办（Product Backlog）、冲刺待办（Sprint Backlog）、冰箱（Icebox）以及如 “待办”（Todo）、“进行中”（In Progress）、“待审查”（Awaiting Review）和 “已完成”（Done）等状态容器。
敏捷中的用户故事有不同的优先级，高优先级的用户故事优先实施。
与瀑布式项目相比，敏捷项目在所有规模上都有更高的成功率和更低的挑战与失败率。
敏捷方法最适合一次处理一个项目的团队。
我们还学习了如何在 GitHub Projects 中实现和使用敏捷看板。

GitLab

我们没有在本学习模块中介绍如何使用 GitLab 的 “问题看板”（Issues Board）工具创建敏捷看板，因为它提供的灵活性不足以采用本模块中推荐的敏捷方法。GitLab “问题看板” 中的容器或列表必须具有固定范围，即它们必须共享相同的标签、指派人、里程碑或迭代，才能出现在同一列表中。这一限制使得我们无法创建所需的容器（如产品待办、冲刺待办、待办等）并将问题（用户故事/任务/Spikes）在其中移动。因此，如果您正在启动一个新项目并希望使用本学习模块中涵盖的敏捷方法，建议选择 GitHub，而不是 GitLab，因为 GitHub Projects 更适合创建敏捷看板。