小型软件开发组的管理问题

提个问题供大家讨论交流，我自己也学习学习：

我在的公司有个小型软件开发组，大约5-10个人,所用的开发工具主要是：vs2008。
采用怎么样的管理方法最合适呢？
1.代码管理方面。用vss，cvs呢？还是不用代码管理，直接人工管理（目前就是这种方式，我觉得不好）。
2.bug跟踪管理。我建立过bugzilla系统，但是用了一段时间就没坚持下去了，目前是用简单的excel表格来管理的。 
3.开发文档方面。目前最缺乏的就是这个了，但是总感觉力不从心，项目一紧就没时间去实施了。


以上几个方面不知大家有什么体会?或者还有什么方面需要注意，提高的。


有效发言都有分，分数不够我会再加的：）

33 个解决方案

#1

引用楼主 brouno 的帖子:

提个问题供大家讨论交流，我自己也学习学习： 

我在的公司有个小型软件开发组，大约5-10个人,所用的开发工具主要是：vs2008。 
采用怎么样的管理方法最合适呢？ 
1.代码管理方面。用vss，cvs呢？还是不用代码管理，直接人工管理（目前就是这种方式，我觉得不好）。 
2.bug跟踪管理。我建立过bugzilla系统，但是用了一段时间就没坚持下去了，目前是用简单的excel表格来管理的。 
3.开发文档方面。目前最缺乏的就是这个了，…

1.VS的不是自带VSS吗？

配置管理是基本的，否则日后集成是个大麻烦

2.bugfree有中文版，挺好用的，excel也没问题，关键是跟踪好了，用系统的话可以节约跟踪和分析的工作量
缺陷要统计，要分析的，而且可以比较明确负责人是谁

3.项目文档，还是先把计划做好
需求分析
和设计多花时间
而且做出来的文档一定要大家一起评审
数据库的设计找个靠谱的人来做，或者找个相当厉害的哥们评审
最好有原型，这样需求比较容易确定，但是比较花费时间，我个人觉得在需求和设计阶段多花时间还是值得的

一家之言仅供参考

祝你成功～～

#2

项目计划制定很花时间
要留出做文档时间


做好项目规模估算，结合人力资源计划
做好项目计划
不断更新项目计划，要让组员了解项目进度和计划
每日早上立会，让组员自己说今天他应该做什么，做到什么程度，任务何时能够完成
每日晚上立会，让组员介绍自己的进度，能否按时完成

如果你能让组员写日报是最好的，当然你之前做开发人员的时候最好写过，认识到写日报的好处

软件项目最好监控的粒度以天为单位，如果以周为单位都有些勉强，变化太快了

5个人的项目计划一周起码要更新2次左右

#3

1、当然用vss，集中管理代码，做好版本控制。
2、bug管理工具可以选择轻便小巧的，具备将bug分配给具体人员的功能即可。
3、文档是必要的。项目经理最好不要做具体编码，除了管理职位，主要精力就放在写文档上，比如需求、概要设计，详细设计我认为基本没有必要写，关键是要做好代码规范，规范的代码就是详细设计。

#4

1.代码管理应该用代码管理软件，不然会出现版本问题，项目越大问题越多
2.bug跟踪用好excel也是挺好的，简单
3.文档跟不上项目是很普遍的，对于一般的项目没有很大的影响，没文档的话程序里面要做好注释

#5

excel很强大，管理bug很不错。

#6

safd

#7

所有那些原本只能做程序员但是硬被任命为pm的人，会问出你的典型问题。我觉得你当好程序员就可以了，慢慢学习。

#8

你的问题没有研究到这些东西的高级应用，找那些软件的推销用的文档，或者网上的最简单的文章，全都是有入门说明。

#9

引用 7 楼 sp1234 的回复:

所有那些原本只能做程序员但是硬被任命为pm的人，会问出你的典型问题。我觉得你当好程序员就可以了，慢慢学习。

谢谢你的提醒。那么你可以告诉我怎么样才能做个合格的pm呢？想必你是个经验很丰富的人吧。

#10

