【我的项目经验】——开发流程管理
我所在的公司过了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数量很少，可是啊……谁来在乎偶们滴健康呢？周而复始的这样加班……搞的偶现在肚子都鼓鼓的……明显胖了好几圈挖……唉……如果时间给多点就好了。
