问题标签 [waterfall]

在传统的 Waterfall 中，需求是按照深奥的模板收集的——通常是在 MS-Word 文档中。在“严格”的瀑布模型中，该文档在需求阶段之后被冻结，变更控制/变更管理流程负责引入受控变更。(**) [通常情况下，文件会变成“活文件”，最终变成“活生生的噩梦”]

目前，我要领导一个项目，该项目是将现有桌面应用程序重写为 Web（从 VB 6.0 到 ASP.Net）。客户有一个他想要重写的应用程序的基线版本。[所以需求被冻结......没有范围蔓延]。要按原样重用的数据模型。只迁移前端/业务规则。看应用程序，我觉得它最多只有 3/4 个主要屏幕，仅此而已。

一些团队成员想要在开始新开发之前记录（在我看来是老派的思想）整个事情。我和其他一些人认为，将 UI 转换为 Web 应该相对容易，查找旧代码，编写业务逻辑，进行自动化单元测试，进行集成测试并逐屏交付（或逐个业务功能）

我的问题是：在敏捷开发中，如果我不对其进行优化，我该如何保持“敏捷”。我的观点是写详细的文档是反敏捷的。你怎么看？敏捷大师将如何解决上述问题（将现有的 VB 6.0 应用程序重写为 ASP.Net）？

免责声明： 创建 1000 页的功能规范可能是为了履行合同义务、政治上的必要性，系统可能真的很复杂（现在，“复杂性”的定义是通往黑暗之地的旅程）。

If so, how do you deal with things that just don't "feel" right such as:

• not writing unit tests
• not having a continuous build
• not refactoring
• not having a team coding standard
• not pair programming
• not doing iterations
• no daily standups
• no retrospectives

Now, some agile organizations do leave out some of these practices, but most successful ones incorporate most of them.

What do you do to deal with the seeming chaos of the traditional development processes?

如果你必须选择 Scrum 相对于瀑布式流程的一项优势，你会选择什么？

我读 了what-payment-structure-do-you-use-for-small-projects ，我想知道你们是如何处理错误与功能的。我曾经遇到过客户想要静态报告的情况。然后在项目的大部分工作完成后，在项目接近尾声时，他说他一直想要动态报告。这种改变并不容易，因为我们选择的框架不支持动态报告。这是一个奇怪的情况，因为客户有一个编程团队，所以他们应该知道。也许只是缺乏沟通技巧。

你们如何处理试图让您添加功能的客户，因为他们忘记了，改变了主意，或者被误解了？

我的意思是大功能，而不是小功能。

编辑：

他说预算是固定的，不能改变，而且这个特性（就像每一个一样）是至关重要的，没有它他们就不会接受这个系统。（只是最坏的情况）

神话人月现在很经典，但“手术团队”方法仍然很有趣。哪种方法最接近它或具有相同的本质？

总结外科团队的类比：外科医生了解问题/业务领域并且是专家。当团队中有问题或冲突时，他们是权威。当出现问题时，外科医生之间会相互合作，比如设计，作为一个较小的紧密专家团队。所以本质上他们拥有领域的知识，被委托去做他们认为正确的事情，并做实际的编码？团队的其他成员专注于支持、测试、文档和项目计划，这些都是委派的任务。因此，外科医生也是最熟练/训练有素的资源。

答案可能是项目、编程、设计方法，因为它似乎对主要方法领域都有影响。采购开发中的敏捷、MDA、Extreme？这个问题对于复杂业务领域中的大型软件也更有意义，比如空中交通管制，而不是 COTS 开发人员或通用实用程序。

在分布式离岸环境中从事产品开发的传统大型软件产品组织很难遵循 Scrum 中的敏捷精神，原因如下：

1. 他们的产品开发不是迭代的。产品工程团队经过多轮迭代系统工程，提前正式确定给定版本的产品需求、产品架构和设计。可能会发生这种变化，但不会大规模。

2. 产品工程团队现在让离岸团队根据创建的规范构建此产品。这些大型离岸团队不能在迭代和经验模式上工作，因为这在这里没有保证。

3. 然而，产品经理可能希望通过在短期迭代中请求增量交付来定期了解离岸团队的产品开发。

4. 如果这些离岸团队可以在定义的正式流程（非经验性）、经理管理的环境（非授权）和使用增量开发方法（非迭代和自适应）中遵循 Scrum 的变体，那对他们将非常有用。

5. 在这种情况下实施的真正 Scrum 方法可能看起来很虚伪。但是，如果我们可以给他们一个正式的 Scrum 变体，用于传统的瀑布式场景，他们可能会利用它来为每个人带来好处。

我试图在我的博客scrumtales.blogspot.com上更详细地描述这种情况。

我们可以这样做吗？

我知道，对我来说，我首先开始遵循项目管理的瀑布方法，然后我开始使用预测方法进行软件设计。我的意思是我们有大量的文档、UML、数据库模式、数据字典、工作流、活动图等。

在软件领域工作了 10 多年，现在我发现从响应式方法进行软件设计更加现实。我经常采用 Scrum 方法进行项目管理，并且几乎不会生成繁重的文档。我们的工作流程规范很少（尽管它们仍然有用）。这是一种更加动态的软件创建方法。当然，随着时间的推移，随着时间的推移，随着时间的推移，随着时间的推移，我们会发现我们预先计划好的新功能会发生巨大的变化，随之而来的是频繁的重构。

对我们来说最大的不同是第一种方法花费的时间更长，在软件构建世界中似乎更频繁地失败，并且几乎没有那么灵活。第二种方法提供了更大的灵活性，让我们更快地意识到失败（因此我们可以更快地纠正），并在每次迭代结束时提供某种形式的功能。

从经验中了解双方，我仍然发现很多人喜欢瀑布方法而不是敏捷方法进行软件开发。我不明白。

问题：为什么有人会在所有研究都支持敏捷的情况下使用瀑布而不是某种形式的敏捷？使用瀑布而不是敏捷的有力论据是什么？

我需要帮助来创建存储在缓冲区中的图像数据的瀑布显示。图像数据流需要在从相机获取时向下滚动屏幕显示。我正在使用 Visual Studio C++ Windows 窗体。有人可以帮我弄清楚如何实现这种显示吗？

提前致谢

我曾在Java 世界中参与过Death March项目——这些项目从一开始就注定要失败，因为管理不善和笨拙、复杂的技术相结合，通常跨越多个系统并且通常与瀑布方法相关联。

Rails 和 Django 被吹捧为敏捷开发技术，这意味着它们旨在能够快速响应变化。

这是否意味着他们不受大型企业系统的死亡行军情景的影响？或者在 Rails/Django 项目中是否还有足够的复杂性，它可能会像 Java 项目一样失控？

在很多地方，我都看到过这样一种说法，即通过预先设计系统，您可以显着减少开发时间。即，通过花一个小时的设计，您可以节省一周的编码时间。我的问题是我从未见过我发现这是真的情况。所以我想知道人们有哪些例子是正确的：

所以：

1. 在编码过程中出现了什么样的问题？（或者被避免了？）
2. 您如何通过花更多时间进行设计来避免（或确实避免）了这个问题？
3. 为什么很难（或者会很难）解决代码中的问题？