小公司如何做项目管理(上)

我所在的公司和大多数国内IT公司一样，十几到几十人的规模，每次在做完项目过程中我们都会感觉很累，老板其实也很累，在小公司老板更像是一个项目经理的角色，很多东西都没有流程化的东西可走，所以很多事情都要等老板拍板后才可以继续下去，员工在很多时候就会感到迷茫，随着公司规模的扩大，公司也意识到没有一套规范的项目管理方案是万万不行的，自己在这方面也摸索的一段时间。

我首先接触的是敏捷开发的方法，但很快我就感觉这个方法行不通，至少对于我们是这样，因为我们无法保证和客户以及业务人员及时沟通，一个月见几次面就很不错了，而且我们的开发人员也并不具有敏捷能力。后来接触了下CMMI，CMMI对于小公司就更不靠谱了，它庞大的身躯足以把一个小公司压垮，如果仅为一个证书的话，我建议完全可以向o6z订购，但不可否认的是CMMI也有很多优秀的地方可以借鉴。那么我对小公司项目管理的看法是一定要精简，做到不是傻瓜都能够理解并且能够执行，况且很多项目经理（老板）也并不是领域专家。在此我想简单谈谈我对适合小公司的项目管理方案的一些想法，所谓基本适合就是80%适合，我要是说100%适合那我是在扯淡，另外20%怎么办？那就像06z所说的那样，靠经验这个王道。

首先要谈的是需求这个东西，那么什么是需求？需求就是掏钱买你产品的人一些需要，只要是客户的需要，不管是合理不合理那都是需求。其实很多开发人员都意识需求的重要性，那么真正去做需求的人有多少呢？需求应该是包括需求开发和需求管理这两个过程，这里有个特别的情况是对于自主研发的项目，我接触的项目也是这种情况居多，于是我们认为自己就是客户，所以需求开发做的很简单甚至跳过去，结果后期的需求管理非常混乱，我觉得既然自己是客户，那就要当好客户这个角色，在做客户时应完全忘却自己是个开发人员，同样要把需求做全面。很多教科书上都说应该做需求，但关于怎么做的问题上却和实际情况差别比较大，以下是我关于需求该做什么以及怎么做到一些看法。

1 需求调研

我觉得需求调研非常的重要，1年前我还打算做一个在线教育服务平台，理念就是淘宝在网上卖商品，我在网上卖教育资源，我提供网上交易场所，签约的老师、学校以及培训机构提供可交易的服务，这种服务可以通过视频、音频、在线PPT、文本的形式展现。忙活了好一阵，发现这个市场早就有很多人做了，而且这个市场并不是很好做，首先在网上学习的人有几个？并且先不说前期推广需要海量资金就是所需要的那么些高性能服务器丫也买不起！这件事就此搁浅，结果信了马云的邪，2年后你还想创业你在创业！我觉得这就是典型的需求调研没做好，没有对用户需求做调查，没有考虑同行竞争，没有考虑可行性！另外还要考虑括行业标准和法律规定，比如前些时候国家就出台了关于办视频网站的政策，我觉得你丫没有足够的背景就不要往火坑里跳楼。总之根据所做行业情况尽可能的把需求调研做全面，这样才可以保证项目首先是可以赚钱的。那么文档要写吗？我觉得可以不要正式的文档，小公司的人手本来就不够用，要把主要文档化工作集中在重要的环节上，对于需求调研，本来就很杂乱，完全可以记在工作笔记上，放到需求分析的时候整理。

2 需求分析

为了得到用户的金钱，我们总是在说，用户是上帝，用户永远是对的，尽管背地里在说客户端坏话：“你丫钱给的倒不多，要求还真少，这需求根本不合理，是正常人的逻辑吗？”，如果你想活下去，最终我们还是要想方设法满足用户的要求。用户是个外界因素，我们是无法控制的，那么我们只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派专人去现场，随时记录关键性的需求，即使不能去现场也尽可能的获取尽可能多大信息，不要指望开发后去获取什么有价值的东西。那么是否应该做个原型给客户看看？我是觉得这不大合适，因为如果项目周期短的话，等你做好原型，黄花菜都凉了。但我觉得等到需求做到差不多的时候可以做用户界面，所谓用户界面就是用户接口，是和用户打交道的地方，所谓一图解千言，有了界面用户会清楚自己所买的东西在未来会是个什么样的东西，再者开发几个有说明性都界面倒是不会暂用很多时间。等到需求确定下来后就要整理成文档了，这个是很重要的一步，是做设计时候的重要凭证和依据，这个文档就是用户规格说明书，所谓规格就是有规范的格式和内容。

