2018-05-24 11:20:45 runOnWay 阅读数 458
  • SCRUM敏捷开发视频教程

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

    10427 人正在学习 去看看 CSDN讲师
    一、敏捷开发是一种开发方式
    敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发,所以它主要的驱动核心是人,而不是像瀑布模型那样,以文档为核心。
    敏捷开发更注重的人与人之间的沟通、交流。它认为个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划。虽然右项也有价值,但是敏捷开发认为左项具有更大的价值。
   迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样一个周期就是一次迭代的过程,同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
   二、几个重要的名词
   Scrum:是一个橄榄球专业术语,意味并列争球。用了这样一个词在敏捷开发中,可以证明,在整个敏捷开发的过程中,团队中的每一个人都要像橄榄球运动员一样迅速、富有战斗激情,在这种氛围下才会达到敏捷开发快速迭代的要求。
   XP:极限编程,是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的开发方式。它强调在更短的周期内,更早地提供具体、持续的反馈信息;在迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它;依赖于自动测试程序来监控开发进度,并尽可能早地捕获缺陷;依赖于口头交流、测试和源程序进行沟通;倡导持续的演化式设计;依赖于开发团队内部的紧密协作;尽可能达到程序员短期利益和项目长期利益的平衡。

注:Scrum和XP是敏捷开发的两种方式,Scrum偏重过程,XP偏重实践。

    PO:Product Owner,产品负责人。主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
    SM:Scrum Master,流程管理员。主要负责整个Scrum流程在项目中的顺利实施和进行,以及扫清挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
    ST:Scrum Team,开发团队。主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5-10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力。成员可以采用任何工作方式,只要能够完成开发任务。
   PB:Product Backlog,产品需求列表。由PO负责,按优先顺序排列产品需求。
   Sprint:冲刺。指一次迭代,每次迭代的周期大约是一个月。
   INVEST原则:是缩写组成,Independent独立的、Negotiable可协商的、Valuable有价值的、 Estimable可估计的、Small小的、Testable可测试的
   三、Scrum开发
   1.首先由PO,制定PB。
   2.ST根据PB,进行工作量的预估和安排。在工作量预估中,可以使用计划筹码,每个筹码代表着完成一个故事的时间,是一个故事点的倍数,一般有1、2、3、5、8这几个数字。每个人对工作的预估在亮出筹码之后,如果有不同意见,不能折中选平均数,而是要各自说出理由,再重新进行预估。
   3.有了PB列表,就需要通过Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完成的目标,然后将这个Story进行细化,一个优秀的Story要遵循INVEST原则,形成Sprint Backlog,然后再继续细化,争取每个细化的任务能在2天内完成。
   4.在ST完成PM上选出的Sprint Backlog过程中,要进行Daily Scrum Meeting,每次会议要控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报昨天完成的工作和承诺今天要完成的任务,如果遇到问题也可以提出问题,表述结束后,要更新自己的燃尽图。
    5.要做到每日集成,每天都要有一个可成功编译、并且可以演示的版本,这就凸显出了持续集成的重要性。
    6.当一个Story完成,也就是Sprint Backlog被完成,就代表一次Sprint完成,要进行Sprint Review Meeting,PO和客户都要参加,每个ST成员都要展示自己完成的任务。
    7.最后就是Sprint Retrospective Meeting,所有成员轮流发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

   敏捷开发的快速迭代有很明显的优势,但是对团队的要求也更高,尤其是按时完成任务,对自己的承诺负责这点,如果要保重能够按时完成任务,就要在预估工作量上更加严谨,而不是取折中这种方式,每个人要更加坚持自己的立场,只能够因为合理的逻辑做出计划。
2015-09-25 13:48:31 fw0124 阅读数 2173
  • SCRUM敏捷开发视频教程

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

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

什么是敏捷开发?

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

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

为什么说是以人为核心?

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

关于Scrum和XP

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

-----------------------

什么是Scrum?

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

Scrum流程如下图:
  


-----------------------

