2019-08-27 00:33:42 seagal890 阅读数 89
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10411 人正在学习 去看看 CSDN讲师

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

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

敏捷开发中采用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)

(持续更新中……)

2019-05-23 02:15:13 weixin_34384557 阅读数 85
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10411 人正在学习 去看看 CSDN讲师

蔡建斌 -国际物流公司亚洲 IT 交付团队经理

导语

敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。

关于质量的定义,我前不久接触到一个文章,里面有一个图讲到质量的五个维度,但是我做了一些微调,改成了四个。接下来就从我定义的4个维度的质量分别探讨一下。

1. 基于价值的质量,交付影响而不是交付产品

在IT业有一个很著名的人叫做 温伯格 的咨询师, 他提到质量的定义叫做质量是对某些人的价值,价值是什么意思?

福特问客户想要什么,他说要一匹更快的马,但是福特提供给了客户汽车。马和汽车是提供给客户的产品,价值是什么?客户可能有天天从各个城市飞来飞去需求,他希望有更快的马来助力,这个就是价值的意思。客户的需求往往是方案,它很少告诉你这个东西背后是什么目的。所以User Story的背后,就是价值。

在工作上,我认为我们不是在交付产品,而是是交付影响力,就是交付对用户的影响。你让我开发一匹更加的马,我要问这个马用来干什么,对你有什么影响,因为我交付的是影响而不是产品。

Impact Mapping通过 Why Who How What得到一些想法:我们做产品是为了什么?影响哪些人?

-如果说一个咖啡馆老板,他想赚一个亿,谁能帮助他达成这个目标

-如果说顾客可以帮助他达成这个目标,那怎么帮助他达成

比如顾客(who)买了咖啡之后,觉得不错然后会推荐给其他朋友(how),所以顾客通过把咖啡店推荐给好友的行为可以帮助他赚到一个亿(why)的小目标,但是需要注意的是,这个"who"可以很多。

有了前面的铺垫后就能得到"what"

为了鼓励顾客去推荐好友这个行为,我可能会开发一个“推荐赚积分积分换咖啡”(what)的功能系统。我们开发Story不是Story本身,产品本身不是我们直接的目标,我们的目标其实是为了影响“顾客去推荐好友”这样一个行为,这个影响,最终达到业务目标,就是这个why。

我们跟产品合作,他们给我们做了一次what,他会说你给我做一个积分换咖啡的功能,其实背后这些功能会带来什么样的价值,才是更需要探讨的。但是这样的思想框架并不是真的去问why 、who等等,而是告诉我们真正需要交付的东西,而不是真正的产品。所以说提出一个可能符合背后目标的更好的what出来,这才是框架的一个根本目的。

2. 基于产品的质量,利用反馈

例如,我们要研发更快的马,或者研发一辆汽车,这个就是产品本身,定下来仍然有质量因素在里面,就是怎么把东西做对。

Cynefin模型:

simple :你要解决问题很简单,你有一些最佳实践套用就可以了,如果你的公司,你的研发在这个象限上,其实是恭喜你,其实是非常舒服的

complicated :比较繁杂的场景,这个场景下你的解决方案可能有多个,可能不存在最佳实践,又或者可能有多个实践,可能找几个专家来帮你搞定,这个是一个场景

complex :没有办法简单找几个专家来研究得出结论,这个应付的东西是各个维度,有可能是质量出问题,加上预算有限,加上产品方向不清,需求不清,产品跟架构师之间合作不来,各种交织在一起,但是有一个目标需要推进。

chaotic :就是混乱,如果碰到这种,这个挑战确实是非常大,可能不是一般的管理者能够应付得了,需要CXO坐在一起给出方向。

disorder :管理者把解决问题分解成多个子领域,分解成多各个情境来逐个击破。

产品研发大部分属于第二和第三象限,这两个维度的实现就是先做,然后再反馈。反馈有一个原理:越早的反馈越便宜

