9

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

有没有人对如何在这样一个根深蒂固的环境中实施即使是最小的敏捷技术有任何建议。

4

6 回答 6

7

至少你可以开始编写单元测试，甚至——在情况允许的情况下——自己进行测试驱动开发（也可能在你的合作开发者中传播这些想法）。您可以在没有管理层注意到任何事情的情况下进行很多更改；-)

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

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

另一个有用的工具是提问。如果你对某件事——一份文件，一种做事方式——不了解，敢于提问：

  • 为什么我们要这样做？
  • 有没有更好的办法？
  • 我们真的需要这个东西吗？
  • 谁需要这份文件？
  • 她实际上需要什么信息？
  • 它是否包含适合她的信息？
  • 它是最新的吗？
  • 谁更新它？

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

一个非常有用的敏捷工具是回顾。在每次迭代之后（无论在实际过程中如何调用），团队都会聚在一起并集思广益

  • 这次迭代中出了什么问题，以及如何确保它不会再次发生（或至少在一定程度上改进它）
  • 什么进展顺利以及如何确保它会继续这样

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

于 2010-02-23T13:47:09.413 回答
4

根据我的经验，大型企业关心风险、可预测性和可衡量的结果。如果能比现有实践更好地与这些指标保持一致，那么您将更容易（尽管可能并不容易）引入敏捷。

  1. 让经常发布成为可能，即使您还没有这样做：利用 CI 工具和自动构建脚本来构建和打包您的应用程序。这样，您就可以利用任何机会逐步发布可能出现的新代码。

  2. 现在测量你的生产力，这样你就有一个基线：你可以测量的越多越好。

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

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

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

  5. 寻找赞助商：尝试说服比自己地位更高的人相信敏捷的优点。让他们帮助以决策者熟悉的术语来构建“敏捷与瀑布”的论点。

  6. 请耐心等待……可能需要一些时间才能看到结果。

  7. ......或者不要。如果你对敏捷非常感兴趣并且获得零支持，那就找份新工作吧。是的，从野兽的腹部实现改变是值得的，但与那些分享你关于构建软件的想法的人一起工作也是值得的。

于 2010-02-23T18:11:31.287 回答
2

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

在我的职位上，我们已经打破了很多这样的壁垒——从直接接触客户开始。当这种情况发生时，客户得到了更好的产品。这导致了更快乐的客户。这驱走了像 BDUF 之类的东西。

我们仍然没有真正的迭代/冲刺、持续集成等，但我们正在实现。（旧习惯等等。）

于 2010-02-23T13:47:49.270 回答
1

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

在我看来，敏捷性是指能够对软件的更改充满信心，并防止对功能的大量错误投资，而这些功能没有人需要沿着瀑布路线走三步。测试和重构以及避免过度设计是这里的关键。

于 2010-02-23T13:52:32.833 回答
1

对我来说，问题似乎并不在于您使用的是瀑布而不是敏捷。那是你的瀑布实现有很大的问题。最明显的：

需求聚集不懂业务的人

如果做得好，瀑布可以而且确实可以很好地工作。我认为这听起来像是涉及的一些人以及他们做事的方式是错误的，而不是概念过程。

于 2010-02-23T14:34:23.937 回答
0

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

此外，考虑为您当前分配的任务制定自己的、高度精细的燃尽清单（石碑）。它应该有助于您的工作估算更加可预测，并使您更容易解释任何进度延误和计划外任务。

一般来说，跟踪系统中的一些指标。如果您可以展示一些敏捷技术增加了价值（缩短了周期时间、降低了缺陷率等），那么您应该很容易推销您在该技术上的领导地位。

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

于 2010-02-23T13:52:39.377 回答