3 需求评审

我们已经有了较正规的文档了，那么下一步就是召集所有开发人员开会，最好有客户代表参加，尽管我是很厌烦开会，但该开的会还是要开到，因为之前我遇到这种情况，开发人员根据设计文档写代码，可是他并不知道自己在开发什么，站在自己的角度想一下，如果自己都不确定自己做的东西，即使有再完备的设计，也会对开发毫无兴趣，只会让自己觉得自己是个代码机器。所以所有人员参加需求评审是让大家知道自己在做一件有意义的事情，自己正在满足社会的需要，自己在为和谐社会做贡献，即使你从没那么想过，那你敢保证的你的潜意识没那么想过吗？人是要有社会满足感的吧。另外开会前一定要准备关键有价值的议题，据我观察需求评审会最容易扯到不着边的话题，所以主持人要控制话题，会议控制在2-3个钟头，最好做成幸运52的形式，所有人员一定要互动起来，否则就变成了个人演讲。需求也做了，会也开了，那么要求客户签字吧。

4 需求管理

需求管理是在开发开始之后进行的，这也是另所有人头疼的一件事，之前做完一个项目后，客户经常打电话找我们，改过来改过去，后来我听到电话，血压都要升高50个百分点，后来索性就不接电话，客户就在网上找我，搞的我连QQ都不敢登，但躲是躲不掉滴，客户直接打我手机，丫的真烦人，见过难缠的，没见过这么难缠的。后来转念一想，难道这种情况真的不能避免吗？至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要修改的地方有了依据，迫使我们去调查到底是改什么地方，怎么改，最后改成了什么样。可能你会说客户需要大幅度修改原有计划，很难跟踪到具体某一项需求，那么我觉得这是由于前期的需求开发没有做好，在后期客户进行实质性的修改的几率是很小的，比如客户要求我们做个OA系统，最后总不会要我们改成个门户网站吧，在举个例子，在比如你开发一个ERP系统，客户自己的业务流程不会轻易的改变吧，总不至于把盘点这个业务改成一个报表系统吧。如果真是这样，我们完全有理由告诉客户，你丫乖乖掏银子，我们再给你们开发2期工程，要改，没门！

大家开始拍砖吧，有时间继续……

评论

53 楼 nowaytj 2009-01-01  

有许多理想状态下的理想值：）
从客观上讲，所谓成功经验和模式乃至于认证，都不是一成不变的，得适合当时的情境才行，没有最好只有更好，只有更合适。火候怎么掌握？这就是人了，说到底其实还是“人制”。
首先要领导认同，问下认同，大家有一个认知的情况下才好办事。
问题就在这里，尤其是我们优秀的中国人，你承认吧？呵呵，谁也不服谁，谁都觉得自己的对，别人的错。所以那些规章制度，认证流程都是给别人看的，就算那个好，最后也是难以实施。

那么，先知先觉们怎么办呢？你说服别人效果是很差的，还是先把自己做好，自己先做出成果来，用实际说话比较好。我一直有一个观点，国内的程序员太浮躁，自己读了几本大师的书，做过几个项目就自以为得道升天了，更些刚入门的没写几行代码就觉得自己可以当PM，就激扬文字了。呵呵

所以国内也出不了什么好项目，更出不了能在国际上叫上名的技术，也没有为开源世界做出什么贡献，就这么天天喊啊叫啊，批呀评呀，年轻轻的就想改行，就想当领导了。

大伙在这里主要还是谈论了比较切实的问题，比较好。

52 楼 steeven 2008-08-29  

所以框架一定要灵活，可以重构，随时修改，不易出错

51 楼 zhangtao 2008-08-24  

受益匪浅。感谢各位前辈的赐教！！

50 楼 nieliqiang84 2008-08-23  

收藏了！好东东啊

