敏捷开发：想要快速交付就必须舍弃产品质量？

在创新驱动的市场环境中，敏捷开发已成为许多组织的首选软件开发方法。其关键优势在于能够快速适应市场变化，并频繁地交付靠谱的产品。然而，快速交付的同时，团队要如何确保产品质量，确保交付的产品都是高质量的、可靠的且附加价值的，一直以来都是大家挑战以及争论的焦点。

敏捷开发原则植根于"持续交付有用的软件"，不过这并不意味着快速交付就要牺牲质量。这是一种误解。实际上，敏捷开发最本质的部分是找到平衡点。本文将和大家一起聊聊如何在敏捷开发中平衡快速交付和产品质量这二者。

方法一：持续集成与持续交付

敏捷开发强调“持续”：持续集成（CI），持续部署/交付（CD）。这些都强调了同一个点，即软件必须始终保持在可交付状态。之所以这样，是因为团队可以快速，频繁地获取反馈，并据此改进产品。而我们实现这一点的关键工具包括自动构建和测试，版本控制，以及构建流水线等。

CI/CD 行动指南

Jenkins和GitLab作为最知名的流水线自动化工具之一，在DevOps实践中发挥着重要作用。它们帮助团队构建出高度定制化的流水线，满足项目的需求，并实现持续集成、持续交付的目标。

比如在禅道项目管理软件中（集成了Jenkins和GitLab），开发者在每次提交代码到Git时，Jenkins可以自动执行构建和测试。这一流程不仅提升了开发效率，而且确保每次提交的代码都能通过测试，显著提高了代码质量。

ZenTao pipeline function

利用版本控制工具，例如禅道项目管理软件，支持管理多种类型的源代码管理工具，包括本地私有化部署的Git和Subversion，以及流行的GitLab、Gitea、Gogs等源代码托管平台，保证所有的源代码和文档都能被追踪，随时可以获取历史版本。除了利用工具，也可以建立规则，确保只有测试通过的代码才能被合并进主开发分支。此外，可以采用更为成熟的持续发布流程，自动化生产环境的部署和发布。

ZenTao: Source code management tool

方法二：测试驱动开发

测试驱动开发是一种以测试先行的开发模式，即先写测试，再写代码。这在理论上可以帮助我们避免因过早地投入到过多的开发工作中，而无法保证其质量。这还有助于确保我们的代码正常运行和可读，并且反映出实际需求。

行动指南

在编写任何新功能的代码前，先写具有挑战性的测试。确保测试的是基于客户的需求，而不仅仅是基于技术的考量。这样一来，代码的正确性和完备性就有了保障，同时还能提供随时可用的使用文档。

方法三：团队协作

我们都知道在敏捷开发中，团队共享责任。开发、测试、产品以及其他干系人都对质量负责。换句话说，质量不仅仅是测试团队的责任，也是开发团队的责任。我们可以在建立明确的协作和沟通方式、定期的团队会议或者其他形式的协作中，在开发过程中的每一步都强调质量。

行动指南

所有团队成员，无论是开发者还是业务方，都必须认可在项目中分担责任这一共识。这是通过提供持续而高效的沟通来实现的。例如，利用每日站立会议、迭代规划，以及回顾会议等形式进行。

方法四：及时迭代和快速反馈

及时迭代和快速反馈，并不意味着团队要一次性地尝试完成所有的工作，而是将其分解成小块，以便快速并有效地完成所有工作。每一轮迭代都包括规划、分析、设计、编码、测试以及回顾。每个阶段都是为了提高质量和适应变化，以便我们可以快速交付有价值的产品。

行动指南

将项目分成多个小的迭代周期进行，每个周期重复规划、分析、设计、编码和测试步骤。在每个周期结束后，进行回顾会议，寻找改进的地方，为下一个周期提供反馈。

在迭代和反馈的过程中，我们可以利用禅道提供地看板和燃尽图等工具来进行项目的追踪和管理。看板将项目进度可视化，方便团队成员随时查看当前的工作进展。燃尽图则为我们提供了一种从宏观角度了解项目的有效工具，通过查看燃尽图，我们可以了解到当前的工作量和项目进度，从而做出相应的调整。

ZenTao Burndown Chart Function

方法五：质量内建

质量内建，即质量保障体系，在敏捷开发中将质量视为内建的，而不是在完成所有开发工作后再去实现的。我们通过设立质量目标，进行代码审查，编写单元测试，执行集成测试，以及其他质量保证的措施来实现这一点。此外还强调整洁编程，以及重构等实践，以确保我们的代码始终保持良好，可维护的状态。

行动指南

将质量保证视为一个持续、整个开发周期都在进行的过程，而不局限于某个阶段。通过自动化测试、重构、简单设计等手段，可以使在编码阶段引入的缺陷变少。除此以外，还可应用静态代码分析工具，在构建过程中自动执行。并定期进行代码审查，以增加分享知识和提升代码质量的机会。对于重构，也应视其为常规的开发活动，根据需要迭代修改代码，确保开发和维护的便利性。

其他有效实践

结对编程：它并非很多人简单地认为是一人写码、一人观看（因为这样其实是浪费了一个人力）。它更像汽车拉力赛，导航员看地图并告诉驾驶员前路如何、该如何行驶，所以他的视野会更加宏观，看得更远，引导驾驶员思维。同样，在编程中也是一个人输入代码，另一个人引导思路，通过这种互相协作的模式提升代码质量。

代码评审：就是大家坐在一起，分享代码的收获、踩过的坑以及解决问题的方法、技巧，并非形式化的质量审查，而是开发的交流分享会。

暴徒式编程：是结对编程的延伸，只有一个人操作键盘，并定时，其他人根据屏幕显示进行指导。每隔一段时间换人 。

通过合理地引导和实施上述行动，团队能更容易在快速交付和保持高质量之间找到平衡，记住，敏捷并不是在速度和质量之间做出取舍，而是找到二者之间的平衡，依靠团队的协作，使得速度和质量可以共同提高。不过知易行难，但是采用敏捷精神，并且接受持续改进的思想，是值得的，一旦真的步入敏捷的道路，在施行的过程中，不断通过各种实践，修直前行的道路，团队一定会有质的改变与提升，持续地提供高质量的产品。