完全缺乏计划和分析瘫痪之间的分界线在哪里？
在我在编程领域工作的很短的时间里，我看到了两个极端：
- 项目几乎没有进行规划，从而成为维护噩梦。
- 项目永远处于规划阶段并且不会从那里移动。
后者似乎常常是对前者的反应。 快乐的媒介在哪里？ 更重要的是，如果一个项目正在朝着这些方向之一发展，那么将其推向上述快乐媒介的最佳方式是什么？
In my very short time working in the programming field, I've seen two extremes:
- Projects where little to no planning was done and thus become maintenence nightmares.
- Projects that are perpetually in the planning stages and don't move from there.
It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据我个人的经验，我发现“决定”是我的瓶颈。
如果是这种情况，那么：
“概念验证”是一个用于证明某事的最小应用程序。 （我的通常是 1-6 小时）
如果你遇到 2 个或更多选项相同的情况，给自己一个时间限制（比如 5 分钟，而不是 2 个月）并做出决定......任何决定，不要看后退。
并相信自己能够处理在设计时没有考虑到的任何问题。
In my own personal experience, I have found that 'decisions' are my bottle neck.
If this is the case, then :
A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)
If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.
And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.
初始规划应大致为 O(log n)，其中 n 是预期的总开发时间。
如果你必须推迟一周，可以在餐巾纸上画一些东西。
如果你有一个月的时间，第一天就是初步设计。
如果你有一年的时间，就花一周的时间。
这确实假设您迭代地重新审视规划，并且不要在没有成人监督的情况下在代码库上采用所有突击队风格:-)。
Initial planning should be roughly O(log n) where n is expected total development time.
If you have to push in a week, sketch something on a napkin.
If you have a month, the first day is for initial design.
If you have a year, spend a week.
This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).
分析瘫痪可以有很多症状。 我注意到，每次会议都会提出相同的问题，但没有达成任何解决方案。 如果你能向人们指出这一点，也许能够帮助他们承认规划过程停滞不前。
如果可以的话，在项目开始时，声明您希望在规划阶段满足一定比例的需求，例如 80-90%。 这样就有了明确的目标，并且您不必追求完美。 您可以稍后重新审视计划和分析，只是不要让它耽误事情。
Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.
If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.
我认为这取决于两个因素：
项目的长度
项目中引入的变更的风险
显然，这是上述两个因素的结合。 花 1 个月的时间设计一个需要 2 天才能实现且对架构风险很小的功能根本没有意义。 我在这里描绘了一个长度/风险/设计时间权衡的矩阵。
Code Complete 2 中有一些有趣的建议，我目前正在阅读。 我不记得确切的措辞，所以我在这里解释一下，但它说的是：
在设计中可能犯的两个最大错误是：
找到快乐的媒介这两者之间是成功设计和规划的关键。
I think it depends on 2 factors:
The length of the project
The risk of the changes being introduced in the project
Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.
There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:
The 2 biggest mistakes you can make in a design are:
Finding the happy medium between these 2 is the key to successful design and planning.
伟大的问题——没有绝对的答案——这就是让体验变得有意义的原因。 经验包括：
一个重要因素是正在开发的系统 - “生命”越重要，您需要的细节就越多（心脏监测仪与一个网页）。
越复杂、成本/时间有限、事关生命，前期工作就越多 - 越少，您在工作时可以详细说明的越多（原型到生产）
Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:
A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).
The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)