附录A:敏捷方法

敏捷是一种软件开发方法，强调通过增量和迭代的方式来创建软件程序的重要性。项目的每个增量周期称为 “冲刺(Sprint)”，通常在 1 到 4 周之间进行。敏捷方法优先考虑快速交付、适应变化、开发者之间的协作以及客户与开发团队之间的持续沟通。敏捷还减少了对自上而下管理和预设长期计划的依赖。

敏捷方法通过鼓励开发者打破项目孤岛并在每个增量开发周期中进行合作，促进了团队的协作工作。此外，软件开发者与客户之间的持续反馈循环使得团队能够优先考虑聚焦于客户需求的功能，并在需求变化时迅速调整重点。

另一方面，像瀑布模型这样的传统软件开发方法通常是线性推进的，包括规划、设计、实施、验证和维护等阶段。每个阶段必须完成后才能进入下一个阶段。这种线性的软件开发方法常常导致较低的成功率、更高的开发成本，以及可能无法满足客户不断变化需求的软件产品。

目标

本学习模块的目标是学习如何根据敏捷项目管理指南组织和进行软件项目。我们将涵盖敏捷方法的基础知识，包括其历史、支柱和原则，以及在这种软件开发策略中使用的主要组件。我们还将学习如何使用 GitHub Projects 工具创建看板，帮助你组织项目并遵循推荐的敏捷工作流。完成本学习模块后，参与者将能够更好地管理项目，以便逐步构建一个令人满意的软件产品，而不陷入传统软件开发方法（瀑布模型）的常见陷阱。

在本学习模块结束时，参与者将能够：

  • 描述软件开发的敏捷方法论

  • 理解敏捷的不同阶段

  • 理解敏捷方法论中涉及的不同组件

  • 在 GitHub Projects 中创建敏捷看板

  • 认识到使用敏捷方法相比瀑布模型的优势

  • 在设计阶段到部署阶段，以迭代方式进行软件项目的实施，采用敏捷方法

敏捷的历史

2000 年春季，一群 17 名软件开发人员在俄勒冈州会面，旨在寻找新的方法以加快软件开发时间，从而更快地将新软件推向市场。他们识别出两个关键机会，可能有助于他们实现目标：

  • 缩短从接收到软件项目的用户需求到交付最小可行产品之间的时间。

  • 从用户那里获得持续反馈，并据此对新软件进行持续迭代。

不到一年后，同一组 17 名开发人员再次在犹他州雪鸟举行会议。在为期三天的时间里，团队制定了《敏捷软件开发宣言》（通常称为敏捷宣言），其中列出了敏捷方法论的四大支柱。

敏捷的四大支柱是什么？

如《敏捷软件开发宣言》所述，敏捷软件开发有四大核心支柱：

  1. 个体和互动重于过程和工具：敏捷优先考虑团队协作，而非独立工作或遵循预定义的规则和流程。

  2. 可工作的软件重于全面的文档：敏捷的主要目标是通过迭代方式创建功能性软件。虽然文档有用，但它不像开发可工作的软件那样重要。

  3. 客户合作重于合同谈判：敏捷软件开发以客户需求和反馈为指导。因此，客户与软件开发团队之间的合作比合同谈判过程更为重要。

  4. 响应变化重于遵循计划：敏捷的主要优势之一是其灵活性和适应不断变化需求的能力。因此，敏捷允许团队迅速调整策略和工作流，而无需导致整个项目的脱轨或重启。

敏捷的12项原则是什么？

《敏捷软件开发宣言》列出了 12 条原则，这些原则应始终指导团队的决策和软件开发过程：

  1. 我们的最高优先级是通过早期和持续交付有价值的软件（或你交付的其他内容）来满足客户。

  2. 欢迎变化的需求，即使在开发的后期。敏捷流程利用变化为客户创造竞争优势。

  3. 经常交付项目，从几周到几个月，优先选择较短的时间周期。

  4. 协调的团队成员必须在整个项目中每天一起工作。

  5. 围绕有动力的个人构建项目。为他们提供所需的环境和支持，并信任他们完成工作。

  6. 面对面的交流是最有效且高效的信息传递方式，不论是对内还是对团队之间。

  7. 最终产品是进展的主要衡量标准。

  8. 敏捷过程促进可持续发展。所有利益相关者应能够保持一个持续的节奏。

  9. 持续关注技术卓越和良好设计能够增强敏捷性。

  10. 简单——最大限度减少不必要工作的艺术——至关重要。

  11. 最好的架构、需求和设计来自自组织的团队。

  12. 团队在定期的间隔时间进行反思，思考如何提高效率，然后调整行为以改进。

敏捷的关键组件是什么？

