When the project has reached a complexity level, either in management or code requirements, that all the members of the team cannot give instant answers to stakeholders about the status (immediate or projected) of the project.
What this means: you can start using management tools or the equivalent at any stage you like (here 'equivalent' means using a tool like Excel along with a burn down chart or similar). There is no line in the sand that somebody can draw and then say "once you cross this line you must use a management tool".
You don't have to justify using management tools, you simple have to justify the expense of them. Do they give you enough efficiencies to be worth what you paid for them, the time you invested in training, or the time it takes to use them?
I'm not familiar with redmine, but assuming it has functionality and complexity comparable to trac, I would recommend "going for it" earlier rather than later -- and I wouldn't really call trac a "project management" tool (a term which makes me think of Microsoft Project, GANTT charts, etc, and whose appropriateness to software development projects is much iffier and debatable), but rather an "issue tracking" tool.
If you have a simple project there will be fewer and smaller issues (feature requests, bug fixes, ...), but there's no harm and definitely some good in tracking them -- it helps organization even in a single-person project to easily determine and tweak what areas the problems or desires are in, their relative priorities, etc.
There are other approaches to tracking (e.g., Pivotal's tracker) that may even more appropriate to projects run along agile lines, at least in theory, but personally I've always liked a trac-like system whatever other tools and approaches I'm using (if I can get it to integrate with my code management system -- track changesets automatically wrt what issue or feature they target, etc, etc -- then I'm a really happy camper).
Some tools and approaches that help with big complex projects don't "scale down" well to simpler, smaller ones (because there's a minimum threshold of complexity or rigidity in the approach or tool that makes it too heavy to bother for small-enough projects), but, in my experience, some tools and approaches (a version control system, an issue tracker, code reviews if I can get them and automatic "programming style" checkers in any case, etc) scale down sweetly and I'm always happy to have them in my toolbelt, simple as a project may be!
发布评论
评论（2）
当项目达到管理或代码要求的复杂程度时，团队的所有成员都无法立即向利益相关者提供有关项目状态（立即或预计）的答案。
这意味着：您可以在任何您喜欢的阶段开始使用管理工具或类似工具（这里的“同等工具”是指使用 Excel 等工具以及燃尽图或类似工具）。没有人可以划定界限，然后说“一旦越过这条线，就必须使用管理工具”。。
您不必证明使用管理工具的合理性，您只需证明花费它们的合理性即可。它们是否为您提供了足够的效率，值得您为它们付出的代价、您在培训上投入的时间或使用它们所需的时间？
When the project has reached a complexity level, either in management or code requirements, that all the members of the team cannot give instant answers to stakeholders about the status (immediate or projected) of the project.
What this means: you can start using management tools or the equivalent at any stage you like (here 'equivalent' means using a tool like Excel along with a burn down chart or similar). There is no line in the sand that somebody can draw and then say "once you cross this line you must use a management tool".
You don't have to justify using management tools, you simple have to justify the expense of them. Do they give you enough efficiencies to be worth what you paid for them, the time you invested in training, or the time it takes to use them?
我不熟悉
redmine，但假设它的功能和复杂性与trac相当，我建议尽早而不是稍后“去做”——而且我不会trac 并不是真正的“项目管理”工具（这个术语让我想起 Microsoft Project、甘特图等，其对于软件开发项目的适用性还不确定且值得商榷），而是“问题跟踪”工具。如果您有一个简单的项目，那么问题会越来越少（功能请求、错误修复等），但是跟踪它们没有坏处，而且肯定有好处——即使在单人项目中，它也可以帮助组织轻松地确定和调整问题或愿望所在的领域、它们的相对优先级等。
还有其他跟踪方法（例如，Pivotal 的 tracker），这可能更适合沿着敏捷路线运行的项目，至少在理论上是这样，但就我个人而言，我一直喜欢类似 trac 的系统，无论我使用其他工具和方法（如果我能得到）它将与我的代码管理系统集成——自动跟踪变更集以及它们针对的问题或功能等——那么我就是一个真正快乐的露营者）。
一些有助于大型复杂项目的工具和方法不能很好地“缩小”为更简单、更小的项目（因为方法或工具存在复杂性或刚性的最低阈值，这使得它太重而无法为足够小的项目而烦恼），但是，根据我的经验，一些工具和方法（版本控制系统、问题跟踪器、代码审查（如果我能得到的话）以及任何情况下的自动“编程风格”检查器等）规模甜蜜地下来，我总是很高兴将它们放在我的工具带中，就像一个项目一样简单！
I'm not familiar with
redmine, but assuming it has functionality and complexity comparable totrac, I would recommend "going for it" earlier rather than later -- and I wouldn't really calltraca "project management" tool (a term which makes me think of Microsoft Project, GANTT charts, etc, and whose appropriateness to software development projects is much iffier and debatable), but rather an "issue tracking" tool.If you have a simple project there will be fewer and smaller issues (feature requests, bug fixes, ...), but there's no harm and definitely some good in tracking them -- it helps organization even in a single-person project to easily determine and tweak what areas the problems or desires are in, their relative priorities, etc.
There are other approaches to tracking (e.g., Pivotal's tracker) that may even more appropriate to projects run along agile lines, at least in theory, but personally I've always liked a trac-like system whatever other tools and approaches I'm using (if I can get it to integrate with my code management system -- track changesets automatically wrt what issue or feature they target, etc, etc -- then I'm a really happy camper).
Some tools and approaches that help with big complex projects don't "scale down" well to simpler, smaller ones (because there's a minimum threshold of complexity or rigidity in the approach or tool that makes it too heavy to bother for small-enough projects), but, in my experience, some tools and approaches (a version control system, an issue tracker, code reviews if I can get them and automatic "programming style" checkers in any case, etc) scale down sweetly and I'm always happy to have them in my toolbelt, simple as a project may be!