一些IT人在畏惧敏捷，但管理阶层应该去调研敏捷的真相。
最近我和一个朋友聊天时吃惊地了解到他所在公司IT部分正在考虑的一些新变化。我吃惊地发现他们选择了更加烦琐的规程，尽管这些规程看上去根本无法生效。我问他们为什么不考虑使用敏捷的方法，答案是：高层领导认为“敏捷”这个词太过激动（is a swear word）。
问题的根本在于管理层没有真正地理解敏捷软件过程。他们听到了对之理解得不甚了了以及清楚从而很恐惧敏捷的属下的说法。敏捷计算的主要好处之一就在于他使得官僚主义和对组织没有贡献或贡献甚少的人难以容身。在过去复杂的传统的开发过程：重型和讲究文档的过程中，这些人能够很好地藏身其中，而敏捷方法却让他们没有藏身之地，或者意识到自己必须快速地提高自己的技能。
这种情况中，害怕敏捷的人会很狡猾地对管理层进行误导。而非常不幸的是，领导们往往想不起来请假一下了解故事的另一面的（像我这样的）专家。我曾经使用过诸如面向对象软件过程和企业统一过程（enterprise unified process）等传统的软件过程，也曾经使用过诸如敏捷建模和敏捷数据等敏捷过程（agile data）。
这家公司的领导听到关于敏捷的各种谎言，他们被告知，敏捷开发人员根本不建模，也不写文档，但事实是，敏捷开发者在每天都在进行分析和设计，而且要书写高价值的文档。他们被告知，敏捷开发者尽开发一些低质量的系统，这一点和事实恰恰相反。他们还被告知，敏捷就是黑客式开发的一个新名字，但只需要上www.agilealliance.org看看就知道事实并非如此。你真的认为业界的领袖们：Martin Fowler、Bob Martin、Alistair Cockburn、Barry Boehm和Jim Highsmith都在倡导黑客式的开发方式？
敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得开发更加成功。敏捷是大家肩并肩地工作，而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是成天去写状况报告，用那个来监督到底发生了什么事情。敏捷是开发人员和涉众（stakeholders，译者注：项目开发中涉及的从需求到最后交付的各种人员）在一起制定实际的计划，而不是用复杂的微软Project去制定一些几乎没人看的进度表。
公平地说，很难设想敏捷术能如何发挥作用，尤其是在一些软件开发本身都问题重重的传统组织中，被误导过的敏捷更是难以帮上什么忙。
文章来源于领测软件测试网 https://www.ltesting.net/