敏捷与DevOps里没有最佳实践，只有正确姿势

“敏捷与DevOps的目标是为了高效交付以适应快速变化的市场环境和业务需求。落地敏捷与DevOps最重要的是因地制宜，在原则的指导下寻找最适合自己的具体实践和工具，并且持续改进。没有所谓的“最佳实践”，如果照套“最佳实践”就可以实现目标，我们早就不必再谈敏捷和DevOps的话题了。但是，每个具体实践都有它的正确姿势，都有其清晰的目标，姿势错了，你就无法实现其原则和目标。下面我观察到的一些实践误区。我将逐一分析并给出正确姿势。”

01

—

Scrum

不少宣称在实践Scrum的团队只是把瀑布中的开发阶段，截断成一个个短的周期，其结果是，每个Sprint出来的都是未经验收的半成品，并没有实现持续交付。更可怕的是，不少项目经理把Sprint planning当做承诺，计划了10个故事，团队加班加点都要在Sprint结束前把这10个故事死出来。试问，这样的Scrum和瀑布有什么区别？

Scrum的目的是为了把整个项目拆分成一个个小的业务目标。通过一个个Sprint，看到成品，从而让业务或用户对产品有一个更清晰的认知，是一个验证假设的过程，如果通过前期交付发现假设不成立，也可以及时调整产品和需求方向。

正确的姿势是，每个Sprint要有一个清晰的小目标，然后Sprint planning是把相关的用户故事与该目标匹配的过程。当然，团队需要估算能完成哪些用户故事。DOR（符合什么条件可以开始开发，比如已澄清业务价值和有具体的验收条件等）和DOD（什么叫在Sprint内完成，是Ready for release还是ready for UAT还是ready for SIT）也要有清晰的约定。每个Sprint应该能产出一些业务价值。

我明白现实有很多限制阻碍你达成目标，要么坚持原则死磕到底，要么重新思考Scrum是否真的适合你的环境。

02

—

每日例会

每日例会如果超过半小时，姿势肯定不对，没有人会喜欢每天固定开一个长会。例会时间被拖长，一定是在会上讨论某个具体问题。

正确姿势是，每日例会一定要限定时间，不要超过20分钟。议程是1）查看持续集成结果；2）对着看板或Scrum板从右往左过在制品的进度；3）询问是否有问题、阻碍、提醒和分享。有问题的时候，如果不能快速得出结论，把该问题记录下来，以便次日例会回溯情况，但具体讨论应该单独安排时间找相关同事进行。为什么进度板要从右往左看呢？因为我们要聚焦完成。一个用户故事只有交付到生产环境才能产生价值，进度板的右端相当于“临门一脚”，如果右端不及时完成该做的事情，比如用户不及时完成验收测试，左端做得再快也没有，而且会堆积半成品，造成浪费。如果人数太多，势必难以把控时间，应该考虑拆分团队或者思考哪些人可以不必参加。

每日例会的目的是快速反馈，及时发现问题和清除障碍。站着开还是坐着开不重要。

03

—

自动化测试

一提起自动化测试，很多人就抡起袖子把现有的功能测试全部进行自动化。这工程浩大得成了不可能的任务，而且如果功能测试都是UI测试的话，其执行时间、稳定性都是问题。

自动化测试的目的是给你一个关于质量的快速反馈，如果不能实现快速反馈，就要掂量掂量是否值得做下去。

正确的姿势是，根据测试金字塔原则，应该最大化单元测试的自动化，最小化UI测试的自动化。单元测试简单、隔离性高、依赖少，编写和执行的速度快，可以实现快速反馈。UI测试执行时间长，结果不稳定，应该更多用于冒烟测试。要最大化单元测试，应该实践测试驱动编程（TDD），编程前想好该如何进行单元测试，写好测试再编程，以终为始。这样你就可以为每一个新特性累积自动化测试用例，并在持续集成中执行，形成稳固的质量基石。单元测试应该尽量少地依赖外部环境，它应该聚焦在你要完成的逻辑，而不是具体的输入、输出环境（网络、中间件、数据库等），因此应该尽量适用Mock技术，把单元测试和集成测试区分开。

