2018-12-25 09:56:21 weixin_44118769 阅读数 24
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13667 人正在学习 去看看 张传波

什么是敏捷开发?

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

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

在这里插入图片描述

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

什么是迭代?

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

关于Scrum和XP

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

什么是Scrum?

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

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

【Scrum开发流程中的三大角色】

产品负责人(Product Owner)

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

什么是Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

如何进行Scrum开发?

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

2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

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

4、Sprint Backlog是由Scrum Team去完成的,每个成员根据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的产品需求中;在这里插入图片描述在这里插入图片描述

2016-02-18 22:28:13 wu__di 阅读数 2417
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13667 人正在学习 去看看 张传波

     前两天,有群里的朋友在管理团队开发过程中有一些敏捷方面的疑问,类似如何评估工作量、如何高效的进行早会等问题。今天开一篇敏捷开发相关的文章,说说我对敏捷的理解和实践。

     Scrum 是什么?

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

     接下来我们以实际的项目为例,详细阐述敏捷开发的运用。

1.首先,项目开展之前,项目经理同产品部门达成一致,明确产品的形态,功能等,项目经理输出backlog,针对本次迭代,列出需求列表,并进行优先级排列。

2.

(1)backlog输出后组织开发人员进行本次迭代会议,会议上向所有开发人员通报本次迭代的任务,时间点。

(2)根据本轮迭代的需求按照story的优先级,组织大家进行任务的认领。此时有两种方式,一种是项目经理根据每个开发人员的特点指定任务,另一种是让大家自己根据兴趣认领。

(3)第三步与第二步其实是并列的,安排story的时候需要评估工作量。工作量的评估也有两种方式,一种是大家举手表决,比如对于story A,三个人给出的工作量是4天,另外两人给出的5天和3天,这个时候就需要最低和最高的给出具体的原因分析,最后取合理值。另外一种是个人认领了相应的story,这时候可以给出工作量,或者在任务分配后,预留一段时间,会后大家反馈给项目经理。

      注意:工作量的评估不单单包括开发的过程,还包括前期的分析设计,自测以及测试部的签收等,要预留出时间,以免工作量评估与时间时间相差悬殊。

(4)迭代会议完成后,项目经理在确定完工作量后,将backlog归档,后期按照这个结果进行每天的项目进度跟踪。

(5)正式迭代开始前,所有的story都需要上状态墙,状态墙分为以下几个部分:初始化、分析、设计、编码、自测、BA验收、测试,最初story都走到初始化阶段。

(6)迭代开始,每天早上进行站立会议,时间尽量缩短,每人不超过2分钟,先描述自己昨天干了什么工作,今天准备干什么,同时将相应的story移到对应的状态。

(7)本轮迭代结束,项目经理召开迭代总结会议,针对本次迭代的情况,进行总结。主要包括以下几个方面:迭代是否符合预期,有没有延期等。然后组织大家针对本次迭代过程有哪些好的方面和不好的方面,每人分别写几条。项目经理进行归类,挑选出公认的观点,进行总结,同时督促大家在下一轮迭代过程中发扬上次的优点,避免上次的缺点。

        以上就是敏捷开发的全部过程。在实践的过程中,要根据项目本身的情况,如果团队人员较多,可以划分出来,比如安卓和iOS,还可以按业务再细分,每次早会时间控制在15分钟以内,提高效率。此外,backlog确定后,迭代过程中不要插入其他需求,破坏敏捷的完整性,新需求放到下次迭代。

        欢迎大家添加我的微信,有任何问题都可以一起讨论,不限于安卓,iOS,后台,项目管理,创业等。

 

2019-01-07 22:16:56 SystemEngineeringLab 阅读数 67
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13667 人正在学习 去看看 张传波

更多请关注微信公众号 SystemEngineeringLab
SystemEngineeringLab

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Scrum是一种敏捷过程框架,不同于其他敏捷开发方法,Scrum不仅仅适用于软件开发领域。

1. Srum 的目标

Deliver the highest business value in the shorttest time

Scrum的目标是“交付最高的商业价值,通过尽量短的时间”。用英文表达可能更准确一些,中文的语义比较容易混淆。Scrum的目标并不是“在最短的时间内交付最高的商业价值”,它强调的不是最短的时间,而是价值。我们关注的是如何在交付最高价值的前提下花费更少的时间。

2. Scrum 框架的组成(3-3-5-5 模型)

3 个工件

Product Backlog
Sprint Backlog
Product Increment

3 个角色

Product Owner
Scrum Master
Development Team

5 个价值观

勇气 专注 承诺 尊重 开放

5 个事件

Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective

2.1 价值观

