2014-02-28 14:08:16 aboy123 阅读数 2128
  • SCRUM敏捷开发视频教程

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

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

转载于http://blog.csdn.net/caowenbin/article/details/8457510

 站会,几乎在所有的敏捷开发相关的书籍中都必然会加以阐述,虽粗略不同,但都把他视为敏捷开发过程中不可或缺的一环。个人认为,站会最大的意义是沟通,是在面对面沟通的敏捷原则之上创造的一次强制性的沟通机会,为那些在需要面对面沟通时由于个人性格、时间、被沟通者不在现场等客观理由创造一次机会。因此,站会在敏捷开发中具有非常重要的意义。

        但在具体的执行过程中,有一些现象还是让敏捷开发很受伤。

        1.站会是可以自由选择的可选项。这一伤害无疑让敏捷开发打了折扣,至于站会有多重要,随便找本相关的书看看就是了,我们期望通过站会让团队成员有一个机会聚在一起,如果谁都可以不想来就不来,那势必会造成信息的不对称,也就背离了敏捷的原则。另一种常见的理解认为站会是开发人员的事,其他人可以不参加。这是在缩小团队的范围,敏捷的基础就是多角色的团队,是要所有的团队成员共同合作完成任务,如果视觉设计师不参加站会,就不利于与开发工程师同步进度,如果测试人员不参加站会,也不利于了解开发过程中具体的问题。站会是个必选项,只要你在这个团队就一定要参加。

        2.不知道站会要说什么,拖沓冗长,随性而为 。站会用于同步信息的目的很明确,所以其内容很简单,每个人轮流说一下自己昨天做了什么工作,今天要做什么工作,是否需要其他人帮助解决某个问题。这样下来每人有30秒到1分钟就够了,10人的团队也不会超过10-15分钟,那些一开站会就30分钟的是应该反省一下了。其实站会更重要的是结束以后的时间,对于会上某人提到的问题,会有相关的人员继续讨论,而其他的人则解散了。这也就是站会对促进沟通的重要作用。

        3.站会纪录变成检查工作的手段。对于项目经理或某些起管理作用的人员,往往会把站会纪录看做是检查工作的手段,依据每天的站会纪录来分析每一个成员的工作情况,有的甚至忽视了站会纪录中所表现的风险、问题,久而久之,团队成员在站会上的发言就变味了,站会也就变成了工作检查会了。

        4.站会无内容。“我昨天解bug,今天继续解bug”,开发人员时常在站会上这样说,如果都是如此,站会就起不到作用了,作为站会的主持者,对于这种现象要加以引导,同时也要分析现象背后的问题所在,是懈怠了,还是其他的什么原因,要把站会的内容引导到一个正常的轨道上。

        5.站会迟到。迟到总是不可避免,也总是有各种理由。但是我们可以给迟到加一点处罚,让迟到者意识到自己耽误了大家的时间,影响了团队的活动。重要的还是养成习惯,让每个人的心和团队在一起。以某团队的站会为例,在迭代启动会时会规定参加站会的时间、地点、人员和迟到罚责,比如迟到会请所有参加站会的成员吃鸡翅。由于有这样的规定在先,所以主持人可以认真执行落实,经过几次以后,几乎很久都不会再有迟到的,也可以保证站会的按时进行。

        当然,以上不是全部,有人会说这都是小事,无关紧要,但是一个迭代一个迭代的累积下去,站会就越来越淡化,越来越变味。就像代码一样,任由‘坏味道’存在并霉化,最后可能整个架构都会被毁掉。代码可以重写,但敏捷过程如果出了问题,其代价可就远大于代码重写了。