Scrum 中的角色

  Scrum Master——项目负责人、项目经理

  保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

  Team——开发人员、测试人员、美工设计、DBA等全职能性团队

  团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

  Product Owner——产品负责人、产品经理、运营人员

  从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。

  User——最终用户、运营人员、系统使用人员

  很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。

  Manager——管理层、投资人

  管理层要为 Scrum 团队搭建良好的环境,以确保团队能够出色工作,必要的时候,他们也会与 Scrum Master 一起重新组织结构和指导原则。

  Customer——客户、系统使用人员、运营人员

  客户是为 Scrum 团队提出产品需求的人,她会与组织签订合同,以开发产品。一般来说,这些人是组织中的高级管理人员,负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中,负责批准项目预算的人就是客户。

-----------------------

Scrum 中的三个工件/产出物

  Product Backlog——Backlog 待开发项,积压的任务。

  产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

  Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。

  在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。已定 Product Backlog是Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。

  Sprint燃尽图(Sprint Burn-down Chart)

  Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

  在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

      发布燃尽图(Release Burn-down Chart)。在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

一些其它的术语

  User Story、Task——用户故事、任务

  用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。

  为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

  障碍 Backlog——问题列表,积压的待处理事务。

  列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

-----------------------

通用会议规则

  基本要求

  • 每次会议都要准时开始、准时结束。
  • 每次会议都采取开放形式,所有人都可以参加。

  会前准备

  • 提前邀请所有必须参会的人,让他们有时间准备。
  • 发送带有会议目标和意图的会议纲要。
  • 预订会议所需的全部资源:房间、投影仪、挂图、主持设备,以及此会议需要的其他东西。
  • 会前24小时发送提醒。
  • 准备带有会议规则的挂图。

  会议推进

  • 展开讨论时,会议的推进人必须在场。他不能参与到具体讨论中,但是他需要注意讨论进程,如果讨论参与者失去重点,他还要将讨论带回正规。
  • 推进人展示会议的目标和意图。
  • 有必要时,推进人可以商定由某个撰写会议记录。
  • 推进人可以记录团队的意见,或是教授团队如何自己记录文档;而且推进人可能会在挂图上进行记录,将对话可视化。
  • 推进人会对会议进行收尾,并进行非常简短的回顾。

  会议输出

  • 使用手写或挂图说明来记录文档,给白板和挂图上的内容拍照。
  • 必须传达会议记录和大家对会议结果的明确共同认知。

  让团队坐在一起!

  • 大家都懒的动,尽量让“产品负责人”和“全功能团队”都坐在一起!
  • 互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。
  • 互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。
  • 隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会被打扰到,反之亦然。

-----------------------

团队建设

  • Scrum 团队最佳人数控制在“5~9”人。
  • 全职能性团队:开发组(后台开发、前端开发、测试人员——3~8人)、Scrum Master(项目经理)、产品负责人
  • 兼职团队成员:美工、DBA、运维

----------------------- 

每日立会(Daily Standup Meeting)——建议下班前开始

  会议目的

  • 团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
  • 任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。

  构成部分

  • 任务板、即时贴、马克笔
  • 提示:ScrumMaster 不要站在团队前面或是任务板旁边,不要营造类似于师生教学的气氛。

  基本要求

  • 成员:团队、Scrum Master
  • 无法出席的团队成员要由同伴代表。
  • 持续时间/举办地点:每天15分钟,同样时间,同样地点。
  • 提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”

  会议输出

  • 团队彼此明确知道各自的工作,最新的工作进度图。
  • 得到最新的“障碍 Backlog”
  • 得到最新的“Sprint Backlog”

  会议过程

  • 团队聚在故事板旁边,可以围成环形。
  • 从左边第一个开始,向团队伙伴说明他到现在完成的工作。
  • 然后该成员将任务板上的任务放到正确的列中。
  • 如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
  • 如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
  • 每个团队成员重复步骤2到步骤5。

  每个人三个问题:

  • 上次会议时的任务哪些已经完成?:把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么?
  • 下次会议之前,你计划完成什么任务?:如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——明天做什么?
  • 有什么问题阻碍了你的开发?:如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——今天遇到了什么问题?

  注意事项

  • 不要迟到
  • 不要超出限制时间
  • 不要讨论技术问题
  • 不要转变会议话题
  • 不要在没有准备的情况下参加
  • Scrum Master 不要替团队成员移动任务卡片,不要替团队更新燃尽图。
  • Scrum Master 不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告。
  • 如果不能出席会议,需要通知团队,并找一名代表参加。

-----------------------  

