2019-05-23 13:51:53 u012169230 阅读数 45
  • SCRUM敏捷开发视频教程

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

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

读“零道书院|『干货』敏捷开发模式下,如何进行质量管理”有感。

原文:http://www.sohu.com/a/138301117_278472

我们今天有个新颖的idea,我们可以很快的让用户看到效果,很快的上线,然后去进行验证,如果有问题立即就下线,如果可以改进,下星期再改再上线。这是一个持续实现idea的过程。

传统的软件设计模式采用瀑布式开发,需求分析——概要设计——详细设计——编码开发——测试——交付,每个阶段都依赖于它的上游阶段。在敏捷开发模式中,软件项目被切分成多个子项目,单独子项目可以独立开发、测试、具备集成可运行特点。

由于互联网行业的竞争性,敏捷开发被提出用于快速满足用户需求,允许有所不足,不断试错,在持续迭代中完善产品。

敏捷开发下,如何保证在“快”的同时满足质量要求,成为了敏捷开发下的一大难题。

在推动敏捷开发的同时,如何降低项目管理成本,提高研发人员工作效率,保证项目交付质量,变得日益重要。以下是一种敏捷开发过程质量判断的方案。这种方法用明确的数据从各个维度来说明一个迭代的质量问题,长期可以看出一个项目多个迭代之间的质量变化趋势,如果多个项目同时进行,还可以轻松对比各个项目的迭代质量优劣和质量发展趋势。

以一个迭代为单元,从以下6个角度分析:

1. story延期率:统计功能是否按时提测,超过提测时间,标记为延期。

2. story打回率:统计story在开发完成提测后能否满足提测标准,以冒烟测试用例为例,不通过则打回。

3. bug打回率:开发人员解决了bug并提测,但经测试人员验证发现并未解决。

4. bug不收敛率:测试提出的bug未按照解决时效要求修复的,超过规定修复时间。

5. bug引发率:开发人员在解决一个bug时,引起了其他的bug。

6. bug重启率:已经关闭的bug在开发人员解决问题的过程中或部署误操作重新出现。

六个指标优先级从高至低为:story延期率、story打回率、bug打回率、bug引发率、bug不收敛率、bug重启率。story如果延期,会造成后面的工作整体受影响,并且测试人员的工作安排冲突。

JIRA是个项目管理工具,管理需求和开发过程以及bug、story的计划提测时间和打回次数可以进行记录,在迭代结束后很快就能统计出质量数据。

2012-04-17 15:27:23 luowangjun 阅读数 1285
  • SCRUM敏捷开发视频教程

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

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

敏捷开发模式下的质量管理

  前几天,笔者与一位在大型互联网公司从事质量保证的朋友交谈,作为互联网产品质量和测试的负责人,他最近负责的质量管理方面遇到了很多困难。主要有:

1)测试团队在敏捷开发模式下的价值非常有限;

2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,

3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;

4)由于测试人员得不到开发团队的认可,离职率非常高;

5)质量部门无法收集到数据,不能进行质量度量;

6)测试团队也有一批自动化测试专家,但派不上用场

  这些问题可能很多开发团队都会遇到,总结一下,大致是这几个方面:

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

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

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

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

5、缺乏相应的质量控制方法

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

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

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

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

1QA角色的转变

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

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

QA和测试人员也是敏捷团队的一部分,作为敏捷教练,要向他提供支持和训练,以使作们适应开发的快节奏。比如,如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独立定义故事和需求,那你应该主动站出来和团队的其他成员交流,并偿试三方协作,即测试人员、开发人员和业务专家。腾讯公司把业务专家称为BA,即BussinessAnalystBA和开发人员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共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。

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

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

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



敏捷开发中QA如何做质量管理?

经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过两年多的PQA,在中兴通讯的敏捷转型中也遇到过这些问题。

先总结一下敏捷转型中遇到的问题吧,QA的工作也是要围绕这些问题展开的:

  1. 很多公司希望采用敏捷,但是又没有把握

  2. 传统的瀑布式开发流程在公司已根深蒂固,虽无法满足快速发展的需要,但大规模改动又不现实,老板也不愿意花太多的成本

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

  4. 研发人员需要观念的转变和方法培训

  5. 缺乏相应的质量控制方法

  6. 需要经常的和及时的质量度量

  7. 自动化测试不能落到实处,持续集成发挥不出作用

  8. 人员水平参差不齐,有人支持有人反对

