完全缺乏计划和分析瘫痪之间的分界线在哪里？

Question

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

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

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

Answer 1

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

如果是这种情况，那么：

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

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

如果你遇到 2 个或更多选项相同的情况，给自己一个时间限制（比如 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

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

• 您实际上可以从任何用户/赞助商以及这个特定群体那里获得多少详细信息
• 您当前的团队需要多少详细信息（技术/业务特定技能水平）
• 您的赞助商/用户在开发过程中提供帮助的开放程度如何（如何您是否拥有敏捷的团队 - 它包括赞助商/用户吗？）
• 您识别差距的能力如何

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

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