任务板

  • 任务板集合了选择好的 Product Backlog 和 Sprint Backlog,并以可视化方式展示。
  • 任务板只能由团队维护,使用不同颜色的“即时贴”来区分开发人员,或者在“即时贴”写上接受任务的姓名。
  • 尽量使用大白板,也可以使用软件。

  任务板有4列:

  • 选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
  • 待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。
  • 进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。
  • 完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡。

----------------------- 

燃尽图(Burn Down Chart)

  • 跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
  • 团队每天更新燃尽图。
  • 如果燃尽图一直是上升状态,或当 Sprint 进行一段时间之后,Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几,就说明这个 Sprint 中的 Story 过多,要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快,例如 Sprint 刚过半时Y值已经接近0了,则说明这个 Sprint 分配的任务太少,还要多加一些任务进来。在 Sprint 计划会议上,如果团队对即将要做的任务理解和认识不充分,就很可能导致这两种情况的出现。(锻炼团队人员的自我估算时间)
  • 燃尽图要便于团队更新,没必要让它看起来很炫,也不要过于复杂,难以维护。

  Release 燃尽图:记录整个Scurm项目的进度,它的横轴表示这个项目的所有Sprint, 纵轴表示各个Sprint开始前,尚未完成的工作,它的单位可以是个(Story 的数量),人天等。



----------------------- 

Sprint 规划会议——第一部分(上午)

  会议目的

  • 该会议的工作以分析为主,目的是要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西。
  • 产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。

  基本要求

  • 迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
  • 只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

  构成部分:

  • 经过估算和排序的 Product Backlog。
  • 挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
  • 假期计划表、重要人员的详细联系信息。
  • 参会成员:团队成员、Scrum Master、产品负责人

  持续时间:在 Sprint 中,每周该会议占用时间为 60 分钟,在早上召开该会议,这样还有可能在同一天召开 Sprint 规划会议的第二部分。

  会议输出

  • 选择好的 Product Backlog 条目。
  • 各个 Backlog 条目的需求。
  • 各个 Backlog 条目的用户验收测试。

  会议过程

  • 从第一个 Product Backlog 条目(故事)开始。
  • 讨论该 Product Backlog 条目,以深入理解。
  • 分析、明确用户验收测试。
  • 找到非功能性需求(性能、稳定性...)
  • 找到验收条件。
  • 弄清楚需要“完成”到何种水平。
  • 获得 Backlog 条目各个方面的清晰了解。
  • 绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
  • 回到步骤1,选取下一个 Backlog 条目。

  流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。——接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。

  结束流程:

  • 在 Sprint 规划会议第一部分结束前留出 20 分钟。
  • 再次提问——这次要更加严肃、正式:“你们能否完成第一个 Backlog 条目,...第二个,...?”
  • 如果团队认为他们不能再接受更多的 Backlog 条目,那就停下来。
  • 现在是非常重要的一步:送走 Product Owner,除了团队和 Scrum Master 之外的所有人,都得离开。
  • 当其他人都离开后,再询问团队:“说真的——你们相信自己可以完成这个列表?”
  • 希望团队现在能短暂讨论一下,看看他们到底认为自己能完成多少工作。
  • 将结果与 Product Owner 和最终用户沟通。

  注意事项:不要改变 Backlog 条目大小,不要估算任务。

Sprint 规划会议——第二部分(下午)

  会议目的

  • 该会议的工作以设计为主,产品开发团队可以为他们要实现的解决方案完成设计工作,在会议结束后,团队知道如何构建他们在当前 Sprint 中要开发的功能。

  基本要求

  • 只有产品开发团队才能制定解决方案,架构师或其他团队之外的人只是受邀帮助团队。

  构成部分:

  • 能够帮助团队在该 Sprint 中构建解决方案的人,比如厂商或是来自其他团队的人员。
  • 选择好的 Product Backlog 条目。
  • 挂图......

  注意事项:不要估算任务,不要分配任务。

  会议输出

  • 应用设计、架构设计图、相关图表
  • 确保团队知道应该如何完成任务!

  会议过程

  • 从第一个 Backlog 条目开始。
  • 查看挂图,确定对于客户的需求理解正确。
  • 围绕该 Backlog 条目进行设计,并基于下列类似问题:
    • 我们需要编写什么样的接口?
    • 我们需要创建什么样的架构?
    • 我们需要更新哪些表?
    • 我们需要更新或是编写哪些组件?
    • ......

  当团队明确知道自己应该如何开发该功能后,就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟,团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展,将这些任务放在任务板上。

  持续时间:在 Sprint 规划会议第一部分完成后,召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分,在 Sprint 中,每周该会议占用时间为 60 分钟。

