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

以我个人的经验, 我发现“决定”是我的瓶颈 .

如果是这样,那么:

1. 列出所有设计选项
2. 选择一个选项(如果您不能决定一个选项,请选择几个)
3. 列出最佳选择的风险
4. 对于每一个风险,头脑风暴一个解决方案,然后设计一个决定性的概念证明并写下来。
5. 如果你的概念证明是行不通的,那就放弃这个选择,选择另一个。

“概念证明”是 极小值 应用程序来证明什么。(我的通常是1-6小时)

如果你有两个或两个以上选项相等的情况,给自己一个时间限制(比如5分钟,而不是2个月),然后做出决定……任何决定,不要回头看。

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

最初的计划应该大致是O(log n),其中n是预期的总开发时间。

如果你必须推进一个星期,在餐巾纸上画些东西。 如果你有一个月,第一天是初步设计。 如果你有一年,花一周。

这确实假定您反复地重新访问计划,并且不要在没有成人监督的情况下,在代码库上执行所有的突击风格。

分析性麻痹可以有许多症状。我注意到的一个问题是,每次会议都会提出相同的问题,而且没有达成决议。如果你能向那些有能力帮助他们的人指出这一点,他们就会承认计划过程是停滞的。

如果可以,在项目开始时,说明您希望在计划阶段满足一定比例的需求,比如说80-90%。这样就有了一个明确的目标,而你不是在追求完美。你可以稍后再回顾计划和分析,只是不要让它拖后腿。

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

• 这个 长度 项目的

  • 这是一个为期一周的项目吗?
  • 这是一个为期一年的项目吗?
  • 或者介于两者之间?

• 这个 风险 项目中引入的变更

  • 它们本质上是体系结构吗,可能会影响很多原始代码?
  • 或者您只是添加了一个新功能?

显然,这是上述两个因素的组合。花1个月的时间设计一个需要2天时间才能实现的特性是没有意义的,而且对体系结构的风险很小。我在这里画一个长度/风险/设计时权衡的矩阵。

在代码完成2中有一些有趣的建议,我目前正在阅读。我记不清确切的措辞,所以我在这里转述,但它说的是:

在设计中你能犯的两个最大错误是:

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

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

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

• 您可以从任何用户/赞助商和这个特定的组中获得多少详细信息
• 当前团队需要多少详细信息(技术/业务特定技能级别)
• 在开发过程中,您的发起人/用户在帮助方面有多开放(您的团队有多敏捷——是否包括发起人/用户?)
• 你发现差距有多好

一个很大的因素是正在开发的系统——生命越重要,你需要的细节就越多(心脏监护仪与网页相比)。

越复杂,成本/时间限制,生命周期越重要,前期工作越多——在工作中越详细(从原型到生产)