2019-11-20 09:34:20 qq_44614026 阅读数 45
  • SCRUM敏捷开发视频教程

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

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

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2013-01-01 17:05:12 caowenbin 阅读数 8196
  • SCRUM敏捷开发视频教程

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

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

        站会,几乎在所有的敏捷开发相关的书籍中都必然会加以阐述,虽粗略不同,但都把他视为敏捷开发过程中不可或缺的一环。个人认为,站会最大的意义是沟通,是在面对面沟通的敏捷原则之上创造的一次强制性的沟通机会,为那些在需要面对面沟通时由于个人性格、时间、被沟通者不在现场等客观理由创造一次机会。因此,站会在敏捷开发中具有非常重要的意义。

        但在具体的执行过程中,有一些现象还是让敏捷开发很受伤。

        1.站会是可以自由选择的可选项。这一伤害无疑让敏捷开发打了折扣,至于站会有多重要,随便找本相关的书看看就是了,我们期望通过站会让团队成员有一个机会聚在一起,如果谁都可以不想来就不来,那势必会造成信息的不对称,也就背离了敏捷的原则。另一种常见的理解认为站会是开发人员的事,其他人可以不参加。这是在缩小团队的范围,敏捷的基础就是多角色的团队,是要所有的团队成员共同合作完成任务,如果视觉设计师不参加站会,就不利于与开发工程师同步进度,如果测试人员不参加站会,也不利于了解开发过程中具体的问题。站会是个必选项,只要你在这个团队就一定要参加。

        2.不知道站会要说什么,拖沓冗长,随性而为 。站会用于同步信息的目的很明确,所以其内容很简单,每个人轮流说一下自己昨天做了什么工作,今天要做什么工作,是否需要其他人帮助解决某个问题。这样下来每人有30秒到1分钟就够了,10人的团队也不会超过10-15分钟,那些一开站会就30分钟的是应该反省一下了。其实站会更重要的是结束以后的时间,对于会上某人提到的问题,会有相关的人员继续讨论,而其他的人则解散了。这也就是站会对促进沟通的重要作用。

        3.站会纪录变成检查工作的手段。对于项目经理或某些起管理作用的人员,往往会把站会纪录看做是检查工作的手段,依据每天的站会纪录来分析每一个成员的工作情况,有的甚至忽视了站会纪录中所表现的风险、问题,久而久之,团队成员在站会上的发言就变味了,站会也就变成了工作检查会了。

        4.站会无内容。“我昨天解bug,今天继续解bug”,开发人员时常在站会上这样说,如果都是如此,站会就起不到作用了,作为站会的主持者,对于这种现象要加以引导,同时也要分析现象背后的问题所在,是懈怠了,还是其他的什么原因,要把站会的内容引导到一个正常的轨道上。

        5.站会迟到。迟到总是不可避免,也总是有各种理由。但是我们可以给迟到加一点处罚,让迟到者意识到自己耽误了大家的时间,影响了团队的活动。重要的还是养成习惯,让每个人的心和团队在一起。以某团队的站会为例,在迭代启动会时会规定参加站会的时间、地点、人员和迟到罚责,比如迟到会请所有参加站会的成员吃鸡翅。由于有这样的规定在先,所以主持人可以认真执行落实,经过几次以后,几乎很久都不会再有迟到的,也可以保证站会的按时进行。

        当然,以上不是全部,有人会说这都是小事,无关紧要,但是一个迭代一个迭代的累积下去,站会就越来越淡化,越来越变味。就像代码一样,任由‘坏味道’存在并霉化,最后可能整个架构都会被毁掉。代码可以重写,但敏捷过程如果出了问题,其代价可就远大于代码重写了。


——欢迎转载,请注明出处 http://blog.csdn.net/caowenbin ——


2011-06-28 10:45:00 dollybol 阅读数 431
  • SCRUM敏捷开发视频教程

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

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

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中"轻架构设计"的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 # G1 Y% K2 ~; ]; q% w
首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。
% |, e: q! f' v
但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。
3 X0 E9 @' y3 U7 Q3 W7 Z& i( P1. 敏捷开发中架构设计的方式
# A% @' L0 j2 U1 M这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。
! Z" C( n# {" Q5 C% p/ f( _# E* K! D/ d
下图描述了敏捷开发前和后架构方式:
8 y6 m) |/ n6 m1 Q* f/ d' c1 |

下载 (6.72 KB)

2009-7-7 09:16


0 O4 n& l& n+ H0 a8 ?# `