估算会议——根据项目情况合并到 Sprint 第二部分会议

  会议目的

  • 要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
  • 团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

  基本要求

  • 只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

  构成部分:

  • Product Owner 根据业务价值排定 Product Backlog 各项顺序。
  • 需要参加的人员:Team、Product Owner、User、Scrum Master

  注意事项:

  • 不要估算工作量大小——只有团队能这么做。
  • Product Owner 不参与估算。

  会议过程

  • Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
  • 团队使用规划扑克来估算 Backlog 条目。
  • 如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
  • 重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

  持续时间:该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周,那么每个 Sprint 举行两次估算会议比较合适。

  会议输出

  • 经过估算的 Product Backlog。
  • 更小的 Backlog 条目。

  扑克牌估算(Planning Poker)

  具体步骤:

  • 每个人各自估算后独立出暗牌,听口令一起开牌。
  • 数值最大者与最小者PK,其他人旁听也可参考。
  • 讨论结束后重新出牌和开牌。
  • 重复上述过程,直到结果比较接近。

  常见问题

  1、为什么任务要分给组而不是个人?

  答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。

  2、为什么不让最后领任务的人自己估算?

  答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

  3、为什么不让师傅估算大家采纳,他不是最厉害吗?

  答:师傅的想法常常是徒弟们理解不了的,比如为什么不留在女儿国而偏偏去西天取经之类的,共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

-----------------------  

Sprint 评审会议(Review Meeting)——根据项目需要举行

  会议目的

  • Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。

  基本要求

  • Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

  构成部分

  • 有可能发布的产品增量,由团队展示。

  会议输出

  • 来自最终用户的反馈。
  • 障碍 Backlog 的输入。
  • 团队 Backlog 的输入。
  • 来自团队的反馈为 Product Backlog 产生输入。

  持续时间:90分钟,在 Sprint 结束时进行。

  会议过程

  • Product Owner 欢迎大家来参加 Sprint 复审会议。
  • Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
  • 产品开发团队展示新功能,并让最终用户尝试新功能。
  • Scrum Master 推进会议进程。
  • 最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

  注意事项:

  • 不要展示不可能发布的产品增量。
  • Scrum Master 不要负责展示结果。
  • 团队不要针对 Product Owner 展示。

-----------------------

Sprint 反思会议(Retrospective Meetin)——根据项目需要举行

      会议目的

  • 该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

  构成部分

  • 参与人员:团队成员、Scrum Master

  基本要求

  • 从过去中学习,指导将来。
  • 改进团队的生产力。

  注意事项

  • 不要让管理层人员参与会议。
  • 不要在团队之外讨论找到的东西。

  会议输出

  • 障碍 Backlog 的输入。
  • 团队 Backlog 的输入。

  持续时间:90分钟,在 Sprint 评审会议结束后几分钟开始。

  会议过程

  • 准备一个写着“过去哪些做的不错?”的挂图。
  • 准备一个写着“哪些应该改进?”的挂图。
  • 绘制一条带有开始和结束日期的时间线。
  • 给每个团队成员发放一叠即时贴。
  • 开始回顾。
  • 做一个安全练习。
  • 收集事实:发放即时贴,用之构成一条时间线。每个团队成员(包括 Scrum Master)在每张即时贴上写上一个重要的事件。
  • “过去哪些做的不错?”:采取收集事实同样的过程,不过这次要把即时贴放在准备好的挂图上。
  • 做一个分隔,以区分“过去哪些做的不错”和接下来要产出的东西。
  • “哪些应该改进?”:像“过去哪些做的不错”那样进行。
  • 现在将即时贴分组:
  • 我们能做什么》团队 Backlog 的输入。
  • 哪些不在我们掌控之内?》障碍 Backlog 的输入。
  • 根据团队成员的意见对两个列表排序。
  • 将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入,并决定到时候要如何处理这些发现的信息。

转载文章,原文链接:
1)http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
2)http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1
3)http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html