举个例子

在产品研发中,有一个很大的问题,就是你的技术团队和产品经理的鸿沟。这个鸿沟很常见,但是在我自己的工作场景里面这个鸿沟不常见,我一直是技术领域的人,但是我在产品上或者需求上跟产品经理一直是通力协作的,用实时的反馈来跨越反馈,而不要等产品经理已经设计了两个月,然后给我们开发完上线后,再提出需求不对,这样就比较被动。

如果反馈能做到实时,下面就是实践。在新的产品研发开始的时候,我与技术人员产品经理会一起先把概念模型画下来,因为一个团队有很多的角色,包括架构师、开发、US、甚至外包人员,不同的角色怎么确保理解的一致,最后明白如何做自己的工作。你怎么确保这份活动基于统一的理解,没有共识就比较容易出现鸿沟。把概念模型画下来就是为了现实上的例子,可以很简单,我们有什么业务对象,他们之间关系是什么样,把这些东西画下来,大家基于一份共识去做各自的活,这个鸿沟会少一点。

3. 基于产出的质量,定义完成,以终为始

我自己是研发出身,研发质量产出是什么?就是需要建立条目化,短周期之内可以交付的东西,这个是产出,第一个产出是代码,尤其在软件行业,代码占了80%的产出,怎么把代码写对,就是第三个维度。

代码质量有一个心法叫做定义完成

举个例子,很多程序员你问他这个Story做了没有,他给你的答案是什么?度量BUG是为零,程序员做完之后交给QA,QA告诉开发有没有BUG。你的QA下一道工序是我的客户,我应该告诉你有没有BUG或者有多少个BUG,而不是反过来。

需求质量也是很重要的产出;

你要保证你的产品经理做的需求是不是符合,是不是条目化,是不是按照优先级,你是不是做最重要的事情。你有三个团队,每个团队都在按照优先级来做事,但是三个团队是不是有统一的优先级,很多团队是没有做到的。

有些需求你不做用户会不高兴,但是你做了也不会很高兴,就像我们的实践一样,项目大的时候不做实践会很惨,但是做了项目也不一定会成功。

工作中当你问程序员说这个做完没有,很多程序员告诉你90%完成,或者完成了但是没有测,或者有几个BUG,或者需要重构一下,这种心态是不好的,但是没有反馈。

我们叫做以终为始,用户故事只有两种状态,只有完成和没有完成,没有但是,没有完成你要把它完成掉。程序员会说这个做了90%,然后去做下一个故事,结果是没有一个可以工作。而我们倡导的是把一件事情全部做完,才做下一个。

4. 过程质量,拆

有这样一句话,如果你用同样的方式去烤面包只会得到相同的面包

过程质量就是写代码的质量,这个心法就是拆,拆成小的东西,拆成一个可交付的东西,其实写代码也是需要拆的。

举一个例子,很多程序员写代码,一天下班的时候代码还没有编译,我们写代码方式应该是这样,很多程序员写代码是东写一点,西写一点,这个意味着什么?没有透明度,他不知道写哪一个,这样的过程想代码质量好是不可能的。

总结

我们已经讲了四个维度的质量,价值和成本,可很多团队的人没有办法控制价值的部分,有些人却可以。我们是一个技术负责人,产品都不是我们能控制的。你要考虑定制权在哪里?影响权在哪里?你能控制的东西就是你的成本,你不能控制的地方就是你不能提供的。

谁为质量负责?如果开发工程和QA之间出现问题,最后辛苦开发出来的功能,用户抱怨难用,就是价值和质量出现了问题,现在分工越来越细,在很多团队集中在某一层,比如程序员关心写代码,不关心价值和产品,产品经理只关心价值,不关心技术实现,这些鸿沟会影响整个质量。


文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。


转载于:https://juejin.im/post/5ce60205e51d45108b2cadd6