49 楼 bubble 2008-08-10  

引用

5-10人 ： 需求开发及管理，bug管理，编码规范，版本管理。
10-30人 ： 需求开发及管理，bug管理，编码规范，单元测试，代码评审，版本管理
30-50人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，代码评审，架构设计，配置管理。
50-100人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，3系统测试，代码评审，架构设计，配置管理，质量保证。
100人以上： 还没想清楚。

我就在2-3人的团队里呆过，但是严重同意以上的5-10人的观点。
我只说只有2-3人的团队怎么干项目，干的即能好又能快，最重要的是文档的量上即不能给团队带来负担，又不能给项目带来隐患，这个尺度不好把握。
但从如何协调管理小团队任务和进度来说，必要的工具支持是必须，是可以提高工作效率的，换句话说，当每个人都清楚自己要干什么的时候，这个团队才会良性运转，而不是项目经理自己一个人知道该做什么。
因此推荐按照团队和公司的需要以及可释放的资源，DIY敏捷流程。
具体如何实现我正想写篇文章来和大家探讨呢。

48 楼 ozzzzzz 2008-08-07  

to gurudk
关于cmmi的问题，我觉得真的需要单独的仔细认真的进行分析讨论。因为这个系统很多内容，而且排列错综复杂，同时还存在各种不同的注解和阐释的方式。
至于cmmi提出的连续表述方式，并不是1.2版本才提出的，而是一开始就有。只不过1.2版本把阶段式跟连续式合并到了一起。至于背后的原因很复杂，我就不展开讨论了。
而我再次强调一下我前面提出的一个重要观点，那就是过程改进之前必须就开始建立一个对于过程改进自身的评估系统，或者叫过程改进应该以建立对自身改进过程进行评估的系统建立为单一启动点。
我们抛开软件行业看看普遍的商业活动领域，任何一项商业流程改进其实都是会提前设定一套对这个改进的投入和产出以及其他后果的评估系统。而本身cmmi这些号称标准的东西，居然不在其中涉及相关内容，我想更多的是道德的问题，而不是他们学术的问题。

47 楼 blackangel_can 2008-08-05  

呵呵，我也想小公司好好做需求，可是每次老板都是以项目进度为原因把需求分析跳过，结果每次都是做出来的东西不符合要求。真的是郁闷。。。。。。

46 楼 gurudk 2008-08-02  

tuti 写道

那问个问题，做什么不做什么 是怎么决定的，是谁决定的？

关于由谁来决定：

我觉得最好交由项目经理（或Team Leader）去决定。因为他最了解团队，对成本，进度，质量负责。这对项目经理要求很高。
其次，就是组织一级的，既然不是每个项目经理（或Team Leader）都有这个水平，那就该在组织一级进行规定。定义裁剪指南，这时往往项目经理被动的接受某个过程。

条条大路通罗马，按照重过程的方式，就是选一条都知道的大路，肯定可以走到，过程成本可能偏高。
依赖于人，可能选择一条比较优化的路，成本较低，也可能反而比重过程的情况成本更高。
从轻量级到重量级过程，对人的依赖是逐渐减少的，但过程的成本是增加的，这似乎是一条定理。

关于如何决定：

基本要考虑团队人员水平，工期进度，质量要求，成本限制，业务稳定性。
目前就想到这些了。

想想现在很多成功的开源系统，他们需求管理做的都不错，一般使用jira，用feature来表述。
同样问题跟踪也可以使用jira或者bugzilla，一般也有一套编码规范，或者遵循已有的规范。
做一般的业务系统，Struts+spring+hibernate足够了，因此架构可以不用过多考虑。
至于性能，你代码写的规范，注释合理，遇到性能问题，还不知道改哪里吗？再说只要不是写的超级烂，
当前的硬件足以满足性能要求，大多数性能问题是sql语句和索引有问题。
对小公司，能做到这样，开发水平估计至少中国前40%了。

45 楼 Julian 2008-08-01  

gurudk 写道

ozzzzzz 写道

xiepinghejun 写道

