在瀑布式开发中保持敏捷

Question

在瀑布式开发中保持敏捷

9

我们有一个大型企业应用程序，项目是通过正式的瀑布流程进行范围设计和最终编码的。由于非相关倡议位于同一代码部分中，我经常会收到代码更改。所有倡议必须同时交付。开发团队对范围或交付时间表也没有太多发言权。我们不能直接与用户交流，必须通过不了解业务的需求收集组进行沟通。

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

- rerun

1

SO的专家S. Lott在他的文章《瀑布模型不起作用——连客户都这么说》（http://homepage.mac.com/s_lott/iblog/architecture/C551260341/E20080211062302/index.html）中写到了类似的问题。他从咨询的角度谈论了这个问题，但其中一些想法也可以应用于内部团队面对相同挑战的情况。 - Jeff Sternal

6个回答

4

依据我的经验，大型企业非常关注风险、可预测性和可衡量的结果。如果你能够展示敏捷开发相比现有实践更符合这些指标，那么引入敏捷开发可能会更容易（虽然也许并不容易）。

以下是需要翻译的具体内容：

1. 通过利用CI工具和自动化构建脚本来构建和打包应用程序，即使你还未开始频繁发布新代码，也可以让其成为可能。 2. 现在就度量你的生产力，以便有一个基线。越多的度量，效果越好。比如每个“功能”所需的平均程序员工作时间、代码检入和发现缺陷之间的平均时间、发现缺陷和在生产环境中解决缺陷之间的平均时间、确定、解决和部署缺陷修复所需的平均时间等。 3. 预测在敏捷过程下这些指标的变化。例如，在大多数情况下，我们越早发现漏洞，修复起来就越容易/廉价，因此可以很容易地量化从TDD和快速发布到QA中获得的收益。 4. 先从小处开始。也许你手上有一份瀑布式的时间表，但你仍然可以把它分解成迭代。先建立好你的工程实践，然后开始尝试调整流程。看看能否在小型辅助项目上尝试敏捷开发作为概念证明。 5. 寻找赞助商。试图说服比你更高层级的人相信敏捷开发的优点，并获得他们的帮助以用决策者熟悉的术语来构建“敏捷与瀑布”的论点。 6. 要有耐心……可能需要时间才能看到结果。 7. 或者不要。如果你对敏捷开发非常感兴趣，但没有得到任何支持，那就找份新工作吧。是的，从“巨兽”的肚子里影响变化是令人满足的，但与那些分享你关于软件构建理念的人共事也同样令人满足。

- Seth Petry-Johnson

2

敏捷方法是为了打破那些瀑布式的框架。BDUF；同时、多组件发布；开发人员与业务流程所有者之间缺乏沟通；计划的迭代 - 这些都阻碍了你在瀑布式流程中前进。

在我的职位上，我们已经打破了很多这些壁垒 - 起点是直接接触客户。当发生这种情况时，客户获得了更好的产品。这导致了更满意的客户。这消除了诸如 BDUF 等问题。

我们仍然没有真正的迭代/冲刺、持续集成等，但我们正在努力。(老习惯了，诸如此类.)

- Jarrett Meyer

1

作为开发团队，您仍然可以使用敏捷方法（测试驱动开发、配对编程、用户故事卡片、持续集成、共同语言等）进行内部协调。

在我看来，敏捷性是指能够对软件的变化有信心，并防止在瀑布式开发中出现大规模的错误投资。在这里，测试和重构以及避免过度工程是关键。

- Christopher Oezbek

1

在我看来，问题似乎不是你使用瀑布式开发而不是敏捷开发。而是你的瀑布式实现存在很大的问题。最明显的问题是：

不了解业务的需求收集者

如果正确执行，瀑布式开发可以做得很好。我认为听起来有些参与者和他们的工作方式是错误的，而不是概念上的过程。

- Mr. Boy

1

同意，我们遭受了许多反模式的困扰，但很多问题都是由于功能跟随形式的问题。由于结构上的障碍，我们似乎无法实施任何好的变化。目标是看看我们是否能够实施一些敏捷方法来展示它们的价值，然后逐渐掌控整个项目的生命周期，这是主要问题。 - rerun

0

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

此外，考虑为您当前分配的任务制定自己的高度细化的燃尽清单（英寸石）。它应该有助于您的工作估计更加可预测，并使您更容易解释任何时间表滑动和未计划的任务。

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

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

- thebretness

我的团队做的一件事是编制我们自己的缺陷、错误、缺失功能等底层列表。我们称之为“技术债务”清单，并开始将其视为某种燃尽图表来处理。 - thebretness

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Péter Török · Accepted Answer

至少你可以开始编写单元测试，甚至 - 在情况允许的情况下 - 自己实践测试驱动开发（可能还要向同事推广这些想法）。即使没有管理层的注意，你也可以做出很多改变；-）

当然，在一个平均或更好的地方，管理层的人并不完全愚蠢。随着时间的推移，当你已经成功提高了开发团队对这些问题的认识时，你（作为团队的一员）也可以与上级管理层进行谈话，并说服他们朝着正确的方向采取行动。从小处着手，取得具体成果，并建立起来 - 通过在开发团队和（尽可能地）在管理层和用户中找到盟友来建立杠杆效应。

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

另一个有用的工具是提问。如果您遇到了某些东西——文档、某种操作方式——您不理解，请勇于提问：

我们为什么要像这样做？
有更好的方法吗？
我们真的需要做这件事吗？
谁需要这个文件？
她实际上需要什么信息？
它是否包含她需要的正确信息？
它是否是最新的？
谁更新它？

通常人们会把事情视为“理所当然”，但当你开始询问原因时，你可能会发现很多有趣的事情...和改进的想法。

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

本次迭代出了什么问题，如何确保不再发生（或至少在某种程度上改善）
本次迭代进行得如何，如何确保继续保持良好状态

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