【我的项目经验】——开发流程管理

  我所在的公司过了CMMI-level5级最高认证。严格来说,我一直认为只能达到CMM3-4级的水平,因为当时05年过了3级之后,一下子就跳到了5级认证,从理论上来讲,CMM是持续改进,不可能在短时间越级,尤其越到最高级5级。不过,不管怎样,国内公司达到CMMI5级挺少的。我们公司的CMMI5最明显的特征就是Reject标准,一个模块Priority >= Normal级别的Bug数如何超过预估数的1/3,就会Reject。比如 “Login"用户登陆模块,QA估计了6个Bug,你如果出现了3个Normal以上的Bug,整个Login模块就拒绝进行测试,被QA打回来重做,模块的开发者还要加班完成bug修复,同时写《检讨书》给所有人~~⊙﹏⊙b汗,而且绩效考评降一个等级,还要罚钱……+_+,唉……在这做开发真累啊,工资也不必QA高……感觉开发都是奴隶……囧(跑题了……)

  这次主要是讲《开发流程管理》。完全是我们项目经验的总结加上我自己的体会,没有任何理论的东西,都是可行性很高的方法论。

  其实,做开发做久了,就有一个深刻体会:开发前期如果对需求不明确,如果设计不得当,后期修Bug,维护代码,实现微小功能改动都要付出惨痛的代价。因此,开发流程管理的核心思想就是:问题提出和解决越早越好,尽量在前期消除所有可预料到得Bug。

  那么,我们怎么做呢?分以下几个步骤:

  1. BA与UI Designer,我们开发应该督促BA和UI Designer把文档写的更加细致一些,甚至细致到Error message怎么显示,是Dialog还是在页面上方出现,要不要支持鼠标右键。其实最重要的是潜在的业务逻辑。比如BA在A文档描述了一段信息,但是你如果做这个模块的话,还必须看B、C文档。因此,开发做模块钱都要向BA问模块所需的所有文档和信息的来源,平时沟通都不可以口头,要以Meeting Review来记录。

  2. FSD Review。看完文档后,我们开发必须来讲这个功能是怎么回事。没错,是开发人员讲,而不是BA。为啥?人只有复述才能让别人知道你到底想的和他的对不对。此时,架构师和BA都会以各种刁难问题来挑战你的理解程度,如果你复述不清,那么就必须自己加班去学习相关业务,不会再给你任何额外的时间。QA也会提出难题来提问。答辩过后,一般会有N多问题提出,此时要做好Meeting Minute。一天之后,必须向BA和架构师发送Email来告知所有问题的处理结果。

  3. High-Level Design。需求了解清楚之后,紧接着就是设计,但这个设计不是出完整的DSD,而是要根据FSD来描述你如何设计这个模块,别人如何调用你的模块,你的UI是如何设计,有没有用到通用控件和第三方控件,有没有符合UI Specifaction文档的描述,是用Grid啊,还是StackPanel来布局,是Grid嵌套Grid还是划分M行N列,用RowSpan来搞定。总之,High-Level Design是让架构师和Team Leader来知道你是如何做设计的。High-Level Design的产出物是DSD文档的雏形,里面只需“流程图”“外部调用图”“类图”“公共模块图”“序列图”“UI开发框架图”即可,可以不包含文字。同样,High-level Design也是答辩形式的,别人会提很多问题,所以开发人员不可以掉以轻心。虽然是High-level,也会精细到UI的布局,缩放,滚动条,外部调用接口,通用类,辅助类等等的编写。开完会之后,每个开发也要发Meeting Minute给所有人,一天之后,必须将所有问题的解决方案给列出。一天不完成High-level Design,一天不让写代码!

  4. Test case Review。这是发生在开发刚刚写代码的时候。QA此时会列出他的Test case, 你要知道,QA的Test case非常的细致,QA懂的业务逻辑比BA还多还细。因此,Test case review meeting对开发掌握细节非常有帮助。与QA交流一般都会很有收获,那些被我们开发遗忘在角落的边缘地带和不被关注的字段都会被QA挖掘出来从而让我们大开眼界!因此Test case review不要以为是QA的事情,其实对开发很有帮助。

  5. 交叉测试。虽然是测试,其实是开发内部的交叉测试,交叉测试一定要打包。A开发测B开发的模块,B开发测C的模块,等等。重点是以开发的视角来发现Bug,尤其是那种出异常的严重的Bug一定要消除。

  6. Demo。交叉测试之后,迅速修复Bug。修复完之后,就到了Demo Time. Demo 是 Developer的Show Time。没错,还是开发操作。Demo一定要打包。开发根据功能依次向QA来演示,QA会时不时的提出问题,此时会有一些Bug由于自己或者别的开发的bug的缘故表现出来,QA会把此次Demo所有的Bug记录在案,同时发给所有人。如果Demo的bug有1个不消除,QA就拒绝进行真正的测试。

  7. 冒烟测试。这是开发正式测试前最后一次测试。此次测试打包后就交给QA,QA再大概过一遍,主要是检查Demo的bug有米有修复,同时也需要检测出模块所有Major级别以上的Bug。发出Email给开发之后,留给开发1天时间消除所有的Bug。

  8. 测试。真正的提交测试。提交测试要签字,并写上估计有的Bug数目,这个很关键,如果超出1/3的bug数,就要Reject,就要写检讨书……还有,提交测试书上还要表明FSD的版本号,注明哪些功能没实现,暂时不测等等。提交之后,就是QA的Show time了。

  9. 修Bug。这个不必多说。不过每个bug都是记录在案的。老大会看你的bug数,太多了你就等挨批吧。

  10. 开总结会,继续进入下一轮开发。没有总结,没有提高。认认真真写会后总结吧!

 

  以上就是俺们的牛B流程。说实话,虽然每天都加班加点,不过这样做确实bug数量很少,可是啊……谁来在乎偶们滴健康呢?周而复始的这样加班……搞的偶现在肚子都鼓鼓的……明显胖了好几圈挖……唉……如果时间给多点就好了。

你可能感兴趣的:(流程管理)