笔者也先后参加过多次华为、腾讯、平安科技等公司的敏捷推行者的分享活动,也参加过Thoughtwork、康仕诚、ScrumCN等专业机构的培训,对国内敏捷项目的质量管理有一些想法,结合笔者这几年的质量管理经验,总结一下:

1)QA角色的转变

QA以往主要还是作为警察的角色,从事各种审核活动,要从警察转变成教练。传统项目里,QA习惯拿着事先准备好的检查单,对项目一条条做审核,发现问题开不符合报告,给团队的感觉就是一个监工。虽然笔者自己也不喜欢人家这么说我,但确实我们给项目成员你的印象就是监督。

中兴通讯从2014年开始,各研究院都大力推行敏捷转型,刚开始觉得有点失落,都敏捷了,都不知道该怎么下手了,审核不能叫审核,要叫观察,审核报告也要叫观察记录。经过几个月基本上适应了,QA、项目管理员都往敏捷教练的方向上转,在外界专业教练的指导下,引导项目开展各类敏捷活动。

比如该如何开站立会议,该怎么去做迭代的计划等等指导性的工作,不过以前的项目团队划分成十多个特性团队,一个人要跟十几个PO、SM打交道,对于QA的沟通能力增加很多,每天奔赴各个团队。

2)QA参与各项活动,如需求梳理会、计划会、早会、持续集成看板、演示、回顾会等,各项持续集成结果也都推送到QA,这样便于及时获取团队的信息,也便于QA输出各类观察记录、报告。

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

4)提供并获取反馈

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

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

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

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

  2. 看板:最便宜的敏捷工具,可实现价值流、可视化、拉动、限制在制品、找出瓶颈等多个作用。用户故事可以用看板,QA自己的任务同样可以用看板管起来,便于QA之间互相沟通、对齐信息。

  3. 自动化测试:持续集成的前提是有自动化测试用例,以及代码静态检查、代码行覆盖率、代码复杂度等各种工具,如果这些没做起来,只是持续构建,并没有太大意义。自动化测试属于防御性测试,把所有的质量风险用穷举法列出测试用例,然后测试用例提前写好,然后写代码帮你执行,预防缺陷的泄露。但是成本同样非常大,是否能推行起来,就看领导的魄力了。

  4. 每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。QA可以参加晨会,根据自己的观察提出问题。

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

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

  7. 迭代回顾会议:在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步。会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。QA同样可以参加回顾会议,引导团队如何召开,并跟踪改进事项。

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

(为偷懒,本文有些内容为网上抄袭)



2013-11-01 09:36:49 jk050802 阅读数 2127
  • SCRUM敏捷开发视频教程

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

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

敏捷开发的简单歌诀,这也概括了敏捷开发的全部内容

迭代开发,价值优先

分解任务,真实进度


站立会议,交通畅通

用户参与,调整方向


结对编程,代码质量

测试驱动,安全可靠


持续集成,尽早反馈

自动部署,一键安装


定期回顾,持续改进

不断学习,提高能力

以上这个歌诀,1,2段表明敏捷开发的开发总模式;3,4段表明敏捷开发的项目管理;5,6段表明敏捷开发的编码方式;7,8段表明敏捷开发的反馈方法;9,10段表明敏捷开发中,如何协作和提升自己能力。


敏捷宣言

敏捷开发是一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。


敏捷的精神

只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的不重要的事情它强调团队合作,人们专注于具体可行的目标实现真正可工作的软件)。它打破那种基于计划的瀑布式软件开发方法,将软件开发的实际重点转移到一种更加自然和可持续的开发方式上。

它要求团队中的每一个人(包括与团队合作的人)都具备职业精神,并积极地期望项目能获得成功。它并不要求所有人都是有经验的专业人员,但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。


敏捷的核心——持续前进

事实上,只要有人继续使用这个软件,开发就没有结束。我们进行的是持续开发、持续反馈。这种持续前进的方法根植于敏捷方法。它不但应用于软件开发的生命周期,还应用于技术技能的学习、需求采集、产品部署、用户培训等方面。


敏捷软件开发概括

敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

1.它要整个团队一起努力。敏捷团队往往是一个小型团队(10个人以内),团队的所有成员在一起工作,如果可能,最好有独立在一起的工作空间,一起共享代码和必要的开发任务,而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起,尽可能早且频繁给他们演示最新的系统。

2.不断从自己写的代码中得到反馈,并且使用自动化工具不断地构建(持续集成)和测试系统。在前进过程中,你都会有意识地修改一些代码:在功能不变的情况下,重新设计部分代码,改善代码的质量。这就是重构,它是软件开发中不可或缺的部分,因为编码永远没有一天是真正意义上的“结束”。