勇气:面对难题团队成员都有勇气做正确的事情和工作
专注: 团队成员要专注于冲刺要完成的工作以及团队目标
承诺: 团队成员对完成Sprint目标做出承诺
尊重:团队成员之间都尊重对方是有能力的、独立的人
开放:Scrum团队以及利益相关者对所有的工作以及完成工作所面临的挑战的开放性一致认同。

2.2 角色


Scrum核心框架包含三个角色,即PO、SM、DevTeam。与传统的开发方法不同,Scrum的研发团队不再有细分的例如系统架构师、后端工程师、前端工程师、UI工程师等角色,而是将整个开发团队统一在了“Development Team”这一Scrum角色下。以上三个角色构成了 “Scrum Team”。

Product Owner

关键职责

  1. 为Product Backlog负责
  2. 为投资回报率负责
    关键属性:
  3. 是利益相关者和客户的代表
  4. 只能由一个人担任
  5. 有绝对的决策权
  6. 随时能够被团队找到
  7. 决定产品发布日期和内容
  8. 不能兼任Scrum Master
  9. 根据业务价值和重要性为PBI排序
  10. 能够决定Sprint是否取消

Scrum Master

职责

  1. 促进Scrum的进行,为开发团队移除障碍
    特征:
  2. 没有权利
  3. 服务型领导

Development Team

职责
DevTeam的职责就是实现Sprint目标,在每个Sprint结束交付可潜在发布的产品增量。
特征:

  1. 自组织
  2. 跨职能:团队是跨职能的,具备交付产品所需要的所有能力
  3. 同地协作
  4. T型人才,成员具备“一专多通”的特点
  5. 没有头衔,大家都是平等的团队成员
  6. 开发团队的成员必须是全职参与
  7. 人数范围3-9人:人数不宜过多或过少。过少的团队无法具备跨职能的要求,过多的团队降低沟通效率
  8. 没有子团队:团队是平级团队,子团队增加了沟通的成本

2.3 工件

产品清单 - Product Backlog

Product Backlog是已排序的产品需求列表,它定义了最终要交付什么(What)。

Product Owner 对Product Backlog负责,其有权决定产品清单的内容,例如哪些需要纳入产品清单、哪些需要修改、哪些需要删除、哪些PBI(Product Backlog Item)优先级需要调整。大多数的PBI对客户有实际的业务价值,有些可能针对客户来说没有直接的业务价值。原则上PO认为PBI对整个产品的交付是有价值的,那么它也可以放入PBL.
PBI最常见的表述形式是用户故事,但这不是绝对的。用户故事本身不是Scrum框架的一部分,Scrum并没有要求PBI的表现形式,用户可以使用用户故事、用例或其他有意义的格式均可。
好的Product Backlog遵循 DEEP 原则

Detailed appropriately - 详略得当

  1. PBI的表述要详略得当,近期要做的PBI要足够详细,以便团队能够清晰的认识需求。同时,PBI的粒度要足够小,能够放到一个冲刺中执行。
  2. 越靠近PBL顶端的PBI要越详细且粒度越小,越靠近底部的PBI粒度越大。

Emergent - 涌现式的
产品清单是动态的,随着对产品认识的深入,以及产品内外部环境的变化,已有的PBI可能会被修改、废弃,新的PBI会被加入到产品清单,因此,PBL是一个会被持续更新动态需求池。

Estimated - 已估算的

Prioritized - 已排序的

Sprint Backlog

SBL是在当前冲刺中开发团队需要完成的工作任务列表,有点像传统开发方法中的WBS,这是DevTeam对实现PBI所做出的承诺。在冲刺计划会议中,DevTeam要对当前迭代所选择的PBI进行任务拆解,细化为具体的工作任务,足以支撑实现这些PBIs。
Spring Backlog的形式有多样,可以采用看板、电子表格或专门的在线系统进行记录和追踪。同时,拆分后的任务和PBI的对应关系也要一同记录

产品增量 - Product Increment

Potentially Shippable Increment,PSI
冲刺中所完成的所有的PBI的总和,在冲刺结束时作为产品增量交付。增量是稳定的、可工作的产品组成部分。冲刺中没有完成的部分不纳入增量。

2.4 事件

冲刺 - Sprint

Spring的目标是完成可潜在可交付的产品增量

  1. Scrum的核心,也是Scrum开发方法中的基本单元
  2. 固定的时间盒
  3. Sprint是一个容器,以冲刺计划开始,以冲刺评审和冲刺回顾结束

冲刺计划 - Sprint Planning

  1. 确定当前冲刺所要完成的工作范围
  2. 从Product Backlog中选择当前冲刺需要完成的PBI
  3. 确定Sprint Backlog,以支撑所选的PBIs
  4. 以两周的冲刺为例,建议会议时间为4小时

