敏捷开发流程总结 - CSDN
  • 本文主要来源于华为软件开发流程,同时根据在创业团队的实践在细节上稍有修改。 需求管理 先了解几个概念: IR(Initial Requirement):原始需求。这种需求来自客户,一般由产品经理/需求经理编写。如果是研发内部...

    本文主要来源于华为软件开发流程,同时根据在创业团队的实践在细节上稍有修改。

    需求管理

    先了解几个概念:

    IR(Initial Requirement):原始需求。这种需求来自客户,一般由产品经理/需求经理编写。如果是研发内部产生的需求,可以不需要有IR。

    SR(System Requirement):系统需求。架构师对IR进行分析以后,结合系统设计,将需求描述成一个个要实现的子系统或者模块,比如:提供用户权限管理系统/模块,要求满足用户、角色、权限管理,满足3A/4A要求。

    AR(Allocation Requirement):分配需求/分解需求。架构师或者高级工程师分析SR,将SR分解成一条条的可以分配给开发人员去实现的需求。注意,AR分解完成的时候,每个AR的预估工作量也应该给出。AR的分解没有非常明确和固定的分解方式,需要根据人员、项目时间要求进行把握,在笔者经历的项目中,通常有以下几个原则:

    • 一个AR的工作量不要超过一轮迭代的单人工作量。比如,如果一轮迭代安排一个月(以22个工作日计算),那么一个AR的工作量不要超过22人/天,不然会出现一个AR需要两轮迭代完成的情况,敏捷禁止在一轮迭代中出现半成品。
    • 一个AR尽量由一名开发人员完成。比如,需要完成用户的增删改查功能,可以分两个AR:

            SR001-AR001:提供用户增删改查Web API。

            SR001-AR002:前端实现用户增删改查功能。

    一个典型的AR可以是下面的格式(xx项目迭代跟踪表.xlsx):

    SR号 AR号 AR描述 迭代周期 设计 开发 测试 是否已交付
    SR001 SR001-AR001 提供用户增删改查接口 迭代一        
    SR001 SR001-AR002 提供用户增删改查操作界面 迭代一        

    CR(Change Requirement):变更需求。项目开发的后阶段,可能因为客户需求变化或者系统实现方案有变化造成需求变更,这种需求属于变更需求,同样需要跟踪。

    迭代开发

    AR是方案设计阶段的出口,也是开发阶段的入口。

    项目经理拿到AR列表以后,需要根据AR之间依赖关系、结合团队一轮迭代可以完成的工作量,对AR进行分配和排期。

    这里根据具体公司组织架构,分配方式略有不同,通常,项目经理要列出一轮迭代需要完成的AR列表,根据模块划分将AR分给开发组长,由开发组长来分配给团队内具体的开发人员,分配好后,填写上面的跟踪表。

    迭代过程要包含基本的质量控制流程,以笔者经历的项目为例,如果一轮迭代安排一个月时间(22个工作日),那么大致将迭代内各阶段时间安排如下:

    1.设计串讲:1天 。

      参与人员:设计、开发、测试,

      入口条件:设计文档。

      出口条件:设计、开发、测试对需求及实现方案理解达成一致。

      任务:给开发、测试串讲AR实现总体方案,这个流程主要针对方案设计与开发人员由不同人完成的团队,小团队中不一定需要,可把时间留给其他流程。

    2.开发详细设计:3天

       参与人员:开发。

        入口条件:设计文档,开发与设计对需求及实现方案理解达成一致。

        出口条件:模块数据流向图或者接口调用流程图,总之要能体现代码层面的设计思路。

        任务:这一阶段要根据高级工程师设计的总体方案,进行接口级别的设计,可以直接指导编码实现,时间可以根据复杂程度做      适当调整,不一定要安排满3天。

    3.开发反串讲:1天

        参与人员:开发、设计

        入口条件:模块数据流向图或者接口调用流程图。

        出口条件:设计、开发对代码设计理解一致。

        任务:开发给设计讲解自己的代码设计,设计提出问题及建议,防止实现与设计不一致。

    4.编写测试用例:2天

        参与人员:开发、测试

        入口条件:开发、测试

        出口条件:测试用例

        任务:编写测试用例,有的团队直接由测试完成,有的会让开发编写,可以根据实际情况安排,重要的是双方达成一致理解。

    5.编码:6天

        参与人员:开发

        入口条件:详细设计(指的是开发自己完成的代码层面的设计)

        出口条件:代码

        任务:根据设计完成编码工作

    6.code review:2天

        参与人员:开发人员、高级工程师或者模块owner。

        入口条件:编码已完成

        出口条件:review意见及修正

        任务:完成code review,并修改review comments。

    7.开发自测:3天

        参与人员:开发

        入口条件:用例已完成;代码已完成走读。

        出口条件:用例自测通过。

        任务:开发根据测试用例进行自测

    8.联调:3天

        参与人员:有调用关系的模块开发人员

        入口条件:自测已完成

        出口条件:联调通过,能完成集成验证。

        任务:模块间联调完成

    9.产品验收:1天

        参与人员:开发、产品、测试

        入口条件:已完成联调

        出口条件:产品验收确认书

        任务:开发给产品演示本AR开发的成品,产品检查是否与产品设计一致,如有不一致的地方要提出,如果时间够,就修改,        否则作为下一轮迭代的补充需求完成。

    迭代回顾

    持续改进是敏捷开发的一个重要需求,敏捷团队在一轮迭代完成以后应进行一次回顾,迭代回顾有以下原则:

    1. 只用于找出改进措施,不用于表扬和批评,建议考评负责人不参与。
    2. 迭代回顾会议引导人只做引导,杜绝一言堂,要让项目成员畅所欲言。
    3. 从亮点和待改进点两个角度提出问题,包含开发流程的各个环节,不限于开发人员。
    4. 每一项待改进点要有责任人,以及闭环日期。

    一个典型的迭代回顾记录表参考如下:

      亮点 待改进点 改进措施 责任人 完成日期
    管理 1.xxx
    2.xxx
    1.xxx
    2.xxx
    1.xxx
    2.xxx
       
    开发技能          
    测试          
    产品          

      

           

     

    展开全文
  • 敏捷开发实践总结

    2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
    敏捷开发实践总结

    前言
    敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

    什么叫敏捷开发?
    敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

    对概念的理解:
    以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
    迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    敏捷开发的4句宣言
    1,个体与交互 胜过 过程与工具
    2,可以工作的软件 胜过 面面俱到的文挡
    3,客户协作 胜过 合同谈判
    4,响应变化 胜过 遵循计划

    我对这4句宣言的理解:
    产品结果大于形式,先把产品做出来,然后再整理出完善的文档
    在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

    为什么要使用敏捷开发模式?
    敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

    scrum流程图:


    scrum 开发中的三种角色:
    1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
    2,scrum master:scrum的推动者,掌握大节奏的人。
    3,team:一般由多个developer组成,开发的主力。

    scrum 开发中的三大神器
    1,production backlog(产品待办事项列表)
    2,print backblog(详细任务列表)
    3,sprint burn down(计划走向和实际走向组成燃尽图)

    scrum 开发中的四个会议:
    1,sprint计划会(理解需要做什么,然后讨论怎么做)
    2,每日站会(昨天做了什么,今天打算做什么)
    3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
    4, sprint回顾会(讨论哪里完成好,哪里需要改进)

    SCRUM敏捷开发流程是什么?

    1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
    3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
    4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
    5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
    6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
    7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
    8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
    9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
    10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

    下面是crum开发流程中的一些场景图:
    上图是一个 Product Backlog 的示例,产品需求列表

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

    上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

    作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
    1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
    2,及时是敏捷开发,也要尽可能的有详细的需求
    3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
    4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
    5,坚决杜绝以下问题的出现:
    需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
    代码质量低劣不停出更新版本,叫快速迭代中;
    不写正规设计文档,叫降低沟通成本和最好的文档是代码;
    领导站身后指挥码农写代码,叫结对编程;
    产品质量不靠设计靠测试的,叫测试驱动研发;


    参考:


    展开全文
  • 敏捷开发方法总结

    2018-10-23 10:10:39
    敏捷开发方法 极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快 水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论 并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一...

    在备战软考做题的过程中,发现敏捷软件开发方法考的还算比较多,而自己也一直没弄明白!

    敏捷开发方法

    极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快
    水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论
    并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一次的迭代成为一个冲刺,并按需求的优先级别来实现产品,有多个自治组织和自治小组并行的递增来实现产品。
    自适应软件开发  

     

     

     

    展开全文
  • 今天,有渔老师就来讲下我在团队中使用的版本管理发布流程。 一、软件 1、版本命名规范 软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本...

    版本管理是非常重要的,但很多公司或者程序员根本对这个版本管理毫无概念。今天,有渔老师就来讲下我在团队中使用的版本管理发布流程。

    一、软件

    1、版本命名规范

    软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。例如:1.1.1.051021_beta。

    敏捷开发系列-1:版本管理发布流程

    2、版本号修改规则

    ⑴ 主版本号(1)

    当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

    ⑵ 子版本号(1)

    相对于主版本号而言,子版本号升级对应的是软件功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

    ⑶ 阶段版本号(1)

    一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

    ⑷ 日期版本号(051021)

    用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

    ⑸ 希腊字母版本号(beta)

    此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

    3、软件版本阶段说明

    ⑴ Base:

    此版本表示该软件仅仅是一个假页面链接,通常包括所有的功能和页面布局,但是页面中的功能都没有做完整的实现,只是做为整体网站的一个基础架构。

    ⑵ α(Alpha)版:内测版。

    软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件开发者 内部交流,或者专业测试人员测试用,一般而言,该版本软件的Bug较多,需要继续修改,是测试版本。测试人员提交Bug经开发人员修改确认之后,发布到测试网址让测试人员测试,此时可将软件版本标注为alpha版。

    ⑶ β(Beta)版:公测版。

    该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI,供专业爱好者大规模测试用。

    ⑷ RC 版:

    是 Release Candidate 的缩写,意思是发布倒计时,候选版本,该版本已经相当成熟了,完成全部功能并清除大部分的BUG,基本上不存在导致错误的BUG,与即将发行的正式版相差无几。

    ⑷ Release 版:

    该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的是符号®。

    4、版本号修改举例说明

    比如版本号为:1.0.0.0321_alpha ,此时为内部测试阶段

    ⑴ 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为:1.0.0.0321_beta ,如当前日期跟上一个版本号的日期不一样,版本号可改为:1.0.0.0322_beta。

    ⑵ 如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版,如1.0.1.0322_beta,日期为发布的当前日期。

    ⑶ 如果对软件进行了一些功能上的改进或增强,进行了一些局部变动的时候要修改次版本号,如:1.1.0.0322_beta(上一级有变动时,下级要归零)。

    ⑷ 当功能模块有较大变动,增加模块或整体架构发生变化时要修改主版本号,如新增加了退款功能,则版本号要改为:2.0.0.0322_beta 。

    ⑸ 紧急情况:如果bug比较紧急可跳过一般流程,由开发人员尽快修复bug,测试确认之后直接发布该版本的beta版。

    5、软件包

    软件名称_版本号,即中间用“下划线”分割。

    二、文档

    1、文件命名规范

    文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀,例如:项目外包平台测试报告1.1.1.051021_beta_b.xls,此文件为项目外包平台的测试报告文档,版本号为:1.1.1.051021_beta。

    敏捷开发系列-1:版本管理发布流程

    如果是同一版本同一阶段的文件修改过两次以上,则在阶段标识后面加以数字标识,每次修改数字加1,项目外包平台测试报告1.1.1.051021_beta_b1.xls。

    当有多人同时提交同一份文件时,可以在阶段标识的后面加入人名或缩写来区别,例如:项目外包平台测试报告 1.1.1.051021_beta_b_LiuQi.xls。

    当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别,例如:项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls。

    2、版本号的阶段标识

    软件的每个版本中包括11个阶段,详细阶段描述如下:

    阶段名称 阶段标识
    需求控制 a
    设计阶段 b
    编码阶段 c
    单元测试 d
    单元测试修改 e
    集成测试 f
    集成测试修改 g
    系统测试 h
    系统测试修改 i
    验收测试 j
    验收测试修改 k

    展开全文
  • 瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...

    瀑布模型

    简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

    一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

    弊端:

    1.接力棒的协作模式带来信息差:瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

    2.难以响应变化瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”


    敏捷开发:

    敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征


    Scrum:

    目的

    1. 适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。
    2. 快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
    3. 我们作出的决定中, 50% 都是错误的。早早失败,早早学习。因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。

      Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错

    流程:

    1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

    2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

    3.有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    4.Sprint Backlog 是由 ST 去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)

    5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

    6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员

    7.当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)

    8.最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中


    极限编程:简称XP

    思想:交流、简单、响应和勇气:加强交流;从简单做起;寻求反馈;勇于实事求是


    敏捷开发的特点

    1)敏捷开发中更加强调沟通,沟通频率可能比以前更高,沟通时间可能会比以前更长,占用更多的个人工作时间,反而可能因此导致实际开发时间起过原来开发出某个功能的时间; 

    2)敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”,使开发人员反而感觉工作量增加了,短时间内会表现出开发效率的下降,而且要求所有开发人员对需求的理解能力也要求更高了,所以很多人会感觉敏捷开发对人员的要求更高,其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。 

    3)快速的迭代使重构工作量增加,会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识,不仅会误以为影响了工作效率,而且会使程序员很受伤,因为他们认为是在不停地返工。 

    4)信息的透明性要求较多的数据收集,敏捷成熟度越高,收集的信息就越多,收集这些数据会占用一定的精力,如果不能够正确的理解这些数据的价值,会让程序员感觉浪费了很多时间在做无用功,反而降低了开发效率。 


    敏捷开发的流程:

    需求评审:

    (1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

    (2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

    (3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

    (4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

    (5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。


    敏捷开发的思想

    1)拥抱变化:各种因素都会影响计划的执行,所以计划要短,及时调整才能响应一切变化导致的计划的不可行性,避免走弯路。 

    2)快速响应:市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划

    3)快速将功能推向市场变现:迅速占领市场更显得尤其重要,这是在向时间要效益。比如做个用户系统,按照程序员的想法,一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完,而如果按功能逐版本开发而不是一次开发完成,而是放在不同的版本里,可能需要更多天数,因为里面会有重构、修改界面等,但是应用可以在第3天就上线。争取了15天上市时间,有哪个系统因为没有验证码在上线后第3天就就被恶意注册?有几个用户会在6天后就忘记密码?有几个人会在9天后就修改密码?有几个人会因为登录频繁因为没有记住密码功能而不在使用?,讲到这里,那位朋友想起他们在上一个版本中的一个功能,如果这个功能按照敏捷的方式开发,可以早3个月推向市场,每个月有上千万的收(上线后的效果统计数据),这才是敏捷真正的价值所在。 

    4)做最值得做的事:什么事最值得做,什么事就优先级最高,也就是ROI最高,ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标,非常复杂的综合指标,它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关,需要全方位评估。


    敏捷开发的误区

    1)敏捷开发不是用来管理开发人员的,不是用来提高开发人员的工作效率的,而是企业全面提升团队绩效的方法

    2)瀑布开发模型是以文档为驱动的,把需求文档写出来后,根据文档进行开发的,而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。 

    3)在敏捷开发中每次迭代都被成为一个sprint,中文意为“冲刺”,可见其速度与效率

    4)尽管对敏捷开发的变通运用,可以带来巨大的效益,但现实情况是,多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中,在经历阶跃变化前,交付能力可能还会下降,当经历这个转变后,才开始获得交付能力的提升。

    5)当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时,存在一个显著的风险,即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情,却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展,同时执行业务最好的方式也在不断转变。因此,执行一个大爆炸式的“敏捷”转型后,想当然地认为进一步的改进不再必要,是一个错误认识。

    6)没有MRD,如何管理好需求?使用story模式来管理需求,将庞大的MRD划分为一个个可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了可节省大量的需求评审时间。

    7)项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。

    8)敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”,  “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

    客观因素\最适用方式敏捷 (Agile)计划驱动 (Plan-driven)形式化的开发方法 (Formal Method)
    产品可靠性要求不高, 容忍经常出错必须有较高可靠性有极高的可靠性和质量要求
    需求变化经常变化不经常变化固定的需求,需求可以建模
    团队人员数量不多较多不多
    人员经验有资深程序员带队以中层技术人员为主资深专家
    公司文化鼓励变化, 行业充满变数崇尚秩序, 按时交付精益求精
    实际的例子写一个微博网站;开发下一版本的办公软件; 给商业用户开发软件开发底层正则表达式解析模块; 
    科学计算; 复杂系统的核心组件
    用错方式的后果用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。用敏捷方法,  商业用户未必受得了两周一次更新的频率。敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

    专有名词:

    PB: Product Backlog , 即按优先顺序排列的一个产品需求列表,只能有一个产品backlog

    poProduct Owner产品负责人

    Sprint Backlog有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    sprint backlog和Product Backlog的关系


    每个矩形都表示一个故事,按重要性排序。最
    重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点
    估算的时间长短)。

    sprint每次迭代都被成为一个sprint,中文意为“冲刺”

    story:翻译是故事,本意是产品的功能,backlog中包含了许多story,故事中包含了如下字段

    1、id

    2、name,也即功能名

    3、重要性,越高越重要

    4、初始估算,该故事所需工作量,单位是故事点,3个人需要4天时间,就是12故事点

    5、如何做演示,测试规范

    6、注解

    例如:



    注意点:

    1、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品

    2、Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

    3、sprint计划会议:

    内容:

    (1)制定Sprint目标

    (2)团队成员名单

    (3)Sprint backlog(Sprint中包括的故事列表)

    (4)确定sprint 演示日期

    如何做:

    创建索引卡,放到墙上,这种用户体验比计算机和投影仪好得多。


    每个故事下面有多个任务,任务只会存在于故事下面,而不会存在于product sprint中


    4、们已经完成了 sprint 计划会议,应该创建 sprint backlog 了。它应该在 sprint 计划会议之后,第一次每日例会之前完成,这样规划:没做的,正在做的,已经做的,和燃尽图


    经过每日scrum后变成这样:


    最后变成这样:


    对于燃尽图:


    5、每日例会,时间15分钟,每个人都会一边描述昨天已经做的事情和今天要做的事情,一边移动任务板上对应的即时贴,如果他讲的是一个未经计划的条目,那他就新写一张即时贴贴到板上。如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉。

    如果有人不知道今天干什么,解决方法

    (1)请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说,“我们已经过了一遍任务板,你们现在对今天要做的事情有想法了么?”。希望他们有点儿概念了。

    (2)如果他们还不知道该干什么,我会考虑他们是不是可以去跟其他人结对编程。

    (3)从任务板右下角的“Next”区域中拿出一两个故事,放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声,你已经把一些条目加进了 sprint

    6、对于大部分的团队sprint长度为三周,一个sprint包含10个故事左右

    7、对于故事的任务量估算需要每个成员都参与,每个故事的估算,需要每人给出一个故事点,如果两人故事点相差太大,要讨论为什么,直到把所有工作估算完

    8、Sprint 演示(有人也叫它 sprint 回顾)是 Scrum 中很重要的一环,且所有的 sprint 都结束于演示

    9、Scrum 注重的是管理和组织实践,而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题,可以互为补充,相得益彰

    10、测试驱动开发(TDD):测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续

    11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。

    12、多项目一起进行,那么两个项目的sprint应该是同步的


    同步进行的 sprint 有如下优点:
    可以利用 sprint 之间的时间来重新组织团队!如果各个sprint 重叠的话,要想重新组织团队,就必须打断至少一个团队的 sprint 进程。
    所有团队都可以在一个 sprint 中向同一个目标努力,他们可以有更好的协作。
    更小的管理压力,即更少的 sprint 计划会议、sprint 演示和发布

    13、团队构建:




    参考资料:

    1、https://blog.csdn.net/nocky/article/details/51236848

    2、https://blog.csdn.net/xinxing__8185/article/details/46708439

    3、https://blog.csdn.net/baynkbtg/article/details/52402727

    4、https://blog.csdn.net/liyangbing315/article/details/5387129

    5、https://blog.csdn.net/ostrichmyself/article/details/5375223

    6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html

    7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096

    8、https://www.zhihu.com/question/19638322

    9、scrum and xp chinese version.pdf


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

    2015-12-14 16:36:10
    敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。敏捷开发宣言——个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到的文档客户合作 ...
  • 什么是敏捷开发流程

    2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....
  • 项目组学习、实践、摸索敏捷开发模式已经近两个月了。这里对两个月来的成果作一次总结。首先是关于敏捷开发的核心思想。我理解的敏捷开发的核心思想,简而言之,就是八个字:“化整为零,逼近极限”。敏捷开发的世界...
1 2 3 4 5 ... 20
收藏数 34,954
精华内容 13,981
关键字:

敏捷开发流程总结