2016-11-03 17:37:57 buding_pmp 阅读数 4088
  • SCRUM敏捷开发视频教程

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

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

[摘要]  
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。

  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
  在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
  对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
  并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
  运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
  但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
  一、敏捷开发最少需要维护哪些文档?
  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
  实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
  但文档宜少且精炼,一般情况下建议维护三份文档:
  《产品需求规格说明书》
  也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
  《系统设计说明书》
  开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
  《测试用例和测试报告》
  由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
  二、敏捷开发是否需要系统设计?
  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
  小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
  传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
  三、敏捷开发是否需要项目计划?
  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
  它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
  但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
  四、敏捷开发的迭代周期大概多长?
  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
产品项目里的九个敏捷开发实战经验
  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
  五、敏捷开发为何提倡小版本?小版本有哪些优势?
  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
  1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
  2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
  3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
  六、敏捷开发与重构的关系如何?
  敏捷开发以重构为基础,时时刻刻处于重构过程中;
  七、敏捷开发为何强调团队人员的参与、用户的参与?
  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
  由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
产品项目里的九个敏捷开发实战经验
  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
  “是的,就是这样的”
  “这正是我想要的……”
  “这里需要修改一下……”
  “我的想法是这样的……”
  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
  八、怎么才能评估团队是否已经敏捷了?
  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
  • 团队有共同的愿景,并且对这个愿景充满信心;
  • 团队有明确的阶段目标并且为每个成员所知晓;
  • 团队知晓当前计划:做什么、何时完成、预期效果等;
  • 团队任务是低耦合的,并且紧密协作;
  发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
  九、敏捷开发能缩短项目时间并提高质量吗?
  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
  • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
  • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
  • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
  • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
  以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用

2019-09-29 15:34:43 heibuliuqiu_gk 阅读数 28
  • SCRUM敏捷开发视频教程

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

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

敏捷开发,在百度上这样介绍的:

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

敏捷开发宣言如下:

  • 个人和他们之间的交流胜过了开发过程和工具。
  • 可运行的软件胜过了宽泛的文档。
  • 客户合作胜过了合作谈判。
  • 对变更的良好响应胜过了按部就班地遵循计划。

敏捷原则如下:

  • 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
  • 即使是开发的后期,也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
  • 经常交付可运行的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  • 围绕有积极性的个人构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最富有效果和效率的信息传递方法是面对面交谈。
  • 可运行软件是进度的首要度量标准。
  • 敏捷过程提倡可持续的开发速度。负责人、开发者和用户应该能够长期保持稳定的开发速度。
  • 不断地关注优秀的技能和好的设计会增强敏捷能力。
  • 简单——使不必做的工作最大化的艺术——是必要的。
  • 最好的架构、需求和设计出自于自组织团队。
  • 每隔一定时间,团队会反省如何才能更有效地工作,并相应调整自己的行为。

首先需要明确,敏捷开发不是一个具体的框架或者过程,也不是软件开发的具体方法,而是一种价值观和原则,因此敏捷开发是不可模仿的。每个不同的团队都会在开发软件的工程中根据敏捷开发的价值观和原则去做适合自己团队的决策。

敏捷开发是一个不断迭代的过程,需要具有极强的适应性,简洁性和完整性。敏捷团队也需要是一个高度自主的团队,团队中不会存在“打酱油”这种人,团队中每个人都有极强的个人能力,同时,他们每个人还必须具备良好的沟通合作能力。在做决策时,每个团队都要遵循敏捷开发的价值观和原则,而不是去模仿其他的团队,即:“他们怎么做不重要,重要的是明白他们为什么这么做”。

2017-09-12 21:42:52 dog_eggs 阅读数 423
  • SCRUM敏捷开发视频教程

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

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

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

用于敏捷开发团队的项目管理工具
已经有一些项目管理工具用于敏捷开发,可以用它们来帮助规划,跟踪,分析和整合工作。 这些工具在敏捷开发中扮演的重要的角色,也是知识管理的一种方法。
通常包括:版本控制整合,进度跟踪,工作分配,集成发布和迭代规划,论坛和软件缺陷的报告和跟踪。

敏捷技术
1.测试驱动开发,TDD/Test-Driven Development
2.行为驱动开发,BDD/Behavior-Driven Development
3.Scrum

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