问题标签 [project-planning]

Jeff 最近的文章链接到First Fit Decreeasing算法的时间管理示例，其中谈到了时间管理的帕累托原则（或 80/20 规则），即我们在 20% 的工作中产生 80% 的工作我们的时间。

现在我们都听过程序员的名言：

前 90% 的代码占了前 90% 的开发时间。剩下的 10% 的代码占了另外 90% 的开发时间。

但抛开所有的玩笑不谈，通常你的代码中有 20% 是做你想做的事，另外 80% 是处理异常……那么 80/20 规则真的适用于开发人员吗？

有没有人有任何例子说明为什么它适用/不适用于我们？

只是想知道你们中是否有人知道任何基于网络/基于浏览器的员工调度软件/工具？

目前在 Excel 中完成这一切，但它还不够智能……有什么产品建议吗？

需要在数周和数月内处理多个员工的时间......安排短期和长期工作，让我看到可能的资源问题等。

当您只从事项目工作时，这是一个简单的问题答案，但在我的机构，我们从事项目和日常保留类型的事情，这些事情可以随时进入，通常属于“放下一切，现在就做”类型.

如果只是项目，那么任何一种在线项目管理工具（GoPlan、Cop​​per Project、MS Project）就足够了（但肯定不是 Basecamp，我觉得这对于非常小的项目和小团队来说还可以，但我认为任何更大的工具都可以它作为 PM 工具完全倒下）

唯一接近完成我想要的所有事情的是 Workschedule - http://www.workschedule.net/

它基于浏览器，成本低，有无数的选项，真正让我能够为该机构规划资源水平。唯一的缺点是它看起来很糟糕，但我很快就克服了这一点。

澄清：必须是通用的，即不仅仅是一个行业

• 您在项目规划和为新项目创建工时估算方面有何经验？

• 您使用的方法是什么，为什么对您有效或无效？

• 是否有任何最佳实践需要考虑？

正如标题所说，我现在正在启动一个项目，并尝试为项目布局基础设施（SVN、电子邮件、错误跟踪、在线论坛等......）

那么，Bugzilla 还是 Mantis？

I have seen a few questions about how to interview potential employees and employers, but this is something fairly important that I've come across in the past and I'm sure a lot of other users here will have too:

If you are running a small development company, consultancy or working freelance, what are the warning signs you look for in a potential client? There must be some things that are indicators that a customer will require a lot of supervision, demand a lot of your time and perhaps need you to adjust your charging model accordingly- what are these in your experience and how do you handle them?

What are the red-flags that indicate to you that a customer is going to simply be too much trouble to work with at all? Where do you set the threshold for this decision?

您如何估计实施用户故事所需的时间？如果这是您在知道需要多长时间之前就已经完成的事情。但是，如果它对您来说是全新的呢？你为“惊喜”预留了多少时间？

如果你不得不在一个软件项目中没有一个或另一个，你会选择哪一个？我有很多项目，其中客户或 PM 认为他们可以在没有其中一个的情况下逃脱。我们总是付出代价。

是否有关于在 Visual Studio 项目和解决方案中使用产品代号的做法？通常，一旦选择了产品名称，命名空间、程序集名称、二进制输出等都需要重命名：有什么方法可以解决这个问题吗？

你什么时候知道是时候重构/审查一些代码了？更好的是，你什么时候做？

可能像其他人一样，我发现自己知道某些事情需要重构/审查，但截止日期和管理没有时间去做。我还想听听您如何在一般开发过程中包含代码审查。

最近我发现自己在开发新功能/代码之前就这样做了。例如，如果我必须在应用程序的模块 X 中开发新内容或更改某些内容，我会对该模块进行代码审查。我发现它还可以帮助我更好地理解模块，这样我就可以更轻松地进行更改。

那么你什么时候知道是时候了，什么时候做呢？最重要的是，您如何将其纳入项目规划中？

功能规范是帮助还是阻碍您的期望？练习瀑布方法的程序员是否对功能规范持开放态度？我是一名网页设计师/开发人员，与一个由 5 名程序员组成的团队合作，我想编写一个功能规范来解释我们需要什么，这样当我开始工作时——我知道我们正在朝着同一个目标努力。