2015-07-20 15:17:38 dieyong 阅读数 449
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10411 人正在学习 去看看 CSDN讲师

Java 项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入 和周期等问题。
这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介 绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高 质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。

如图 所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。
在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:
统一 编码规范、代码样式;
静态代码分析(static code review);
单元测试;
持续集成;
代码评审和重构(Review & Refactor)。

下文将针对每个步骤和其所使用的工具、方法进行详细描述。

这里写图片描述

步骤一:统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的 Java 代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码 时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面:

一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。
命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。
编程规范。例如异常、并发、多线程等方面的处理方式。
其他规范。例如日志格式、属性文件格式,返回值和消息格式。
项目的编码规范可以参考已有的一些 Java 编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《 Java 编程风格》(英文书名为:The Elements of Java Style)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。

一旦编码规范确定,就可以利用 Eclipse 自身提供的功能来控制代码样式和格式。具体做法是,点击 Eclipse 的 Windows -> Preference 菜单项,在打开的 Preferences 对话框的左侧栏中找到 Java 节点下的子项 Code Style(如图 2),该项和它的子项允许您对 Java 代码的样式进行控制。
这里写图片描述

例如,为了使用自动格式化工具,可以在 Eclipse 提供的默认代码格式配置的基础上建立自定义的格式。在 Formatter 面板中,点击 New,输入新的名字并选择一个默认的配置作为初始化格式,如图 3 所示。
这里写图片描述

单击 OK 后就可以在新打开的窗口中进行修改定制自己需要的格式。如图 4 所示。
这里写图片描述

修改完成后点击 Apply 保存所作修改。同时可以点击 Export 将当前的格式定义导出成一个 XML 文件,这样项目组的其他成员就可以很方便通过点击图 3 中的 Import 按钮来导入该 XML 文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过 Eclipse 界面里的 Source->Format 菜单来对代码进行格式化,从而使整个项目的代码具有相同的格式。同样可以通过对 Code Style 下的其他项目进行设置来帮助对 Java 代码的样式进行控制。将所有这些样式文件导出成 XML 文件后,同编码规范一起归档,供所有项目成员使用。

步骤二:静态代码分析

在完成源代码的开发以后,下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外,还能利用一些静态分析工具来快速、直接 地提高代码质量。
静态代码分析工具并不需要运行代码,可以直接对 Java 文件和 Class 文件进行分析,通过一些检查条件的设置,快速找到代码中的错误和潜在缺陷。
现在的静态分析工具很多,有 FindBugs、PMD、IBM Rational Tool,等等。
在这里介绍PMD,具体看之前写的文章;

步骤三:单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要 具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测 试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹 配方法来衡量用例设计的完整性。

在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补 缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码 逻辑结构为前提,如果评审员来自相关模块,还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化, 或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟 对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面 向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试。

模拟技术有很多种,如 jMock,EasyMock,Mockito,PowerMock 等等。其中 Mockito 消除了对期望行为的需求,避免了这些代码的大量初始化。

在模拟对象过程中,先模拟一个需要调用的 List 对象 LinkedList,再设定这个对象的行为,当调用 get(0) 的时候,返回”first”。这样,测试代码就可以利用这个对象来测试我们的功能代码,需要调用和返回值的时候,可以顺利的得到模拟对象的返回值。也需要 对模拟对象进行错误情况的模拟,保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围,需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路 径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定,以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进 度。

EMMA 是一款比较流行的开源 Java 测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采用多种颜色来高亮显 示不同的覆盖率状态。EclEmma 是一款基于 EMMA 的 Eclipse 插件,方便在 Eclipse IDE 中进行测试覆盖率分析。

为了保证单元测试的有效性和质量,可以规定一个测试覆盖率的下限,例如所有的包和类的覆盖率必须达到 80% 以上。不过值得注意的是,不要单纯追求高覆盖率,要同时注意测试用例的质量,如果测试用例本身就写的有错误,那么即使测试覆盖率很高也没有意义。

