敏捷开发如何提高质量_提高敏捷开发效率 - CSDN
  • 主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到...

      前几天,笔者与一位在大型互联网公司从事质量保证的朋友交谈,作为互联网产品质量和测试的负责人,他最近负责的质量管理方面遇到了很多困难。主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到开发团队的认可,离职率非常高;5)质量部门无法收集到数据,不能进行质量度量;6)测试团队也有一批自动化测试专家,但派不上用场…..这些问题可能很多开发团队都会遇到,总结一下,大致是这几个方面:

        

    }        越来越多的企业希望采用,但没有把握

    }        习惯于传统的瀑布式产品开发流程已不满足快速发展需要,但大规模改动不现实

    }        缺少敏捷软件开发专家和人才

    }        技术人员需要观念的转变和方法培训

    }        缺乏相应的质量控制方法

    }        需要经常的和及时的质量度量、测试、决策

    }        自动化测试不能落到实处,每日构建仍是纸上谈兵

    在现在行业中,需求变化太快,不管我们怎么努力去做,发现还是不能满足客户的需要,不管需求搞得多么细,到交付产品给客户的事情,总是有这样那样的问题,这个时候就不得不去修改我们的软件,这是目前很多企业尤其是互联网公司面临的一个挑战,如何解决这个问题?

    笔者先后在华为、阿里巴巴软件质量部门任职,最近也深入研究了腾讯敏捷开发平台TAPD(腾讯敏捷产品开发)和IGD(集成游戏开发)一些资料,对国内敏捷项目的质量管理有很多独到的见解,结合共创力咨询公司多年的项目经验,总结如下:

    1)QA角色的转变

    QA要从警察的角色转变到一个教练的角色。在以前,团队实施CMM的时候,QA更多的是一个警察的角色,他整天拿着一个checklist、报告什么的到处去团队里面看,你是否ok,不ok就要怎么怎么样,整天就干这个活,但是引入敏捷之后,QA就觉得有点失落,都敏捷了,我都不知道该怎么下手了,在著名的通信企业华为的做法是将QA转变了一下,将QA更多的充当教练的角色,充当SCRUM Master的角色,他去指导项目团队该如何去开这个站立式会议,该怎么去做迭代的计划等等指导性的工作,这样QA也觉得挺好,这样他能参与到在不同的团队中去,QA的角色更多的偏向于全过程的敏捷活动指导,以提高产品开发效率和质量。QA在这个过程中也能得到一些数据,如代码缺陷率,版本的不良率,上线遗留问题数,团队成员配合度等等。

          2)要使敏捷团队整体参与

       QA和测试人员也是敏捷团队的一部分,作为敏捷教练,要向他提供支持和训练,以使作们适应开发的快节奏。比如,如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独立定义故事和需求,那你应该主动站出来和团队的其他成员交流,并偿试“三方协作”,即测试人员、开发人员和业务专家。腾讯公司把业务专家称为BA,即

       Bussiness Analyst, BA和开发人员DE、测试人员TE组成了敏捷开发团队,这些成员不仅仅把都在忙着最终的交付而努力,他们还乐于收集和分享信息,与客户或者产品负责人协作以帮助他们充分展示自已的需求,从而得到他们的需要的功能,同时向所有人提供项目进展的反馈。

    3)              自动化回归测试。敏捷团队没有自动化会成功吗?可能也会成功,但我们所知道的成功团队都依赖于自动化回归测试,如腾讯和支付宝公司的Selenium框架,阿里巴巴和淘宝网的QTP框架。汉捷咨询认为,敏捷开发利用测试来指导开发,为了编写的代码使测试通过,需要快速而简单地运行测试,没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

    4)            提供并获取反馈

     反馈是敏捷的核心价值,敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转,测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例?你怎么知道编写的测试用例正确地反映了这些示例?开发人员通过查看测试用例能够理解应该编写什么代码吗?QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码,询问客户是否理解质量标准,应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。把反馈的结构可表示为如下:

     

     

    5)            构造核心的敏捷实践活动

    软件行业有一名老话是:软件质量是设计出来的。对于敏捷开发也是如此,汉捷咨询认为没有一些基础的实践活动,无法产生出高质量的软件。

    持续集成。持续集成(CI)是一项软件开发实践,其中团队的成员经常集成他们的工作,通常每人每天至少集成一次,每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决,降低缺陷修改成本;将集成工作分散在平时,通过每天生成可部署的软件;避免产品最终集成时爆发大量问题。

    灰度发布。这是互联网产品的一个特点,说白了,就是对用户一个逐步放量的一个过程,而且不要求团队要尽早 的将产品包发布出来,也就是不要求马上发布给所有用户,而是会分批的去发布,比如按号段发布,比如在公司内部先体验。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证4小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB产品的发布,可以同时有多个版本,1.1版可能会有100%的用户在用,1.2版可能只有1%的用户在用,它们是一个交叉升级的过程,目前腾讯采用了该活动。

    每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。笔者在阿里巴巴工作时,就经历过每日晨会,一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。

    结对编程:两位程序员在一台电脑前工作,一个负责敲入代码,而另外一个实时检视每一行敲入的代码;操作键盘和鼠标的程序员被称为“驾驶员”,负责实时评审和协助的程序员被称为“领航员”;领航员检视的同时还必须负责考虑下一步的工作方向,比如可能出现的问题以及改进等。有助于提升代码设计质量;研究表明结对生产率比两个单人总和低15%,但缺陷数少15%,考虑修改缺陷工作量和时间都比初始编程大几倍,所以结对编程总体效率更高,同时结对编程能够大幅促进团队能力提升和知识传播。

    用户故事。用户故事是站在用户角度描述需求的一种方式;每个用户故事须有对应的验收测试用例;用户故事是分层分级的,在使用过程中逐步分解细化;典型的描述句式为:作为一个XXX客户角色,我需要XXX功能,带来XXX好处。用户故事的好处是:用户故事站在用户视角便于和客户交流,准确描述客户需求;用户故事可独立交付单元、规模小,适于迭代开发,以获得用户快速反馈;用户故事强调编写验收测试用例作为验收标准,能促使需求分析人员准确把握需求,牵引开发人员避免过度设计。

    迭代回顾会议。在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步;围绕如下三个问题:本次迭代有哪些做得好?本次迭代我们哪些方面还能做得更好?我们在下次迭代准备在哪些方面改进?会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。

     

    总之,共创力咨询认为,测试和质量是整个敏捷团队的职责,团队中的每一个人都应该关注手边的一个任务或者故事,敏捷模式下的质量管理更具有挑战性,但与传统瀑布模式相比,其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于持交付有价值的软件让一直到客户满意为止。在这个“快鱼吃慢鱼”时代,要想交付好而快的产品,不防用敏捷模式试试。

    展开全文
  • 敏捷开发中如何提高开发质量 问题:敏捷开发中如何提高开发质量敏捷开发中采用Scrum过程框架是常见的开发方式。最近上校经历的几个开发项目均采用了Scrum过程框架开发,团队规模从5个人到12个人不等;开发周期...

    敏捷开发中如何提高开发质量

    问题:敏捷开发中如何提高开发质量?

    敏捷开发中采用Scrum过程框架是常见的开发方式。最近上校经历的几个开发项目均采用了Scrum过程框架开发,团队规模从5个人到12个人不等;开发周期从2个月到8个月也不同。项目进行中和项目结项时,都不同程度的存在质量问题:

    • Sprint “带病迭代”
    • 开发周期 Delayed,系统不能如期交付和发布
    • Sprint Test 不能满足度量指标要求
    • 系统阶段性发布后,存在缺陷
    • UTA测试阶段,缺陷率过高
    • Product Owner 频繁变更系统需求,导致Sprint迭代过程中开发范围蔓延
    • 使用SonarQube检测,系统 Defect 和 vulnerability 过多,不能满足 Code Quality要求
    • 系统存在安全漏洞,使用 Security Testing 工具检测后,需要修复漏洞
    • ……

    以上质量问题同样也困扰着各种开发团队。

    那么如何在敏捷开发中提高开发质量?这个话题成为了讨论的焦点。

    上校任务,质量的改善需要从三个方面入手:

    Scrum团队自身的开发质量改善活动

    需要从Scrum团队管理、技术、沟通、个人能力等4个方面做出改善。

    [以下内容未归类,更新后归类]

    • 首要任务是根据项目的重要程度和优先级,组建Scrum团队,合理优化人员能力 —— 从团队下手
    • 树立良好的开发规范并且Scrum团队共同遵守
    • Scrum Master需要真正的起到Scrum规则确保和维护的作用,必要时需要和Product Owner “谈判”
    • Scrum Master要逐步在 Product Owner和其它干系人(Stakeholders)中提高威信力
    • Scrum Planning Meeting 时,根据团队能力和经验数据,做好合理的估算(偏差不要超过20%)
    • 敏捷不代表不需要文档,必要的文档一定要按照规范按时完成
    • JIRA管理一定要每日检查并更新,保证信息的最新状态
    • 双向反馈要及时,除了邮件共享信息之外;项目相关的信息都需要采用JIRA管理
    • Scrum团队需要正确理解Product Backlog,正确理解 User Story,不清晰的需求要及时澄清;
    • Scrum团队提高Coding能力,尤其是一定要基于 Security Checklist 的要求Coding
    • Scrum团队做好Unit Test,提高 Unit Test 的覆盖率
    • Scrum团队内部确保沟通畅通,信息共享
    • Scrum团队中的成员要遵守承诺,具有“契约精神”,遵守DoD规则
    • Scrum Master真正的在Product owner和Scrum团队之间做好沟通“桥梁”
    • Scrum Master收集每个Sprint的度量数据,及时做出分析,实施改善活动
    • Scrum Master带领Scrum团队做好Retrospective活动,改善团队气氛

     

    独立的测试团队加强测试和缺陷分析

     

    QA采取有效的行动做好质量保证

    • 过程控制(Process Control)
    • 定量管理(Quantitative Management)
    • 持续改善(Continuous Improvement)
    • 缺陷预防(Defect prevention)

    (持续更新中……)

    展开全文
  • 敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的

    很多人认为软件质量是软件是否存在 Bug,是否性能高,安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个(或某些)人的价值;价值是指创造利润,又或是降低成本。总的来说,软件质量是软件的灵魂和存在意义。敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。

    本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的开发。

    陈 序明, 架构师, EMC

    孙 沛, 产品开发经理, EMC

    单 建洪, 首席架构师, IBM

    2009 年 10 月 28 日

    • +内容

    前言

    什么是软件质量?很多技术同仁都认为软件质量是软件是否存在 Bug,是否性能高,安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个(或某些)人的价值;价值是指创造利润,又或是降低成本。总的来说,软件质量是软件的灵魂和存在意义。另外,我们知道现在敏捷开发日趋流行,其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。

    本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的开发。

    软件质量的理解

    首先,我们先来看看什么是软件产品质量?先有了软件质量定性的了解,才能介绍如何影响、控制和改进质量。

    大师温伯格在《质量·软件·管理系统思维》说到:“质量就是软件产品对于某个(或某些)人的价值”(某个或某些人文章中统称之为用户),这里面包含两个层次的质量含义,即“正确的软件”“软件运行正确”

    1. “正确的软件”是说,一个软件要能够满足用户的需求,为用户创造价值。此处的价值可以体现在两个方面,即为用户创造利润或者减少成本。如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大,则该软件产品的质量越高。反之,一个产品尽管运行良好,没有 Bug,扩展性很强,性能很好,但如果没有服务的用户人群,没有为用户创造价值,则这样的软件尽管运行良好,也无任何质量可言。
    2. “软件运行正确”是说软件没有或很少 Bug,扩展性很强,性能良好,易用性高等。这样的软件是一个运行良好的软件,但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上,运行良好的软件,才是一个高质量的软件。当然,如果软件完全符合用户需求,但不易使用,经常出错,性能很差,这样的软件也不是一个高质量的软件。

    “正确的软件”及“软件运行正确”二者相辅相成,前者关系到软件的成败,后者关系到软件的好坏。在现实的很多开发团队中,特别是偏技术的开发团队中,往往过分注重后者(软件的 Bug 率,性能,可扩展性,架构等),经常陷入在软件开发过程的细节之中,而忽略了前者(软件需要符合用户的需求),开发出的软件经常能用但无用,不是最终用户期望的软件,这样的软件是能用但无用零质量软件

    在产品开发中,能用但无用的现象尤为明显。产品和项目不一样,项目往往是为某个客户而开展,有特定的需求来源,而产品往往是一个更广泛的概念,是市场上某一类客户群体的价值代表,没有固定的需求来源,而且良好的产品往往要起到引导客户需求的作用,超越现有客户能提出的需求,所以对产品来说,“正确的软件”更加困难,但也更加重要。

    当然,“软件运行正确”同样非常重要,关系到软件的好坏。Bug,扩展性,性能,易用性等问题会造成客户想用但用不了,同样造成软件质量问题。

    敏捷开发对软件质量的影响

    敏捷开发对软件过程和质量控制产生了一系列的影响,主要来自两个方面的影响,用下图表示如下:

    图 1. 敏捷过程带来的影响
    敏捷过程带来的影响

    图中的具体含义如下:

    1. 敏捷开发对“正确的软件”的影响

    敏捷开发拥抱市场变化,拥抱客户需求变化,采用迭代反馈的方式管理项目。其背后的一个核心理念是:一个高质量的软件,首先应该是一个“正确的软件”,能够满足客户的需求。

    我们知道当今的世界产品极大丰富,不管任何产品都会有的竞争对手和替代产品,大家熟知的有浏览器大战,输入法血拼,视频网站、博客满天飞,国内外 ERP 系统竞争激烈等。所以,软件的质量是要在市场化的竞争激烈的环境中去进行验证,进行优胜劣汰,最终高质量的软件产品被客户接受。所以,一个高质量的软件首先应该是一个“正确的软件”,能在激烈的市场和竞争对手中找到市场定位,有客户需求和市场销量,能提高产品的使用者客户体验的软件。否则,软件做的再好、性能再快、界面再优美好用也不是一个高质量的产品。

    敏捷开发正是符合这样市场环境而诞生并流行,其迭代反馈、拥抱变化的理念和方法,能够使得团队更能开发出符合市场和客户的高质量软件。如上图 1 中所示,左图中的大半圆表示传统的开发模式中,产品不能满足客户需求的风险。因为传统的开发模式基于中央控制的计划,没有足够的迭代和反馈理念和方法,犹如一次性的把所有的资金购买了一只股票,导致质量风险大。上图 1 中右边的敏捷开发中,采取迭代反馈的原理,通过一系列的方法(下面会介绍)把市场和客户的需求和期望分散到个整个软件的生命周期中,犹如把所有资金进行资产组合,最后的软件产品质量风险小,能够较大概率的符合市场和客户的需求,并带来价值。

    敏捷开发响应市场和客户价值取向,但如果没有完善的方法去收集和分析市场和客户的反馈,也会导致严重的质量问题,如软件随波逐流,随客户朝夕更改;市场定位模糊,没有核心竞争力;和竞争对手没有任何区别,陷入艰难的红海战争中等。所以,敏捷开发方法对高质量软件也提出了挑战,需要相应的方法和流程去执行和控制。

    1. 敏捷开发对“软件运行正确”的影响

    “软件运行正确”是说软件运行良好,没有或很少 Bug,扩展性很强,性能良好,易用性高等。

    软件工程中有个经典的统计,即软件生命周期的前期造成的 Bug 的影响比后期大的多,所以需求的变动影响是最大的。而敏捷开发拥抱市场变化的理念,会积极响应市场需求,这会对整个软件,如软件架构、编码、测试、文档都会造成很大影响。犹如长鞭效应,长鞭前端的抖动会逐渐放大到整条长鞭,而且波动会越来越大。这会影响“软件运行正确”的高质量要求。

    所以,我们不仅要看到敏捷开发带来的高质量客户价值的好处,如上图 1 右边敏捷开发的上部分波动所示,还要看到这些小波动导致的长鞭效应。如上图 1 右边下半部分所示。敏捷开发拥抱市场变化和客户反馈会对整个软件的架构、开发、测试造成很大的波动。如果控制不好,会使得项目失控,造成严重的质量问题,如错误 Bug 多,架构不合理,易用性不好,性能不好等等。

    总的来说,敏捷开发的理念和方法,响应市场和客户的价值,有利于发布符合客户价值的软件。下面介绍敏捷开发过程及质量控制最佳实践,能很好的解决敏捷开发中的软件质量问题,辅助团队发布高质量的软件。

    敏捷开发过程及质量控制最佳实践

    敏捷开发的需要敏捷过程的支持才能快速响应市场需求,发布高质量的软件产品。下图是作者用过的敏捷过程(可以定制适合自己项目的敏捷过程),文章不详细介绍下面敏捷开发过程,主要介绍其中的质量控制流程及最佳实践,也是围绕质量的两个方面介绍质量控制实践:“正确的软件”及“软件运行正确”两方面。

    下图 2 中是一个软件敏捷开发的迭代过程,每个迭代有需求,有变化,有架构,有设计,有开发,文档等。其中深蓝色背景,白色字体的是敏捷过程中质量控制流程。主要包括两个方面的质量控制:“正确的软件”及“软件运行正确”两方面。下面依次介绍:

    图 2. 敏捷开发过程及质量控制
    敏捷开发过程及质量控制

    查看大图

    “正确的软件”的质量控制流程和最佳实践

    这个作者认为是敏捷开发中质量控制中最重要的一点,因为这是后面所有其他软件质量的前提。如果软件刚开始就是错误的,不能给客户带来价值的,就犹如路和方向就是错误的,那尽管在这条路上走的多好,多稳,也不会通向理想的目的地– 高质量的软件。做正确的事情,说起来简单,但做起来是最为困难和艰险的一件事情。犹如上文说到的长鞭效应,在这里一步走错,就会导致整个软件的极大波动,导致项目失败。因为产品定位和价值都错了,那再如何努力开发和测试也是不可能交付高质量的软件。敏捷开发强调拥抱变化,迭代开发,客户反馈原则等也无非是使得软件在正确的方向上前进。

    下面作者敏捷开发过程中经常使用的几种最佳实践,能够辅助团队正确捕获市场需求和客户反馈,并进行需求分析及过滤,设计出能给客户带来价值的高质量软件。包括上图中的“需求”、“SWOT 分析和需求审核”和“CDD & User Story 审核”。

    1. 需求

    需求又包括需求获取和反馈,需求分析和需求创造三个方面

    演示和原型

    在软件敏捷开发过程中,如何获取市场的需求和客户的反馈是高质量软件的前提。敏捷开发中,除了正式的软件开发及发布,我们还有专门的团队开发演示和原型。演示是为了向客户和业务人员展示产品功能,并获取客户反馈;原型是为了展示对产品未来的雏形和概念,便于与客户讨论和展示,并获取市场需求。产品、原型和演示三者的关系如图所示:

    图 3. 敏捷开发过程中的软件、原型和演示
    敏捷开发过程中的软件、原型和演示

    Persona 的方法论

    Persona 指的是角色,也就是基于角色的方法论,强调一切从角色出发思考问题。我们知道,每个人的思考的角度都不一样,客户的思考问题的角度和开发团队的思考角度不一样,甚至不同客户之间思考问题的角度也不一样。团队在设计和开发软件的时候,容易陷入自己的思维角度,开发不符合客户思维角度的软件,而不符合客户的需求。更严重的是很多团队陷入这样的惯性,而根本不知道错误在哪里。

    Persona 的方法论中强调,不论软件的哪些需求,哪个功能模块,甚至会议中的讨论,请首先确认出 Persona。Persona 可能不止一个,所以需要分析并确认出不同的 Persona,并设定所有 Persona 的背景,需求,期望等。然后把讨论的需求、功能模块、会议的议题,对应到定义的 Persona 中。然后根据 Persona 的重要与否,Persona 的背景等,就可以进一步分析、确认需求。下面是一个 Persona 的简单模板

    Persona 的简单模板:

    • Name
    • Photo
    • Brief Biography
    • Goals
    • Context scenario

    确认出 Person,尤其是关键客户的 Persona,然后尽量使软件符合该 Persona 的价值需求。作者的经验中,Persona 的方法论,非常有益于理清思路,特别是在需求分析和讨论阶段尤为重要。需求收集和讨论时,不同的同事代表不同的 Persona(有的是客户业务人员,有的是客户架构师,有的是客户技术人员)他们提出各种不同的假设、需求、改进、功能模块。这时如果不从 Persona 的角度去思考和理清问题,就经常陷入混乱和口水大战。而最终却没有满足项目或产品的最重要 Persona 的需求,不能创造价值。可想而之,以此为基准的软件将是能用但无用的零质量产品

    最高境界“跟随需求,不如创造需求”

    这点对软件产品来说尤为重要,前面说过产品和项目不一样,产品的需求更加模糊,而且一些新产品往往需要带有一定的新特性。产品需求的最高境界是创造概念、规则,并由此创造需求。不管是软件行业,还是其它商业界都是如此,如:

    1. 从 BP 机到手机,再到 iPhone;
    2. 从胶片相机到数码相机;
    3. 从门户广告到搜索广告;
    4. 从 Blog 到 Twitter 等

    商业界创造概念、规则、模式,并由此创造需求,才能创造出蓝海,并成为领头羊。而其他跟随着只能符合创造者的提出来需求。

    在这个境界上,创新是最至关重要的因素,唯有创新才能打破规则,打破需求跟随者的状态,创造出符合未来用户需求的规则和产品。

    而这样的软件,也是最有价值的高质量软件。

    1. SWOT 分析和需求审核

    敏捷开发中通过需求收集及客户反馈得到了大量的客户需求,如何进行有效的过滤并选出最有价值的需求呢?这是敏捷开发中高质量软件的关键之一,因为没有一个很好的以客户和市场为中心分析方法,产品会随客户朝夕更改,市场定位模糊,散失稳定的核心竞争力。

    开发团队常见的误差是从技术的角度来考虑哪一些需求价值大,哪一些需求紧急度高,造成的结果是有一些功能模块投入了很多资源,但却并不一定是客户最想要的。

    在作者的敏捷开发中,对产品的需求和模块进行 SWOT 分析,分析的输入是所有的 Persona 客户需求、市场现状、产业现状、竞争对手现状等,输出是需求的重要度和紧急度,以及投入的成本。然后按照性价比可以进行排序,选出最能符合市场的模块。SWOT 分析有益于以最少的投入研发出符合客户和市场价值高质量的软件。

    下面是一个 SWOT 分析的事例:

    图 4. SWOT 分析事例
    SWOT 分析事例
    1. CDD 以及 User Story Review

    CDD(Concept Design Document)指的是软件的概念设计文档,User Story 指的是用例细化的用例故事。

    这二者发生在进一步细化需求并要转换成软件架构时,对这二者进行进一步的分析和审核,有益于保证从需求分析到架构设计的过度阶段的软件质量,降低客户需求理解偏差的概率。

    “软件运行正确”的质量控制流程和最佳实践

    敏捷开发的拥抱变化,如上面的图 1 中所示,会对软件架构、编码、测试、文档都会造成很大影响,犹如长鞭效应,长鞭前端的抖动会逐渐放大到整条长鞭,而且波动越来越大。在敏捷开发中,为了快速响应变化,敏捷开发中的如下特性:

    1. 需求变化更频繁
    2. 轻详细设计,没有那么多的架构和设计的时间
    3. 反对冗余繁重的文档
    4. 反对冗长会议和电话会议
    5. 赞同代码就是最好设计和文档(Code is design and document),并通过重构自然呈现架构和设计

    这些特性和传统的进行大量的架构设计,然后通过文档记录并沟通的方式有很大差别。敏捷开发中这样灵活的方式就更要求有严格的质量控制流程。否则,最终的产品的质量很大概率出现问题。如可扩展性、架构、可用性、测试稳定性 Bug 等。

    下面是敏捷开发流程中控制架构、开发、测试等质量的流程:

    1. 架构和概要设计 Review

    敏捷中轻详细设计,但并非不注重设计,只是敏捷中架构的形式和内容发生了变化。敏捷中进行的架构设计是高层次的架构设计,如:组件的结构,软件的层次,技术选型等。敏捷中没有进一步的详细设计。架构设计就显得尤为重要,架构层次的错误,在后期需要大量的人力物力来弥补。架构和概要设计审核主要围绕下面几点:

    1. 组件结构是否清晰。围绕组件的特性:“高内聚”、“松耦合”、“隔离性”、“颗粒度”、“分层”等特点,设计良好的组件结构。组件的抽取过程,可以在公司组织结构部门设立中找到似曾相似的影子。在公司组织结构中,任何事情重复或重要到了一定程度,就会产生一个新的部门,如做销售的人多了,就产生了销售部门,不同省的销售多了,就产生了省分部门。在架构设计中也是一样,任何功能重复的到了一定程度,就应该抽象出新的组件,甚至一个产品。在设计好组件结构后,就可以分工进行开发。
    2. 层次结构是否清晰。关系是否混乱?是否需要抽取单独的层次?
    3. 是否符合 Do not repeat yourself 的规则。好的架构设计应该是“不重复自己”,并且“不重复已有的成熟组件”。尤其是当架构中有些功能有免费成熟开源框架或者标准可以依据,但架构设计时没有采用考虑,而重新发明轮子,导致不能重用已有的标准或开源框架的优势,这些都是不可取的。
    4. 技术选型是否合理。包括数据,模型,展现,逻辑等技术选型,以及使用框架,依赖产品等。
    1. 代码审核,以及重构出设计

    传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的 UML 图(详细的类图,顺序图等),详细的 API 设计以及接口描述,存储层数据库表字段设计等等。敏捷开发中不进行详细设计然后再开发,它推崇 Code is design,设计是通过对代码进行重构自然产生。所以,敏捷开发中,代码质量和可读性很重要。是否能通过高质量的编码,以及重构,自然呈现出软件设计,关系软件可维护性,Bug 出错率和修改、可扩展性、稳定性、甚至性能等质量问题。所以,在敏捷开发中并非没有详细设计,而是详细设计的方式和时机发生了变化:敏捷开发详细设计转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又 Don’t Repeat Yourself。

    敏捷中代码审核的质量规格应该类似与详细设计的规格,要求开发人员能够发布高质量的代码及代码结构。团队可以设立统一的编码规范,命名规范,代码结构规范。确保代码和代码结构的质量。团队也可以选用一些自动化的代码扫描工具来分析代码结构及存在的不合规范的地方。

    开发规范是能提高代码质量,好的代码,结构清晰,读起来毫不费力,是一种享受。好的代码包括如下特性:

    1. 高质量代码结构在于开发人员不断重构,把代码按照逻辑结构分成不同的包。
    2. 高质量的代码格式一般可以通过工具中的编辑器的代码模板和格式器来控制。
    3. 高质量注释即是代码的注释,又是软件的设计文档。
    4. 这里强调一点是高质量的命名,不管是包命名,类命名还是变量命名,命名时应该采用能够让人看懂的名字,名字长一些往往更好,尽量少用不清晰的缩写。如:People 对象,应该用 people 等能够一目了然的命名,而不是 p, pe 等简短不清晰的命名。
    1. 测试流程

    在讲测试之前,我们重新回顾一下:什么是“高质量”的软件产品?只有统一了“高质量”的概念,测试人员才有测试的标准和最后交付软件的标准。

    “高质量”的软件,可以认为是:能为客户在最少时间内,带来最大价值的软件。测试人员在测试软件的时候,应该在思想层次和终端用户统一“高质量”软件的认识,并且所有的测试标准也将围绕这个“高质量”的衡量标准进行,否则测试结果为高质量的产品,对客户来说可能就未必是这样。

    所以测试团队在软件测试的过程中,要时刻站在客户的角度思考问题,设计测试用例,以及测试产品。敏捷开发中的测试包括功能测试、集成测试、性能测试、安全测试、可消费性测试和无障碍测试等,这些确保能够按照设计发布高质量的软件。这里不细讲每一个测试的环节。需要强调的是可消费性测试。

    一个高质量的软件,不仅要能够按照既定的设计良好运行,还应该是一个很好用的软件。只有客户能够方便的使用软件,软件才能为客户创造价值,也才能称该软件为一个高质量的软件。大家都很熟悉的 Windows 和 Linux 操作系统,从普通终端用户的角度上考虑,无疑 Windows 是更高质量的产品,因为它能为客户在投入最少时间的情况下,创造最大化的价值。而 Linux 我称之为技术层面的高质量产品,对普通终端用户来说,其综合价值不如 Windows。

    可消费性测试涵盖了整个软件生命周期,将在另外的文章中详细介绍。下面的可消费性测试中易用性测试几个常用的原则,它能够帮助测试人员测试软件的容易使用程度。

    1. 效率– 用户要花多少时间,多少个步骤才能完成一个任务。比如注册用户,查找一篇文档。
    2. 准确– 在操作的执行过程中,用户犯了多少错?测试人员要时刻记住,用户在使用产品中犯错,是设计人员的错,而不是用户的错。
    3. 无需记忆性– 用户第一次使用是否能容易的使用产品?或者用户多长时间不用后,还能记得如何操作产品?好的产品设计是无需用户记忆,一切使用规则是隐含在设计中。
    4. 情感反映– 用户完成任务后的感觉是什么?是放松,还是紧张,该用户是否会推荐产品给用户。用户使用产品,就犹如和设计师对话,好的设计师处处为用户考虑,用户使用完产品后会很放松甚至兴奋,会迫不及待的推荐产品给其他用户。
    1. 测试计划及用例 Review

    上面讲到,测试团队在软件测试的过程中,要时刻站在客户的角度思考问题,设计测试用例。测试计划及用例审核 Review,其目的就是为了检验测试用例的结构,计划,及每个测试用例的测试点,确保一切从客户出发。

    审核过程中,应该有业务人员,架构师介入,甚至客户介入。

    1. 文档 Review

    文档是软件的一部分,而且文档能够辅助用户使用软件的,也需要严格的质量控制。文档的目的是让人学会使用产品,所以高质量的文档,不仅是一个没有错误的文档,还需要能够快速的帮助用户学会使用软件。下面是高质量文档书写的几点最佳实践:

    1. 能用视频少用图片,能用图片少用字。现在用 Flash 视频教学是非常好流行的一种教学方式,尽量多用一些 Flash 视频的教学方式,如果没有视频,也尽量多一些图片,产品截图等。
    2. 多一些例子,比如 Struts 框架提供了 show case 等一系列例子,教导用户如何开发和使用技巧,这些比纯文字的文档形象直接,效果更是不可同日而语。
    3. 文档中尽量少用缩写,除非是人尽皆知的缩写,如 IBM, EJB 等词语。如果需要使用缩写,需要在一些地方标记出全名。

    敏捷开发质量控制工具

    如上面几个小节介绍的,敏捷开发中的质量控制贯穿整个软件生命周期。包括需求,架构,设计,测试,文档等的质量控制。

    工具支持上,也涵盖了整个生命周期的质量控制,从早期的需求管理工具,到各个阶段的测试工具,到代码检测及重构工具等。由于篇幅关系,在下一篇文章系统介绍整个质量控制过程的工具支持。

    展开全文
  • 许多人都一直在质疑敏捷开发是否能提高效率与质量? 更有不少人以嘲讽,不屑的口吻看待软件工程。 其实,敏捷开发或者软件工程在团队中无法提升效率与质量,唯一且真正的问题在于…… “每个人都懂得敏捷开发(软件...

    敏捷开发(软件工程)是 “设计” 出来的,不是 “学” 来的……

    许多人都一直在质疑敏捷开发是否能提高效率与质量? 更有不少人以嘲讽,不屑的口吻看待软件工程。

    其实,敏捷开发或者软件工程, 无法提升团队开发的效率与质量,唯一且真正的问题在于……

    “每个人都懂得敏捷开发(软件工程),但却没有人懂得如何 “设计” 可提升团队效率与质量的敏捷(软件工程)的实践。“

    为何没有人懂得? 因为,没有人知道该如何能看明白,团队所面临且真正该解决的核心问题 为何? 更糟糕的是,有时即使是已识别出核心问题,大家却没有勇气,更没有执行力去解决核心问题

    当大家没能力去识别核心问题或者没毅力去解决核心问题时,最终,大家就只是做个表面搞个形式化 的敏捷(软件工程)。而不是深度思考设计 可解决团队核心问题的敏捷实践(软件工程)。

    大家都很用功,也都很聪明。我相信是没有人是不懂敏捷开发(软件工程)的。但……大家所真正欠缺的是深度思考的能力;唯有具备了深度思考的能力,才能真正有能力去看清团队真正核心的问题,也才能有足够的智慧,为团队设计 出,能提升团队效率与质量的敏捷实践(软件工程)。

    深度思考的能力,是需要学习,是需要锻炼的;不是天生就会的。

    在这推荐二本书;借由这二本书,或许能誏大家对如何培养深度思考力,起到个启蒙的作用。





    展开全文
  • 很多人都一直在质疑敏捷开发能否提高效率与质量? 更有不少人以嘲讽。不屑的口吻看待软件project。 事实上,敏捷开发或者软件project, 无法提升团队开发的效率与质量。唯一且真正的问题在于…… “每一个人都懂得...
  • 我相信这些问题都是推广敏捷开发的企业或者 Scrummaster 经常面对的问题。本 Chat 将重点从代码静态检查、Gerrit代码走查、SonarQube、持续集成与自动化等方面分享我们的内建活动经验,推动开发人员输出高质量的代码...
  •   敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,...
  • 敏捷开发流程总结

    2015-12-14 16:36:10
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...
  • 参考1 https://www.sohu.com/a/128624542_177747 参考2 https://wenku.baidu.com/view/b9080553ed630b1c58eeb564.html 参考3 https://www.cnblogs.com/mikeyond/archive/2011/06/30/2094274.html ...
  • 本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 但是人们选择敏捷开发作为管理方法是有原因的:更高的交付保障,更高的生产率,更高的质量……这和人们选择C++(而不是C)的原因还是很接近的:都是为了更高的绩效。在下面的所有文章中,“敏捷开发绩效管理”都将...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
  • 原文地址:敏捷开发有什么好处?作者:苗得雨 软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升...
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。...
  • 敏捷开发中的 Java 代码质量保证步骤   回页首 步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的 Java 代码开发人员的编码风格常常各不相同,...
  •  精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率◦ 另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑◦  本文将从 “度量” 的角度, 运用一轻量级度量的...
1 2 3 4 5 ... 20
收藏数 26,327
精华内容 10,530
关键字:

敏捷开发如何提高质量