敏捷武士：卓越软件的交付之道

〇、前言

因为工作需要，又开始对DevOps进行了一番研究，这次应该是认真的了。

DevOps算是一种当下比较流行的理念，知识体系也算不上繁杂，让我深有启发的是出自《DevOps三十六计》中的一幅图：

三、交付启动计划

这个概念也是从“敏捷武士”那里习得的，初看，确实不太容易理解，而且，书中多个章节都提到了“交付启动计划”，似乎是一个实施敏捷过程的必经之路，促使我又回到前面，去了解“交付启动计划”到底是什么。

思考“HOW”的人只增不减，而思考“WHY”的人却不见增多。

所以，在回答“为什么做这个项目”的时候，交付启动计划给出了非常有意思的答案：电梯演讲和产品包装。

电梯演讲的挑战在于需要你在30秒钟的时间内阐述你的核心思想。短小精悍，思路清晰，直达要点，能做到实属不易，需要和团队多次演练才能做出一个好的演讲。“敏捷武士”给出了一个电梯演讲的模板，读者可以自行填空：

把价值上百万的软件塑封起来，放在超市货架上，虽然离这一天还有很长的路要走，但这确实也引出了一个非常有趣的问题：如果可以从超市的货架上购买软件产品，那产品包装应该是什么样子重要的是，我们会购买吗/p>

“敏捷武士”把这个产品包装的设计过程分为了三步：集思广益，列举产品优势；设计一条广告词；设计产品包装（海 ）。

如果你所在的是一支仪式感十足的团队，那么按上述步骤来做未尝不可，不过，大多数情况下是不会这么做的。

个人建议是把项目的优缺点给想清楚就行了，能清楚意识到自己在做个什么玩意儿就行了。至于那些非常酷炫的宣传图，slogan之类的，让其他部门去操心吧！

四、一些敏捷文化

这个章节并不是把《敏捷宣言》拿出来讲一遍，而是我从这两本书中强烈感受到的敏捷团队必须具备的文化氛围。在此，我只会抛出这些概念，不会进行详细阐述，可以自行阅读感受。

价值导向。很现实的一件事情，我只做对客户来说有价值的东西。如果一件事情风险高，一件事情价值高，螺旋模型会选择风险高，敏捷开发会选择价值高，当然，现实情况往往都是需要平衡的，无绝对。

集中办公。并不要求每个月拉团队出去浪一浪，每个礼拜请团队成员吃吃喝喝，保证团队成员畅通明晰的沟通渠道才是关键，能口头沟通的就尽量不要用IM，事后需要总结的话，就发一份邮件简要说明。

全员参与。这里的“全员”（最好）包括客户，如果有专职客户，那是一件非常幸福的事情。如果你自己都不知道客户是谁，或者从来就没见过客户，那就只能祝你好运了。

通用语言。你可能在DDD中看到过整个词汇，但这并不意味着一定用采用这种开发模式。通用语言的好处显而易见，至少在你说A的时候，别人不会理解成a。当然，实际情况是，业务部门才不管你用什么通用语言，各种词汇往外喷。多聊几次，建立起业务部门的通用语言与技术部门的通用语言的映射关系，当然，这是没有办法的办法了。

拥抱变化。其实你所做的大多数文档在软件交付之前就可能过时了，源码是最好的交付成果，而制造源码的程序员才是公司宝贵的资源。敏捷开发本质上是一个发现偏差，迅速纠偏的一个过程。

测试驱动开发。这个未必能做到，但是我注意到了其中单元测试的重要性，而且可行性很高：发现一个Bug，为此写一个单元测试。这样做可以让你了解Bug的存在，复现之，并且在今后的持续集成中，减轻回归测试带来的痛苦，自动部署的信心也增强了。

随时重构。不得不承认，这部分跟程序员的代码水平是有一定关系的，为了避免后期累积大量的技术债务，导致大面积重构，需要有随时重构的习惯，这部分的能力可以在Code Review阶段得到加强。

生产就绪。这种文化要求有些高了，人们都在追求财务自由，而敏捷开发的程序员们却在追求产品部署自由。

五、总结

最后，不要再去纠结一大堆的需求文档，产品文档，或者是技术文档，一切都是够用就行。可工作的软件是衡量项目进展成功的主要指标。

敏捷开发并不是对传统软件工程的一次颠覆，只是加速了整个软件开发过程的闭环，以适应当下时代对软件开发效率的更高要求。

敏捷开发不“敏捷”，与君共勉。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8697 人正在系统学习中