如何规划庞大的软件项目？

Question

我们已经开始了一个庞大的项目。我们知道它的外观，但不知道如何实现它。我们首先编写原型来测试不同的实现。我们缺乏的是对整体发展进程的概述。我们不知道我们是否在细节上花费了太多时间，或者这些细节是否足够重要，可以花时间。

我首先创建了一个我们必须完成的任务列表，例如“实现功能X”，“检查如何实现Y”。现在我有一个包含大约500个任务的巨大思维导图。我能做的下一步是定义任务之间的依赖关系。这样我就知道首先要实现什么，最重要的任务是最关键的任务。但是我不能用思维导图工具做这种排序。这非常令人沮丧。

您如何规划庞大的软件项目？

Answer 1

有很多关于这个主题的好文章和书籍。但简而言之，减少依赖关系，保持简单但灵活，并从编写可快速编码的组件开始 - 这为您提供了一个更好的“感觉”，即您需要做什么。准备好您的设计以进行改进并准备重写相当多的代码。

不要试图从头开始编写完美的系统。 设置来编写一个简单的系统，你可能偶然会最终写出完美的系统。

Answer 2

在迭代中完成你的工作。专注于一个特定迭代的必要条件。如果你同时关注所有细节，你就会失败。

首先，决定您希望拥有哪些一般功能并为此设计。

在接下来的步骤中，您将添加越来越多的高级功能。

当您拥有稳定的架构线框时，您可以将项目划分为模块并将其分发给多个团队。团队也将在迭代中工作。

没有人可以从一开始就设计一个庞大的软件项目。巨大的项目正在缓慢增长，伴随着所有常见的童年问题。

Answer 3

这是帮助我入门的原因：

<强> [1] 从需求文档开始。从客户的角度写。把所有内容写下来，软件应该能够做什么。避免提供解决方案要明确。如果某个功能将接收输入，请指定它可以预期的内容，它应该预期的程度以及它在错误情况下应该如何操作。

不要忘记指定限制。一切都有限制。如果您的解决方案将管理帐户应该能够处理多少？ 20或1000万？

您的需求文档应包括功能需求而非功能需求。功能要求不是：性能，稳定性，资源使用，安全性等。

<强> [2] 当您完成指定要求时，为每个要求提供重要性分数：必须具有，重要，可选。

<强> [3] 现在编写一个文档，指定每个需求的实现方式。小心细节。不要深入。去20/80规则。深入指定20％的功能，这将影响解决方案的80％。

您可能会注意到，您无法描述每项要求的实施方式。可以写“我不知道如何实现这个”。但重要的是你写下来！ “不知道”的数量将告诉您项目的风险程度。

<强> [4] 下一步是制作任务列表。您需要知道您实际需要做什么。对于每个要求，您都需要执行几项任务。

其中一项任务是找出如何实施“不知道”的要求。不要试图澄清每一个“不知道”。去寻找必须和重要的人。澄清一些“不知道”甚至可能是一个小型子项目。

<强> [5] 完成任务后，您需要估算完成任务所需的时间。不要害羞估计。当你在项目开始时，无法准确估计。随着项目的进行，您将重新估算任务，您的估算将更加准确。

对我来说，做出所谓的三点估计非常有帮助。如果一切顺利，请估计您需要的时间。这是你乐观的时间。然后估计遇到问题需要多长时间。这是你悲观的时刻。然后估计一个现实的时间。乐观和悲观时间之间的跨度将告诉你你对实施的不确定性。

<强> [6] 现在，您必须按照将要实施的顺序执行任务。某些任务将具有您的订单必须反映的依赖项。有一个非常好的工具可以帮助您查看此订单：您的办公室墙。在post-it上写下你的任务并将它们放在墙上。认真。它非常适合我。

<强> [7] 现在你已经处于项目的中间位置了。您的估算总和将为您提供两个发布日期（乐观和悲观）。你可以设置里程碑。定期更新您的任务估算值。计算的发布日期的更改将告诉您如何执行。

Answer 4

一次咬一口。

说真的，只要你没有完全专注，看整件事就很好。我们必须把它分解成越来越小的项目，直到我们能够抓住它。

如果您还没有采用这种方式，那么任何敏捷方法都能发挥最佳作用。 Scrum 很棒， XP 很好。这些使用迭代，尽可能快地获得一些功能。

试图让你的手臂环绕整个事情真的非常非常困难，而且我发现它非常令人失望。但是使用敏捷技术，用户会立即看到进度，我们的团队会因为他们的代码在现实生活中被使用而感到兴奋。

Answer 5

从1 peice开始，开发它，完善它，并从中学习。完成后，转到下一部分。当您执行每个部分时，请添加到可重用代码库中。随着你的进展，这个过程应该更加精细，开发时间应该减少。你能做的最糟糕的事情就是用基于瀑布的方法开发整个东西。得到一些有用的东西并完善它，这不仅可以让你展示老板们的作品，还可以让你在计划和编码之间找到自然的平衡。

如果您想要一个正式的计划方式，我会建议敏捷开发。它将为您提供有关如何规划任务和执行任务的良好指导。但是我仍然认为开发团队会陷入一种最适合自己的方式，并且渐进式方法可以实现这一目标。

Answer 6

所有这些都应该来自项目需求文档，这将让您知道哪些功能实际上是需求，哪些功能是在范围蠕变中添加的。确保你实现他们想要的东西。

我的建议总是与您交付项目所需的人交谈，提出一个时间表，表明您将完成重要功能x。找出必须完成的工作是通过需求文档开始，以及针对哪个任务应该首先交付的大型项目（和小型）优先级。

谈话谈话是确保每个人都知道一直在发生什么的最佳方式。

Answer 7

显然你想把它分成小块，记得在做WBS（工作分解结构）的时候不仅要把它分解成更小的碎片，而且还要：

• 定义将首先处理哪些部分（优先考虑最重要的业务部门）
• 计划交付，许多项目提供代码，但后来很难推广，计划每个版本的交付方式以及对用户的潜在影响
• 尽早/快速完成任务 - 没有什么比早期胜利更能建立信心
• 制定沟通计划 - 谁需要知道什么时间和什么时候 - 例如：每个需要获得变更/影响通知的迭代版本
• 确定您是否会在发布期间重新评估反馈，以确定交付顺序或功能是否已更改
• 意识到越早发布到生产中，越早需要支持它并继续开发