在瀑布中保持敏捷

Question

我们有一个大型企业应用程序，其中项目的范围设计并最终使用正式的瀑布流程进行编码。我经常为非相关计划进行代码更改，因为它们位于相同的代码段中。所有举措必须同时进行。开发团队对范围或交付时间线也几乎没有发言权。我们无法与用户交谈，我们必须通过一组不了解业务的需求收集人员。

是否有人就如何在这样一个根深蒂固的环境中实施最小的敏捷技术提出任何建议。

Answer 1

至少你可以开始编写单元测试，甚至 - 尽管情况允许 - 自己测试驱动开发（也可能在你的同事共同开发者之间传播这些想法）。如果没有管理人员注意到任何事情，你可以改变很多; - ）

当然，在平均或更好的地方，管理层的人并非完全愚蠢。随着时间的推移，当您设法在开发团队中提高对这些问题的认识时，您（作为团队，集体）也可以与高层管理人员交谈，并说服他们采取措施朝着正确的方向发展。从小规模开始，获得具体结果，并以此为基础 - 通过在开发团队中找到盟友并在管理层和用户中尽可能地寻找盟友来建立杠杆。

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

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

• 为什么我们这样做？
• 有更好的方法吗？
• 我们真的需要这件事吗？
• 谁需要这份文件？
• 她实际需要哪些信息？
• 它是否包含适合她的信息？
• 是最新的吗？
• 谁更新了？

人们通常只是把事情视为“给定”，但当你开始询问原因时，你可能会发现许多有趣的事情......以及改进的想法。

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

• 这次迭代出了什么问题，以及如何确保它不再发生（或至少在某种程度上改善它）
• 一切顺利，如何确保它会像那样继续下去

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

Answer 2

根据我的经验，大型企业关注风险，可预测性和可衡量的结果。如果能够比现有实践更好地展示它与这些指标的一致性，那么您将有一个更容易（但可能不是简单）的时间来介绍敏捷。

1. 使其可能经常发货，即使您还没有这样做：利用CI工具和自动构建脚本来构建和打包您的应用程序。通过这种方式，您可以充分利用任何机会逐步发布可能出现的新代码。

2. 衡量您的生产力现在，以便您拥有基线：您可以衡量的越多越好。

   1. 每个“功能”的平均程序员小时数。
   2. 代码签入与针对该代码发现缺陷之间的平均时间长度。
   3. 生产中缺陷发现与缺陷解决之间的平均时间长度。
   4. 识别，解决和部署缺陷修复程序所需的平均时间。
   5. 等

3. 在敏捷流程下投影这些指标的变化：例如，在大多数情况下，我们越早发现错误就越容易/越便宜，因此TDD和快速发布QA应该很容易量化。

4. 从小处开始：您可能有一个瀑布计划交给您，但您仍然可以将其分解为迭代，所以这样做。让您的工程实践到位，然后开始尝试调整流程。看看你是否可以在一个小的辅助项目上尝试敏捷作为概念证明。

5. 寻找赞助商：在啄食顺序中尝试并说服某人高于您自己敏捷的优点。用决策者熟悉的术语帮助他们构建“敏捷与瀑布”的论点。

6. 耐心 ......可能需要一段时间才能看到结果。

7. ......或者不这样做。如果您对敏捷非常感兴趣并且得到零支持，请找一份新工作。是的，从野兽的腹部改变效果是有益的，但与那些分享你关于构建软件的想法的人一起工作也是有益的。

Answer 3

敏捷就是打破那些瀑布墙。 BDUF;同时，多组分释放;开发人员与业务流程所有者之间缺乏沟通;计划的迭代 - 这些都在瀑布流程中阻碍你。

在我的位置，我们已经打破了很多这些墙 - 而且它始于直接访问客户。当发生这种情况时，客户得到了更好的产品。这导致了更快乐的客户。这驱逐了像BDUF等的东西。

我们仍然没有真正的迭代/冲刺，持续集成等，但我们已经到了那里。 （旧习惯，以及所有这些。）

Answer 4

您作为开发团队仍然可以使用敏捷方法（测试驱动开发，结对编程，故事卡，CI，通用语言等）进行内部协调。

在我看来，敏捷是关于能够对软件的变化充满信心，并防止在瀑布路线上没有人需要三步的功能上的大量错误投资。测试和重构以及避免过度工程是关键。

Answer 5

对我而言，问题似乎并不在于您使用的是瀑布而不是敏捷。这就是你的瀑布式实现存在很大问题。最明显的是：

  

要求收集谁不知道   业务

如果做得好，瀑布可以而且效果很好。我认为这听起来像一些参与其中的人以及他们如何做事情是错误的，而不是概念过程。

Answer 6

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

另外，请考虑为您当前分配的任务提供自己的，高度精细的燃尽列表（英寸石）。它应该有助于您的工作估算更加可预测，并使您更容易解释任何计划滑点和计划外任务。

通常，跟踪系统中的某些指标。如果你能展示一些敏捷技术增加价值（缩短周期时间，降低缺陷率等），那么就应该很容易将你的领导力推向这种技术。

...取决于经理，您可能希望避免实际使用“敏捷”这个词，特别是如果您只是在寻找使用一种技术的小胜利。