当。。。的时候敏捷宣言它在大约15年前被引入，提出了一个根本性的方法改变，作为传统项目管理的替代方案。使用敏捷，项目需求和解决方案通过开发周期中的协作演进，将任务分解为小的增量。虽然这种方法有助于企业管理不可预测性，但它也要求企业采取不同的思维方式，以获得成功。
敏捷旨在推动产品和软件开发生命周期内的协作，透明度和质量，但它并不总是每个组织的正确答案。事实上，宣言的签名者会告诉你，虽然在检查敏捷中的价值时，在检查它不是的时也是如此值。
它不是灵丹妙药，也不一定是最便宜的选择。它只是一个框架，使交付团队以更协作和更高质量交付工作软件。
通过敏捷，从业务和开发的角度可以获得巨大的好处:您可以为IT产生积极的结果，同时，更快地进入市场，并增加您的竞争性差异。但是，您如何决定是逐步引入敏捷(称为敏捷采用)，还是在整个组织中实现敏捷(称为敏捷转换)?
从审视公司的产品开发或项目管理文化开始。如果您的组织已经使用预测的、传统的瀑布式开发方法证明了成功，那么继续聚集您的团队、进行发现、生成详细的需求、设计解决方案、开发代码、测试代码，然后将其部署到您的生产环境中可能会有真正的价值。换句话说，如果您的组织的SDLC没有损坏，那么看在上帝的份上，就不要去修复它!
但是，如果您的组织容易受到瀑布的限制，敏捷可能是一个更加可行的选择。一些商业领袖对项目前端的交付团队的巨大投资感到沮丧，因为他们努力做出关于产品的分析和发展决策，他们可能很少知道。毕竟，敏捷辩称，为什么花了这么多时间在你了解它时定义了产品？
撇开格言不谈，如果没有正确处理，项目可能会在后期进行昂贵的返工，因为项目需要转移。这也会导致交付企业认为它想要的产品，而不是它需要的产品。
敏捷利用团队不确定性，让团队成员做最好的事情：可视化解决方案，聘请合适的人员，并建立一个潜在的可付货产品。在这种感觉中，敏捷将更加传统的方式颠覆开发软件开发模型的方式颠倒：1）在通过合同语言和要求工作的经济作用的成本时间和客户之间有利于开发团队与客户之间的合作，以及2）专注于聘请个人和培养互动过过程和工具。
另一个决定指标是您组织的流程成熟度。如果您的企业是流程驱动的，您正在考虑采用敏捷软件开发方法，您可能需要考虑如何在地面实现。例如，从流程和将项目经理从瀑布到敏捷似乎可能看起来好像是要求他们放弃流程和“放弃控制” - 这不是一些过程驱动的PM到胃部的简单主张。在人们可以真正看到采用或转型的好处之前，需要相当的变化管理和教练。
第三次考虑因而在采用后或转型后可能发生的事情。虽然敏捷的基础是非常强大的，但了解普通陷阱公司在过渡时经历是有意义的。考虑以下：
*确定了工作时间和范围- 这限制了团队的能力敏捷，并为企业提供了他们所要求的，而不是他们所需要的。在瀑布中，项目经理使用变更请求舒适地调整他们的工作时间和工作范围。Agile稍微从这种变化方法离开，因为鼓励团队通过不断添加到他们的积压（阅读：要求集）而不是添加到范围和计划来回应变革。虽然需求可能会在敏捷中变化时，计划始终保持相同。
*提前安排所有Sprints /任务—在每一个sprint中预先计划每一个需求、任务和故事的愿望，是首次敏捷项目经理的自然趋势。抵制诱惑!试图提前安排所有任务会阻碍团队真正的自我实现，阻碍他们找到真正速度的能力，并为交付设定不切实际的期望。
*决定所有团队的发展速度 -每个敏捷团队都有自己的速度，自身的挑战和自己的速度。团队在他们去的时候变得更快，因此管理人员不应该试图比较团队和工作努力之间的速度。让团队以自己的节奏学习和采用（当然，通过正确的教练数量）。
*感觉接受敏捷是一种失控-如果敏捷被正确地实施和适当地扩展，项目、程序和组合级别的领导者将更好地理解每天的工作进展，确切地知道剩下的工作要完成，并知道当天是否有什么问题出现。
*在Sprint规划/执行流程上排除您的QA测试仪-将QA作为团队计划的一部分，为测试计划设定方向，并定义“完成”的含义。这就要求组织在过程中更早的时候让他们的测试人员参与进来，这与瀑布式方法的不同之处在于测试人员在过程的最后才参与进来。虽然让测试人员参与是一个很好的想法，但是从理论上讲，在实践中实现它是相当困难的，因为瀑布式项目中的测试/QA资源通常是在项目结束时预算(和分配)的。在您参与复杂的资源容量讨论之前，请确保您的团队和您的测试主管理解转向敏捷的含义!
根据上述建议文化因素的审查，在决定是否完全采用敏捷或变换时，组织也应该考虑什么？我们已经确定，改变瀑布项目经理使用瀑布方法的控制水平并不容易。事实上，敏捷是一种信仰的飞跃;然而，采取飞跃的组织通常更好地掌握着陆后的日常工作进度。经理知道项目是否正在滑落，并且在某些情况下，可能实际上可能具有比更预测性的瀑布方法更强大的项目管理能力。
另一个需要考虑的是质量。根据IT研究公司Standish Group的报告，使用敏捷开发方法的公司在质量上平均提高了63%。公司提高了不良率，同时建立对产品，而不是不一定是企业所追求的产品，将为企业带来真正的、可持续的价值。最后，随着质量和价值的提高，团队可以对交付的内容有完全的透明度，并促进业务和IT之间更好的对话。
抛开好处不谈，全面的敏捷转变对于公司的长期成功并不是必需的。事实上，组织可以在一些计划中选择使用敏捷，但是有些项目需要使用瀑布方法。
因此，当面对采用敏捷或转型的决定时，考虑你的文化和你对改变的渴望。衡量团队获得质量改进和交付更好结果的愿望。了解企业有多愿意优先考虑改善上市时间和推动竞争优势。最后，分析您的客户参与(客户满意度)和员工参与(更快乐的员工)的当前状态，并决定采用、转换或维护瀑布式方法是否适合您的团队。
Walser是AIM咨询公司的客户服务主管，在领导持续改进、软件开发和转型战略项目方面有超过17年的经验。