敏捷开发流程_敏捷开发流程书籍 - CSDN
精华内容
参与话题
  • 敏捷开发流程

    2019-10-22 11:54:24
    敏捷软件开发,又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调...

    敏捷软件开发,又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

    一、story讲解

    1. 制作竞品分析PPT,UE全组参与。(用时:根据产品复杂度,0.5-2小时之内)
    2. 制作产品原型,交由客户看,客户没有异议之后禅道录入story
    3. 产品在禅道拆分好story,并且定义出优先级,关联需求,后续开发根据优先级进行开发
    4. 由产品讲解story,前端和后端都参与。(用时:根据产品的复杂度,1-3小时之内)

    二、人员划分

    1. 新建wiki项目主页,把PPT和产品原型(HTML文件)上传到wiki
    2. 根据产品原型,按照模块划分相关负责人,前端和后端都是,并放到wiki。(由项目负责人新建)

    三、定义接口文档(2-3天)

    1. 前端后端相关人员一起,对照原型,根据模块及页面大概定义出接口
      • 一个页面中有几个接口,每个接口入参与出参是什么
    2. 后端每个模块的负责人,根据开会讨论的结果,在wiki上生成标准的接口文档
    3. 将后端做好的接口文档发给前端模块负责人过目,有问题继续修改;没问题开始后续的步骤 。

    四、方案设计(1小时-1天左右,根据模块大小定义时间)

    1. 后端开发人员,根据原型以及定义的接口,做好方案设计
    2. 对有难度或者有疑点的接口,做出方案,尽量给出多个合理方案
    3. 每个方案写清楚优点缺点

    五、方案评审(2-3小时)

    1. 对做出的方案设计,做方案评审,建议全体人员参与(无论做不做该项目)

    六、禅道拆分(1-2小时)

    1. 相关负责人按照优先级顺序,在禅道拆分自己的任务,单个任务最多不要超过4小时,即拆分要详细

      • 拆分一个task时,以具体写的代码为一个task,并在任务名称中写出该类/方法的名称在任务描述中写出该task的代码块具体有的功能
      • 当拆完task后,这几个task所完成功能的代码已经过了一遍
      • 如果有不了解的功能,在方案评审前先写出一个demo,以方便拆分task的估时
      • 一个task用时应在0.5-2之间,最大最大4个小时
    2. 以文件上传功能为例,分成3个task

      • task1.任务名称:公共模块-文件上传-上传文件controller的方法fileUpload
        任务描述:通过网页获取文件,文件判空,判断文件的归属类型(用户/教材/课时/步骤/咨询)
        工时:1
      • task2.任务名称:公共模块-文件上传-添加文件FileUtil 和FileUtilOssImpl
        任务描述:util处理上传的文件,判断文件类型,大小,设置文件上传的路径,返回的url
        工时:1.5
      • task3.任务名称:公共模块-文件上传-文件接口spring-fileOss.xml 配置文件
        任务描述:oss的文件上传, 调用的spring.xml配置文件(密匙,ID,bucket等)
        工时:1.5

    七、开发

    1. 搭建开发服务器
    2. 开发人员根据禅道上的任务,按时完成自己的开发工作,具体体现到日报上
    3. 每天上午开10分钟左右进度会议,如果有延迟现象出现,拿出解决方案,保证项目按照禅道上的时间点完成
    4. 数据库索引(两种索引):
      1. 经常查询的,数据散列度比较高的,做一般索引,不需要建联合索引。
      2. 数据必须保持唯一的,建唯一索引。(要有文档,文档表明哪些字段要建索引。发邮件。)

    八、阶段测试

    1. 每天至少发布一次代码到开发环境,并且保证发布完之后程序没问题(与开发并行)

    九、性能测试和coderevivew(1天)

    1. 对每个接口做好性能测试
      • 每个接口的响应时间不超过200ms,如果有超过的,做优化,尽量缩小到200ms内
    2. 完成codereview,根据codereview结论完成修改

    十、压力测试

    1. 做好压测报告

    十一、 Demo

    demo

    1. 发demo申请邮件,收件人包括产品、测试同学、前后端相关开发人员
      1. 主题:XX项目demo通知
      2. 内容:时间 地点 参会人员
    2. 开demo会议:主讲人:某个开发人员
      • 会议途中产品和测试提出问题
    3. 发demo结果通知邮件(由产品同学发)
      1. demo结果
      2. 如果不通过,有哪些问题
    4. 如果不通过,召集第二次Demo会议,知道通过为止。第二次会议只需演示之前不通过的部分

    测试

    1. demo通过之后
    2. 开发人员对代码打tag(参考文档: 如何打tag 。)
    3. 开发人员部署测试环境,部署完成之后发邮件,写明域名;
    4. 交给测试人员进行测试,测试人员发送全体测试周期邮件
    5. 测试期间,如果有测试发现bug,会在禅道上面提出bug,禅道会发送邮件到各自开发人员的邮箱,开发人员要关注BUG邮件 ,及时确认BUG,及时修改
    6. 修改BUG之后,开发环境前端代码由前端同学自己部署,后端代码由后端同学自己部署
    7. 测试完成之后,测试或产品发送上线通知
      具体参看: 测试Bug划分及处理流程
      测试和线上环境发布流程: 测试及线上环境发布流程

    十二、 发布测试环境、集成测试(2-3天)

    1. 禅道上建立bug,测试出bug,指派给相关人员修改

    十三、发布线上环境,同时停止开发环境和测试环境

    十四、线上监控

    1. 错误报告
    展开全文
  • 什么是敏捷开发流程

    千次阅读 2018-08-22 08:15:51
    今天给大家分享一下,java项目中需要使用的敏捷开发流程   1.背景介绍   在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多, 测试了半年...

    大家好,我是IT修真院武汉分院第15期学员,一枚正直善良的JAVA程序员。

    今天给大家分享一下,java项目中需要使用的敏捷开发流程

     


    1.背景介绍

     

    在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多, 测试了半年多,修改Bug用了半年多。总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求。 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大。文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多。

     


    2.知识剖析

     

    敏捷开发(AgileDevelopment)是一种以人为核心、迭代、循序渐进的开发方法。怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去 一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

     


    3.常见问题

    提问一:什么是迭代?

    提问二:为什么说是以人为核心?

    提问三:敏捷开发包括了哪些内容?


    4.解决方案

     

    回答一

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程; 同时每一次迭代都可以生产或开发出一个可以交付的软件产品。


    回答二


    以前大多是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的, 一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

    老大强调的理念就是:产品和开发必须是一个Team,大家只是分工不同,角色不同,并不是两个对立的团队,出了问题,不要说这 是产品设计出来,这是开发团队实现不了的。这是一个开发小组所有人的责任,这个后果是所有的人都需要承担的。 如果我们认真的区分这是什么问题,那么也只是为了避免下次出现同样的情况,而用户只会知道是一个公司出了一款垃圾产品,没有 人关心到底是产品还是开发的锅。

    这是做敏捷开发的大前提。或者不仅仅是产品和开发,责任共担,One Team这个理念是贯穿始终的。 产品和开发必须是一个Team还体现在需求分期上,实际上,需求分期如果没做好,敏捷开发只能流于形式。

    在敏捷开发中职责明确,每个人要负责的事情必须清晰无误,谁该做哪些事情,必须要提前讲清楚。做为后端,项目进入真正的开发阶段后,开发组的成员就应该是主动去控制项目的进度,和风险,以及主动去测试项目中存在的问题, 在这个阶段,除了一些需求不明,或者是发生变动的情况出现,不应该去打扰产品经理。不要让产品经理做开发团队的保姆。 开发组的成员的目标就是做好项目的进度控制。

    有风险就及时反馈给Leader,确保自己理解的需求是明确无误的,确保自己的 测试是完整和严谨的,确认自己写出来的代码是可以维护的。一定要理解清楚,一旦PM通过Story讲解,将需求交付给开发组成 员,那么开发组成员就应该主动而独立的为这件事情负责。当项目完工以后,开发组成员应该交叉去做CodeReview, 并且给出性能测试报告,以及组织Demo。

     

    回答三

    1:需求讲解
    2:定义接口文档
    3:方案设计
    4:禅道拆分
    5:方案评审
    6:开发阶段
    7:阶段测试
    8:性能测试和Coderevivew
    9:压力测试
    10:Demo
    11:发布测试环境,集成测试
    12:发布线上环境同时停止开发环境和测试环境
    13:线上监控

     


    5.编码实战

     


    6.扩展思考

     

    敏捷开发与传统开发方法的优劣?

    优势:敏捷开发的高适应性,以人为本的特性,和轻量型的开发方法即以测试为驱动取代了以文档为驱动,这三个主要的特点, 也就是敏捷开发相对与传统开发方式的主要有点。因为他更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    劣势:与传统开发方式相比,敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求,而在每次新的需求产生时都可能引起整个系统的大幅度的修改。 因为开发者在开发上一个版本的时候,完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中,并不一定总是有效的。 而另一个方面,敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档,这样在一个大型项目比如一个操作系统开发的时候, 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

     


    7.参考文献

     

    参考一:https://www.zhihu.com/question/39757751/answer/82927612?group_id=685376196313116672


    参考二:https://www.cnblogs.com/yt96/p/5983265.html

     


    8.更多讨论

    今天的分享就到这里啦,欢迎大家提问和探讨!

    展开全文
  • 敏捷开发流程

    千次阅读 2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...

    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.

        一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?

        先看下面的流程图:

        卓有成效的敏捷开发流程

    一. 前期准备阶段

        有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

        在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

        需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

        数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

        开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:

       可参考我之前的博客:<<概要设计 --需求定义及描述方式>>

         http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html

        卓有成效的敏捷开发流程

      图2(需求分析格式)

       

     二. 方案评审

        这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:

       卓有成效的敏捷开发流程

      图3(任务分析明细图)

    这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.

     

    三. 项目启动会议

        正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道

         我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

        当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

        在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.

        还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:

       卓有成效的敏捷开发流程

       图4(作战图示例)

     

        之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.

        这就是作战图的优势, 把团队的目标凝聚在一起.

    四. 迭代开发

       如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.

        那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.

        在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.

        以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的. 所以, 应该想办法让任务风险前移.

        当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的. 

        这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.

        在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.   

        说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:

     卓有成效的敏捷开发流程

      图5(每日汇报明细)

      点击查看大图

     

        这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.

     

     关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.

        卓有成效的敏捷开发流程

     图7(进度控制超前的燃烧图)

    卓有成效的敏捷开发流程

     图8(进度失控的项目)

      结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.

    五. 集成测试

        在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.

     

    六. 最后就是发版了.

       自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.



    敏捷开发(Agile)是现在时髦的一个软件开发工程管理方式,其中的很多特征,例如scrum,pair coding,standup meeting等,有很多文章描述,这里我想聊一下敏捷开发中的文档和需求分析。


    在传统的软件工程中,无论是瀑布式还是所谓的V型模式或测试驱动模式,基本上需求分析都是要进行的第一步,然后是概要设计,详细设计,编码和单元测试。传统的软件工程对文档要求比较高,而很多公司也为自己做过的大量文档而骄傲,标榜为规范。对于文档量很少甚至没有的软件项目斥之为山寨。

    典型的,在这个项目过程中,需求分析占20-30%的时间,然后概要设计20%左右,详细设计也基本上20%左右,编码通常仅仅占10%-15%,剩余的时间机动给测试和需求变更。一旦需求变更——这个几乎是一定会发生的,根据长鞭效应,就会导致一连串的变更,设计,代码和测试,一切都随之变动。最后往往导致所谓的软件灾变。就是软件本身跟不上业务的变动,发布时间一再推迟。

    还有重要的一点,就我看到的程序员,几乎没有一个喜欢写文档的,通常把写文档归于无聊,无用的工作。大量的文档任务对士气是一个很大的打击。


    在敏捷开发中,号称拥抱变化,在一定程度上,能够降低需求变更和文档对项目的负面影响。

    首先,有两点,是我们看待需求的基础:

    第一,需求和设计是不能分开的,设计是要实现需求所要求的功能,需求也是在现在技术条件许可下的对期望值的折中。

    第二,绝大多数客户实际上并不了解他们的需要,也不清楚他们想要什么产品。这一点,我相信在传统开发过程中,为不断的需求变更头痛的人一定是有体会的。(不过这个你可不要对你的客户说哦,人家会不高兴的)


    于是,在敏捷开发中,需求不再是一个一次性的工作,而是一个伴随整个项目进行的,逐步细化的工作。

    我们在开发中,设计和需求是混在一起进行的。设计文档有两种,Feature Design,这个可以说是功能设计,也就是类似与原来软件工程中的需求分析吧,另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。

    不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析,通常一个一年的项目,这个Feature Design也就10页左右的文档量而已,基本上就是非常粗略地大颗粒地描述要实现的功能而已。往往只描述要达到的结果和效果,对具体的UI,业务流程或者游戏角色等不做描述。

    至于Technical design呢,文档量也不大,基本上就是模块划分,接口模式(不是格式哦),关键算法和数据结构等等框架的设计。对具体的数据格式和类型不做定义。

    至于费时的详细设计,通常由程序员完成的,在敏捷开发中是真正省略了,是依靠代码的可读性来实现。敏捷的观点是:好的代码本身就是最好的文档。

    总之,文档已经很弱化了,基本上就是一个design spec,当然对于软件自身的可读性和注释要求要多一些


    敏捷开发讲究的轻量快速迭代。

    也就是需求和设计实际上在一起进行的,进行的同时几乎就开始写代码。例如有了一个模糊的需求,就有一个前进的方向,例如可以写一些框架代码,定义一些消息机制和自动机的状态等,写一些接口类,基类,制定设计模式等。

    进一步细一些的需求出来,就可以写一些派生类和执行逻辑。继续地,更进一步的需求就会表现在一些派生类上成员和成员函数的添加。就这样逐步细化。

    敏捷开发中有迭代(Iteration)和里程碑(milestone)的概念,实际上开发的过程是和用户不断交流的过程,每个迭代基本上指实现一个或几个小Features,甚至是Feature中的一个部分,但是敏捷开发要求保证每个迭代出来的产品是能够使用和能够测试的,这样就可以有基础和客户交流获得进一步详细的需求。换句话说,就是每一吃迭代的工作都有可能得到用户的认可。

    每个Milestone可以根据时间来划分,更多是按功能实现的需求的来划分,也就是每个milestone能够推出一个部分满足客户一些需求的产品。

    所以在开发中,敏捷开发是一个小量递增,小步快走的过程,需求是逐步细化,设计也是逐步深入的,代码也是伴随这个过程不断生长的。需求分析是作为一个交互的过程,是在整个过程中和design/coding/test混合在一起。

    在我们的开发过程中,很常见的情况是最初的feature design只实现了其中70%的功能,但是却另外添加了起初没想到的30%的功能。这也许就是敏捷说声称的“拥抱变化”吧。

    这个就是现在时髦的敏捷编程啊,我感觉不错,效率比以前高多了,员工士气也比以前高。毕竟绝大多数程序员是不喜欢写文档的。

    好一些的项目管理,往往能够把本项目的alpha测试和debugging的时间和下一个项目的design,甚至frame coding的阶段重合在一起,以最大限度提升效率,或者说榨取程序员的价值。


    http://blog.sina.com.cn/s/blog_6296cebc0100pybx.html


    敏捷开发(Agile development)

    目录

    [隐藏]

    敏捷开发概述

      敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    敏捷开发的路线[1]

      Image:敏捷开发的路线图.jpg

      图:敏捷开发的路线图

      Test-Driven Development,测试驱动开发。

      它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。

      Continuous Integration,持续集成。

      在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。

      Refactoring,重构。

      相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。

      Pair-Programming,结对编程。

      在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。

      Stand up,站立会议。

      每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。

      Frequent Releases,小版本发布。

      在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。

      Minimal Documentation,较少的文档。

      其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

      Collaborative Focus,以合作为中心,表现为代码共享。

      在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。

      Customer Engagement ,现场客户。

      敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。

      Automated Testing ,自动化测试。

      为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。

      Adaptive Planning,可调整计划。

      敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。

      敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。

    敏捷开发的特点

      敏捷方法主要有两个特点,这也是其区别于其他方法,尤其是重型方法的最主要特征:

      (1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

      这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

      然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。

      与之相反的敏捷方法则是欢迎变化,目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。所以称之为适应性方法。      (2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

      Matin Flower认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

      在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,资源是可以替代的,而角色不可以替代。

      然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

      敏捷开发的目的是建立起一个项目团队全员参与到软件开发中,包括设定软件开发流程的管理人员,只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策,因为他们是最了解什么技术是需要和不需要的。再者,敏捷开发特别重视项目团队中的信息交流,有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

    敏捷开发的价值观

      实际上敏捷开发运动在数年前就开始了,但它正式开始的标志是2001年2月的“敏捷宣言”(Agile Manifesto),这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的,他们的价值观是:个人与交互重于开发过程与工具;可用的软件重于复杂的文档;寻求客户的合作重于对合同谈判;对变化的响应重于始终遵循固定的计划。

      个人与交互重于开发过程与工具的原因:一个由优秀的人员组成但使用普通的工具,要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程,以便把人当作机器上的一个可以替代的齿轮,但结果却并不成功。敏捷过程是承认每个人都有特定的能力(以及缺点)对之加以利用,而不是把所有的人当成一样来看待。更重要的是,在这样的理念下,几个项目做下来,每个人的能力都从中得以提高。这种人的能力的提高,对公司是无价之宝。而不至于把人当成齿轮,随着时间的推移,人的能力慢慢被消耗掉,最后变成留之无用、弃之可惜的尴尬人物。

      可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候,获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始,并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长,以保证开发小组始终是处理最有价值的功能,而且这些功能可以满足用户的期待。

      寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力,合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢,要么大家一起输。换句话说,就是希望开发小组和客户在面对项目的时候,以一种合作的态度共同向目标前进。当然,合同是必需的,但是如何起草条款,往往影响到不同的团体是进行合作式的还是对抗式的努力。

      对变化的响应重于始终遵循固定的计划的原因:敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外,用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法,也许今天看起来是必需的功能,明天就会觉得不那么重要了。随着小组获得更多的知识和经验,他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说,一个计划是从某个角度对未来的看法,而具有多个不同的角度看问题是有可能的。

    项目的敏捷开发方法

      敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图,下面介绍其有关的特点。

      Image:敏捷过程总图.gif

      1、敏捷小组作为一个整体工作

      项目取得成功的关键在于,所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员;编码人员也不会把只经过部分测试的代码“扔”给测试人员,一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”, “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然,尽管强调一个整体,小组中应该有一定的角色分配,各种敏捷开发方法角色的起名方案可能不同,但愿则基本上是一样的。第一个角色是产品所有者,他的主要职责包括:确认小组成员都在追求一个共同的目标前景;确定功能的优先等级,以便总是处理最有价值的功能;作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员,在开发内部使用的软件的时候,产品所有者可能是用户、用户的上级、分析师,也可能是为项目提供资金的人。

      2、敏捷小组按短迭代周期工作

    在敏捷项目中,总体上并没有什么上游阶段、下游阶段,你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计,但只要项目真正开始,每次迭代都会做同样的工作(分析、设计、编码、测试。等等)。迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。时间框一般很短,大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。迭代的时间长度一般是固定的,但也有报告说,有的小组在迭代开始的时候选择合适的时间长度。

      3、敏捷小组每次迭代交付一些成果

      比选择特定迭代长度更重要的,是开发小组在一次迭代中要把一个以上的不太精确的需求声明,经过分析、设计、编码、测试,变成可交付的软件(称之为功能增量)。当然并不需要把每次迭代的结果交付给用户,但目标是可以交付,这就意味着每次迭代都会增加一些小功能,但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要,但这并不意味着要完成发布的全部工作,因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”(MTBF)测试,他们不可能缩短这两个月的时间,但这个小组仍然是按照 4 周迭代,除了MTBF测试,其它都达到了发布状态。

      4、敏捷小组关注业务优先级

      敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先,他们按照产品所有者制定的顺序交付功能,而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级,并且把它组织到产品发布中去。要达到这个目的,需要综合考虑开发小组的能力,以及所需功能的优先级来建立发布计划。在编写功能的时候,需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能,那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的,但把功能依赖性控制在最低程度还是相当可行的。

      5、敏捷小组检查与调整

      任何项目开始的时候所建立的计划,仅仅是一个当前的猜测。有很多事情可以让这样的计划失效:项目成员的增减,某种技术比预期的更好或更差,用户改变了想法,竞争者迫使我们做出不同的反应,等等。对此,敏捷小组不是害怕这种变化,而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性,也可能更改计划。比如发现某项工作比预计的更耗费时间,可能就会调整进展速度。也许,用户看到交付的产品后改变了想法,这就产生反馈,比如他发现他更希望有另一项功能,或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能,或者减少某些低价值功能,就可以增加产品的价值。迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身,对于项目投资最大化是有益处的。从这个观点来看,迭代周期的长度选择就比较重要了,因为两次迭代之间是提供变更的机会,周期太长,变更机会就可能失去;周期太短,会发生频繁变更,而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑,对于一个复杂项目,迭代周期选择4周还是有道理的。

      MIT Sloan Management Review(麻省理工学院项目管理评论)所刊载的一篇为时两年对成功软件项目的研究报告,报告指出了软件项目获得成功的共同因素,排在首位的是迭代开发,而不是瀑布过程。其它的因素是:

      1、至少每天把新代码合并到整个系统,并且通过测试,对设计变更做出快速反应

      2、开发团队具备运作多个产品的工作经验。

      3、很早就致力于构建和提供内聚的架构。

      从这个报告中所透露出的信息告诉我们,认真研究敏捷过程对软件项目的成功是非常有意义的,它的意义在于:

      1)给开发小组的自组织提供了机会

      经典项目管理就好比一个具备中央调度服务的航空管理系统,这个系统是自治的,而且是封闭的,但现实中更庞大的系统,似乎并不属于中央调度控制系统,但也同样也是有效的。假如我们开车到某个地方,我们可以任意选择所需要的路线,我们甚至不需要准确计算停车,只要我们遵守交通法规,驾驶员可以临时根据路况改变某个转弯点,在驾驶游戏规则的框架内,依照自身最大利益做出决策。成千上万的驾驶者,并不需要中央控制和调度服务,人们仅仅在简单的交通法规的框架内,就可以完成综合起来看是更庞大的目标,很多事情从管理的角度只要抓住关键点,并不需要多么复杂的规则,往往会更有效。随着系统复杂度的提高,中央控制和调度系统面临崩溃。仔细研究交通系统的特点,我们会发现这样的系统中独立的个体在一组适当的规则下运行,并不需要设计每个个体临时变更的方案,而每个个体只需要知道目标和大致的状况,他们完全可以利用自己的聪明才智来决定自己的行为。

      2)缩短了反馈通道

      敏捷过程有效运作的另一个原因是,它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候,便需要有一种方法在比较短的时间内发展完善。事实上,所有的过程改进都不同程度的使用着戴明循环,以研究问题、测试解决方案、评估结果,进而根据已知的事实来进行改进,这就称之为基于事实的决策模式,我们都知道,这比前端预测的决策方式更加有效。

      3)易于集思广益

      敏捷过程能有效应用的另一个原因在于,它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候,总有某些人员知道问题所在,但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸,事后分析出了各种原因,但这种调查也提供给我们一个惊人的事实,就是部分工程师早就意识到这些潜在问题,却无法说服他人重视这个担忧。对这些事实的深入思考,促使我们研究我们应该采取何种管理系统,使前线工作人员的经验、观点及担忧得到充分的重视呢?

    对敏捷开发的误解

      误解一:敏捷对人的要求很高

      很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

      从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

      敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

      误解二:敏捷没有文档,也不做设计

      这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

      至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

      误解三:敏捷好,其他方法不好

      有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

      从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。

      因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

      误解四:敏捷就是XP(极限编程),就是Scrum

      XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

      即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

      误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

      没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

      同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。


    展开全文
  • 什么是敏捷开发流程

    千次阅读 2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....

    这里是修真院后端小课堂,每篇分享文从

    【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

    八个方面深度解析后端知识/技能,本篇分享的是:

    【什么是敏捷开发流程 】

    这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
    一. 先说一下官方的定义:

    敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

    5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

    二. 然后是我理解的敏捷

    主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

    需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
    主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

    Story划分(产品+UI+开发)
    产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

    人员划分(leader+开发)
    主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

    方案设计(数据库设计文档、接口设计文档、方案设计文档)
    先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
    然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
    最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

    方案评审(所有人员)
    对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

    禅道任务拆分(开发人员)
    方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

    开发(项目日报+工作日报+进度邮件)
    每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

    端对端(接口)测试(开发人员)
    前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

    压力测试+集成测试
    系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

    Demo
    对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

    这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

     

     



     

    【欢迎加IT交流群565763832与大家一起讨论交流】

    展开全文
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 【互联网公司的“敏捷开发流程是怎么样的,每个职位的角色和分工是什么?】 前言================================================ 1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。 第一...
  • 敏捷开发步骤简述

    千次阅读 2018-11-25 23:45:14
    1.用户需求分析转化为产品BACKLOG 这个部分的内容由PM具体负责,主要的工作内容如下: 用户调研、需求分析,确定产品迭代功能,出具产品BACKLOG。...参与排序的条目一般足够接近半年的开发工作...
  • 敏捷开发流程介绍

    2018-09-07 16:30:27
    今天给大家分享一下,修真院官网Java任务10,深度思考中的知识点————什么是敏捷开发流程? 1.背景介绍 为什么需要敏捷开发? 在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了...
  • 简述敏捷开发中的测试流程

    千次阅读 2019-01-21 18:11:10
    敏捷sprint进程中测试任务的简要描述:   需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行中产生的扯皮...
  • 敏捷开发 迭代流程

    千次阅读 2011-06-12 07:46:00
    现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,就是迭代的开发,到最后敏捷变成了混乱,然后开始说敏捷的不好等等。其实他们都只是表面上的敏捷,而没有真正的理解...
  • SCRUM敏捷开发视频教程

    万人学习 2019-06-24 13:20:54
    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 产品研发敏捷统一过程2.0

    千人学习 2019-06-24 13:18:07
    产品研发敏捷统一过程2.0视频教程,该课程介绍一种极轻量级又能涵盖整个产品研发生命周期的敏捷开发框架,包含了产品创新、敏捷需求建模与分析(QUML)、精益创业、Scrum等体系,全程无缝连接。 讲师介绍:陈勇,...
  • 敏捷开发与瀑布式开发的区别

    千次阅读 2019-03-04 11:30:30
    敏捷方法与传统方法的区别与联系 首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,... 其次,说一下敏捷开发的方式流程,敏捷...
  • 你真的知道敏捷和迭代吗?

    万次阅读 2017-07-11 09:06:22
    在这敏捷开发横行的时代中,人人都在谈敏捷,人人都在谈迭代,似乎大家好像都尝到了敏捷带来的甜头,记得有一次跟朋友吃饭,说他们现在的项目用敏捷开发,每个迭代都能看到不断完善的产品,非常有成就感,客户的满意...
  • 打造敏捷团队

    万人学习 2019-11-05 13:41:19
    敏捷门派很多,什么才是敏捷呢?敏捷过于理想,无法在中国落地?如何才能让敏捷真正发挥实效呢?开发人员过于“闷骚”,敏捷不起来,咋办呢?本课程将会为你逐一拆解!
  • 软件测试干货——敏捷测试流程

    万次阅读 2017-08-29 16:42:47
    千锋教育软件测试:敏捷测试流程 千锋教育的王晓军老师在对敏捷测试做出介绍的时候与现行的瀑布式测试流程做出过对比: 对于一个三个月的项目说,产品把需求分析完了给开发,然后产品就没事儿了;开发开发完成之后...
  • 敏捷开发——SCRUM

    万人学习 2018-10-22 21:38:02
    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 原生Android开发实战教程,讲授如何实现在App中发送文字、语音、图片、VoIP、自定义(如红包)等消息,以及如何添加/删除好友、设置/修改头像、创建群组、讨论组、聊天室等基础IM功能。
1 2 3 4 5 ... 20
收藏数 98,467
精华内容 39,386
关键字:

敏捷开发流程