刚刚本人看了O6Z大师的帖子，觉得见解很独特，本人也觉得对于一个小的团队来说个人经验和集体经验的积累和传递，比大团队要成本低很多，成熟度也大很多，提供的效率也高很多。同时由于小团队中，自然的责任很多，委派职责很少，管理成本和监督成本虽然比例比较高，但是总额却很少，以至于有些时候可以忽略。所以说对于小的团队实施项目管理和监督作用是很大的，他们的职责是很分明的，实施起来难度也不是很大，对提高公司的效率也是很有效的；比如说用CMMI的标准来对一个软件公司的制度化，实施起来相对是简单多了；但是我想问下对于一个十几个人的公司，实施项目管理和监督对于成本来说是能否相对减少相应的成本呢?

就cmmi的问题，我更希望单独的讲，因为这个系统十分复杂，事实上实施的方式也很多，并且评估中人为的因素也很多，最终的实施结果差异也很大。这些都是cmmi这个体系自身的内在矛盾的体现。
回过头来讲小团队的管理问题。实际上管理的加强和监督的加强，往往意味着管理和监督的减少而不增加，这一点不管小公司还是大公司都是一样的。实际上管理的增加造成的成本是否能够回收，并且如何回收，这一点不管所处的组织规模，都是十分困难的工作。而不管是什么场景，增强管理和监督首先要做的，就是这个方面。当然我们不可能一步到位的解决这个问题，也不可能固定不变的采取一个固定的模式解决这个问题。但是如果不能对一个管理和监督措施进行评估，你又如何能够相信它们能够对你进行的开发工作进行评估，而没有这个评估，你又如何进行管理和监督的工作呢？
而一旦你有了这个评估的体系和标准，那么你就可以对你的工作以及对工作的改进进行评估。也就是说，你需要一个对cmmi以外的结合自身具体情况的评估体系，以对包括cmmi或者agile的实施后果的评估系统。

我目前在公里里负责CMMI过程改进，也在思考这个问题。其实我们的软件过程和最佳实践应该有一个频谱，一个多维空间，每一个公司都有自己的特点，都在这个多维空间中有唯一的一点。敏捷，RUP，MSF所有这些框架都只能覆盖这个多维空间的一部分。这也是CMMI1.2提出的连续式表述的原因所在，就我理解：

5-10人  ： 需求开发及管理，bug管理，编码规范，版本管理。
10-30人 ： 需求开发及管理，bug管理，编码规范，单元测试，代码评审，版本管理
30-50人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，代码评审，架构设计，配置管理。
50-100人  ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，3系统测试，代码评审，架构设计，配置管理，质量保证。
100人以上： 还没想清楚。

另外有一个不明白的地方，想缺陷分析和预防这中最简单的错误反馈纠正过程，为什么被CMMI放在了第五级。

我认为不论多少个人开发，单元测试都是有必要的，配置管理，架构设计也不能扔。

44 楼 cyberwjw 2008-07-31  

我比较认同的第二和第四点,这样做比较好,但是需求管理好象大公司都难做到！！第二点就是跟界面原形有类似！

43 楼 tuti 2008-07-31  

那问个问题，做什么不做什么 是怎么决定的，是谁决定的？

42 楼 gurudk 2008-07-31  

tuti 写道

gurudk 写道

5-10人  ： 需求开发及管理，bug管理，编码规范，版本管理。
10-30人 ： 需求开发及管理，bug管理，编码规范，单元测试，代码评审，版本管理
30-50人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，代码评审，架构设计，配置管理。
50-100人  ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，3系统测试，代码评审，架构设计，配置管理，质量保证。

这种以人数来定制活动的提法，相当不靠谱。
就比如说 单元测试 吧，难道 5-10人的就不需要单元测试？
这完全违反一般常识，估计是中了CMM的KPI块状堆积的毒。


建议出看看 Alistair Cockburn的Crystal Methods（水晶方法族）

liuqiang 写道

缺陷分析和预防如果定量分析的话，就复杂啦

再复杂有改BUG复杂吗

可以做，什么都可以做，在成本，进度，质量的夹缝中生存，你要有所取舍。
应该说我的想法还不够成熟，但我感觉跟公司规模是有关系的，我是按照重要性来排的。
经济学里有边际成本，我觉得可以用边际收益来看待这个事情。如果需求不做管理可能，我要损失100块，而不做单元测试可能损失30快。在有限的资源下，我当然挑选最重要的来做。