步骤四:持续集成

持续集成(Continuous Integration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时 都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的 反馈。

要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服 务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。IBM Rational Team Concert (RTC) 可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动 构建和代码的自动单元测试是持续集成的关键过程,RTC 在这些过程上提供了有力的支持。

自动构建

RTC 提供了 build engine 来负责构建 build,首选,启动 build engine,并和 RTC 服务器建立了连接。再创建项目的 build 定义。在这个定义中,需要设定编译哪些模块的代码,需要跳动哪个 ANT 文件来启动编译,和一些编译过程中的参数的设定。当这些都准备好了,编译对于项目而言,就变成一个简单的事情。

步骤五:代码评审和重构

代码评审(Code Review)是 Java 项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是 否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速 学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(Peer Review)和小组评审(Group Review)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。

为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有 Jupiter 和 Code Striker。Jupiter 是一款开源的 Eclipse 插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以 XML 文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。

在代码评审任务创建后,Jupiter 将代码评审分成三个阶段,个人评审阶段 (Individual Phase)、团队评审阶段(Team Phase)和问题修复阶段(Rework Phase)。在个人评审阶段,评审成员将发现的代码问题或者缺陷记录下来,每个问题都会作为一个记录保存在评审表格中。在团队评审阶段,团队的全部或者 部分成员会一起对个人评审阶段发现的问题进行定性,如果问题确实存在,就将该问题分配给某个成员去解决,并在 Jupiter 中将该问题设置成相应的状态。在问题修复阶段,团队成员会修复属于自己的问题,并将相应的记录设置成已解决等正确的状态。

Codestriker 是一款基于 Web 的常用代码评审工具,对代码的评审可以针对某一具体行,也可以针对整个代码文件,评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论,代码作 者也可以针对某一具体的评论回复。Codestriker 支持邮件通知,还可以同版本控制服务器进行集成,以跟踪和显示文件内容的改变。

在实践中对所有代码进行小组评审会比较费时,所以可以根据实际情况来挑选一些核心代码进行小组评审,或者在项目的前期安排较多的小组评审,等 项目组的成员对代码评审的标准和要求有较好的理解,进行代码评审的经验提高后,就可以逐渐减少小组评审的次数,从而达到大部分代码即使只进行同级评审也能 保证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉,较小的不涉及多人代码的重构可以由项目成员自己借助 Eclipse 的重构功能完成,不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作,例如整个项目层面的代 码组织形式的改变需要由整个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法,希望大家能从本文得到启发和收益,结合您的实际项目特点,实践以上步骤和方法,并加以完善和改 进,共同打造高效高质量的 Java 代码,为您的项目成功奠定坚实的基础。

2012-04-05 12:27:12 iteye_4001 阅读数 14
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10411 人正在学习 去看看 CSDN讲师
敏捷开发的目的是在保证开发质量的前提下提高开发效率。敏捷开发需要有两个前提,团队人员对所应用的技术有比较全面深入的了解;开发及测试人员对软件的业务逻辑有全面深入的了解。换句话说,一个项目或者一个产品发展到一定阶段之后,可以根据实际情况逐步过渡敏捷开发的方法上来。
一般来说,敏捷开发有以下特征:
1、团队规模比较小,10人左右是比较合适的。
2、团队内部强调沟通,包括经常性的standup meeting和就某个技术、需求问题的讨论,讨论方式包括面对面、电话和邮件。
3、文档特别是开发人员撰写的文档大幅减少,如果只是在现有技术框架下添加一个新的业务功能,甚至不需要标准的设计文档和功能描述文档,当然详细的使用手册或者online help还是需要的。
4、单元测试以及UI自动测试的应用,可以显著增强软件质量。特别是对于开发周期比较长的软件来说,自动测试可以大大减轻QA人员进行回归测试的工作量。
2014-04-19 09:02:40 u011790275 阅读数 1479
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10411 人正在学习 去看看 CSDN讲师

2016, 深圳, Ken Fang 


前言:

   精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率。另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑。

   本文将从 “度量” 的角度, 运用一轻量级度量的方式, 确保团队在精益敏捷开发的过程中, 可同时确保效率与质量。

 

本文:

   此轻量级的度量方式主要的目的是希望: 通过度量驱动团队去做该做的事; 包括:测试用例先行, 逐步提升效率, 同时兼顾效率与产品质量。

1)      测试用例先行 (流程指标)

