许多公司标榜自己在做“敏捷”。敏捷是执行软件开发的最新的框架。这个框架下有不同的方法，如Scrum，极限编程（XP），RUP等。Scrum目前是最热门的。一般来说，组织会使用一个混合的版本来适合他们的需求，也受到组织的环境限制（EEF、OPA；指的是企业环境因素，组织流程资产）(EEF/OPA, or enterprise environmental factors/organizational process assets). 因此，公司为什么要转型到敏捷呢？ 我们用敏捷宣言来概括回答这个问题： Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 敏捷赋予客户更改的灵活性，因为整个流程是迭代的并且客户知道每个迭代的进展。还有，团队计划且承诺每个迭代的工作，并一起完成承诺。 对于双方这是一种双赢的场景： 客户实时得到项目、产品的更新状态，并且客户可以自由地改变需求。 团队就像军队里的阿尔法单元（5-9个人），一起在短迭代内荣做。 不争的事实： 这些都是理论。然而生活不是非黑即白：哪里都有灰色地带。 “do Agile做敏捷”比“be Agile成为敏捷”更容易一些。敏捷需要一定的纪律来得到正确的结果。 会议在时间盒内吗？ 会议中你是很好的倾听者吗？ PO或者ScrumMaster就是唯一说话的人吗？ PO或ScrumMaster把工作“强加”给你吗？ 在Sprint计划会议时，PO不等团队的输入就要求承诺吗？ 被迫给故事ABC分配XYZ点数的估算吗？ 在回顾会议你不“公开”，因为害怕所说的适得其反吗？ 在sprint过程中你被迫承担新故事，而影响了你已经承诺的交付吗？ 在每日站会上你从来不谈论尽管已经存在的障碍？ 你希望PO或SM微管理而你只需要工作即可吗？ 你相信胡萝卜加大棒的管理方法很重要吗？ 这些场景只是其中很少的例子；可能的清单是无穷无尽的。这些表明你在“做敏捷”（只是为了完成而已），但你不是“成为敏捷”，因为你不知道敏捷实践和交付的真正重要性。 你可能是遵循瀑布式开发人的敏捷傀儡。这种Scrum是臭名昭著的“Water-Scrum-Fall”。（译者注：也有叫做Scrum-But） 我给这个方法起了个新名字：“潮湿的”Scrum 遵循瀑布式开发的实践Scrum就变“潮湿”了。人们根据场景和难度有选择的使用Scrum。然而这么做很难（几乎不可能）理解敏捷的精髓。 潮湿的Scrum如何工作 客户需要以下内容： 更多的人为干预 可控的工作组织在短迭代内，而不是把整个项目、产品作为一个整体进行管理。 事实更新完成的工作 改变需求的权利 高质量结果 这些都是Scrum理论上的交付物。然而，如果团队没有纪律性，也不关注使项目成功的话，就没有工作方法可以确保项目成功。