每日站会 - Daily Scrum

  1. 开发团队成员必须到场,PO 和SM可选参加
  2. 欢迎其他人参加每日站会,但只允许开发团队成员发言
    • 每天同一时间、同一地点
    • 准时开始,即使有开发团队成员缺席
    • 控制在15分钟以内
  3. 会议模式基于三个问题:
    • 昨天完成了什么
    • 今天准备完成什么
    • 遇到了什么障碍阻碍了自己或团队达成冲刺目标

冲刺评审 - Sprint Review

评审的目的并不在于评价已完成产品增量的好坏,更不是在没有达到既定要求时的批判和追责。评审的本质在于通过现场的交流和演示,获得利益相关者对产品增量的反馈!反馈!反馈!
主要内容:

  1. 审视已经完成的工作以及已经计划但是没有完成的工作
  2. 向利益相关者展示已经完成的工作(Demo)
  3. 与利益相关者协作,进一步明确后续要做的工作

冲刺回顾 - Sprint Retrospective

回顾会议的精髓在于检视和调整,以期持续改进:

  1. 回顾已经过去的冲刺
  2. 识别持续改进的行动项并达成一致
    典型的会议内容:
  3. 三个主要问题:
    • 在当前冲刺中,哪些做的好?
    • 在当前冲刺中,哪些做的不好?
    • 为了提高生产力,在下一个冲刺中哪些需要改进?
  4. 以两周的冲刺为例,建议时间为一个半小时
  5. 回顾会议由SM负责推进

Scrum工作流

Scrum的工作流以Sprint为核心,通过迭代和增量的方式逐步完成最终产品的交付。

  1. 产品需求被汇总到Product Backlog,PO依据业务价值、重要性等对PBI进行排序。
  2. 冲刺会议标志着Sprint的正式开始,团队对输入的PBL进行选择,确定本次冲刺所需要完成的PBI。DevTeam基于所确定的PBI进行任务拆分,形成Sprint Backlog。
  3. DevTeam执行开发过程,交付潜在可发布的产品增量。

讨论

Scrum不是具体的敏捷方法,它通过价值观、角色、工件和事件等要为我们搭建了一个骨架,但骨架内填充的内容就需要具体情况具体分析了。

同其他敏捷开发方法不同的是Scrum更具有普适性,它不仅仅适用于软件开发领域。
本文主要是对Scrum框架的核心元素进行了总结和记录,理论看戏去简单,但落地Scrum却不容易,尤其是结合不同行业的工程实践更加导致Scrum落地的复杂性,而这也恰恰是Scrum实践者所需要攻坚的问题。

写在最后

这已经是关于敏捷的第二篇博文了,基本上对敏捷和Scrum做了基本的介绍,后续的博文我们更关注如何在汽车行业中实施敏捷。

2016-08-12 10:56:54 Hampton_Chen 阅读数 2620
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13667 人正在学习 去看看 张传波
 最近实习的公司采用的是敏捷开发Scrum模式,在经历敏捷开发培训后,写写一些自己学到的东西。

一、什么是敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。
除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。
敏捷开发现已成为绝大多数IT企业采用的项目管理方法。
下图为美国IT企业主要采用的项目管理方法学2015年调查报告。

这里写图片描述

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
敏捷精神(The spirit of agile):**透明、沟通、协作**

二、什么是Scrum

  • Scrum 是一个框架,在这个框架中人们可以解决复杂的自适应问题,同时也能 高效并有创造性地交付尽可能高价值的产品。
  • Scrum 是:轻量级的、容易理解的 、难以精通的
  • Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum
    能使产品管理和开发实践的相对功效(relative efficacy) 显现出来, 以便进行改进。
  • Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的, 对Scrum
    的成功实施和运用都至关重要。
  • Scrum 基于经验型流程控制理论, 或者称为经验主义。经验主义主张知识源于经验, 而决策基于已知的事物。Scrum
    采用迭代增量式的方法来优化可预测性和管理风险。
  • 透明性、检视、调整是经验型流程的三大支柱,支撑起每个经验型控制流程的实施。

三、Scrum组成人员

这里写图片描述
Product Owner –产品负责人(PO/PM)
职责

  • ROI-产品负责人最大的职责是为产品的投入产出比(ROI)负责,即最大化团队的投入产出比。在Scrum当中,由于Sprint是时间盒(即时间是固定的),且成本(软件开发中人力成本是最大的成本,其他忽略不计)也是固定的,那么最大化投入产出比就是如何做出最有价值的产品增量。
  • 创建产品愿景(Vision)
  • 创建与维护产品 (Mange Prod/Sprint Backlog)
  • 主持产品Backlog优化会(增加、删除、修改或细化用户故事,并根据需要进行排序)(Mange Prod/Sprint Backlog)
  • 协调干系人与开发团队之间的沟通 (Communicate)
  • 参加团队的Scrum会议
  • 在Sprint计划会上和团队一起决定当前Sprint的开发内容
  • 接受或拒绝团队的产品增量 (PO Review-Decisive)
  • 决定何时发布 – 需要团队的承诺 (Decisive)
  • 有空解答团队问题 (Available)