: L, I# ^$ I4 W" N1 [
上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中
, ?6 p/ I. K& X  A+ E* v! l; M( T& [看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。
' ]7 e) n  S3 }9 j7 I2 X; H
"马克威茨资产组合理论"中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。
6 L! n8 L1 Y0 {" J9 m这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。
) A( S  q$ q2 h2 Q. Q如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:
5 a; D' m$ |( V% C) c! R; f
(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。
: c! o* y3 b+ _1 Z(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生
2 [% J6 y7 N8 u* k2 V. y7 F(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。
; D5 k2 h, N1 O  D(4)其他
! Y( d3 z: @7 L- D所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。
: u% U" c8 a+ W* h$ k: m! x4 |! _0 X
2. 敏捷开发中架构设计的内容
' T+ w: V# K+ X/ z; a
传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。
+ F2 }* |9 {% J3 f# W; L出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:
/ a& A6 R! ]: Z(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生,需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。
. w. v& o) r6 /0 N. V; I+ J8 b
(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。
/ {9 L$ U7 |& @3 g& E
基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计
) P/ {$ P/ r+ }' l5 d(1)敏捷开发的架构保留架构部分
; V; W4 _8 V0 y
(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。
! {4 L, B4 B, r1 o2 ~7 ~! z( [5 e
分离后,敏捷开发中的架构就轻装上阵,内容可以包括:
' k$ [0 G0 C! e9 }" [
(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。
! I" v  ^9 E$ Z. D(2)产品和技术选型
2 p+ X/ B' D3 r& D; T3 T
(3)各个组件的结构,以及的关系
) v6 Q6 [( x2 ~
(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。
" K. @# D& _$ C' z# R5 Z/ /9 o4 T! W(5)….
& /6 i8 c) d5 T" w
而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现
; y( @+ P" X; l3 u0 f所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。
8 H7 [' e# d+ v0 V5 e/ H
3. 敏捷开发中架构设计的人员
6 u& h: A4 D, {3 i& J% l. [
敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。
5 `$ n  r+ K+ f
这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。
% V2 /4 K- E4 ~1 L1 x, v& }/ j+ X
这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。
, |7 h* r  U! R. @/ M0 f* C总结
8 X: n' g8 j) W. ~  c, r" Y架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

2009-12-07 15:21:00 programmer_editor 阅读数 18578
  • SCRUM敏捷开发视频教程

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

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

 

一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Test、忙于沟通、忙于Build等,虽然也有编码审核阶段,但大都浮于表面,流于形式,效果不佳。本文结合实践,介绍笔者对敏捷开发中CodeReview的理解和相关经验。

 

文/ 陈序明

 

敏捷开发中Code Review的目的及内容

做任何事情,首先要清晰为什么要做,才能有目标和动力把事情做得更好,Code Review 也是如此。只有清晰明确了敏捷团队进行CodeReview 的动机,才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code Review的目的:

 

设计合理性Review

在笔者的另一篇文章中《敏捷开发中的架构设计》谈到,敏捷开发中崇尚Code is design,对开发人员提出了比以往更高的要求,即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。

这部分的Code Review 包括:设计的合理性(如实现方法,数据结构,设计模式,扩展性考虑等),是否存在大量重复代码和其他组件是否有重复的代码,包结构设计是否合理等。

笔者了解的一些项目中, 进行敏捷开发后, 提高了开发效率, 但是设计的质量却下降了。如Repeat   Yourself 的现象(特别是跨组件之间的Repeat Yourself 现象);更有甚者,在笔者看到一个某银行的应用中(不是国内的),数据库连接和操作是直接在JSP中写SQL语句。

像这些Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一,很有必要在Code   Review阶段进行Review和讨论。

 

互为Backup

这是很容易被忽略,但是又很重要的一个Code Review的目的。

我们知道,敏捷开发中强调高质量的代码胜过详细的文档,所以某种程度上来说Code is Document。敏捷开发中的代码承担了一部分Document的职责,即传递技术的作用。

Code Review 中,Review 的开发人员了解代码的设计和实现,传递了技术,开发人员互为Backup,方便后期的维护,也减少了项目风险。

 

分享知识、设计、技术

这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性的过程,中央集中控制的优点就是有统一的视图和控制,经常开大会,开长会,这样知识和经验也较容易集中。敏捷开发中,分散在两个Scrum Team的开发人员之间,如果没有好的机制,相互沟通也会相对较少,造成知识和好的经验无法在整个团队传播。

笔者参加的项目中就碰到了类似情况, 当时我们整个团队分成三个Scrum Team,其中一个Scrum Team负责一个Eclipse 工具的开发, 其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出,但由于不知道其他Scrum Team同事有这方面的经验,没有很好地分享以往好的经验和知识,以至于最后导致浪费了一些学习的成本。

Code Review是一个学习和享受的过程,一个开发人员的能力有限,而Code Review正是这样的一种机制,让好的知识、设计在团队中分享,实现整体团队的成长和整体的效益最大化。

 

代码可读性

如上所说,敏捷开发中强调高质量的代码胜过冗余的文档,所以Code某种程度上是Document。敏捷开发中,代码的要求不止是能运行功能正确的代码,而是有了更高的要求,即Code   for maintenance。

可维护的代码,需要清晰,可读性强,这里可读性代码检查不是指代码格式(代码格式可以通过工具检查出),而是指代码语义。在笔者的文章《软件可消费性设计》中有一些这方面的讨论和建议。

 

Code中的“地雷区”Review

代码中的逻辑,除了业务逻辑,还应该包括技术逻辑。技术逻辑就是实现逻辑, 比如数据库连接打开是否忘记关闭,是否正确使用线程,Exception 处理,密码是否加密存储等。

我把这些最常出现错误的地方,而且是测试不容易发现的地方,称为Code中的“地雷区”。这些“地雷区”在Code Review 中是值得花费一些时间进行维护和检查的。

建议,在整个团队中维护并共享“地雷区”注意事项列表,以及统一的处理方式和机制。并在编码和Code Review过程中都按照团队的最佳实践进行。

 

发现代码中的业务逻辑错误

业务逻辑指的是代码开发的功能是否符合业务需求,如一个加法函数,检查其是否真的实现了加法的功能。

笔者了解的一些敏捷团队中,把发现代码的业务逻辑错误当做目标和内容,但往往效果都不是很好,基本都是从形式上泛泛检查一番。原因有两个:

1.业务逻辑的检查是从需求到代码的全方位检查,需要花费大量时间,投入产出比失衡。

2.业务逻辑的检查和业务需求紧密关联,已经超出了检查人员的能力范围(一般Code Review是开发人员,不是业务人员)。

笔者认为,发现逻辑错误,不应该是Code Review 的目的和内容。应该是Unit Test,功能测试,集成测试的目的。从投入产出比考虑,不应该花费太多时间在Code Review 阶段去进行逻辑错误检查。

 

敏捷开发中不推荐的Code   Review的目的及内容

下面还有一些常见的Code Review目的和内容被很多团队广泛使用,但作者认为这些并不是敏捷开发中的主要目的和内容,团队应该把时间花费在重要的目的和内容上,而不应该投入精力在下面的这些Code Review目的和内容上。

 

发现性能问题

有些团队把性能问题,也作为Code   Review的目的和内容之一,然后提出一些如String应该使用StringBuilder,而不能使用+,类似这样的看似有用其实无用建议。

笔者认为,性能问题是需要量化的衡量和精确定位, 很难通过Code   Review检查出来。而一些粗浅的性能问题可以通过一些工具方便地扫描出来,而无须花费时间去进行Code Review。

如图1是RAD V7.0 (IBM Rati onal   Application Developer) 中的Software   Analyzer工具带有的Performance检查:


所以笔者认为,开发人员提交的代码,需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的Code Review 上。具体的性能问题交给性能测试。

 

发现开源的授权法律问题

开源软件也可以借助一些检查工具, 统一通过工具扫描, 无需在Code Review 阶段花费时间。

 

其他问题,如国际化,J2EE Best   Practice等

这些问题开发人员可以在提交代码之前通过工具发现和解决, 不是Code Review 阶段的职责和目的,也无须花费时间去处理。

像FindBugs 和RAD 这样的工具就具备类似的代码检查功能,如RADV7.0 中的Software Analyzer 工具带有如下的检查功能:


1.设计原则(5):用于面向对象编程的设计原则的规则。

2.全球化(47):基于全球化编码最佳实践的规则,有助于确保代码在局部环境中正确地运行。

3.J2EE 最佳实践(32):基于最佳的 Java™ 2 Platform Enterprise   Edition( J2EE)开发实践的规则,以及支持瞄准 IBM® WebSphere® 服务的Web 项目的规则;

4.J2EE 安全性(17):验证代码符合 J2EE 技术安全性需要的规则;

5.J2SE 最佳实践(71):基于最佳的 Java™2 Platform Standard Edition   (J2SE)开发实践的规则;

6.J2SE 安全性(9):验证代码符合 J2SE 技术安全性需要的规则;

7.命名(2):关于 Java 代码中命名约定的规则;

8.性能(26):加强在 Java 应用程序中提高性能和减少存储器足迹的建议的规则;

9.私有 API (3):定位那些不属于 Java 代码的 API 的规则。

 

敏捷开发中如何开展Code   Review

在清晰明确了敏捷团队进行Code   Review 的目的和内容后,下面介绍如何有效地开展Code Review。

 

沟通、协作、互助、学习的团队氛围

Code Review 中,Review 人员和开发人员不是对立的关系,而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛,既能互相增长团队的知识和经验,还能把产品做得更好。

Code Review协作过程:

a)先由代码的开发人员向检查人员进行大体的介绍,包括设计思想、数据结构、程序代码结构介绍等。

b)双方进行讨论、交流。

c)检查人员单独进一步进行Code   Review,并记录Review结果和建议。

d)由检查人员和开发人员一起,检查人员反馈Code Review结果,并和开发人员一起讨论改进方法,重构。

e)最后把可重用的Code Review的经验总结编码规范,或者记录到“地雷区”中。便于整个团队复用经验。


开展以上过程可以以开发人员为主,辅助以工具。但无须规定系列的文档、流程、Check List 等,这反而会影响开发人员的积极性。

Code Review是发现问题的过程,同时也是学习和交流过程。需要是灵活、自由、主动的态度,而不是行政上的控制和规章流程。笔者建议:和敏捷开发的核心思想一致,让团队明确Code Review 的思想、作用和目的内容后,充分发挥个体的积极性和学习分享的动力。随时随地地进行Code   Review,讨论,重构,改进。

 

增量式Review

大家都知道,软件开发中存在长鞭效应,即一个问题越在后期发现造成的影响会越大,Code Review 也是

如此,如图4所示:


软件的开发过程中, 应该阶段性地进行Code   Review,而不是等到所有代码都开发完毕后再做一次性的Code Review。那时如果发现问题,造成的改动成本比增量式的检查来的大得多。

笔者了解的一些开发团队,他们在软件开发完毕,并测试后,才临时确定Code Review的人员,然后再安排半天左右的时间进行Code Review。结果尽管发现一些结构或设计方面问题,但由于修改成本大,也无法进行改进。

正确的方式是,在早期就参与设计开发过程,抱着互助、沟通、协作、学习的思想,阶段性的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主动、积极的态度,按照敏捷的思想自己去把握决定。

 

利用工具进行Code Inspection

有很多的工具可以辅助Code   Review :

1.如代码格式检查Checkstyle 工具,检查如过大的类、太长的方法和未使用的变量等这样违反编程规范的问题。

2.RAD中的Software Analyzer工具,可以基于规则进行国际化、J2EE最佳实践、性能、安全等检查。3.CSAR,用于扫描代码检查开源软件等。

4.JDepend,可以检查包依赖关系。

5.CPD工具,Eclipse 的 PMD 插件提供了一项叫做 CPD(或复制粘贴探测器)的功能,用于寻找重复的代码。

6.Eclipse 的Metrics 插件,提供了很多有效地查出代码复杂度的功能。

辅助以工具和自动化流程,能花很少时间轻松完成很多基本的Code   Inspection 工作。让团队有更多的时间和精力去做更重要的Code Review。

 

持续自动化Code Inspection

工具检查可以由开发人员自行检查并修正, 但一种更可持续的做法是自动化的集成工具进行Code   Inspection,可以通过自动化脚本在每日进行Build 前进行扫描,并呈现报告给相应人员。

 

Code Review协作工具

为了快速有效地进行人工Code   Review协作,可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理Code Review任务、问题、建议等。

 

总结

Code Review 的核心是:互助,沟通,协作,学习的过程,这是一个美妙而享受的过程,是跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成Code Review 对产品、对团队、对个人的巨大好处的共识,发挥出个体的积极性,相信会改变“流于形式”的现状,发挥Code   Review巨大的威力。

 

 

作者简介:

陈序明,IBM公司顾问软件工程师。他目前在IBM中国北京研发中心工作,从事银行多渠道整合(网上银行、手机银行、柜面等)方面的开发和研究,对软件架构、敏捷开发、产品管理和银行业务很感兴趣。

 

黄彦军,IBM中国软件研发中心软件工程师,2008年在西安电子科技大学获得计算机系统结构硕士学位。目前主要从事中间件、Eclipse插件开发,深入理解C、C++、Java。感兴趣的技术领域包括:分布式计算,网络应用等。

(本文来自《程序员》杂志0912期杂志)

《程序员》杂志官方网站:http://www.programmer.com.cn/

敏捷开发思想

阅读数 561

敏捷开发中的测试

阅读数 2019

敏捷开发

阅读数 278

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