什么是敏捷开发?

敏捷开发是一个用于描述迭代软件开发的术语。 迭代软件开发通过以短期增量(通常称为冲刺)的形式来完成工作,从而缩短 DevOps 生命周期。 冲刺通常为一到四周。 敏捷开发通常与传统或瀑布式开发形成对比,后者会提前计划较大的项目并根据计划完成它们。

在每个冲刺中交付生产质量代码要求敏捷开发团队加快步伐。 所有的编码、测试和质量验证都必须在每一次冲刺 (sprint) 中完成。 除非已正确设置团队,否则结果就可能低于预期。 虽然这些失望提供了很好的学习机会,但开始之前,吸取一些关键教训会很有帮助。

本文介绍敏捷开发团队的部分关键成功因素:

  • 细致的积压工作优化
  • 提前和频繁集成
  • 尽可能减少技术债务

细致的积压工作优化

敏捷开发团队需处理积压的需求,而这些需求通常被称为用户故事。 积压工作会按优先级排列,最重要的用户故事位于顶部。 产品所有者拥有积压工作,并根据客户需求添加、更改用户案例并重新排列其优先级顺序。

Image of a Kanban board that contains several columns. In each column, a few cards are visible.

敏捷团队工作效率的最大障碍之一是定义不佳的积压工作。 除非团队有明确定义的需求,否则无法指望团队在每个冲刺中始终如一地交付高质量软件。

产品负责人的工作是确保每个冲刺,而工程师已明确定义要处理的用户故事。 积压工作顶部的用户故事应始终可供团队开始处理。 此概念被称为积压工作优化。 为敏捷开发团队做好积压工作准备需要付出努力并遵守纪律。 幸运的是,这很值得投资。

优化积压工作时,请记住以下关键注意事项。

  1. 优化用户故事通常是一项长期活动。 优雅的用户界面、美轮美奂的屏幕设计以及客户满意的解决方案都需要时间和精力来打造。 勤奋的产品负责人会提前将用户故事优化为二到三个冲刺。 他们会考虑设计迭代和客户评价。 他们努力确保每个用户故事都是敏捷团队自豪交付给客户的一项成果。

  2. 除非团队这样表态,否则就不会优化用户故事。 团队需要评审用户故事,并认定它已准备好进行处理。 如果团队在冲刺的第一天之前未看到用户故事,则可能会导致问题。

  3. 积压工作中靠后的用户故事可能仍然模糊不清。 不要浪费时间去优化低优先级项目。 专注于积压工作的顶部。

提前和频繁集成

持续集成持续交付 (CI/CD) 为团队设定了敏捷开发的快速步伐。 尽快自动执行构建、测试和部署管道。 将自动化设为团队在启动新项目时需处理的首批任务之一。

借助自动化,团队可避免速度缓慢、容易出错且十分耗时的手动部署流程。 由于团队会发布每个冲刺,因此没有时间去手动执行这些任务。

CI/CD 还会影响软件体系结构。 它可确保交付可构建和可部署的软件。 当团队实现难以部署的功能时,如果构建和部署失败,他们就会立即意识到问题。 CI/CD 会迫使团队立即解决部署问题。 然后,该产品便会始终准备好交付。

Abstract bar chart that shows the status of CI builds over time. Most builds succeeded. Only a few failed.

有一些关键 CI/CD 活动对于行之有效的敏捷开发至关重要。

  1. 单元测试。 单元测试是针对人为错误的第一道防御措施。 将单元测试视为编写代码的一部分。 将测试签入代码。 让单元测试成为每个构建的一部分。 失败的单元测试意味着构建失败。

  2. 构建自动化。 构建系统应在构建运行时直接从源代码控制中拉取代码和测试。

  3. 分支和构建策略。 配置分支和构建策略,以在团队将代码签入到特定分支时自动进行构建。

  4. 部署到环境中。 设置一个发布管道,以便自动将构建的项目部署到模拟生产环境。

尽可能减少技术债务

对于个人财务,远离债务比从债务中脱身更为容易。 此规则也适用于技术债务。 技术债务包括团队因之前走了捷径而必须解决的所有内容。 例如,如果你的日程安排很紧,你可能会牺牲质量来满足最后期限。 当你必须重构代码来弥补这种质量缺乏问题时,技术债务就成了一种后续需偿付的代价。 示例包括用于解决设计不佳、bug、性能问题、操作问题、辅助功能问题和其他问题的修复工作。

控制技术债务需要勇气。 延迟代码返工存在很多压力。 处理功能而忽略债务让人感觉很好。 不幸的是,有人迟早还须偿还技术债务。 就像财政债务一样,技术债务存在的时间越长就越难偿还。 智能产品负责人会与他们的团队合作,以确保有时间在每个冲刺期间偿还技术债务。 平衡技术债务与功能开发是一项艰巨的任务。 幸运的是,有一些简易技术可用于打造以客户为中心的高效团队

始终保持敏捷

敏捷意味着从经验中学习并不断改进。 敏捷开发可提供比传统项目规划更多的学习周期,因为其流程回路更为紧凑。 每个冲刺都可为团队提供了一些可供学习的新内容。

例如:

  • 团队会向客户提供价值,获取反馈,然后根据该反馈来修改其积压工作。
  • 他们了解到其自动化构建缺少关键测试。 他们会通过在下一冲刺中包含工作来解决此问题。
  • 他们发现某些功能在生产中性能不佳,因此制定了提高性能的计划。
  • 团队中的有人听说了某一新做法。 团队决定尝试进行一些冲刺。

刚开始接触敏捷开发的团队应期待更多学习机会。 它们是此流程的宝贵组成部分,因为它们可带来成长和改善。

后续步骤

有许多方法可选定适合团队的敏捷开发流程。 Azure DevOps 提供了各种流程模板。 正在为其规划寻找不同基线结构的团队可使用这些模板作为起点。 有关选择最适合团队文化和目标的流程模板的信息,请参阅选择要在 Azure Boards 中使用的流程流或流程模板

随着组织的发展,保持纪律可能会成为一个挑战。 详细了解如何将敏捷扩展到大型团队