我们小组七人，四名新员工，麻雀虽小，五脏俱全，我们仔细分工，通力合作，在舵手ＰＭ的指引下，驾驶着蚱蜢舟，向成功的彼岸挺进。“只恐双溪蚱蜢舟，载不动许多愁”，尽管有如此多的愁事，我们总算是跌跌撞撞到达了终点，七天的跌宕起伏，让我深深觉得，软件开发过程，就如另一场人生，无不折射出我们熟知的生活哲理，时刻以铁一般的事实为这些哲理添写着新鲜的注脚。

　　尽信书不如无书

　　软件估计，是项目计划的基础，要作好计划，完成资源的分配、工作量的估计等，估计起着举足轻重的作用。在最开初的代码估计之时，我们将这个.C文件的代码行统计工具分成3个模块：输入模块、计算模块和输出模块。软件估计指导书强调，要避免估计过程中的盲目乐观，所以我估计的时候战战兢兢如履薄冰。等结果汇总出来，我们都吓了大跳：数据明显偏高，如果真是这样，以后大家杀鸡可真要用牛刀了！原来，大家都留意到指导书里关于不要盲目乐观的谆谆教诲，一直抱着宁多勿少的极度悲观主义的态度。后来经过周密讨论和设计思路的介绍，我们达成了共识。最后结果证明，估计和实际的产出偏差在5％以内。可见，书不能给读死了，尽信书不如无书，任何的书籍都只能作为拐杖，要是把它当做腿用，就走不了多远。

　　难辩真伪，指鹿为马

　　经过风险管理培训之后，我们对风险概念的理解完全可以自信到一边踱着方步一边摇头晃脑气定神闲给出解释：风险， 是指任何这样的事件或状况，其发生具有随机性，当其确实发生了，就会对项目目标的实现产生有害的或负面的影响。在写这段话时，我完全可以从风险后面那个逗号的片刻停顿里面品出那份得意。然而，滑铁卢总是无处不在。在列出风险时，我们将开发人员水平参差不齐也列为风险。引导者语重心长的告诉我们：开发人员水平参差不齐是实际存在的问题，不是风险！我们怀着的沉重心情返了工。风险管理，想说爱你还真不容易啊。

　　人无远虑必有近忧

　　需求没有分析好，后面的概要设计、系统测试计划的写作，都举步维艰。我们在需求分析时，确定．C文件的代码行统计工具采用GUI图形界面方式。在需求阶段，大家集思广益讨论了一番，最后确定了需求，本以为既是众志成城，应该比较完善，到做系统测试的时候，却还是发现了问题：当我在输入文件名，习惯性地一个清脆的回车键打算进行统计时，它却弹出个浏览框让我选择需要进行统计行的文件！仔细一看，原来默认的焦点是放在浏览按钮上的。和设计者沟通，他认为焦点应该放在浏览上。说到底，这就是一个客户需求的问题。由于在需求规格说明书中没有考虑周全，导致一系列的骨牌效应：改需求规格说明书，改设计文档，改测试计划，增加用例，改代码，怎一个苦字了得！我们的项目需求是自己拍脑袋想出来的，如果有客户的话，我一定会把需求分析进行到底。

　　No pains , no gains

　　在整个开发过程中，我们不是走在最前的，有时甚至有点落后，每每其他组高声大叫review已经完成的时候，我们还在对隐藏的很深的小bug穷追猛打，在引导者的频频催促下，觉得很是汗颜。然而，谁笑到最后，谁笑的最甜，在最后产品发布经受检验之时，我们一次通过，而平日里叫的比较响的小组，却因通过不了验收在焦头烂额地写变更申请，改代码。看来，关键时刻是不能缺斤少两的。

　　金无足赤，人无完人

　　一味说mini项目培训的完美，多半也会引起各位的猜疑，瑕疵是有的：由于培训条件有限，我们没能用配置管理工具对配置项进行管理，从而导致了开发人员多人不受控地同时修改代码和一次取错版本的事故；配置管理的胶片也因为没有资深配置管理人员的通透讲解而象一个缥缈的影子从我们的脑海里一晃而过，没有带走一片云彩。配置管理是开发过程的守护神，而这次培训，我们却与它擦肩而过，失去了它的庇护。

　　细小的瑕疵并不能抹杀它的成功之处，经过这次培训，虽不能说醍醐灌顶，但收获真是不小。我对一个产品开发的全过程有了宏观的认识，就象目睹了一个婴儿的十月怀胎、痛苦分娩和健康成长的全过程，其过程和输出都深深的印在了脑海里。这些有益的知识以及小组成员间合作的融洽，都是我一生中宝贵的经验和经历，我不会忘记