流程是为了项目服务，能使项目有效地高质量完成的流程就是好的流程，尽管我们的流程不是最完善的，还是有很多值得改进的地方，但是我们一直在探索、在改进，我们不只是追求流程，而是追求流程所给项目带来的实际收益。这是值得国内很多公司学习的地方，我真的希望，我们的本土软件，不要一味地追求所谓的流程，很多所谓好的东西的确是好，但未必适合你，很多好的东西也许只是一个光环，至于这个光环能够给项目带来多少实际的好处就是另一回事了。阅读全文>
发表于 @ 2008年11月24日 22:33:00|评论(loading...)|编辑|收藏
每周或阶段项目例会以及项目总结会议，是实施CMMI后所有成员都达成共识的保留内容，因为我们从中获得了益处。也正是因为项目的例会和总结,让我们及时地发现问题解决问题,及时推动项目的顺利进行.阅读全文>
发表于 @ 2007年09月13日 11:11:00|评论(loading...)|编辑|收藏
我们部门的一个项目，作为公司参与CMMI5评估的主要项目之一，从去年6月份开始，到今年3月份结束，所有的过程都参考了组织的标准过程。因为实施了CMMI，我们需要多花了将近50%的时间，而且，在这个过程中，那些雾里看花的流程，那些堆积着的文档，还有那些烦琐的工作报告，让团队中的成员烦恼。换句话说，实施了CMMI，在短期内我们看不到好处，它不能让我们的工作更好地服务，反而成了大家的负担，为了CMMI而CMMI。于是，在我们项目的2.0版本，完全放弃了CMMI的流程，重新回到了我们传统的开发手法。这让我感到悲哀,也在后续的工作中产生了对CMMI5的碰撞与思考.幸运的是，在项目的后期，我们逐渐也领悟到了CMMI5的好处，大家也逐渐意识到传统的开发流程，虽然速度会快很多，但是快需要付出的代价就是乱。于是，CMMI5，又重新被我们摆在了桌面，这次，我们的目的很明确，流程为了项目服务，我们不会为了应付性地去写一些文档或实施一些不必要的流程，流程的规范，是为了减少人为因素的影响，更及时提交高质量的软件产品。我看到了进步，也看到了管理层的决心与团队其它成员的共识.阅读全文>
发表于 @ 2007年09月11日 17:41:00|评论(loading...)|编辑|收藏
CMMI L5评估已经通过，DM的测试工作也将近尾声，对于我们来说CMMI L5才刚刚开始。CMMI当然是值得肯定的，同时也是需要改进的，正如我的朋友所说的经过消化后应用到项目的开发中，这样的应用才会美丽。阅读全文>
发表于 @ 2007年04月22日 16:58:00|评论(loading...)|编辑|收藏
DM终于正式发布了，项目组的成员都长长的舒了一口气。在这个项目中，我自己的确是成长了，从开始对CMMI5的雾里看花，到现在对CMMI5的娴熟实施，这对我来说，是一个质的飞跃。阅读全文>
发表于 @ 2007年04月22日 16:55:00|评论(loading...)|编辑|收藏
CMMI5评估结束了，这并不意味着过程改进的结束，而是过程持续改进的新开始，也是过程推广的新起点。衷心祝愿AI的过程改进能够在全公司有一个质的飞跃。
阅读全文>
发表于 @ 2007年04月22日 16:31:00|评论(loading...)|编辑|收藏
因为前期项目进度的偏差，尽管后来采取了相应的纠正措施，DM还是不可避免地推迟一周发布。阅读全文>
发表于 @ 2007年04月22日 14:06:00|评论(loading...)|编辑|收藏
每件事情都有两面性，好坏兼并。虽然像高考那样认真地去准备CMMI L5，在这个准备的过程中，结合实际实施经验重温了很多有用的理论，收获不少；虽然培训有些像是应试，但通过培训，各个项目组成员相互交流，也收益不少。而且，不培训，我们也真的不知道正式评估会问什么问题，到时也真的是看各人的发挥了，也就无法保证CMMI L5正式评估的顺利通过了。说到这，忽然想起另一个问题，CMM/CMMI在国内，在认证通过前投入很大，基本上都是一次通过，通过比例远远高于全球的平均水平。是因为我们认真努力，还是因为我们善于考试？阅读全文>
发表于 @ 2007年04月04日 16:06:00|评论(loading...)|编辑|收藏
原本只是一个在很短时间就可以完成的项目，因为CMMI的原因，项目的开发时间比原来多了一倍，CMMI号称控制项目的流程，但流程没有有效控制，有一点点的讽刺。不过，再理想的计划在执行过程中也会发生变化，项目跟踪的目的就是及早发现这些变化和异常，确保项目能够按时保质发布，在现阶段发现了问题并及时进行了纠正与分析，也是流程控制的好处。
阅读全文>
发表于 @ 2007年03月28日 11:10:00|评论(loading...)|编辑|收藏
出现这样的问题，一方面是因为DM项目组中的成员同时兼顾着几个项目的开发与测试，在别的项目比较紧张的时候，项目组中的成员便被调动去完成别的工作了；另一个原因，是因为项目组中某些成员不够积极，有些本应该可以提前完成的任务，打着有别的任务需要完成而延迟了本可以在计划中完成的任务；还有一个原因，就是项目组的管理与跟踪力度不够，项目组中的成员并没有投入足够的精力去做事情，项目组中的成员的积极性没有得到最大的发挥。风险转化成了问题，在某种程度上说是管理跟踪不当造成的，看来，管理，真的是一个大学问。阅读全文>
发表于 @ 2006年12月04日 13:08:00|评论(loading...)|编辑|收藏
从这个项目经理的变更，透过这个变更的动作，可以让人领悟到很多变更背后的故事与缘由。正在抱怨没有机会或怀才不遇的朋友，也许，应该停止抱怨，想想自己能干什么该干什么该怎样干。
阅读全文>
发表于 @ 2006年11月20日 13:27:00|评论(loading...)|编辑|收藏
DM项目到目前为止，已经完成了需求调研、项目计划和需求分析，进入了详细设计的阶段。从长远来看，经过前段时间的实施，对CMMI我持肯定的态度。在此我强调的是长远，如果一个项目没有长远的发展空间，或者项目组在以后的项目中不能应用CMMI的精髓，只是纯粹的一个DM项目跑CMMI流程，成本无疑过高。而且，在项目开发的过程中，大量的文档和会议，每个动作都需要讲究流程，对于我们这些喜欢自由崇尚简约的研发人员来说的确让人有点难以招架。不过，每个改变都会有阵痛，只是看这种痛是否痛得有价值。CMMI并非成功于一个项目的革命，而是一个持续的改进，是不断总结成功经验和失败教训，进行缺陷预防和不断改良的过程变革之旅。
阅读全文>
发表于 @ 2006年09月21日 13:37:00|评论(loading...)|编辑|收藏
如果CIMMI5只是在某个项目中实施，如果实施的目的只是为了过级，如果过级之后就连CMMI5是什么都给丢了，我觉得是没有任何的意义的，浪费时间浪费精力。既然开展了就得认认真真地实施，项目结束之后，将其中的精髓应用于整个团队，改进团队的开发与测试流程，提高产品的开发效率与质量，这才是CMMI5所给我们带来的真正意义。否则，在一个项目中投入如此大的成本，就真的太不划算了。在对CMMI5的应用熟悉到一定程度之后，我们不必实施CMMI5的所有活动来，完全可以适当地剪裁合适我们的东西并应用起来，相信这样效果会更好。这些，当然，需要管理层认为有用并下决心去推动，而且团队中的成员也要积极支持，才会出现积极的效果。CMMI5在DM中的应用，能否给整个团队注入焕然一新的面貌？还是只是一场过场戏？现在给结论还为期过早，咱们拭目以待吧！阅读全文>
发表于 @ 2006年09月04日 10:17:00|评论(loading...)|编辑|收藏