敏捷方法使用以下几个关键组件：

  • 用户故事(User stories)：用户故事是从客户的角度写的工作请求或程序功能的高层次描述。用户故事应清晰地概述客户的角色、他们的目标以及实现目标所获得的收益。用户故事的常见格式是：“作为 <用户类型>，我想要 <执行某任务>，以便我可以 <实现某个目标>。” 例如，“作为经理，我希望能够查看过去一个季度的所有费用报告，以便我可以为下一个季度进行预算。” 你可能希望为用户故事提供努力的估算。在对用户故事的努力进行估算时，我们强烈不建议使用故事点，因为它们会指数性地增加创建估算的时间，并使资源从开发工作中分散出来。相反，我们建议使用一个简单的估算规模来进行用户故事的努力估算。尽量避免过度思考此过程或在估算上花费过多时间。默认的努力估算选项应为 “未指定”，如果不确定使用哪个级别，可以保持默认选项。我们建议采用以下规模来估算努力，并根据需要进行修改，而不会显著增加估算过程的复杂性：

    • 未指定

    • 微不足道

    • 容易

    • 正常

    • 困难

  • 史诗(Epics)：史诗是相关用户故事的集合，当它们结合在一起时形成一个大的连贯的故事。如果你的项目管理工具不允许你在工具中跟踪史诗，你可以创建一个单独的文档（例如，Word 文档）来包含你的史诗。然后你可以使用标签来将属于同一史诗的用户故事分组。

  • 任务/探针(Task/Spike)：任务或探针是从用户故事中分解出来的单个工作单元。任务或探针是用户故事的一个子部分，帮助开发者识别实现用户故事所需的步骤。任务通常包括技术软件工作，如编写代码、设计系统、创建测试数据、自动化流程等。另一方面，探针是一个探索性的待办事项，旨在回答某个问题或探索一个潜在的软件工具或库。探针有助于开发者获取更多关于待做工作的知识，并减少不确定性。探针通常先于任务进行，例如，一个不熟悉 PostgreSQL 的开发者可能会想创建一个名为 “尝试 PostgreSQL 并学习如何使用它” 的探针，然后再进行 “创建关系型数据库并将其连接到前端客户端” 的任务。

  • 冲刺/迭代(Sprint/Iteration)：冲刺或迭代是一个短期指定的时间段，通常需要 1 到 4 周完成，在此期间，团队会处理一组确定的用户故事。敏捷的迭代性质意味着开发者需要不断重复冲刺，直到产品准备好。冲刺的长度可以根据工作量和客户的需求在不同的冲刺之间有所不同。在每个冲刺结束时，团队应重新集结，评估软件产品，识别出已完全功能化的部分和仍需要更多工作部分，做出调整，并开始另一个冲刺以改进产品。

  • 敏捷看板(Agile Board)：敏捷看板帮助开发团队跟踪整个项目以及每个独立冲刺或用户故事的进展。敏捷看板包含以下容器：

    • 产品待办列表(Product Backlog)：包含当前冲刺或迭代之外的用户故事。

    • 冲刺待办列表(Sprint Backlog)：包含当前冲刺或迭代中的用户故事。

    • 冰箱(Icebox)：包含被冻结的用户故事，未来可能会处理，也可能不会。只有当团队评估后决定将其冻结时，用户故事才应移到冰箱容器中。

    • 待办(Todo)：包含当前冲刺中尚未开始的用户故事相关任务。

    • 进行中(In Progress)：包含当前冲刺中正在进行的用户故事相关任务。

    • 等待审查(Awaitingg Review)：包含当前冲刺中已完成但尚未审查的用户故事相关任务。

    • 已完成(Done)：包含当前冲刺中已完成的用户故事相关任务。

  • 同步点/里程碑(Sync Points/Milestones)：敏捷团队需要定期聚集以规划他们的发布。通过使用同步点或里程碑，团队可以跟踪一组用户故事的进展。同步点/里程碑可以为软件产品的季度发布设置。在每个里程碑时，团队应重新集结，评估项目的进展，并根据需要进行调整，然后再进入下一组迭代。同步点也是进行大局评估、评估和反馈的机会。较短的冲刺或迭代可能会对软件产品的整体设计产生负面影响。然而，同步点使团队能够评估之前迭代中的目标如何完成，并有可能重新组织或重构软件设计，以提高清晰度或整体功能。区分专注于短期目标的迭代规划会议和专注于中期或长期目标和计划的同步点非常重要。

软件开发中的敏捷工作流是什么？

