界面原型顺利完成之后，整个团队都想立刻甩开膀子写代码！但是，进入开发阶段之前必须进行过程审计。公司的质量经理审计之后认为诸多事项与公司的过程规范严重不符，在完成整改之前不同意进行开发。小M一下子就郁闷了：
第一，需求规格不符合公司规范。虽然做出了界面原型，但是原始需求除了那些铅笔草图，没有任何电子文档。第二，设计严重欠缺。系统架构、数据库都没有认真设计，每个模块的输入输出、处理流程、数据库接口、异常处理、提示信息等等更是没有提及。第三，没有开发规范。按公司要求编码前要确定完整的开发规范，并对所有的开发人员进行培训，现在没有一点准备。第四，工作计划不足。除了有个简单的进度计划，其他如配置管理计划、测试计划、质量保证计划等文档一概没有……
用质量经理的话说这就是个“三无”项目，是个负面典型！小M苦苦哀求、以“时间紧、任务重”为由希望网开一面，承诺开发完成之后一定补文档。质量经理对小M的这套说辞太熟悉了，根本不予理睬。说实话，以前审计中发现文档偷工减料是常事，如果要求严格项目组还可能会补上，一旦松动，项目结束后人就“一哄而散了”，以后质量经理找谁去？
小M也知道，文档不全最苦的是以后接手的维护人员。面对天书一样的代码绝对不敢轻举妄动。现在，公司的管理已经日趋严格，给予了质量经理非常大的权限，审计不合格就是可以暂停项目。看来这个“文档”的槛是过不去了！
质量经理离开小组之后，小M和大家一起商量对策。发哥提议做点文档应付检查，从以往的经验看，检查时对形式的关注大于内容，有一些小窍门可以保证审计过关。南拳和北腿对这种糊弄人的做法很不屑，认为糊弄人的东西再少也是浪费时间。大师兄经验多，也吃过没有文档的苦头，建议拣重要的文档好好整理一下，不重要的就糊弄糊弄。
小M比较赞同大师兄的建议，但是有个现实的问题：快速开发工具有一定的实验性质，有些实现方法只是设想，需要写代码进行验证；验证通不过的话还要尝试其他方法。也就是说，很多情况下是完成编码才能确定设计，设计文档现在想写也写不出来呀！
小M拿不定主意了，只好找到S总商量对策。S总也觉得问题有点棘手，于是带着小M一起找主管质量的公司高层领导商量。第一次见高层领导小M还真有点紧张，越想注意遣词造句就越是前言不搭后语。S总听着着急，直接三言两语就把问题说清楚了。
听完两位的解释，高层领导又问了一些问题，然后说：“刚刚进行的审计过程确实有一些偏差。根据你的描述质量经理是按照“瀑布模型”的过程规范审计你们的项目的，但我初步听下来你们更像是按“原型法”的过程进行开发。这两种方法的流程和文档要求差别很大。这样吧，我安排一个有经验的过程改进的大拿帮你们梳理一下过程和文档吧。”
听说自己的问题有解，小M立刻请那位过程改进的大拿到项目组现场解决问题。大拿先是了解了需求范围和前期工作内容，然后问小M怎么选择的开发模型。
小M听得一头雾水：选择开发模型？公司的规范不就是那一大本书，哪里有什么好选的？大拿说，就在那一大本里有专门介绍如何选择开发模型的章节啊。这下小M有点不好意思了，说实话大家一看到那一大本过程规范就头痛，很少有人认真地看过一遍，自己真不清楚里面还有这些内容。
在大拿的指点下，小M才发现过程规范里有好几种开发模型，只是因为大家常用瀑布模型，所以原型法、增量法什么的都没有注意看。通过进一步沟通大拿觉得小M他们的开发过程更接近原型法，也就是先构造一个功能简单的小系统，然后不断扩充、逐步完善，直到形成一个满足用户需求的真实系统。如果用原型法，大拿建议大致过程如下：
第一步，做出界面原型演示工作原理和交互的过程，这一步小M他们已经完成。(www.xing528.com)
第二步，通过编码验证关键功能的实现方法，然后分别开发各模块。这时系统可以先不连接起来，而是通过一些临时的驱动程序模拟模块的输入和输出，以降低验证的复杂度。
第三步，把各模块连接起来，用真实数据串接整个流程，把原型系统演化成为真实系统。
听到这里小M觉得真是遇到救星了，跟自己以前设想的路径几乎一样！但是，其他人似乎更关心能省哪些文档。结合项目的实际情况，大拿对文档进行了裁减并确定了几个必需的文档。
1）需求规格：那些铅笔画的草图可以作为临时的需求规格，只是在项目完成之后必须整理成规范的文档。需求规格不能省略，即使有了界面原型，但如果根据界面原型反向推测原始需求得费多大的精力！
2）接口定义：快速开发工具结构简单，性能要求不高，不需要进行架构设计。但是接口设计还是必要的，必须说明模块相互之间的调用关系和接口标准。
3）设计文件：数据库一定要完成设计，这部分不能省。简单的程序有过程的文字说明——编码前怎么也要先有个思路嘛；逻辑复杂的程序必须画出流程图，否则以后的维护人员得“看着零件猜它是怎么加工出来的”。
4）开发规范：这部分公司有现成的模板和样例，其实不需要写很多东西，只要根据项目实际情况选用就行。命名规范、编码规范、异常处理和提示信息等应该形成统一的标准，而且应该全员培训。特别容易忽略的是异常处理和提示信息规范，如果出错了都只写一行“××××出现错误”，测试时怎么定位错误？用户怎么知道该如何应对？
还有，进度计划也需要项目组自己根据实际情况细化。但是其余的管理文档大拿答应安排一个质量经理帮助整理。
听完大拿的指教小M心情豁然开朗，不仅对这位大拿的专业精神赞不绝口，对那一大本过程规范也突然有了几分好感。后来小M才知道，那位大拿以前可是位开发高手，为了确保过程规范不脱离实践公司才“忍痛”将他从开发部门调出来的。
随后的几天时间里，项目组紧张地完成了系统设计、文档整理和规范培训工作。其实，磨刀不误砍柴工，虽然多花了这点时间，但大家对整个开发过程和实现步骤清晰多了，对整体架构、调用关系和接口也都确认了，特别是大家觉得开发规范培训对提高后续的开发效率和质量帮助非常大。
正如大拿所说，规范是从实践中产生的，凝结了很多人的智慧和经验，遵守它可以少走很多弯路；同时，规范又是为实践服务的，实践变化了规范也要不断改进，两者只有相辅相成、有机结合才能达成目标。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
