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

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

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


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



再复杂有改BUG复杂吗

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

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

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

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

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

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

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

关于由谁来决定：

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

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

关于如何决定：

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

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

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

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

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