管理里程碑和Web开发项目

Question

我正在尝试实现Trac+SVN。但我遇到了一个项目管理问题。为了给你一个背景，我的大多数项目都与web开发有关(它们经历了设计、编程、测试等阶段)。

现在我正在为我的项目实现Trac。现在的问题是，我应该把什么作为里程碑和门票。对于票证，我应该获得多大的粒度？例如，我应该说Make X part of Y feature还是Make Y feature only。我做的票越多，我花在这些票上的时间就越多。

此外，对于里程碑，我看到了像CakePHP等项目。当他们使用Trac时，他们将里程碑设置为版本号(对应于SVN中的标签)。这是最好的方法吗？

假设我有一个客户的最终截止日期是X日期。然后我将里程碑设置为1.0，deadline设置为X。但是，我如何跟踪项目，比如每周？因为我不想在发布日期的前一天意识到剩下太多了。我想以某种方式每周检查一次。

此外，我还想考虑增强/错误，也作为门票和俱乐部他们一起作为里程碑。

我设想了类似1.x.x的东西，其中第一个x对应于一组功能增强，而第二个x对应于bug修复。有没有更好的方法？如何在这样的系统中管理每周状态？

有没有一种标准的方法来做到这一点？我该怎么做呢？我完全糊涂了。

谢谢。

Answer 1

好吧，这要看情况。你没有具体说明有多大的项目，有多少程序员将工作，你计划多久交付一次。

如上所述，下面是我们如何在一个由许多较小的子项目组成的跨越几年的大项目上使用Trac。

• Milestones被定义为我们在子项目中有一些功能准备交付的点。每个子项目中的第一个里程碑通常是最长的。我们通常将里程碑命名为“子项目名称v0.01”。版本只是增量0.01，0.02，...当我们实现了子项目所期望的一切时，我们将最后一个里程碑标记为v1.00。后续的错误修复转到里程碑，我们将其标记为“子项目名称- v1.00 -错误修复”
• 里程碑描述只包含新功能或错误修复的列表。文档是用wiki和tickets.
• Trac编写的，Wiki通常至少有一个页面，介绍将在特定里程碑中实现的新功能。它通常是对应用程序预期行为的更高级别的描述。通常，如果produce.
• Tickets包含必须实现的功能或错误的详细描述，则会有预期结果应用程序的示例。

- Bug reporting tickets contain description of bug and steps to reproduce (almost always).
- Feature tickets contain detailed description of feature that must be implemented. One ticket contains **work for up to 6 hours**. When we plan work, we divide features to be in range from 1 - 6 hours of work. If we estimate that feature needs more time, than we split it in several tickets so each of them can fit in 1-6 hours of work. We picked 6 hours because we feel it is the top that we can estimate with error not bigger than 30% (meaning that this 6 hours estimate almost always can be done in range between 4-8 hours). Of course, there are exceptions from this stats. In our experience, main reason for wrong estimates is in bad specifications that we wrote. That, almost always, happens because we (developers) misunderstood business requirements of our users.  

​

• 用于估计和时间跟踪的Trac插件很少。请查看此页面：http://trac.edgewall.org/wiki/TimeTracking。我们使用Timing And Estimation Plugin。您可以输入工单的预计时间和工单上的工作时间。然后你可以得到你在门票/里程碑上花费了多少时间以及你需要完成多少时间的报告。

两年后，我们可以非常准确地估计完成某些工作所需的时间。当我们正确理解用户的需求和要求时，我们通常可以在承诺的时间内交付。目前，我们的统计数据显示，我们高估了约10%的门票所需时间。

Answer 2

前面有一个小小的警告:我不知道如何使用Trac…或者SVN。我认为你的里程碑不应该由版本控制/错误跟踪系统来设置。

通常，里程碑只是项目中的重要事件。它们应该对所有利益相关者都很重要。一个主要可交付成果的完成是一个里程碑。在所有计划和合同上签字是一件重要的事情，但完成10个样机就不是了。

我倾向于使用日程表和任务来与团队合作。在任务完成时将其勾选出来。对于其他人，我只报告里程碑。我们能在5月15日前完成UAT吗？是的我们是。

由于里程碑是向赞助商和其他利益相关者报告的工具，因此您应该将它们设置为他们认为重要的内容。我的发起人会想知道某个核心特性集何时完成，所以这是一个里程碑。他们会想知道UAT是什么时候签署的，所以这是一个里程碑。

设定的里程碑太少，直到最后才会有人知道你的进展情况。如果设置过多，则值将丢失。

没有神奇的公式，但是有数百个任务和数千个工时的项目可能只有4个里程碑。

alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

抱歉，这与Trac和SVN没有直接关系，但希望这能让你大致了解里程碑是如何使用的。哦，为过度使用漫画Sans提前道歉。糟透了。

Answer 3

将1.0里程碑设置为可交付日期很好，但您需要定义更早的里程碑-如果这对您来说是一个很好的间隔，将它们设置为每周一次，并对它们进行适当的编号。对于一个4周的项目，0.2、0.5、0.7和1.0可能会起作用。列出每个里程碑上的相关部分：“设计完成”、“编码完成”、“测试完成”等。如果你没有达到目标，那么真正的项目管理工作就开始了！