软件开发世界里没有统一的标准，所以才会有方法学的百家争鸣。光是敏捷开发学就有几百种，我觉得我们不要刻意追随某一种方法学，而是把他们打散，觉得可以用的最佳实践就拿来用。在我看来，像TDD，持续集成，迭代开发，重构都是比较好的实践，至于结对编程，我感觉还不如有组织的代码评审效果好。

方法学加上你自己的价值观，最后就产生了你的团队，你的组织的方法学，现在的时代就是个性的时代。
就像武侠小说说的样，无照胜有招才是最高境界。不要成为方法学的奴隶，你的过程你自己主宰。

水晶方法学以前确实看过，那时没有完全理解，这几天回去在体会一下。
后面有点跑题了，激情所至，见谅。

41 楼 tuti 2008-07-31  

gurudk 写道

5-10人  ： 需求开发及管理，bug管理，编码规范，版本管理。
10-30人 ： 需求开发及管理，bug管理，编码规范，单元测试，代码评审，版本管理
30-50人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，代码评审，架构设计，配置管理。
50-100人  ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，3系统测试，代码评审，架构设计，配置管理，质量保证。

这种以人数来定制活动的提法，相当不靠谱。
就比如说 单元测试 吧，难道 5-10人的就不需要单元测试？
这完全违反一般常识，估计是中了CMM的KPI块状堆积的毒。


建议出看看 Alistair Cockburn的Crystal Methods（水晶方法族）

liuqiang 写道

缺陷分析和预防如果定量分析的话，就复杂啦

再复杂有改BUG复杂吗

40 楼 liuqiang 2008-07-31  

缺陷分析和预防如果定量分析的话，就复杂啦

39 楼 gurudk 2008-07-31  

ozzzzzz 写道

xiepinghejun 写道

刚刚本人看了O6Z大师的帖子，觉得见解很独特，本人也觉得对于一个小的团队来说个人经验和集体经验的积累和传递，比大团队要成本低很多，成熟度也大很多，提供的效率也高很多。同时由于小团队中，自然的责任很多，委派职责很少，管理成本和监督成本虽然比例比较高，但是总额却很少，以至于有些时候可以忽略。所以说对于小的团队实施项目管理和监督作用是很大的，他们的职责是很分明的，实施起来难度也不是很大，对提高公司的效率也是很有效的；比如说用CMMI的标准来对一个软件公司的制度化，实施起来相对是简单多了；但是我想问下对于一个十几个人的公司，实施项目管理和监督对于成本来说是能否相对减少相应的成本呢?

就cmmi的问题，我更希望单独的讲，因为这个系统十分复杂，事实上实施的方式也很多，并且评估中人为的因素也很多，最终的实施结果差异也很大。这些都是cmmi这个体系自身的内在矛盾的体现。
回过头来讲小团队的管理问题。实际上管理的加强和监督的加强，往往意味着管理和监督的减少而不增加，这一点不管小公司还是大公司都是一样的。实际上管理的增加造成的成本是否能够回收，并且如何回收，这一点不管所处的组织规模，都是十分困难的工作。而不管是什么场景，增强管理和监督首先要做的，就是这个方面。当然我们不可能一步到位的解决这个问题，也不可能固定不变的采取一个固定的模式解决这个问题。但是如果不能对一个管理和监督措施进行评估，你又如何能够相信它们能够对你进行的开发工作进行评估，而没有这个评估，你又如何进行管理和监督的工作呢？
而一旦你有了这个评估的体系和标准，那么你就可以对你的工作以及对工作的改进进行评估。也就是说，你需要一个对cmmi以外的结合自身具体情况的评估体系，以对包括cmmi或者agile的实施后果的评估系统。

我目前在公里里负责CMMI过程改进，也在思考这个问题。其实我们的软件过程和最佳实践应该有一个频谱，一个多维空间，每一个公司都有自己的特点，都在这个多维空间中有唯一的一点。敏捷，RUP，MSF所有这些框架都只能覆盖这个多维空间的一部分。这也是CMMI1.2提出的连续式表述的原因所在，就我理解：