04

—

行为驱动开发（BDD）

很多团队运用了像Cucumber、Fitness、Concordion等的BDD测试框架就宣称在实施行为驱动开发了。但其测试用例都是开发自己写的。虽然让用户、业务参与是一个难点，包括要求他们在开发前给出具体的验收条件也不符合他们原来的习惯，不容易。但对不起，没有用户、业务参与，真心不叫行为驱动开发。因为如果“行为”不是用户或业务的期待，那么你写的还是单元测试或集成测试，虽然可读性比JUnit要高，但并没有实现行为驱动开发的终极目的。

行为驱动开发的目的是以终为始，通过提前与用户、业务确认具体的验收测试，锁定交付的完成定义，并可以在交付前验证是否满足验收条件，形成交付闭环。

所以正确的姿势不是单纯运用工具，而是要把验收条件是否确认作为开发的前置条件，如果没有验收条件，对不起，需求不完整，开发不能开始。在此基础上，再通过那些行为驱动开发测试框架把验收测试过程自动化。所以自动化和工具不是目的，只是锦上添花，切勿本末倒置。

05

—

持续集成

不少团队知道要搭建CI/CD流水线，于是上Jenkins成了标准动作。但是对Jenkins的构建结果却视若妄闻，最后持续集成沦为了纯粹的打包过程，没有对内建质量产生任何贡献。

持续集成除了编译、打包、上传以外，更重要的目的是每次有代码变动，或者每天都自动执行静态代码分析和测试代码，一旦有任何代码不符合规范或测试失败，立即被发现，通过及时修复，防微杜渐，防止质量问题流入到下一个阶段导致更高的修复成本。持续集成的结果是需要每天盯着的，一旦出现构建失败，必须要立即修复，否则问题一旦积累，便会积重难返，再也无法修复，最后不得不降低标准或屏蔽掉一些测试，从而导致代码腐化，自动化测试覆盖率不断下降，最终失去安全网的作用，前功尽弃。

因此，持续集成的正确姿势应该是，在测试驱动编程（包括行为驱动开发）和团队约定的静态代码分析标准的基础上，把这些过程纳入到持续集成中，并且每天监控集成结果，一旦出现构建失败，应该停止交付，直到问题修复为止（这一点和精益/看板里提倡的安灯相通，任何人发现问题都可以拉停整个生产线，防止缺陷下移）。由于每日代码变动非常有限，每日监控、立即修复可以防微杜渐，事半功倍。在敏捷交付中，永远把质量放在第一位。建议把监控持续集成结果放在每日例会的首位。

06

—

看板

很多宣称使用了看板的团队就是竖了一块物理进度板。一段时间后上面的卡片纹丝不动，成为摆设，也没有限制在制品。我要再重申：没有流动的不叫看板，没有限制在制品的不叫看板！！！

看板的原则很简单：1）进度可视化；2）限制在制品；3）观察和改善流动。就这么简单还要偷懒吗？有关看板的正确姿势，请参阅我的文章

《开启你的敏捷之旅，只需要这5步

》和《为什么我更推崇看板方法》，这里不再累述。

引用具体的实践和工具只是一个起点，是手段，不是目的，它们是为了支撑我们所倡导的敏捷和DevOps的原则和理念，实现高效交付。在这个过程中，一定要多问为什么，为做而做不如不做。任何时候发现背离了高效交付的原则和目标，应该停下来好好思考是否姿势错了，并不断寻找适合自己的实践和工具。

关于作者

敏捷、精益、DevOps专家

精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

曾在GDevOps、DevOpsDays Meetup等论坛发表主题演讲

著有《猎豹行动：硝烟中的敏捷转型之旅》一书

请确保您的手机号码正确