精益敏捷开发, 期望以表格式的测试用例, 使开发人员可清楚的明白到底要开发什么? 避免开发人员在不完全理解 User Story 的需求或是 User Story 需求不明确的情况下, 进行无谓的开发, 形成不必要的浪费。

所以, 必需经由度量 “开发前测试用例覆盖率”, 以驱动团队需先有测试用例再进行开发。

开发前测试用例覆盖率开发前已有测试用例的 User Story总数 / User Story总数 

另一方面, 为避免测试用例的设计会形成版本开发的瓶颈, 所以, 必需经由度量 “测试用例设计平均人天”, 以驱动团队提升设计测试用例的效率。

测试用例设计平均人天测试用例设计总人天 / 测试用例总数


2)      逐步提升效率 (效率指标)

精益敏捷开发, 团队的效率并不能仅从 User Story 开发的速度来衡量。因为, 仅提升 User Story 开发的速度, 并无法保证版本的整体开发效率的提升。 为何?

当团队的 Sprint Backlog 中代办事项 (User Stories) 的工作量, 远远超出团队所能负荷的工作量时, 则即使 User Story 的开发速度提高了, 但, 也会因各 Sprint 的工作量过重, 而使团队在各 Sprint 中, 能完成所有 User Stories 开发与测试的时间, 依旧会过长, 因而, 导致版本的整体效率无法提升。

精益敏捷开发是以 “平均等待时间 (平均处理周期)” 来衡量开发的效率, 且同时衡量:

1)     Sprint Backlog 的 User Story 数 (工作量)

2)     User Story 开发, 测试的速度

 平均等待时间  Sprint Backlog  User Story数目 / 每周平均可完成 User Story 的数目 (完成是指开发测试完成)

举例: Sprint Backlog 的 User Story 数目: 30

            某团队每周平均可完成开发, 测试的 User Stories 数目: 15

            平均等待时间: 30/15 = 2 周

所以, “平均等待时间” 便会驱动项目经理要逐步提升效率时; 降低平均等待时间; 除了需提升团队的开发, 测试效率外, 更重要的是, Sprint Backlog 中代办事项 (User Stories) 的工作量 (数目) 需合理化。


3) 同时兼顾效率与产品质量 (质量指标)

   精益敏捷开发的质量指标, 主要是以 “缺陷” 驱动团队的开发质量与测试效率。

I.           开发质量:

              i.  平均多长时间可修复一个新的缺陷:驱动开发人员不可只开发新需求的 User Stories, 而忽视或不处理缺陷的 User Stories。

              ii.   缺陷重新被激活总数目: 缺陷重新被激活指的是开发人员将一缺陷标记为 "已解决", 但实际上并未解决根本, 真正的问题。 缺陷重新被激活总数目, 可驱动开发人员真正针对造成缺陷的根因去解决问题。

II.         测试效率:

             i.  平均多长时间可发现一个新的缺陷:驱动测试人员提升自动化测试与手工测试的效率。唯有测试效率提升了, 产品质量方能获得保证。

 

结论:

  精益敏捷开发的度量指标主要目的是希望, 项目经理不要再追求浮而不实的表象数据, 而能真正经由轻量级的度量指标, 做好 “数据管理”, 驱动团队去做真正该做的事。

没有更多推荐了,返回首页