language-agnostic - 完全缺乏计划和分析瘫痪的分界线在哪里？

Question

在我在编程领域工作的很短的时间里，我看到了两个极端：

• 几乎没有计划的项目，因此成为维护的噩梦。
• 永远处于规划阶段并且不会从那里移动的项目。

似乎后者经常作为对前者的反应而发生。快乐的媒介在哪里？更重要的是，如果一个项目正朝着这些方向之一发展，那么将其朝着上述快乐媒介发展的最佳方式是什么？

Answer 1

根据我个人的经验，我发现“决定”是我的瓶颈。

如果是这种情况，那么：

1. 列出所有设计选项
2. 选择一个选项（如果您无法决定一个选项，请选择几个）
3. 列出最佳选择的风险
4. 对于每一个风险，头脑风暴一个解决方案，然后设计一个结论性的概念证明并编写它。
5. 如果你的概念证明证明它不起作用，那么就放弃那个选项，然后选择另一个。

“概念证明”是证明某事的最小应用程序。（我的通常是 1-6 小时）

如果您遇到两个或更多选项相同的情况，请给自己一个时间限制（例如 5 分钟，而不是 2 个月）并做出决定……任何决定，不要回头。

并相信自己能够处理您在设计时没有考虑到的任何问题。

Answer 2

初始计划应大致为 O(log n)，其中 n 是预期的总开发时间。

如果你必须在一周内完成，请在餐巾纸上画一些东西。如果你有一个月的时间，第一天就是初始设计。如果你有一年，花一个星期。

这确实假设您迭代地重新审视计划，并且不要在没有成人监督的情况下在您的代码库中采用所有突击队风格:-)。

Answer 3

分析麻痹可能有许多症状。我注意到的一个问题是每次会议都会提出相同的问题，但没有达成任何解决方案。如果您可以向可能能够帮助他们承认规划过程停滞不前的人指出这一点。

如果可以，在项目开始时，声明您希望在规划阶段满足一定比例的需求，比如 80-90%。这样就有了一个明确的目标，而你不是在追求完美。您可以稍后重新审视计划和分析，只是不要让它阻碍事情。

Answer 4

我认为这取决于两个因素：

• 项目长度_

  • 这是一个1周的项目吗？
  • 是1年的项目吗？
  • 或者介于两者之间？

• 项目中引入变更的风险

  • 它们是否在本质上是架构性的，可能会影响很多原始代码？
  • 或者您只是添加一个新功能？

显然，它是上述两个因素的组合。花 1 个月时间设计一个需要 2 天时间来实现并且对架构几乎没有风险的功能是没有意义的。我在这里描绘了一个长度/风险/设计时间权衡的矩阵。

Code Complete 2 中有一些有趣的建议，我目前正在阅读。我不记得确切的措辞，所以我在这里解释一下，但它说了一些类似的东西：

您在设计中可能犯的两个最大错误是：

1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation

在这两者之间找到快乐的媒介是成功设计和规划的关键。

Answer 5

伟大的问题——没有绝对的答案——这就是让经验变得有意义的原因。经验包括：

• 您实际上可以从任何用户/赞助商和该特定组中获得多少详细信息
• 您当前的团队需要多少细节（技术/业务特定技能水平）
• 您的赞助商/用户在开发过程中提供帮助的开放程度（您的团​​队有多敏捷——是否包括赞助商/用户？）
• 你发现差距有多好

一个重要因素是正在开发的系统——“生命”越重要，您需要的细节就越多（心脏监测器与网页相比）。

越复杂、越受成本/时间限制、对生命至关重要，前期工作就越多 - 在工作时您可以详细说明的越少（原型到生产）