在瀑布中保持敏捷

Question

我们有一个大型企业应用程序，其中的项目是使用正式的瀑布流程进行范围划分、设计和最终编码的。我经常被给予不相关的计划的代码更改，仅仅因为它们在相同的代码部分。所有的计划都必须同时上交。开发团队在范围或交付时间线上也几乎没有发言权。我们无法与用户交谈，我们必须通过一组不了解业务的需求集合。

对于如何在这样一个根深蒂固的环境中实现哪怕是最小的敏捷技术，有人有什么建议吗？

Answer 1

至少你可以开始编写单元测试，甚至-在环境允许的情况下-自己编写测试驱动开发(可能也会在你的共同开发人员同事中传播这些想法)。你可以在管理层没有注意到任何事情的情况下改变很多东西;-)

当然，在一般或更好的情况下，管理层的人并不是完全愚蠢的。随着时间的推移，当您设法在开发团队中提高对这些问题的认识时，您(作为团队，集体)也可以与上层管理人员交谈，并说服他们朝着正确的方向采取措施。从小处开始，获得具体的结果，并在此基础上构建-通过在开发团队以及(尽可能多)管理层和用户中找到盟友来建立影响力。

通常情况下，遵循某些流程仅仅是因为“我们过去总是这样做”。如果你能向人们展示有更好的方法，并用令人信服的论据来证明这一点，你就有很好的成功机会。请注意，管理层和用户需要的参数与开发人员完全不同。你可以试着进行粗略的成本效益计算(或者谷歌--我非常肯定网上有很多关于这些的东西)。我还记得在Kent Beck's first XP book中有关于这方面的好材料。您还可以收集bug统计数据，这些统计数据随着时间的推移(希望)表明，以敏捷方式开发的特性在以后(集成、测试或生产)阶段的缺陷明显较少。(为此，您需要一个缺陷跟踪系统(如果您还没有这样的系统)。)

另一个有用的工具是提问。如果你做了什么--一份文件，一种做事的方式--你不明白，就敢问问题：

• 我们为什么要这样做？
• 有没有更好的方法？
• 我们真的需要这样做吗？
• 谁需要这个document?
• What信息她真的需要吗？
• 它是否包含适合她的正确信息？
• 它是最新的吗？
• 谁更新它？

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

retrospectives是一个非常有用的敏捷工具。在每次迭代之后(无论在实际过程中叫什么)，团队聚集在一起，进行头脑风暴。

• 在这次迭代中出了什么问题，以及如何确保它不会再次发生(或者至少在某种程度上改进了它)
• 什么进行得很好，以及如何确保它像

一样继续下去

这可能很容易被管理层接受，并且是开始积极变化的好方法。最重要的是唤醒和激活人们-让每个人意识到项目的成败(至少在一定程度上)掌握在自己手中，他们可以做一些事情来改善情况。

Answer 2

根据我的经验，大型企业关注风险、可预测性和可衡量的结果。如果展示出敏捷如何比现有实践更好地符合这些度量标准，那么您将更容易(尽管可能不容易)地介绍敏捷。

1. Make it possible 经常发布，即使您还没有这样做：利用CI工具和自动化构建脚本来构建和打包您的应用程序。这样，您就可以充分利用任何可能会逐步发布新代码的机会，让您的生产力 now 有一个基准：，您可以测量的越多越好。

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.

​

在敏捷过程中对这些指标的改变:例如，在大多数情况下，我们越早发现错误就越容易修复/更便宜，所以从测试驱动开发和快速发布到QA的好处应该很容易

1. Project quantify.
2. Start ：你可能有一个瀑布时间表交给你，但你仍然可以将其分解为迭代，所以这样做吧。将你的工程实践放在适当的位置，然后开始尝试调整流程。看看你是否可以在一个小的辅助项目上尝试敏捷作为概念的证明。
3. Find一个赞助商：试着说服比你更高的人相信敏捷的优点。参与他们的帮助，用与decision makers.
4. Be patient相似的术语来框架“敏捷与瀑布”的争论……可能需要一些时间才能看到results.
5. ...如果你对敏捷很感兴趣，却没有得到任何支持，那就找一份新工作吧。是的，发自内心的改变是有益的，但与与您在构建软件方面有相同想法的人一起工作也是有益的。

Answer 3

敏捷就是打破那些瀑布墙。BDUF；同时，多组件发布；开发人员和业务流程所有者之间缺乏沟通；计划迭代-这些都会阻碍您在瀑布流程中的工作。

在我的位置上，我们已经打破了许多这样的墙-它开始于直接访问客户的。当这种情况发生时，客户得到了更好的产品。这让客户更加满意。把BDUF之类的东西赶走了。

我们仍然没有真正的迭代/冲刺，持续集成等，但我们正在实现。(旧习惯，诸如此类。)