至少你可以开始编写单元测试，甚至-尽可能情况允许-自己进行测试驱动开发（可能还可以在同事之间传播这些想法）。你可以在管理层完全不注意的情况下改变很多事情;-)

当然，在一般或更好的地方，管理层的人不完全愚蠢。随着时间的推移，当你成功地让开发团队意识到这些问题时，你（作为整个团队）也可以与高层管理层交流，并说服他们朝着正确的方向采取行动。从小处开始，取得具体成果，并在其基础上建立优势，通过在开发团队中和（在可能的情况下）在管理层和用户中寻找盟友来建立优势。

很多时候，只是因为“我们一直都这么做”，才会遵循某些流程。如果你能向人们展示更好的方法，并用有说服力的论点证明它，你就有很大的成功机会。请注意，管理人员和用户需要的论点与开发者的不同。你可以尝试进行大致的成本效益计算（或者在谷歌上搜索——我敢肯定网络上有很多相关内容）。我还记得肯特·贝克 (Kent Beck) 的第一本 XP 书中有很好的材料。你还可以收集缺陷统计数据，这样以后（希望如此）就能证明敏捷方式开发的功能在后期（集成测试或生产）阶段缺陷明显较少。（为此，如果你还没有缺陷跟踪系统，请配置一个。）

另一个有用的工具是提问。如果你遇到了什么 - 文档、做事情的方式等 - 你不理解的东西，敢于提问：

• Why are we doing this like we do?
• Is there a better way?
• Do we actually need to this thing at all?
• Who needs this document?
• What information does she actually need out of it?
• Does it contain the right info for her?
• Is it up to date?
• Who updates it?

经常人们只是把事情看作是“确定的”，但当你开始寻求原因时，你可能会发现很多有趣的事情……和改进的想法。

一个非常有用的敏捷工具是回顾议题。在每次迭代之后（无论在实际过程中叫什么），团队会聚在一起进行头脑风暴，探讨。

• what went wrong in this iteration, and how to make sure it doesn t happen again (or at least improve it to some extent)
• what went nicely and how to ensure it will continue like that

这可能相对容易被管理层接受，是开始积极变化的好方式。最重要的是唤醒和激活人们——让每个人都意识到项目的成功或失败（至少在某种程度上）在他们自己手中，他们可以做些什么来改善情况。

根据我的经验，大企业关注风险、可预测性和可衡量的结果。如果能够说明敏捷方法如何比现有的实践更好地与这些指标相符，那么你就会更容易（虽然可能不容易）地推广敏捷方法。

1. 让频繁发货成为可能，即使你还没有这样做：利用CI工具和自动化构建脚本来构建和打包您的应用程序。这样，您可以利用任何增量发布新代码的机会。

2. 現在測量你的生產力，以建立基礎線：測量的越多，越好。

   1. Average # of programmer hours per "feature".
   2. Average length of time between code checkin and the discovery of defects against that code.
   3. Average length of time between defect discovery and defect resolution in production.
   4. Average amount of time needed to identify, resolve, and deploy defect fixes.
   5. etc.

3. 在敏捷开发过程中预测这些指标的变化：例如，大多数情况下，我们发现bug的时间越早，修复起来就越容易/更便宜，因此TDD和快速发布到QA的好处应该很容易量化。

4. 从小做起：也许你会被分配一个瀑布式的日程安排，但你仍然可以将其分解成迭代，因此请这样做。先确立好你的工程实践，然后开始尝试调整流程。看看是否可以从一个小的辅助项目开始尝试敏捷开发作为概念证明。

5. 寻找赞助者：努力说服比你地位更高的人了解敏捷的优点。请他们帮助你以决策者熟悉的术语来构建“敏捷vs瀑布”的论点。

6. http://www.ohchr.org。

7. 如果您对敏捷开发深感兴趣，而且得不到任何支持，请寻找新的工作。在“兽腹”中引起变化固然值得，但与那些分享您关于软件开发想法的人一起工作也同样令人满意。...或者不要。

敏捷开发就是要打破瀑布式开发的壁垒。过度设计、同时多组件发布、开发人员与业务流程负责人之间缺乏沟通、计划迭代 - 这些都会妨碍瀑布式开发的进程。

在我的职位上，我们打破了许多这些墙壁-这始于直接接触客户。当发生这种情况时，客户获得了更好的产品。这导致了更快乐的客户。这驱逐了BDUF之类的东西。

我们还没有真正的迭代/冲刺、持续集成等，但我们正在努力。 （老习惯占据了一部分时间。）

你作为发展小组,仍可在国内协调使用灵活方法(试发式发展、配对方案、故事卡、 CI、共同语言等)

在我的想法中，敏捷性是关于能够对软件的变化有信心，防止在项目瀑布模型的后期阶段进行大的误投资，并进行测试和重构以避免过度工程化。

在我看来，问题似乎不是你使用瀑布模型而不是敏捷开发。问题在于你们的瀑布模型实施存在很大问题。最显而易见的问题是：

Requirement gathers who don t know the business

瀑布模型如果正确执行，可以发挥良好效果。我认为问题不在于概念流程，而在于参与者的做事方式中存在一些错误。

根据您的领域，自动化测试和持续集成应该是可行的。

此外，考虑为您当前分配的任务制定自己的高度细粒度的剩余工作列表（英寸石）。这应该有助于提高您的工作估计可预测性，并使您更容易解释任何进度滑坡和未计划任务。

一般来说，要跟踪系统中的一些指标。如果您能展示出一些敏捷技术增加了价值（缩短循环时间、降低缺陷率等），那么向领导推销这种技术就应该很容易。

根据经理的情况，你可能希望避免实际使用“敏捷”这个词，尤其是如果你只是想在使用一种技术上取得小胜利。