当你做项目，甚至个人写一个自认为比较大一点的商品化程序，不能进行版本管理是不可想象的。除非你从来没有用过，否则一用就肯定离不开了其中的关键功能。

关于你对bug跟踪管理的问题，可以看出没有在那些数十年来一直强调测试的软件公司呆过，否则一定有最低限度的bug管理系统平台。实际上它也是一个pm素质问题，这个方面确实不用说大道理就可以了。

对于文档的作用，仁者见仁智者见智，这倒是可以细化的。

#11

基本上，项目开发组的管理不是在于前两个形式来驱动，而使用用它做保障。呵呵，就好像你看到美国在海外作战的特种兵带了枪，就去评论是不是凡是带枪的就算是美国特种兵了，实际上你并没有讨论到他们的训练课程和个人素质。同样，你提到的是最容易看到的，任何开发组都有的那么一点东西，其实对于其是否必要没有什么好争论的。

#12

基本上，使用版本管理是多个专业开发人员协同工作时凭感觉就知道离不开的东西。使用bug管理系统是多个专业（手工）测试人员协同工作时凭感觉就知道离不开的东西。分配、协调、追踪、回归、事后统计、规划下一步的任务。例如如果你没有在许多专业测试人员与开发人员协同工作的软件公司工作，你才会忽视bug管理系统的任务管理作用。基本上这是避免人的盲动性所必须的最低限度的手段，正规公司根本不可想象忽视它，根本不用去套用书本上的知识来论证它。

#13

引用 10 楼 sp1234 的回复:

当你做项目，甚至个人写一个自认为比较大一点的商品化程序，不能进行版本管理是不可想象的。除非你从来没有用过，否则一用就肯定离不开了其中的关键功能。 

关于你对bug跟踪管理的问题，可以看出没有在那些数十年来一直强调测试的软件公司呆过，否则一定有最低限度的bug管理系统平台。实际上它也是一个pm素质问题，这个方面确实不用说大道理就可以了。 

对于文档的作用，仁者见仁智者见智，这倒是可以细化的。

首先，非常感谢前辈的关注！个人觉得你说的都很有道理（学习了）。
但是很抱歉，我不得不说你的一些猜测是不对的。
1.自从我毕业后在的第一家公司就是一个1000人的研究院。我负责一个小部门的软件集成工作，可以说职责就是版本管理和bug管理，相反的是我对 小公司的管理情况不太了解 。我提出这些问题的原因是觉得我自己学的还不够。
2.不管怎么说，我现在所在的公司虽然规模不大，但是也出过几款很不错的产品，至少也在为国际上知名的公司服务。

总之，我发起这个帖子的目的是真心向大家学习的，希望不要鄙视我！:)

#14

引用 13 楼 brouno 的回复:

首先，非常感谢前辈的关注！个人觉得你说的都很有道理（学习了）。 
但是很抱歉，我不得不说你的一些猜测是不对的。 
1.自从我毕业后在的第一家公司就是一个1000人的研究院。我负责一个小部门的软件集成工作，可以说职责就是版本管理和bug管理，相反的是我对小公司的管理情况不太了解。我提出这些问题的原因是觉得我自己学的还不够。 
2.不管怎么说，我现在所在的公司虽然规模不大，但是也出过几款很不错的产品，至少也在为国际上知名的公司服务。 

小公司的通常是“老板”创立的技术骨架，那么你可以去了解你的老板（或者技术入股的股东）原先在哪些正规公司工作过。小公司的主管在毫无负责大项目经验的情况下要管理10个人的团队，是很困难的。

#15

通常在小公司要比大公司更加务实才最好，大公司里边务虚的人员在小公司可能带来的问题更多，因为小公司没有那么多给员工练手的本钱。

#16

我不知道楼主在“负责一个小部门的软件集成工作”时得到了怎样的锻炼。楼主在题目中所描述的，似乎都是因为没有长期实际团队开发的锤炼而出现的最常见弊病，不知为何会如此？！

#17

引用 16 楼 sp1234 的回复:

我不知道楼主在“负责一个小部门的软件集成工作”时得到了怎样的锻炼。楼主在题目中所描述的，似乎都是因为没有长期实际团队开发的锤炼而出现的最常见弊病，不知为何会如此？！

我想我能够明白代码管理和bug管理在一个大型公司是至关重要的。可能受到我这个小公司的影响，在这个小公司呆了一年多之后，似乎没有这些（具体情况就是我帖子描述的）也能把项目做好。可能是因为原先这个领导（是个有几十年国外工作经历的老工程师）能力太强了的缘故吧。

所以我现在也迷惘，变得有点不太相信自己以前的工作经历了。
而事实上对于小公司，我也确实没有经验。比如人不多，到底有没有必要加强管理呢，因为如果花很多精力做代码管理的话，必然影响工作效率， 我们平时时间都很紧的。

#18

引用 14 楼 sp1234 的回复:

引用 13 楼 brouno 的回复:
首先，非常感谢前辈的关注！个人觉得你说的都很有道理（学习了）。 
但是很抱歉，我不得不说你的一些猜测是不对的。 
1.自从我毕业后在的第一家公司就是一个1000人的研究院。我负责一个小部门的软件集成工作，可以说职责就是版本管理和bug管理，相反的是我对小公司的管理情况不太了解。我提出这些问题的原因是觉得我自己学的还不够。 
2.不管怎么说，我现在所在的公司虽然规模不大，但是也出过几款…

确实很困难，我自己工作经验不太足。但从个人发展的角度来说，有机会肯定要上的。没去尝试怎么知道自己不行呢？你说是不是，前辈？

#19

该回复于2009-02-13 15:43:15被版主删除

#20

引用 17 楼 brouno 的回复:

我想我能够明白代码管理和bug管理在一个大型公司是至关重要的。可能受到我这个小公司的影响，在这个小公司呆了一年多之后，似乎没有这些（具体情况就是我帖子描述的）也能把项目做好。可能是因为原先这个领导（是个有几十年国外工作经历的老工程师）能力太强了的缘故吧。 

所以我现在也迷惘，变得有点不太相信自己以前的工作经历了。 
而事实上对于小公司，我也确实没有经验。比如人不多，到底有没有必要加强管理呢，因为如果花很多精力做代码管理的话，必然影响工作效率， 我们平时时间都很紧的。

那些最基本的东西，还是坚持养成习惯操作为好。

#21

不考虑个人在开发环境发生意外时回滚历史代码，也不考虑他需要对比当前代码与历史代码来看看自己和别人最近修改了哪些代码，也不考虑当开发地点改变时方便地备份和移动所有项目的代码到别的地点，仅仅考虑多人同步签入签出代码的必要性，使用版本管理服务器就很重要。你们“原先那个领导”仅仅将工作分解给程序员就可以管理项目了吗？事实上这种简单草率的项目管理我也做过很多年，但是我发现只要会用版本管理就离不开了（因为很容易上手），通常确实可以断言那位老工程师确实没有用它管理过大项目。

而没有使用bug管理系统，这是常见的小公司弊病。对于一般程序员，小公司似乎只能练手，就好像按照自己的想象先花很长时间按组装好一架飞机，然后把它推下悬崖试试它会不会飞上蓝天。小公司不注重bug管理、正规测试、回归测试，这是常见的质量问题。我的做法是：深入地掌握自动化测试技术，从而使用自动化测试来代替所有手工测试，从而仅需要最少一个能力比较强的人就可以像大公司一样保证测试，甚至更快速、更全面。

对于文档，由于我强调自动化测试，因此文档显得不是那么重要。我可以每天中午花1、2小时对几百甚至上千的测试用例（使用随机生成的不重复的测试数据）回归测试几万次。如果不能如此，那么文档就是很重要的，程序员编程时要参考文档来理解系统相关部分的接口，因为此时没有自动化测试来保证及时发现他们理解上的偏差，只有靠他们读文档自己去理解。

#22

引用 17 楼 brouno 的回复:

比如人不多，到底有没有必要加强管理呢，因为如果花很多精力做代码管理的话，必然影响工作效率， 我们平时时间都很紧的。