为了使用敏捷项目管理，我们建议使用以下工作流程来组织你的项目：

  1. 首先与项目的客户或利益相关者会面，收集以简单术语写成、从他们角度出发的用户故事。确保在用户故事中不包含实现细节。

  2. 将你的用户故事组织成史诗，通过找到互相关联的故事，并将它们组合成围绕单一主题的连贯史诗。

  3. 使用项目管理工具创建敏捷看板。

  4. 评估你的用户故事，识别出优先级更高的用户故事，并决定哪些应该在当前迭代中处理。如果遇到任何想要冻结的用户故事，确保将其移动到冰箱容器中。

  5. 将每个用户故事拆分为多个任务，任务中包含更多的实现和技术细节。然后，开发团队将处理这些任务。确保每个任务按以下顺序逐步通过容器：待办 → 进行中 → 等待审查 → 已完成。

  6. 迭代结束时，团队应重新集结，评估他们的进展，并根据客户反馈进行必要的调整。保持开放的心态，接受可能出现的需求变化。

  7. 一旦迭代完成，团队可以进入下一个迭代，重复步骤 4-6。

  8. 团队应设置同步点或里程碑，评估项目的进展，评估使用的策略以及项目的中期和长期目标。

  9. 然后，团队将继续通过冲刺的方式迭代地构建软件产品，直到创建出可部署的最小可行产品（MVP）。

image 2025 01 09 17 39 13 553

我们将在接下来的章节中提供更多具体细节，告诉你如何使用像 GitHub Project 这样的项目管理工具来实现上述工作流程。

如何在敏捷中优先排序用户故事？

在收集了客户或利益相关者的用户故事后，软件开发团队需要根据优先级对这些用户故事进行排序，以确保首先处理最关键的用户故事。有几种技术可以用来优先排序用户故事。我们推荐使用 MoSCoW 模型，该模型由数据科学家 Dai Clegg 提出。MoSCoW 模型源于敏捷方法论，其名称来自构成其标准的字母：Must Have（必须有）、Should Have（应该有）、Could Have（可以有）和 Won’t Have（不需要有）。

  • Must Have：此类别中的用户故事被视为高优先级且对成功发布至关重要，如果没有它们发布产品将是不安全的。如果团队可以想到解决方法，以便在没有 “Must Have” 用户故事的情况下发布产品，那么它应该被降级为 “Should Have” 或 “Could Have”。

  • Should Have：此类别中的用户故事重要，但对软件产品的正常运行不是必不可少的。忽略这些故事可能会影响软件的质量或功能，但不会影响产品的最小可行性。

  • Could Have：此类别可以视为愿望清单。若时间或资源有限，“Could Have” 类型的用户故事应当是首先被忽视或拒绝的对象。

  • Won’t Have：此类别包含团队一致认为不会纳入产品的用户故事。如果你认为某个 “Won’t Have” 类型的用户故事可能在未来重新考虑，可以将其放入敏捷看板的冰箱容器中。

团队必须避免在优先排序用户故事上花费过多时间或精力。敏捷开发中的唯一真正的进展衡量标准是功能性软件（即使它不完整）。过多地在用户故事的估算上花费时间，将减少用于开发软件产品的时间和资源，从而使你的方法论更远离敏捷的真正原则。

敏捷与传统软件开发方法（瀑布模型）相比如何？

Standish Group 混乱研究报告探讨了软件开发的多个方面，包括传统的瀑布式软件开发方法与敏捷方法的比较。该研究基于超过 10,000 个软件项目的样本进行分析。报告发现，使用敏捷方法的项目成功率几乎是瀑布式项目的四倍。此外，使用瀑布式方法的项目失败率是敏捷项目的三倍。结果还清晰地表明，瀑布式项目不具备良好的可扩展性，而敏捷项目则扩展性更好。

image 2025 01 09 17 42 12 985

上表显示了基于项目大小对敏捷与瀑布式项目进行的详细比较。Standish Group 将项目分为成功、挑战和失败三类，并根据以下定义进行分类：

  • 成功：如果一个项目满足三重约束（时间、成本、范围），则被认为是成功的。

  • 挑战：如果一个项目满足三个约束中的两个，例如按时按预算交付，但未达到预期的范围，则认为是挑战项目。

  • 失败：失败项目是指在完成之前被取消，或者虽然完成但没有被使用。

上表中的结果表明，所有大小的项目在采用敏捷方法时都会受益，因为所有规模的敏捷项目在成功率上都高于瀑布式项目，而挑战和失败率则低于同等规模的瀑布式项目。

image 2025 01 09 17 42 29 309

Standish Group 混乱研究还强调了掌握敏捷原则的重要性。报告发现，随着开发团队在敏捷方面能力的提高，敏捷项目的成功率也随之增加。同样，技能更高的敏捷团队在开发过程中通常面临的挑战较少，失败率也较低。因此，我们认为学习并掌握敏捷开发过程将大大有利于各类软件项目，并为开发团队带来长期的收益。

敏捷方法特别适用于专注于单个项目的团队。尽管同时处理多个敏捷项目是可能的，但将团队的时间和精力分散到多个软件项目上将导致更长的交付时间和质量妥协的软件产品。换句话说，团队并行处理的项目越多，敏捷的效率就越低。因此，我们建议根据优先级对项目进行排序，并一次只处理一个敏捷项目，以最大化生产力和效率。