3.以迭代的方式进行工作:确定一小块时间(一周左右)的计划,然后按时完成它们。给客户演示每个迭代的工作效果,及时得到他们的反馈(这样可以保证方向正确),并且根据实际情况尽可能频繁地发布系统版本让用户使用。


2011-06-20 17:05:54 john521 阅读数 59
  • SCRUM敏捷开发视频教程

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

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

由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。

    目前公司配置管理在策略上采用的是不稳定主干(unstable trunk) 模式,所有的项目都在同一主干上进行修改,在每周上线后并没有明确的stable分支版本,基本上是靠SCM人员手工拷贝代码来管理维护的。这就引起了很多问题:

   1)、多个项目组开发人员都可能并发对同样代码进行修改,造成了严重的代码冲突问题。例如张三修改了a.java并上QA测试服务器,在QA测试过程中, 李四也对a.java进行修改并上QA,李四的代码覆盖了张三的代码。由于是SCM人员并不清楚代码冲突情况,这样张三和李四的代码上QA很容易相互影响 并很难查具体原因

   2)、由于没有明确stable分支版本,导致上QA、上生产只能采用增量更新,上QA、上生产出问题后的代码回滚很麻烦,严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理,导致生产系统出问题后要排查问题也很难查。

   3)、由于核心基础包没有与上层应用隔离,导致大家都会对核心包进行修改,修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象

  类似的问题很多。要在新的项目实施及后期运营中避免类似问题的重现,至少要从如下几个方面来:

  1)、分支管理策略:采用适当的分支管理策略来保证开发库、测试库、发布库的隔离

  2)、适当引入每日编译、持续集成、Code Review等敏捷开发的最佳实践

  3)、采用自动化脚本完成上QA、上生产的部署工作,避免人工失误

  4)、对核心框架、后台应用、前端页面开发采用不同的配置管理策略

 

1、分支策略(Branching Strategy)

   代码分支管理策略一般分为3种(参考Branching Strategy Questioned

  1)、不稳定主干策略(The unstable trunk strategy)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

   此种分支策略使用主干作为新功能开发主线,分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current,也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定,达到一个发布的里程碑以后,从主干分出来一 个stable分支。freebsd是每个大版本一个分支。也就是说4.x,5.x,6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善, 而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后,就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。
   此种分支管理策略比较适合诸如传统软件产品的开发模式,例如微软Windows开发,对于互联网开发不是很适合。已经在主干上集成的新功能,如果达不到里 程碑的要求,稳定分支就不能创建,很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。

  2)、稳定主干策略(The stable trunk)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

    此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本,可以随时发布。bug的修改和新功能的增加,全部在分支上进行。而且每个bug和新功能都 有不同的开发分支,完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
    这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成,就不可能合并到主干,也就不会影响其他变更的 发布。另外,每个分支的生命期比较短,唯一长期存在的就是主干,这样每次合并的风险很小。每次发布之前,只要比较主干上的最新版本和上一次发布的版本就能 够知道这次发布的文件范围了。
   此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂,或者应发布计划的要求而长期没有合并到主干上,很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中,测试工作量较大。

  3)、敏捷发布策略(The agile release strategy)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

    此种模式在采用敏捷开发模式(例如Scrum)的项目中广泛采用,这些项目有固定的迭代周期(例如Scrum中每个Sprint的两周时间),新的功能开 发都在Task branch(Feature branch)上进行,在接近迭代周期的发布阶段时候,新建Release branch来完成本迭代周期的发布,各Task branch(Feature branch)的功能merge到Release Branch中。在完成发布后,Release branch的功能merge到Trunk和尚在进行的Task branch中。

    采用敏捷发布策略要求主干的版本:
  • 任何时候都可以发布 :在任何时候,产品所有者都可以基于主干的最新版本,发布新版本的产品
  • 希望尽早发布

  此种模式较适合敏捷开发软件的要求,但对程序员及SCM要求较高。

  关于敏捷发布策略可以参考:多个敏捷团队之间的版本控制

 

