中国4200万家企业需要精益生产;全球70亿人都需要精益思维;
学精益,就上环球精益网
  • 精益管理名词解释大全

    本月热词:

    栏目分类
    热门精益质量文章推荐

    主页 > 精益质量 > INTRODUCE

    【敏捷开发小知识15】质量改进的2个前提

    2019-10-20 16:02 作者:snrxa1209 来源:未知 浏览: 我要评论 (条) 字号:

    摘要:---质量改进的2个前提--- 前提一:向开发要质量 当前很多公司将测试的同学称为QA(Quality Assurance,质量保证),意思是由测试保证质量。前三节我们讲了内部质量和外部质量的关注系:质量是向开发要的。(即质量管理是需要向前管控的) 原因一:测试不能提

    ---质量改进的2个前提---
    前提一:向开发要质量
     
    当前很多公司将测试的同学称为QA(Quality Assurance,质量保证),意思是由测试保证质量。前三节我们讲了内部质量和外部质量的关注系:质量是向开发要的。(即质量管理是需要向前管控的)
     
    原因一:测试不能提高产品的内部质量
     
    测试阶段发现的Bug修正后,报告数据暂时看起来好了,但是发臭的代码并不会因此变好,测试只能消灭Bug,不能消失Worm,只要环境和复杂条件触发(软件产品应用端的使用环境及用户操作方式,在测试的层面无法100%覆盖),Worm一定会变成Bug。
     
    原因二:开发移交质量差,测试的质量也会差。
     
    没有经过开发冒烟测试的软件移交给测试后,要么测试的等待时间变长(开发没有考虑可测试性,部分转测需要造的参数、造环境,到转测时才发现这没有那没有),要么测试受阻。
     
    而移交的质量高,则给测试争取到更充分的时间。好的软件工程是很难测出BUG的,这给测试提出了挑战,也需要给测试同学足够的时间接受挑战。
     
    原因三:依赖测试发现BUG再去修复是非常低效的。
    测出问题后再去定位修复,会降低效率。相反,由开发来保证质量,可以更早的发现缺陷,还可以由代码层面发现同类的问题,从根源解决。
     
    前提二:以需求为粒度控制质量
     
    精益敏捷一直宣导小步迭代,快速交付。传统的瀑布模型的特点是很多需求绑在一起批量移交开发,开发完成后再批量移交测试。在瀑布模型下,很难在开发内建质量。
     
    1、开发人员无法对需求交付质量负责
     
    当需求绑在一起开发时,在开发阶段又被拆分为各模块。没有使用用户故事并实例化需求,开发同学关心的是单一模块的开发完成,没有针对用户故事进行验收。
     
    2、在时间压力下,牺牲整体的质量
     
    开发团队都有帕金森综合症,在开发阶段所有的需求都绑在一起,任何一个需求未完成都会影响整体交付。到批量移交的时限时,质量往往成了牺牲品。
     
    在瀑布的批量移交模式下,开发更关注的是移交的时间,也叫“以项目为单位控制时间”。
     
    当下的精益敏捷开发,以用户故事拆分需求,制定严格的DOD(达到质量标准,需求才可以移动到下一阶段)。每个需求可以单独移动,更灵活,使开发更关注需求及实例化验收。叫“以需求为粒度质量”。
    (责任编辑:环球精益网)
    顶一下
    (0)
    0%
    踩一下
    (0)
    0%
    ------分隔线----------------------------
    特别说明

    此处放横条广告

    ◎最新评论
        谈谈您对该文章的看
        表  情:
        评论内容:
        * 请注意用语文明且合法,谢谢合作 审核后才会显示! Ctrl+回车 可以直接发表

        精益疑问
        免费咨询

        一键加群交流

        石老师

        18970479044