天下武功，唯快不破！在这样一个快速变化的时代，企业也在追求高响应力（快）的路上一路狂奔！这才有了敏捷、DevOps大行其道。然而，很多企业发现，虽然团队号称敏捷了，但是响应力变化并不明显，质量可能还下降了，程序员996加班更严重了。这是敏捷/DevOps转型的锅吗？企业该怎么办？
单腿走路的敏捷是假敏捷
敏捷转型常常从管理实践开始，搭起看板，把任务可视化；每天站会；有了迭代计划会和回顾会，迭代运作起来了。然而压力接踵而至。
以前几个月才上一次线，现在两周就要上线，还要留出时间给测试和部署，开发的时间少了。自动化程度严重不足、手工操作效率低、经常出错。测试人员也抱怨测试时间更少了，根本没有办法做必要的回归测试，生产事件开始增多，客户满意度下降。
压力之下，996成为标配，质量成为牺牲品。随着质量下降，生产问题增多，技术骨干开始忙于救火，无暇顾及日常开发质量，导致新代码质量越来越差，形成了质量差、忙于救火、质量更差的恶性循环。
这不是真的敏捷！真的敏捷不仅需要管理实践提升团队协作水平、发现和暴露问题，还需要有效的技术实践解决问题。最重要的是，敏捷不会妥协质量，因为质量是一切的根本。
质量是一切的根本
当团队面临压力时，最容易妥协的就是质量。先不说质量问题导致的业务影响，单看它对团队自身的影响就已经让人震惊了。
为了解决质量问题，团队要消耗大量的时间。问题发现得越早，解决的成本越低。当产品发布后发现问题，成本就更高了。至少要经过发现问题、复现问题、修复问题、验证修复效果、部署上线再验证这么多环节才能把它解决掉。
当团队焦头烂额地解决层出不穷的质量问题时，又会在当前项目的进度压力下继续妥协质量，陷入无法自拔的漩涡。伴随代码质量的下降，会不断积累技术债。当技术债积累到一定程度，系统再也无法支撑新的需求。
残酷的现实是，加人无法解决质量问题，加人只能让团队以更糟糕的质量完成任务。代价就是降低未来的响应力。
要实现高响应力的目标，同时让团队实现可持续的良性运作，就必须将质量放在第一位，而这离不开人员能力的提升。
能力是绕不开的门槛
我在很多客户那里看到这样的代码，它们有一个共同的特点：一次性。这些代码是程序员一次性完成的，也只能一次性使用。因为没人能再看得懂，包括作者自己。未来的变更成本将高于重新开发的成本。
对比其它行业，我们也看到软件行业的怪象。很少有人能够一次性把文章写出来就可以发表，人们需要打草稿、修订，不断推敲润色。但代码可以，写出来的草稿读不懂没关系，CPU能读懂就行；同样没有任何一个建筑师可以一遍就把图纸设计出来。但代码可以，一次性写完，只要没被测出Bug，任务就完成了；
这不是程序该有的样子。代码同样是需要打草稿不断推敲的，需要及时优化调整它的结构，确保它不仅运行正确，而且可读性好、易维护。这个叫重构的能力非常重要。缺了重构的能力，团队开发出来的系统刚上线就进入苟延残喘的状态，过不了2-3年就不得不重新开发新系统替换掉它。而具备重构的能力，系统可以持续演进，基业长青。
要想达到程序该有的样子，就必须提升人的能力，如何才能提高人员能力？
面向程序员的能力评估和认证
管理学大师彼得德鲁克曾经说过“你如果无法度量它，就无法管理它”。对于代码，SonarQube这样的静态代码扫描工具可以在某种程度上度量代码质量。但就像Word的拼写检查功能，它能够识别错别字，却无法告诉你文章写得好不好。
我们需要提前一步，帮助程序员评估和提升自身能力，从而能够自己刻意练习。因此我认为”重构能力评估与认证“是一个好的选择。它不是考卷，不仅仅只考察最终代码，还要考察写代码和重构的过程。它能够：
- 帮助程序员：评估自身能力，找到差距，通过刻意练习提升自我，进而加薪晋爵（认证勋章）。
- 帮助团队：评估团队成员重构能力，构建人才金字塔，切实提升代码质量。再也不会出现代码走查发现不了问题的状况了！
- 帮助组织：建立招聘、晋升门槛，管理外包供应商团队，构建质量护城河，实现能力提升、交付质量提升的双赢。
欢迎扫码进一步了解“重构能力评估及认证服务”。