2、配置管理策略

   根据目前公司的实际情况,建议采用稳定主干策略为主(The stable trunk 。参考淘宝网最佳实践之ABS自动编译 可以看到,淘宝也采用了类似的版本管理策略。

   具体操作策略如下(尚需要细化):

   1)、trunk保持稳定,保证可以随时发布。trunk只有SCM人员才具有写权限,开发人员等只有读权限。

   2)、为降低SCM分支管理的压力,branch的权限可以授予给指定的几个组长

   3)、在每一个项目开始前,采用Branch per feature(Branch per Task)的分支管理模式(Common Branching Patterns ),由各组长或SCM人员按照branch管理规范建立对应项目的开发分支development branch,例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。

       项目定义:新功能开发、bug修复、需求变更等

   4)、在每周的上线发布后,在主干建立基线release版本(通过svn tag),以当前的主干作为基线,建立下一发布周期的test branch

   5)、开发人员在所在项目的development branch完成开发及集成测试后提交上线单,由SCM人员根据项目上线单的分支名称merge分支代码到本发布周期的test branch,进行测试。如果在测试过程中有新的上线单且有可能与其他上线单存在冲突,则在merge到test branch的过程中,SCM人员可以很容易及时排查问题。

       只要对上线单命名按照规范进行定义(例如与分支名称相同),此部分工作可以由脚本来自动化,存在冲突再人工干预。

   6)、测试人员完成本发布周期test branch所有上线单的功能测试后,由SCM人员将本发布周期的test branch合并到trunk,并通过打tag来release 一个上线版本

   7)、系统人员利用自动化部署脚本从trunk检出对应的release版本进行上线部署

     此部分工作采用自动化脚本完成,自动化脚本主要完成如下操作:从trunk检出完整的release 版本并打包,并包含部署包的md5验证码-> 上传部署包到生产系统各服务器->校验发布包的md5验证码是否正确,保证文件正确传输->完整备份生产系统的运行包->部署生产系统

   8)、每日晚上对trunk进行持续集成,保证能够正常编译和部署。工具建议采用hudson

   9)、对于核心代码及后台代码的修改,采用Pre-commit review模式,必须通过code review后,才能够提交到trunk中。工具可以采用reviewboard

   10)、其他一些值得讨论的问题

    开发分支的生命周期问题 :上线后,原有的development branch变为只读的或者可以定期删除掉。

    紧急上线策略 :紧急上线不遵循每周两次的上线周期,因此对于需要紧急上线的程序可以从trunk检出最 近的release版本代码建立临时测试分支(test branch),紧急上线仍然需要按照规范建立对应的development branch,然后与临时测试分支合并,测试通过后上线,同时由SCM人员将紧急上线的development branch合并到当前的测试分支,继续进行测试。

    不同项目的配置管理策略 :对核心框架、后台应用、前端页面开发可以采用不同的配置管理策略,例如核心框架可以采用不稳定主干策略(The unstable trunk strategy);后台应用采用稳定主干策略(The stable trunk

 

3、版本控制工具选择

  SVN的集中管理模式较为适合目前公司协作开发的需要,例如SVN所提供的集中式权限控制,对代码、二进制文件及文档的集中管理,类似 TortoiseSVN的支持工具以及Eclipse 插件等。而Git/Mercurial(hg)的分布式管理特性,很适合开发人员本地版本开发管理。

   因此可以结合SVN和Git/Mercurial(hg)来作为版本控制工具。用SVN进行集中管理,用Mercurial(hg)在多个不同机器上进行 开发,功能完善并测试完成后再提交至 SVN Repository。可以借助git-svn、HgSubversion、hgsvn这样的工具来结合使用。考虑到目前的开发环境为Windows环 境,建议采用Mercurial。

  值得一提的是SVN从1.5版本开始,对branching merge的支持有很大的提升,大大简化了分支合并的难度,可以参考What’s New in Subversion 1.6?

4、一些工具

code review

    http://www.reviewboard.org/

持续集成

    https://hudson.dev.java.net/

自动部署

    http://www.smartfrog.org/

    http://www.capify.org

商业软件中采用atlassian的系列产品倒是不错的选择:Jira+Crucible+FishEye+Bamboo

 

5、参考文档

  http://www.programmer.com.cn/3223/

  http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.commonpatterns.feature

  http://martinfowler.com/bliki/FeatureBranch.html

  http://codicesoftware.blogspot.com/2010/03/branching-strategies.html

  http://msdn.microsoft.com/en-us/library/bb668955.aspx

  http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

  http://www.cmcrossroads.com/bradapp/acme/branching/

  http://www.vance.com/steve/perforce/Branching_Strategies.html

  http://blog.gravityfree.ca/2009/02/using-feature-branches.html

  http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

  http://thinkernel.bokee.com/4518935.html

  http://www.infoq.com/cn/articles/agile-version-control

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