管理里程碑和 Web 开发项目
我正在尝试实施 Trac+SVN。 但我遇到了项目管理问题。 为了给您提供背景知识，我的大多数项目都与 Web 开发相关（它们经历了设计、编程、测试等阶段）。
现在我正在为我的项目实施 Trac。 现在的问题是我应该将什么作为里程碑和门票。 对于门票，我应该获得多细的粒度？ 例如，我应该说“使 X 成为 Y 特征的一部分”还是“仅使 Y 特征成为特征”。 我制作的门票越多，我花在制作这些门票上的时间就越多。
另外，对于里程碑，我见过像 CakePHP 等项目。当他们使用 Trac 时，他们将里程碑设置为版本号（对应于 SVN 中的标签）。 这是最好的方法吗？
假设我有一个客户，其最终截止日期是 X 日期。 然后我将里程碑设置为 1.0，截止日期为 X。但是我如何每周跟踪该项目呢？ 因为我不想在发布日期前一天意识到还剩下太多东西。 我想每周进行一次检查。
此外，我还想将增强功能/错误也视为门票，并将它们作为里程碑组合在一起。
我想象过类似 1.xx 的东西，其中第一个 x 对应于一组功能增强，而第二个 x 对应于错误修复。 有没有更好的办法？ 如何在这样的系统中管理每周状态？
有没有标准的方法来做到这一点？ 我该怎么办？ 我完全困惑了。
谢谢。
I am trying to implement Trac+SVN. But am encountering a project management issue. To give you a background, most of my projects are related to web development (they go thru phases like design, programming, testing etc.).
Now I am implementing Trac for my projects. Now the problem is what should I place as milestones and tickets. For tickets how granular should I get? e.g. should I say Make X part of Y feature or Make Y feature only. The more tickets I make, the more time I spend making these tickets.
Also, for milestones, I have seen projects like CakePHP etc. When they use Trac, they set their milestones as version numbers (corresponding to tags in the SVN). Is that the best way?
So say I have a client whose final deadline is X date. Then I set my milestone as 1.0 with deadline as X. But then how do I track the project say weekly? Cause I don't want to realise one day before the release date that that too much is left. I want to have somehow weekly checks.
Also I want to take into account enhancements/bugs also as tickets and club them together as milestones.
Ive imagined something like 1.x.x where first x corresponds to group of feature enhancements while second x corresponds to bug fixes. Is there a better way? How do I manage weekly status in such a system?
Is there a standard way to do this? How do I go about it? Am totally confused.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这得看情况。 你没有具体说明项目有多大、有多少程序员将工作、你计划多久交付一次。
如上所述，以下是我们如何在一个跨越数年的大型项目（由许多较小的子项目组成）中使用 Trac。
里程碑定义为子项目中的某些功能已准备好交付的点。 每个子项目中的第一个里程碑通常是最长的。 我们通常将里程碑命名为“子项目名称 v0.01”。 版本只是增量 0.01、0.02……当我们实现子项目预期的所有内容时，我们将最后一个里程碑标记为 v1.00。 后续的错误修复将进入我们标记为“子项目名称 - v1.00 - 错误修复”的里程碑
里程碑描述仅包含新功能或错误修复的列表。 文档是在 wiki 和票证中编写的。
Trac Wiki 通常至少有一页关于将在特定里程碑中实现的新功能。 它通常是应用程序预期行为的更高级别的描述。 通常，会有应用程序应产生的预期结果的示例。
票证包含必须实现的功能或错误的详细描述。
用于估算和时间跟踪的 Trac 插件很少。 检查此页面：http://trac.edgewall.org/wiki/TimeTracking。 我们使用计时和估计插件
。 您可以输入预计的工单时间和处理工单所花费的时间。 然后您可以获得报告您在票证/里程碑上花费了多少时间以及您需要多少时间才能完成。
两年后，我们可以相当准确地估计完成某些工作所需的时间。 当我们正确了解用户的需求和要求时，我们通常可以在承诺的时间内交付。 目前，我们的统计数据显示，我们高估了购票所需的时间约 10%。
Well, it depends. You didn't specify how big project, how many programmers will work, how often do you plan to deliver.
Stating that, here's how we use Trac on one big project spanning several years that consists of number of smaller subprojects.
Milestones are defined as points where we have some features in subproject ready for delivery. First milestone in each subproject is usually the longest. We usually name milestones as "Subproject Name v0.01". Versions are just increments 0.01, 0.02, ... When we implement everything expected for subproject we mark last milestone as v1.00. Subsequent bug fixes go to milestone that we mark "Subproject Name - v1.00 - bugfix"
Milestone description contains only list of new features or bug fixes. Documentation is written in wiki and in tickets.
Trac Wiki usually have at least one page about new features that will be implemented in specific milestone. It is usually higher level description of expected behavior of application. Often, there are examples of expected results application should produce.
Tickets contain detailed description of feature or bug that have to be implemented.
There are few Trac plugins for estimating and time tracking. Check this page: http://trac.edgewall.org/wiki/TimeTracking . We use Timing And Estimation Plugin
. You can enter estimated time for ticket and time spent working on ticket. Then you can get reports how much time you spent on tickets/milestones and how much time you need to finish.
After two years, we can pretty accurately estimate time needed to do some work. When we correctly understand users needs and requirements, we usually can deliver in promised timeframe. Currently, our stats show that we overestimate time needed for tickets for about 10%.
前面的一个小警告：我不知道如何使用 Trac... 或 SVN。 我认为你的里程碑不应该由版本控制/错误跟踪系统设置。
通常，里程碑只是项目中的重大事件。 它们对所有利益相关者都应该具有重要意义。 重大交付成果的完成是一个里程碑。 一些功能的完成则不然。 签署所有计划和合同是一件重大事件，但完成 10 个模型则不然。
我倾向于使用时间表和任务来与团队合作。 完成任务后将其勾掉。 对于其他人，我只是报告里程碑。 我们会在 5 月 15 日之前完成 UAT 吗？ 是的我们是。
由于里程碑是向发起人和其他利益相关者报告的工具，因此您应该将其设置为他们认为重要的内容。 我的赞助商会想知道某组核心功能何时完成，所以这是一个里程碑。 他们会想知道 UAT 何时签署，这是一个里程碑。
设置太少的里程碑，直到最后没人会知道你进展如何。 设置太多，值就会丢失。
没有神奇的公式，但包含数百个任务和数千个工时的项目可能只有 4 个里程碑。
alt text http://officeadd .in/Images/articles/ProjectMilestones-scribblea.png
抱歉，这与 Trac 和 SVN 没有直接关系，但希望这能让您大致了解里程碑通常如何使用。 哦，对 Comic Sans 的过度使用提前表示歉意……糟糕。
A small caveat up front: I have no idea about using Trac... or SVN. I think your milestones shouldn't be set by the version control / bug tracking system.
Typically milestones are just significant events in your project. They should be significant to all stake holders. The completion of a major deliverable is a milestone. The completion of a few features isn't. Sign off on all plans and contracts is a significant event, but the completion of 10 mockups isn't.
I tend to use the schedule and tasks for working with the team. Tick tasks off as they are done. To everyone else i just report on milestones. Are we going to make UAT by May 15th? Yes we are.
Since milestones are tools for reporting to sponsors and other stakeholders you should set them to be what they think is important. My sponsors will want to know when a certain core set of features is completed, so that is a milestone. They'll want to know when UAT is signed off so that is a milestone.
Set too few milestones and no one will know how you are progressing until the end. Set too many and the value will be lost.
There is no magic formula, but projects with hundreds of tasks and thousands of man hours may only have 4 milestones.
alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png
Sorry this doesn't relate to Trac and SVN directly, but hopefully this gives you a rough idea on how milestones are generally used. Oh and apologies in advance for the overuse of Comic Sans... yuck.
将 1.0 里程碑设置为可交付日期很好，但您需要定义更早的里程碑 - 如果这对您来说是一个合适的间隔，则每周一次，并适当编号。 对于一个为期 4 周的项目，也许 0.2、0.5、0.7 和 1.0 就可以了。 列出每个里程碑的相关部分：“设计完成”、“编码完成”、“测试完成”等。如果您没有达到目标，那么真正的项目管理工作就开始了！
Setting your 1.0 milestone to the deliverable date is fine, but you'll want to define earlier milestones - make them weekly if that's a good interval for you, and number them appropriately. For a 4 week project, maybe 0.2, 0.5, 0.7, and 1.0 would work. List relevant bits on each milestone: 'Design complete', 'Coding complete', 'Testing complete', etc. If you're not on target, then the real project management work starts!
我看到你有几个选择和几个决定要做。
您可以考虑功能驱动开发。 您可以使用 trac 来支持通信而不是控制。 粗粒度的任务、细粒度的票据和早期发布。
列出要开发的功能，并说明发布（例如...版本 1.0）是在所有功能都开发和测试后进行的。 制作所有功能的伞票。 有粗粒度，就会定义开发节奏。
现在根据计划的功能数量和时间定义几个里程碑。 第一个里程碑应至少包含一个功能，因为里程碑的目标是构建项目以进行测试和反馈。 定义一个或多个里程碑来标记所有功能何时完成，将它们称为“测试版”、“候选发布版”或其他名称。
如果在开发过程中需要更细粒度的任务，请不要羞于执行它们。 并使伞式任务依赖于这些新的票证。
错误报告不需要位于其中任何一个之下，并且可以根据需要提供尽可能多的详细信息。 这些都是细粒度的。 这些不会定义开发节奏。 一个例外是为了消除阻碍因素而进行的 bug 压缩冲刺。 公布有更多已分配且未解决的错误的开发人员的姓名，以迫使他们解决问题。
制作里程碑、测试版或候选版本的过程的一部分是标记源以使该过程可重复，并且即使在主干源已经更改时也能够发现错误。 在 SVN 上，通常的标记方法是将主干源复制到“tags”上的目录，并确保没有人提交到该分支。
我相信对于大多数情况来说，两个数字的版本号就足够了。 第一个数字表示兼容性，第二个数字表示版本。 但是版本号中可以包含几个变量：源代码兼容性、二进制兼容性、错误修复级别、版本、配套产品版本（ala oracle）、协议兼容性等。
I see you have several options and a couple of decisions to make.
You could think about Feature Driven Development. You could use trac to support communication rather that control. Coarse-grained tasks, fine-grained tickets and early releases.
Make a list of the features to be developed and state that the release, say... version 1.0, happens when all the features are developed and tested. Make umbrella tickets for all features. There are coarse-grained and will define development rhythm.
Now define a couple of milestones based on the amount of features planned and time. The first milestone should contain at least one feature, since the goal of a milestone is get the project built for testing and feedback. Define one or more milestones to mark when all features are completed, call them "beta", "release candidate" or whatever.
If during development there is a need to finer-grained tasks, don't be shy in making them. And make the umbrella tasks dependent on these newer tickets.
A bug report doesn't need to be under any of those, and can have as much detail as needed. These are fine-grained. These will not define development rhythm. One exception is a bug squashing sprint to eliminate showstoppers. Publish the names of the developers with more assigned and not solved bugs to compel them to solve the issues.
Part of the process of making a milestone, a beta or a release candidate is tag the source to make the process repeatable, and be able to spot bugs even when the trunk source has already changed. On SVN, the usual way to tag consists of copying the trunk source to a directory on "tags" and make sure nobody commits into that branch.
I believe a two number version number is enough for most cases. The first number denote compatibility and the second, the release. But there are several variables that can be inside a version number: source compatibility, binary compatibility, bugfix level, release, companion product version (ala oracle), protocol compatibility, etc.
我已经使用 Trac/SVN 两年半了。
以下是我的建议：
Trac 是一个非常好的工具。 Trac 的最佳功能是能够将 WikiLink 放置在任何地方，包括变更集注释。 如果您要求将工单号放入变更集注释中，然后将变更集编号放入工单注释中，这会将任务和更改链接到代码。 后来，这些链接使跟踪软件的演变变得更加容易。 这是一个救星，尤其是当项目持续时间超过几个月时。
I've been using Trac/SVN for two and a half years now.
Here is what I suggest:
The Trac is a very nice tool. The best feature or Trac is ability to put WikiLinks everywhere, including changeset comments. If you demand putting ticket # in changeset comment and then putting changeset number to the ticket comment this links the tasks and changes to the code. Later these links make it easier to track the evolution of the software. It is a life saver especially if the project goes beyond a couple of month in duration.