浅谈软件开发定律系列之1:10:100定律
1:10:100定律&＃xff1a;需求错误导致的成本是修复程序错误成本的100倍。
定理解析&＃xff1a;1:10:100定律更加形象的说明每个开发阶段&＃xff0c;修复问题所花费的成本。 比如在需求阶段&＃xff0c;可能修复一个问题的成本是1&＃xff0c;那么在开发阶段&＃xff0c;修复问题的成本就是10&＃xff0c;在发布阶段&＃xff0c;修复一个问题的成本就是100。
针对这个定律&＃xff0c;如果问题越早发现&＃xff0c;则成本越小&＃xff0c;抛出了三个问题&＃xff1a;
一、我们有哪些措施预防需求的错误&＃xff1f;
二、我们有哪些措施发现需求的错误&＃xff1f;
三、我们的质量成本是如何分布的&＃xff1f;
一、预防需求的错误&＃xff0c;目前流行的是原型法
----------------以下摘自百度百科---------------
原型法的基本思想
是在投入大量的人力&＃xff0c;物力之前&＃xff0c;在限定的时间内&＃xff0c;用最经济的方法开发出一个可实际运行的系统模型&＃xff0c;用户在运行使用整个原型的基础上&＃xff0c;通过对其评价&＃xff0c;提出改进意见&＃xff0c;对原型进行修改&＃xff0c;统一使用&＃xff0c;评价过程反复进行&＃xff0c;使原型逐步完善&＃xff0c;直到完全满足用户的需求为止。
原型法定义
原型法是指在获取一组基本的需求定义后&＃xff0c;利用高级软件工具可视化的开发环境&＃xff0c;快速地建立一个目标系统的最初版本&＃xff0c;并把它交给用户试用、补充和修改&＃xff0c;再进行新的版本开发。反复进行这个过程&＃xff0c;直到得出系统的“精确解”&＃xff0c;即用户满意为止。
原型法的工作步骤
利用原型法进行信息系统的设计过程中&＃xff0c;分四步进行&＃xff1a;首先快速分析&＃xff0c;弄清用户/设计者的基本信息需求&＃xff1b;然后构造原型&＃xff0c;开发初始原型系统&＃xff1b;之后&＃xff0c;用户和系统开发人员使用并评价原型&＃xff1b;最后系统开发人员修改和完善原型系统。
----------------以上摘自百度百科---------------
原型法是一种很好的工具&＃xff0c;包括我们自己&＃xff0c;在对内部提需求&＃xff0c;甚至自己家里装修的时候&＃xff0c;一开始都没有办法描述清楚自己的需求&＃xff0c;只有软件出来&＃xff0c;房间的3D图出来&＃xff0c;才能理清楚自己的想法。所以装修的3D模型图&＃xff0c;就是一种典型的原型法。
但是在实际的执行中&＃xff0c;原型法用的好不好&＃xff0c;还看公司执行的力度。比较推荐的沟通需求的做法&＃xff0c;是三次闭环。
第一次闭环&＃xff1a;客户描述需求&＃xff0c;然后需求人员当场复述&＃xff0c;第一次闭环。
第二次闭环&＃xff1a;构图完成界面原型图&＃xff0c;然后和客户构图闭环。建议是原型图&＃43;人机交互步骤表格的方式&＃xff0c;进行闭环。
| 步骤 | 人&＃xff08;操作&＃xff09; | 机器&＃xff08;反应&＃xff09; |
| 1 | 点击“登录”按键 | |
| 2 | | 连接数据库进行用户名密码效验 |
| 3 | 成功登录 | 显示主页界面 |
| 4 | | |
| …… | …… | …… |
第三次闭环&＃xff1a;软件有α版本后&＃xff0c;用最终原型和基本实现的功能&＃xff0c;和客户进行第三次闭环。
备注&＃xff1a;在预防需求的错误时&＃xff0c;需要考虑沟通成本。考虑到如果拜访客户需要飞机往返&＃xff0c;此类的成本还是较大。这部分的投入是否能立竿见影的见效&＃xff0c;是关系到成本和产出的统计分析&＃xff0c;目前该阶段拿出数据来较为困难。
二、 如何发现需求的问题
依赖于同行评审&＃xff0c;同行评审&＃xff08;包括需求评审、设计架构评审、代码评审、测试设计策略、测试用例、后续的各种发布说明等林林总总&＃xff09;是非常耗成本的&＃xff0c;占总成本的1/4。这点在很多公司做不到。但往往是忽略了评审&＃xff0c;导致暴露问题的阶段滞后&＃xff0c;最后的结论就是修复问题的成本由1&＃xff0c;变成10&＃xff0c;最后会变成100。
关于评审&＃xff0c;大体有三种模式&＃xff1a;
2.1、写文档的水平高&＃xff0c;评审人水平一般
此类的评审倾向于培训&＃xff0c;主要目的是培养新人&＃xff0c;让新人熟悉业务&＃xff0c;起到传帮带的作用。
2.2、写文档和评审人水平差不多
大家的意见各执一词&＃xff0c;谁也说服不了谁。一般而言&＃xff0c;技术上的方案肯定不止一种。当谁也说服不了谁的时候&＃xff0c;就要提交技术经理&＃xff0c;由技术经理评定到底选择那一种方案。
2.3、写文档的水准低于评审人
比如部门经理作为评审人参与到评审过程中。这种也是指导&＃xff0c;不过是反向的指导。
实际上&＃xff0c;评审是非常耗工时的事情&＃xff0c;这里面还有很多细节&＃xff0c;暂时不展开。
如果评审是第一步&＃xff0c;那么评审遗留问题的闭环则是第二步&＃xff0c;也是最重要的一步。每个团队都有自己跟踪遗留问题的方法&＃xff0c;简单的说&＃xff0c;自己的测试团队&＃xff0c;关于事物跟踪的方法&＃xff0c;大概推行了半年多&＃xff0c;才能基本做到遗留问题的闭环&＃xff0c;这是知难行易的一步&＃xff0c;具体的分析在此略过。
评审的结果有三种&＃xff0c;需要一个量化的指标&＃xff0c;或者一个详细的检查评定表来判定结果&＃xff1a;
1、通过。
2、需要修改&＃xff0c;修改后再次评审&＃xff08;有关键检查项不过&＃xff09;
3、需要修改&＃xff0c;修改后可直接发布&＃xff08;无关键项、有轻量级的问题&＃xff09;
关于同行评审&＃xff1a;
高水平的同行&＃xff0c;肯定自己的业务工作很多。如果公司制度制定不好时&＃xff0c;请同行评审的阻力比较大。比如单一产品线管理模式&＃xff0c;或者强矩阵模式。很多公司是通过制度保证的同行评审&＃xff1a;如果你挂公司内的高级工程师、专家、资深专家头衔并匹配相关福利待遇时&＃xff0c;必须承担自己的工作义务&＃xff1a;每年带多少人、每年讲多少课、每年评审多少次等。
关于沟通&＃xff1a;
这点对市场人员的要求较高&＃xff0c;能否有效的沟通&＃xff0c;把话听明白&＃xff0c;把话说明白&＃xff0c;是需要慢慢的磨练的。如果是新人培养&＃xff0c;员工成长的成本太大。建议有资深想转行的研发体系管理人员担任&＃xff0c;最方便。关于沟通的方法&＃xff0c;在前面已经说过。
关于评审&＃xff0c;说道可执行性&＃xff0c;就要提到分级控制&＃xff1a;
不分级控制&＃xff0c;中间流通的关键点太多&＃xff0c;任务串行&＃xff0c;很容易导致效率低下&＃xff1a;比如有一个问题&＃xff0c;修复花了十分钟&＃xff0c;组长审核20分钟&＃xff0c;技术经理审核20分钟。加起来50分钟&＃xff0c;太麻烦。
如果能分级控制&＃xff0c;用检查表分类&＃xff0c;什么改动不需要评审&＃xff0c;什么改动需要组长评审&＃xff0c;什么改动需要技术经理评审&＃xff0c;这样就会优化过程时间&＃xff0c;提高效率。
三、质量成本分布
整体而言&＃xff0c;针对1:10:100定律&＃xff0c;质量成本的分布很值得思考。
扪心自问&＃xff0c;很多公司在测试投入和返工投入的成本很大&＃xff0c;而在同行评审投入、沟通投入、培训投入的成本太少。更直接点说&＃xff0c;根本没有关注&＃xff0c;或者战略舍弃了在同行评审、沟通、培训的投入。
所以这肯定是一个系统级别的问题&＃xff0c;需要系统级别的解决方案。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 