问题的关键是：你所举出的三条，丝毫不显多余，而是非常必要的三条，确保项目进度的必须的保证。所以说他影响工作效率，是有问题的。

软件开发有一个规律，就是没有经验从而无法保证项目进度的pm，往往自认为完成了90%的开发工作量而高兴的时候，没想到剩下的10%的功能可能同样需要90%的开发时间才能交付一个足够质量的产品。如果你的项目确保跳出这个“规律”，你就是一个好的pm。

#23

引用 21 楼 sp1234 的回复:

不考虑个人在开发环境发生意外时回滚历史代码，也不考虑他需要对比当前代码与历史代码来看看自己和别人最近修改了哪些代码，也不考虑当开发地点改变时方便地备份和移动所有项目的代码到别的地点，仅仅考虑多人同步签入签出代码的必要性，使用版本管理服务器就很重要。你们“原先那个领导”仅仅将工作分解给程序员就可以管理项目了吗？事实上这种简单草率的项目管理我也做过很多年，但是我发现只要会用版本管理就离不开了（因为很…

非常感谢！这段话对我很有启发，我一定好好理解。

#24

很受启发，是个好贴！

#25

vs2008的话，你可以试试Visual Studio Team System 2008 Team Foundation Server，这里是官方下载地址：
http://www.microsoft.com/downloads/details.aspx?FamilyId=B0155166-B0A3-436E-AC95-37D7E39A440C&displaylang=zh-cn

#26

引用 17 楼 brouno 的回复:

引用 16 楼 sp1234 的回复:
我不知道楼主在“负责一个小部门的软件集成工作”时得到了怎样的锻炼。楼主在题目中所描述的，似乎都是因为没有长期实际团队开发的锤炼而出现的最常见弊病，不知为何会如此？！ 
 

我想我能够明白代码管理和bug管理在一个大型公司是至关重要的。可能受到我这个小公司的影响，在这个小公司呆了一年多之后，似乎没有这些（具体情况就是我帖子描述的）也能把项目做好。可能是因为原先这个领导（是个…

让我想起腊肉了，看着很美但制作过程惨不忍睹。
也许你的领导工作能力太强，把工作安排的很妥贴，掩盖了很多细节吧。

#27

这帖很好。。受教了。

#28

来晚了，顶

#29

对于1和2，一定是要做的，我目前也是对3比较头疼，项目一忙起来，很多文档就写的不够仔细了，不知道是否有比较合适的解决方法

#30

我公司也一样，项目经常赶进度，开发出来的项目都不走流程的，也没有文档保存下来.而且项目经理就不重视也可说不懂流程，搞得我们做配置管理的人员都无能为力，不知道各位有什么好的建议吗？

#31

你们公司没有 配置管理员？ 或者你没经过项目管理培训就上岗了？


源代码管理 SVN 目录结构的建立

.bug跟踪管理。可以使用项目管理平台，无论是BUG还是项目跟踪，REDMINE 和 testlink 都很好。建议你用用。我们公司就在用，干特图 也非常方便

文档：你们公司是外包还是 研发？ 研发别想着让手下的人写大篇文档了。。不现实，你可以叫他们写写技术方案设计的思想 并且注释写好点就行了！

楼主还是多接触下项目管理吧！

#32

先做一个整体规划，然后制定相关计划，计划在旦确认，一定要坚持，坚持下去就是胜利！！

#33

软件项目管理无非是几条线：
1.需求：需求的无序带来了所有过程的无序，很多的项目其实受需求所累；
2.开发过程：开发过程需要控制的东西挺多，例如团队代码管理、代码质量管理、自动构建、单元测试（我习惯于将单元测试放在开发里面）、模式和框架等等；
3.质量控制：说实话，小项目不靠测试，或者说靠的是最后的集成测试，一般也够用了；质量控制更倾向于开发人员来控制，代码质量；
4.计划和进度：要为自己做好余地；
5.人员管理：人员激励；
我自己开了个博客讨论项目的问题， 大家有兴趣可以去看看，希望能够与大家交流心得