敏捷正在蓬勃发展，身边好像每个公司都在推行“敏捷”，至少大家都是这么说的。调查显示，约90%的公司管理者将推进敏捷作为第一要务，然而尽管人们喜欢给自己戴上敏捷的帽子，但是在渴望敏捷与真正实现敏捷之间却存在着巨大的鸿沟，这其中充满了混乱与误解，仅10%的管理者认为他们的公司已经表现出了很高的敏捷性。
那么什么是敏捷呢？
从根本上说，敏捷是一套软件开发的哲学，它通过相互协作和自组织的团队来完成可工作的软件和解决方案的迭代开发。 它也是许多开发框架的总称，但是敏捷不仅仅意味着看板或Scrum。
当团队将敏捷方法等同于使用“敏捷框架（ Agile framework）”时，就会出现一些混乱。 这类框架之所以具有吸引力，是因为它们作为解决项目管理问题的简化解决方案比较易于理解和使用。 当然，这些框架可以成为敏捷实践的重要组成部分，但实践还需要坚实的基础，仅通过简单地实践这些行为并期望因此实现“正确的工作”是不够的，尤其是在从僵化和传统的习惯（如瀑布式）来转变时。
为了推动敏捷成功，团队需要理解并践行敏捷哲学，需要改变他们对工作职责、与客户的关系和义务的思考方式。
如果没有这种思想的支撑，Scrum和看板之类的框架将无法真正实现其价值。
在本文中，我将研究真正的敏捷与伪敏捷之间的区别，这通常也是成功的开发团队与失败的开发团队之间的区别。
本文大纲
1. 什么是假敏捷？
2. 为什么假敏捷对您的团队不利？
3. 如何发现假敏捷与真正敏捷之间的差异
4. 误导的敏捷领导力
5. 了解真正的敏捷
欢迎来到黑暗敏捷剧院...
敏捷的怀疑论者似乎对这种骇人听闻的事物非常着迷，以下是用来描述本文称为“伪敏捷”现象的少数术语：
僵尸Scrum、仿冒的敏捷、暗黑敏捷、敏捷剧院、名义上的敏捷、 敏捷BS ……
这个清单还可以列出很多，除了怪诞的隐喻之外，它们的共同点是缺乏促进真正的敏捷成功所必需的重要动力。
什么是伪敏捷呢？
首先，并没有用于评估敏捷性是否正确的标准化方法，敏捷最初的来源是一种哲学，而不仅仅是框架。我们需要的是“Be Agile"，而不仅仅是 “Do Agile"
此处的区别在于，对于“Be Agile" ，使用哪种框架都无关紧要，因为敏捷的某些核心价值得到了维护，几乎所有“真正的”敏捷框架都拥护这些相同的价值。
下面是美国国防部的一个对比图，说明了成功的敏捷与他们认为的“Agile BS”之间的根本区别：
虚假敏捷是一种浪费，是一个破坏的过程。 当团队只关注用户反馈，为了促进客户反馈而大量开发功能时，将会造成更多浪费，因为很多功能都没有达到目标。
我们需要关注是否由于过度的管理不民主地将他们的敏捷议程强加给尚未做好准备的开发团队， 或好心的项目负责人通过实施一种炙手可热的新方法来寻求提高其团队的生产力。而伪敏捷的根本问题在于其未达到其应有的表现。 更具体地说，伪敏捷是伪造的，因为它并没有真正维护敏捷的价值观和原则。伪敏捷是用糖衣（重命名）包装传统方法得到的，例如：
为什么伪敏捷会对团队带来不利呢？
Ron Jeffries 创造了”暗黑Scrum" 一词，他谈到Scrum时说：
“我真诚的认为Scrum是一个很好的框架，它通过与业务方建立牢固的联系，决定需要做什么以及需要推迟什么，这是很好的做法。 拥有在团队中正确构建产品所需的所有技能也是很好的。 每两周构建一次经过测试的有形产品，将其展示给利益相关者也是很棒的做法，并且回顾迭代的进展情况以及如何改进它们也十分必要。我已经研究、思考并与Scrum合作很多年了， 关于它的一切虽然并不完美，但确实已经相当不错了。”——敏捷宣言签署人，极限编程的创造者之一 Ron Jeffries
理想的敏捷可能会很好，但现实常常与愿望背道而驰，这两者之间的失调就是我们说的“伪敏捷”，他会带来什么问题呢？
让我们先看一下敏捷团队拥护所谓的敏捷方法的一些共同信念：
1. 现在，我们变得灵活得多，生产力更高！
2. 人与人之间的合作重于流程
3. 可工作的软件重于文档
4. 适应和调整的能力比坚持计划的能力更有价值
尽管这些陈述具有一定的道理，但许多敏捷方法将它们扭曲成了粗糙的实践，缺少了每个敏捷团队都需要的重要生命力–正确理解了敏捷背后的价值观。
加布里埃尔·贝内菲尔德（Gabrielle Benefield）在她的名为Frankenbuilds的GOTO会议中明确解释了粗暴敏捷方法的危害：如果敏捷是如此出色，为什么我们的产品如此糟糕？
她的观点可以归结为很多敏捷实践将敏捷过分简化为优先考虑数量而不是质量的系统。 她认为这种粗矿的“机关枪式的敏捷”方法会给团队带来压力，迫使他们推出更多常规工作版本，以增加实现正确目标的几率，但这会造成大量浪费。
为了更好地理解错误引导的伪敏捷方法的危险，请考虑以下示例。
想象一下，一个项目经理在日常工作中刚刚宣布：由于采用了新的敏捷方法，该团队已成功按时和按预算交付了35项功能。
这个数据很容易令人印象深刻并得到老板的青睐。但谁将使用这些功能？他们将如何帮助公司为客户提供更多价值并赚更多钱？为什么要有35个功能？使用两个或三个功能是否可以获得相同的结果？
虚假敏捷是“正确地构建错误的事物”。如果您没有从一开始就构建正确的东西，则无论使用看板，Scrum还是自定义的框架都没有作用。
假敏捷与真正敏捷：如何区分差异
我列出了几个关键领域，并阐明了假的敏捷方法与真正的敏捷方法有何不同。
忽略真实用户
真敏捷： 开发人员了解在开发和部署过程中与客户和用户进行沟通的重要性。 他们将共享开发进度并积极寻求反馈，以改进流程或产品。
伪敏捷： 开发人员对与应用程序的真实用户进行交流不感兴趣（程序测试和评估不计算在内）；如果有反馈，则它不是连续的（例如仅在项目开始时发生）。
时间收益递减
真敏捷：优先考虑构建工作并了解快速迭代的重要性。每周或至少在每个冲刺结束时完成新的功能的构建与发布。
伪敏捷：与快速发布可用的系统相比更关注需求。在冲刺结束时，很少能发布可用的系统版本。版本的发布工作经常被推到发布冲刺或“下一个冲刺”。
责任
真敏捷： 开发人员很活跃，并愿意为提供客户价值和对产品进行改进承担的责任。
伪敏捷： 开发人员会推卸责任，表现出“这不是我的工作”。
简化流程
真敏捷： 流程尽可能地自动化，以消除繁琐的手动任务，并专注于为客户提供价值。
伪敏捷：流程大部分是手动的；需要自动化的范围很大。
功能的重要性
真敏捷：专注于可工作软件的迭代开发，关键利益相关者的反馈在每个过程中都至关重要。
伪敏捷：专注于承诺和需求，可工作软件通常会被推迟到“另一个冲刺”。
被误导的敏捷领导
团队通常会分配Scrum主管和产品负责人等职位，实际上却发现这些人在实践中承担着与很多传统开发框架中的项目经理完全相同的职能，这种情况下一定会存在个人导致的瓶颈。 这在传统的开发结构中是可以预期的，传统项目结构中，项目经理基本上负责确保团队中的每个成员都能完成工作。而在敏捷团队中责任的本质是根本不同的。高效能的敏捷开发团队中的每个人应该有共同的责任感。
产品负责人和Scrum负责人在其中扮演着关键角色，例如向业务负责人报告并与利益相关者进行沟通，但是他们的角色与典型的项目管理职位存在着根本不同。
管理方法上的差异也表现在工作中对惩罚和恐惧的态度上。 如果个人害怕因失败而被惩罚，那么他们的创造力和创新能力就会消失。这种恐惧不会激发动力；它只是驱动数字并阻碍团队创意。
对惩罚的恐惧也使人们摆脱了责任感。 如果您的团队知道如果他们表现不佳将会被淘汰，不可避免地遭受更多损失，则个人就会花更多精力避免问责制，而不是专注于尽力而为。
追求“真正的”敏捷
”我们想重建平衡，我们接受创建模型，但是不是为了创造一些在资料库里吃灰的文件。我们使用文档，但不是那些很少使用且从不维护的文件。 我们进行计划，但要意识到在动荡的环境中进行计划的局限性“ —— 敏捷宣言
敏捷宣言的发表时间可以追溯到2001年的世纪之交，这是尝试理解“Be Agile "与“Do Agile” 意味着什么的最好起点，从本质上讲，它是一种哲学，它优先于任何单独的框架或方法。每个框架将采用不同的价值观和原则，但基础保持不变。“真正”敏捷的目标是引导及时开发出高质量的可工作的软件，并牢记客户的最大利益。为简化起见，可以这样理解：“ Be”是哲学。 “Do”是框架。
更多文章欢迎微信搜索 敏捷新视界
原文地址