我们有一个大型企业应用程序，其中项目的范围设计并最终使用正式的瀑布流程进行编码。仅仅因为它们在同一段代码中，我经常会为不相关的计划进行代码更改。所有倡议必须同时上交。开发团队对范围或交付时间线也几乎没有发言权。我们无法与用户交谈，我们必须通过一组不了解业务的需求收集。
是否有人对如何在这样一个根深蒂固的环境中实施哪怕是最小的敏捷技术有任何建议。
【问题讨论】：
至少你可以开始编写单元测试，甚至——在情况允许的情况下——自己进行测试驱动开发（也可能在你的合作开发者中传播这些想法）。您可以在没有管理层注意到任何事情的情况下进行很多更改；-)
当然，在一般或更好的地方，管理层的人并不是完全愚蠢的。随着时间的推移，当您设法提高开发团队对这些问题的认识时，您（作为团队集体）也可以与高层管理人员交谈，并说服他们朝着正确的方向采取措施。从小处着手，获得具体结果，并以此为基础 - 通过在开发团队中以及（尽可能）在管理层和用户中寻找盟友来建立影响力。
经常遵循某些流程只是因为“我们总是这样做”。如果你能向人们展示有更好的方法——并用令人信服的论据证明——你就有很大的成功机会。请注意，管理层和用户需要与开发人员完全不同的论据。您可以尝试进行粗略的成本效益计算（或谷歌 - 我很确定网上有很多关于这些的东西）。我还记得在Kent Beck's first XP book 中有很好的资料。您还可以收集错误统计信息，这些统计信息随着时间的推移（希望）表明以敏捷方式开发的功能在后期（集成测试或生产）阶段的缺陷明显减少。 （为此，您需要一个缺陷跟踪系统，如果您还没有的话。）
另一个有用的工具是提问。如果您对某件事——一份文件、一种做事方式——不了解，敢于提问：
通常人们只是把事情当作“给定的”，但是当你开始寻找原因时，你可能会发现很多有趣的事情......以及改进的想法。
一个非常有用的敏捷工具是retrospectives。在每次迭代之后（无论在实际过程中如何调用），团队都会聚在一起并集思广益
这可能很容易被管理层接受，并且是开始积极变革的好方法。最重要的是唤醒和激活人们——让每个人意识到项目的成败（至少在某种程度上）掌握在自己手中，他们可以做一些事情来改善情况。
【讨论】：
根据我的经验，大型企业关心的是风险、可预测性和可衡量的结果。如果展示敏捷如何比现有实践更好地与这些指标保持一致，那么您将有一个更容易（虽然可能不是容易）引入敏捷的时间。
使其可能经常发布，即使您还没有这样做：利用 CI 工具和自动构建脚本来构建和打包您的应用程序.这样，您就可以利用任何机会逐步发布可能出现的新代码。
现在衡量您的生产力，以便您有一个基准：您可以衡量的越多越好。
在敏捷过程中预测这些指标的变化：例如，在大多数情况下，我们越早发现错误就越容易/更便宜地修复，因此可以从 TDD 和快速发布给 QA 应该很容易量化。
从小处着手：您可能会收到一份瀑布计划，但您仍然可以将其分解为多个迭代，因此请这样做。让您的工程实践到位，然后开始尝试调整流程。看看您是否可以在一个小型辅助项目上尝试敏捷作为概念证明。
寻找赞助商：尝试说服某人比你自己的优先级更高，了解敏捷的优点。让他们帮助以决策者熟悉的术语构建“敏捷与瀑布”的论点。
耐心等待...可能需要一段时间才能看到结果。
...或者不要。如果您对敏捷非常感兴趣并且获得的支持为零，请找一份新工作。是的，从野兽的腹中实现改变是值得的，但与分享您关于构建软件的想法的人一起工作也是值得的。
【讨论】：
敏捷就是要打破那些瀑布墙。 BDUF；同时，多组分发布；开发人员和业务流程所有者之间缺乏沟通；计划的迭代——这些都阻碍了你在瀑布过程中的方式。
在我的职位上，我们已经打破了很多这样的障碍 - 首先是直接接触客户。当这种情况发生时，客户得到了更好的产品。这导致了更快乐的客户。这驱走了诸如 BDUF 之类的东西。
我们仍然没有真正的迭代/冲刺、持续集成等，但我们已经做到了。 （旧习惯等等。）
【讨论】：
作为开发团队，您仍然可以使用敏捷方法（测试驱动开发、结对编程、故事卡、CI、通用语言等）进行内部协调
在我看来，敏捷性是指能够对软件的更改充满信心，并防止对功能的大量错误投资，而这些功能不需要沿着瀑布路线走三步。测试和重构以及避免过度设计是这里的关键。
【讨论】：
对我来说，问题似乎并不在于您使用的是瀑布而不是敏捷。那是你的瀑布实现有很大的问题。最明显的是：
需求集合谁不知道 商业
如果处理得当，瀑布可以而且确实可以很好地工作。我认为这听起来像是涉及的一些人以及他们做事的方式是错误的，而不是概念过程。
【讨论】：
根据您的领域，自动化测试和持续集成应该是可行的。
此外，请考虑为您当前分配的任务制定自己的高度详细的燃尽清单（石碑）。它应该有助于您的工作估算更加可预测，并使您更容易解释任何进度延误和计划外任务。
一般来说，跟踪系统中的一些指标。如果您可以展示一些敏捷技术增加了价值（缩短了周期时间、降低了缺陷率等），那么您应该很容易推销您在该技术上的领导地位。
...根据经理的不同，您可能希望避免实际使用“敏捷”这个词，特别是如果您只是想在使用一种技术上取得小小的胜利。
【讨论】：