Scrum Master
职责

  • Scrum权威(Role model of scrum value)
    ScrumMaster是团队中最熟悉和了解Scrum框架的,并可以根据实际情况对团队进行指导。
  • 辅导团队和产品负责人(Coach/Facilitation)
    如果产品负责人或团队不知道该怎么办,ScrumMaster需要提供相应的辅导、培训或支持。
  • 保护团队 (Project Team)
    在一个Sprint中,ScrumMaster要保护团队不受打扰,可以专注于Sprint目标和承诺。
  • 移除障碍 (Remove Impediment)
    ScrumMaster要善于发现障碍,并可以帮助团队移除障碍,包含但不限于个人障碍,团队障碍以及组织级的障碍。
  • 变革大师 (Agent of change)
    ScrumMaster不仅要在团队内实行Scrum,还要能够影响并促进组织或整个公司内的变革。
  • No Authority /Servant Leader

Dev Team-开发团队
开发团队在Sprint中主要负责以下工作:

  • 每日检视与调整 – 每天开发团队成员都需要参与每日例会。在会上大家一起检视和调整团队的进展。

  • 产品列表梳理 –
    每个Sprint中团队都要花一些时间来为下一个迭代做准备工作(即产品列表梳理活动),包括产品列表条目的创建、细化、估算、排序等工作。每个Sprint最多分配10%的时间来协助产品负责人完成这些工作。

  • Sprint计划会 – 在Sprint计划会团队一起决定Sprint内要完成哪些故事,并进行任务分解和估算。检视和调整产品与过程 –
    即参加Sprint评审会(检视调整产品)和Sprint回顾会(检视调整过程)。

四、Scrum流程

这里写图片描述

Artifacts-工件

  • Product Backlog (产品backlog)
  • Sprint Backlog(冲刺/迭代backlog)
  • Increments (产品增量/可交付成果)

Ceremonies-会议

  • Sprint 迭代
  • Planning/Grooming Meeting 计划会议
  • Daily Standup 每日例会
  • Reviewing Meeting 评审会议
  • Retrospective Meeting 回顾会议
2018-03-09 10:37:19 u014378181 阅读数 318
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13667 人正在学习 去看看 张传波

Scrum 使用迭代的开发方式,每一次迭代,都会经历一个“计划-实施-验证-反思”的工程。

Scrum 框架包括3个角色,5个会议,3套工具。

3个角色:

    1、SM:Scrum Master,Scrum 过程管理者,服务于PO、团队和组织。

    2、PO:Product Owner,对产品 Roadmap 和 Backlog 负责,确保产品价值最大化。

    3、Dev Team:架构师、开发人员、测试人员等,负责实现 Sprint 目标。

5个会议:

 WhyWhoWhenWhat/HowHow long
需求澄清会把不清楚的需求梳理清楚,为下面1-2个Sprint准备PO、Dev Team、SMSprint期间

1、拆分Story

2、优先级排序

3、澄清

2小时
计划会把清楚的Product Backlog变成Sprint Backlog,确定Sprint交付增量以及如何完成PO、Dev Team、SM

Sprint开始前

回顾会之后

1、PO讲解Sprint目标及待办列表

2、Team 预测Sprint开发功能

3、Team确定如何完成

2小时
每日站会为了开发活动同步指定下一个24小时Dev Team、SM每天

1、检视昨天

2、计划今天

3、确认和清除障碍

15分钟内
评审会检视,调整PO、Dev Team、SMSprint结束前

1、Demo

2、收集反馈

3、Review DoD(众测)

1小时
回顾会检视、改进Dev Team、SM评审会与计划会之间

1、检视:人、关系、过程、工具

2、成就、困难/挑战、解决方案

3、指定改进计划

1小时

3套工具:

    1、Product Backlog产品功能列表

    2、Sprint Backlog迭代任务

    3、Burn-down Chart燃尽图

        燃尽图能形象的展示当前迭代中剩余工作量和剩余工作时间的变化趋势,是放映项目进展的一个指示器。


Scrum敏捷开发流程

阅读数 2387

Scrum敏捷开发流程的要点

博文 来自: ogreworld1987

Scrum敏捷开发

阅读数 18

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