5-10人  ： 需求开发及管理，bug管理，编码规范，版本管理。
10-30人 ： 需求开发及管理，bug管理，编码规范，单元测试，代码评审，版本管理
30-50人 ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，代码评审，架构设计，配置管理。
50-100人  ： 需求开发及管理，bug管理，编码规范，单元测试，集成测试，3系统测试，代码评审，架构设计，配置管理，质量保证。
100人以上： 还没想清楚。

另外有一个不明白的地方，想缺陷分析和预防这中最简单的错误反馈纠正过程，为什么被CMMI放在了第五级。

38 楼 gurudk 2008-07-31  

ozzzzzz 写道

xiepinghejun 写道

刚刚本人看了O6Z大师的帖子，觉得见解很独特，本人也觉得对于一个小的团队来说个人经验和集体经验的积累和传递，比大团队要成本低很多，成熟度也大很多，提供的效率也高很多。同时由于小团队中，自然的责任很多，委派职责很少，管理成本和监督成本虽然比例比较高，但是总额却很少，以至于有些时候可以忽略。所以说对于小的团队实施项目管理和监督作用是很大的，他们的职责是很分明的，实施起来难度也不是很大，对提高公司的效率也是很有效的；比如说用CMMI的标准来对一个软件公司的制度化，实施起来相对是简单多了；但是我想问下对于一个十几个人的公司，实施项目管理和监督对于成本来说是能否相对减少相应的成本呢?

就cmmi的问题，我更希望单独的讲，因为这个系统十分复杂，事实上实施的方式也很多，并且评估中人为的因素也很多，最终的实施结果差异也很大。这些都是cmmi这个体系自身的内在矛盾的体现。
回过头来讲小团队的管理问题。实际上管理的加强和监督的加强，往往意味着管理和监督的减少而不增加，这一点不管小公司还是大公司都是一样的。实际上管理的增加造成的成本是否能够回收，并且如何回收，这一点不管所处的组织规模，都是十分困难的工作。而不管是什么场景，增强管理和监督首先要做的，就是这个方面。当然我们不可能一步到位的解决这个问题，也不可能固定不变的采取一个固定的模式解决这个问题。但是如果不能对一个管理和监督措施进行评估，你又如何能够相信它们能够对你进行的开发工作进行评估，而没有这个评估，你又如何进行管理和监督的工作呢？
而一旦你有了这个评估的体系和标准，那么你就可以对你的工作以及对工作的改进进行评估。也就是说，你需要一个对cmmi以外的结合自身具体情况的评估体系，以对包括cmmi或者agile的实施后果的评估系统。

小公司，文化，凝聚力，团队领导人的威信，统一的目标都很重要。靠监督和管理来做，是最差的一种方式。
大公司，因为上述元素很难统一，所以要靠管理和监督，这也是必然。

37 楼 guooo 2008-07-29  

不错.我的项目也快到尾声了,需求还在变,自主开发,也不需要这样吧.关键学是开始需求都不确定,写一块是一块,结果块与块之间要整合,问题出来了,一个接一个.哎.郁闷.

36 楼 liuqiang 2008-07-29  

