最近开发的一个软件项目管理软件(也算是对管理的讨论)

to 曹晓钢：
呵呵，你还是要显示出更多的证据证明这个软件确实减少了管理的复杂性而不是增加了复杂性。
如果一个公司本来在管理上有很多繁文缛节，那么一个项目管理软件对于简化项目管理、减轻工作量确实是有好处的。但是如果一个公司本来采用比较简化但是有效的管理方法，那么如果使用不适当的项目管理软件，反而会增加管理的复杂性。我只是害怕这个项目管理软件反而会增加我们这里的管理复杂性（这只是猜测，确实很武断，不要当作恶意攻击就好了）。另外林博士是研究 CMMI 的，我们根本就不想走 CMM 这条路。我说的所有的都是我们这里的情况，并没有说这个软件不适合你们那里，所以说是一家之言。
我只是不太迷信这些东西，没有必要靠大谈某种项目管理软件提高了开发效率来证明我确实是一个称职的 PM。
CVS+TODO List 确实不能做 Bug Trace。我们早就考虑过这个问题，我们是用 Bugzilla 来做这件事的，目前可以完全肯定已经够用了。还有你说的 Code Review 就更加荒谬了，一个项目管理软件能帮助你做 Code Review 吗？Code Review 是靠人来读代码啊，如果做这个工作的人不负责任，敷衍了事，那么项目管理软件能帮助你吗？
这个问题我不想再多谈下去了，因为显然大家都是在泛泛而谈。

黑黑，我本来就是泛泛而谈的，没有针对任何一个管理软件。所以我也没有说jlinux的这个软件就适合你们的情况或者适合特定团体的情况。
实际上我自己也在构建另一款管理软件。

我对CMM也没有什么特别的兴趣。
至于攻击一说大伙更不必在意，论坛就是用来讨论用的。讨论的越多，了解就更深入么。

我说的code review的意思是这样的：公司里面有时候会进行code review，比较资深的程序员帮助新程序员提出意见。这时候，这些意见需要有一个地方纪录。我们使用一个bug trace工具来记录所有的bug和这些需要改写的代码的位置，并且给出详细的描述。那么在VSS或者CVS里面（我们不同的项目有的用VSS,有的用CVS), check in/commit的时候，就需要指明这次checkin针对的是哪个bug或者code review.这样的话，这次code review之后所做的具体代码改进，一个diff就可以看到。

如果没有这样的方式，code review很可能说过就说过了，大家还要依靠纸面或者大脑来进行记忆，这就是我所说的复杂性。我先我已经说的很清楚了，管理工具不能代替人进行任何有创造性的工作，但是可以用来追踪事务性的工作。Code Review就是一个例子。

to 曹晓钢：
你这样说就清楚多了。如果只做跟踪和记录的话我们完全可以靠 Bugzilla 来做这些事情。
Bug-zilla 其实是一个 Defect Tracking System 或者 Issue Tracking System，并不一定专门来做 Bug Tracking 的。Bugzilla 已经可以与 CVS 集成在一起来做你们正在做的事情。这也是为什么那么多 Open Source 软件采用这套组合的原因。
在这类 Open Source 的项目管理软件已经有不少而且基本满足需要的情况下如何证明你们的产品是真正的 Killer 呢？何况很多时候别人吃了第一个馒头已经饱了，如何说服他再吃掉一桌的山珍海味？这就不是技术所能做到的了，靠 Sales 吧。

赫赫，并非bugzilla或者同样是开源的GNATS在这个领域中就是最好的。否则JIRA也就没有生存的空间了。这个市场中，除了JIRA之外，还有BugZero,BugFogz,TestTracker等等著名的管理工具。任何市场都存在技术进步，都是有机会的亚。

晓钢，我承认你最后说的非常有道理。我只是希望软件公司的管理者不要太迷信这些项目管理软件，工夫还是要下在实处的。正如 Brooks 所认为的，这些项目管理软件所解决仍然不是软件开发的核心问题，所以只能取得很有限的收效。

我对于这些工具的感觉很复杂，25岁的我很相信这些东西（因为当时没有）。可是我现在都35（少说一岁，显得年轻点）。其实有些过程很复杂，比如RUP，你要是所有的工作都手工作显然有问题。可是事情也有另外一个方面，那就是这么复杂的必须依赖工具辅助的方法是不是就比较有效呢？我的经验是这个时候应该重构你的方法，让它简单起来。不过这个时候就又用不到那些工具了。

所以支持jlinux的努力，但是对于他的产品定位感到不十分同意。

另：我发了个帖子，里面有两个链接，希望大家讨论一下我的观点。因为我对我说的不是特别有底气，特别是code review。我只能说我以前实施过这样的做法是成功的，但是我想应该还有很多别的好办法，简单而便宜。

呵呵，叫你 ozzzzzz 兄看来是没错了。
这些问题也是我很关注的，不过目前还没有完全考虑清楚，所以不太敢乱说。项目管理谁敢自称是专家啊？我目前见到过最自信的就是 Kent Beck 和 XP 了，但是发现 XP 和 TDD 具体实施起来还是要做很多的折中。
晚上一定拜读这两篇文章。

所以说jlinux的future在某些特定项目中是的确有其价值的。好的项目管理工具是需要和完整的项目管理咨询服务一起推广的。假若某个公司在实施CMM(虽然你我可能都不会实施，但是的确国内有很多公司在实施），,在和咨询公司一起处理实施细节的同时如果有这样一款软件辅助，当然还是很有用途的。软件能起到减少人工管理的复杂性的效果。

各人有各人的天堂，不同的软件当然有不同的使用者。在管理角度上，不存在绝对的对和错。所谓项目管理软件，理解成辅助项目管理的工具就更好了。

ps:其实future的bug trace部分也做的相当出色。

嘿嘿，所以我说：所以支持jlinux的努力，但是对于他的产品定位感到不十分同意。
其实这些东西给别人用就可以了，咱们自己就免了。
有个真实的故事，忘了在什么地方看来了的。

一次为重型方法提供服务产品的会议，一个使用重型方法的客户询问产品提供商他们使用什么重型方法开发的这些产品。得到的回答是：“如果那样，你就见不到这样的产品了。”

能具体说说产品定位的问题.