<div class='quote_title'>xiaoqulai 写道</div>
<div class='quote_div'>看到这么多回帖，到这里有个疑问？？难道敏捷<span style='color: #ff0000;'>紧</span>限于项目管理吗，公司如果有一定技术积累，比如高度抽象<span style='color: #ff0000;'>项目骨架</span>，以不变应万变，不是非常敏捷吗？ <br/>管理很重要，但开发方法也和重要。 <br/><br/>我的第一份工作是在一个小公司，里面做了3个10W到20W的项目，模板就是一个。项目经理会把需求分解成具体的用例，每个用例下面有具体的流程，全是很清楚的步骤，然后我们飞快的，就完成了初期的开发（我当时只是菜鸟级的，都没有问题）。之后派一人到客户那边，做具体的需求变更工作。 <br/><br/>其实把业务很开发分开很重要吧，业务流程整清楚，给客户让他签字，前好后拿回来给程序员开发，只要公司的项目骨架里面集成了一些如分页，防止重复提交，错误验证，导出各类报表，各类页面组件之类的东东，编程跟写文档一样非常轻松。 <br/>做需求变更的时候，代码的修改量非常少。 <br/><br/>我记得当时项目经理对我们有一个要求，我们做的jsp页面不允许写java代码，必须能够在dreamwaver中可以预览，这样修改页面就直接用DW。 <br/><br/>后来换了几个公司，看他们的代码，业务代码与视图耦合，jsp中到处都是&lt;% %&gt;,看得我都反胃了，改一个jsp要半天时间。所以，编码规范也很重要。 <br/>敏捷并不一定体现在项目管理上，对吧。 <br/><br/>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>sg552 写道</div>
<div class='quote_div'><br/>我觉得，一个月才跟客户见几次，是软件开发的很危险的信号。 <br/></div>
<br/>事实往往如此，前期可能多一点，开发过程中总是有各种理由难得和客户见一面，不是他忙就是我忙。尤其是做异地项目。 <br/><br/>
<div class='quote_title'>sg552 写道</div>
<div class='quote_div'><br/>另外，能否请楼主 说一下， 敏捷开发在小公司里实行不起来的 原因吗？ 我比较关心这个，希望学习下。 <br/></div>
<br/><br/>敏捷开发在10人以下我不好说，但十几到几十人的公司我看还是别冒险了。 <br/>只谈2点，首先看看敏捷开发的特点，业务是敏捷的，业务人员和开发人员很难经常在一起，就算经常在一起，那么随时都会有新的需求，系统要经常重构，开发人员具备这个素质吗？就等着和业务人员吵架吧。 <br/>另外敏捷要求你们公司要有很好的员工激励机制，我看这是大多数小公司所缺乏的。 <br/>你觉得呢？ <br/></div>
<br/><br/><br/></div>
<p> </p>
<p> 那你给解释下敏捷是个什么东西吗？</p>

35 楼 xiaoqulai 2008-07-29  

看到这么多回帖，到这里有个疑问？？难道敏捷紧限于项目管理吗，公司如果有一定技术积累，比如高度抽象项目骨架，以不变应万变，不是非常敏捷吗？
管理很重要，但开发方法也和重要。

我的第一份工作是在一个小公司，里面做了3个10W到20W的项目，模板就是一个。项目经理会把需求分解成具体的用例，每个用例下面有具体的流程，全是很清楚的步骤，然后我们飞快的，就完成了初期的开发（我当时只是菜鸟级的，都没有问题）。之后派一人到客户那边，做具体的需求变更工作。

其实把业务很开发分开很重要吧，业务流程整清楚，给客户让他签字，前好后拿回来给程序员开发，只要公司的项目骨架里面集成了一些如分页，防止重复提交，错误验证，导出各类报表，各类页面组件之类的东东，编程跟写文档一样非常轻松。
做需求变更的时候，代码的修改量非常少。

我记得当时项目经理对我们有一个要求，我们做的jsp页面不允许写java代码，必须能够在dreamwaver中可以预览，这样修改页面就直接用DW。

后来换了几个公司，看他们的代码，业务代码与视图耦合，jsp中到处都是<% %>,看得我都反胃了，改一个jsp要半天时间。所以，编码规范也很重要。
敏捷并不一定体现在项目管理上，对吧。

liuqiang 写道

sg552 写道

我觉得，一个月才跟客户见几次，是软件开发的很危险的信号。

事实往往如此，前期可能多一点，开发过程中总是有各种理由难得和客户见一面，不是他忙就是我忙。尤其是做异地项目。

sg552 写道

另外，能否请楼主 说一下， 敏捷开发在小公司里实行不起来的 原因吗？ 我比较关心这个，希望学习下。

敏捷开发在10人以下我不好说，但十几到几十人的公司我看还是别冒险了。
只谈2点，首先看看敏捷开发的特点，业务是敏捷的，业务人员和开发人员很难经常在一起，就算经常在一起，那么随时都会有新的需求，系统要经常重构，开发人员具备这个素质吗？就等着和业务人员吵架吧。
另外敏捷要求你们公司要有很好的员工激励机制，我看这是大多数小公司所缺乏的。
你觉得呢？

34 楼 niceo 2008-07-28  

呵呵！！
我也一样啊在一家小公司上班。软件开发的管理根本太不上啊 。
有的时候我都很无奈啊 ？