scrum_scrum 工具 - CSDN
scrum 订阅
Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums. [1] 展开全文
Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums. [1]
信息
业务领域
管理软件开发项目以及运行软件维护团队
定    义
是一种迭代式增量软件开发过程
成员组成
主管,产品负责人,开发团队
应    用
敏捷软件开发
外文名
Scrum
包    括
实践和预定义角色的过程骨架
Scrum创始人
Jeff SutherlandJeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务。服役后期,他到斯坦福大学拿下统计学硕士学位,并在美国空军学院教授数学统计 学和概率学。11年军旅生涯结束后,他成为了科罗拉多医学院的教师并获得了博士学位。在诺贝尔化学奖得主莱纳斯·鲍林的赞助下,他以放射学、生物学及预防医学助理教授的身份参与了维生素与癌症研究中心的创立,担任八年国家癌症中心的主要研究员,负责科罗拉多地区所有癌症患者的数据统计和IT方案与研究,整合了国家注册、临床试验、流行病学研究和癌变的超级计算机数学模型。1983年,他进入了一家遍及北美、经营着150家银行的公司,职务为先进系统副总裁及ATM业务部总经理。此后,Sutherland先后担任了11家软件公司的CEO、CTO或者工程副总裁,积累了丰富的软件开发经验。Ken SchwaberKen Schwaber最初的职业也很特别——商船经理。在随后40多年开发生涯的前10年中,他曾经编写过操作系统,搞过嵌入式,为IBM大型机开发系统软件;先后在芝加哥大学、伊利诺伊理工学院、王安公司实验室工作,并逐渐展现出在软件开发方法上的天赋。在CASE工具和结构化方法热门的时候,他自己创办了ADM公司,从事软件开发方法培训服务。期间,公司开发了软件方法自动化工具MATE,用来生成各种软件流程所需的模板、计划等,生意很好。
收起全文
精华内容
参与话题
  • 敏捷开发——SCRUM

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

    2020-01-15 22:21:47
    Scrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是一至四周。在...

    Scrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是一至四周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营,以及几乎我们(作为个体和群体)日常生活中所使用的一切。

    Scrum流程如下图:

    ScrumCN_Scrum_Process_710

     

    Scrum的历史

    • 1986年,竹内弘高和野中郁次郎阐述了一种新的整体性的方法 ,该方法能够提高商业新产品开发的速度和灵活性:
      • 他们将这种新的整体性方法与橄榄球相比较,前者各阶段相互重叠,并且由一个跨职能团队在不同的阶段完成整个过程,而团队“作为一个整体前进,把球传来传去”。
      • 他们对来自汽车,照片机器,计算机和打印机等产业的案例进行了研究。
    • 1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为scrum,在竹内弘高和野中郁次郎的文章中提到的橄榄球术语。
    • 1990年代初,Ken Schwaber在其公司使用了一种方法Advanced Development Methods(先进开发方法),这种方法后来发展为Scrum。
    • 1993,Jeff Sutherland 在Easel公司开发了一种类似的方法,并首次称之为Scrum。
    • 1995年,在奥斯汀举办的OOPSLA ’95上,Jeff Sutherland 和Ken Schwaber联合发表了论文首次提出了Scrum概念。Ken Schwaber和Jeff Sutherland 在接下的几年里合作,将上述的文章,他们的经验,以及业界的最佳实践融合起来,形成我们现在所知的Scrum。
    • 2001年,Ken Schwaber与Mike Beedle合著了《敏捷软件开发-使用Scrum过程》一书,介绍了Scrum方法。
    • 2001年,Jeff Sutherland和Ken Schwaber参与了犹他州的17人聚会,参与发布了《敏捷宣言和十二原则》。
    • 2002年,Ken Schwaber和Mike Cohn创办了Scrum Alliance。

     

     

    SCRUM框架

    Scrum框架包括3个角色、3个工件、5个事件、5个价值:

    3个角色

    1. 产品负责人(Product Owner):
    2. Scrum Master
    3. 开发团队

    3个工件

    1. 产品Backlog(Product Backlog)
    2. SprintBacklog
    3. 产品增量(Increment)

    5个事件

    1. Sprint(Sprint本身是一个事件,包括了如下4个事件)
    2. Sprint计划会议(Sprint Planning Meeting)
    3. 每日站会(Daily Scrum Meeting)
    4. Sprint评审会议(Sprint Review Meeting)
    5. Sprint回顾会议(Sprint Retrospective Meeting)

    5个价值

    1. 承诺 – 愿意对目标做出承诺
    2. 专注– 把你的心思和能力都用到你承诺的工作上去
    3. 开放– Scrum 把项目中的一切开放给每个人看
    4. 尊重– 每个人都有他独特的背景和经验
    5. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重

     

     

     

    SCRUM理论基础

    Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

    Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:

    第一:透明性(Transparency)

    透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

    第二:检验(Inspection)

    开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

    第三:适应(Adaptation)

    如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

    Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

    展开全文
  • Scrum基础知识

    千次阅读 2016-09-01 20:00:08
    agile和scrum的基础知识,主要概念。

    agile和scrum的基础知识,主要概念。

    敏捷软件开发宣言(4大价值)

    Manifesto for Agile Software Development

    项番 详细(英文) 详细(中文)
    No.1 Individuals and interactions over processes and tools 个体和互动 高于 流程和工具
    No.2 Working software over comprehensive documentation 工作的软件 高于 详尽的文档
    No.3 Customer collaboration over contract negotiation 客户合作 高于 合同谈判
    No.4 Responding to change over following a plan 响应变化 高于 遵循计划
    结论 That is, while there is value in the items on the right, we value the items on the left more. 也就是说,尽管右项有其价值,我们更重视左项的价值。

    敏捷宣言遵循的原则(12原则)

    项番 详细(中文)
    No.1 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    No.2 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    No.3 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    No.4 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    No.5 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    No.6 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    No.7 可工作的软件是进度的首要度量标准。
    No.8 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    No.9 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    No.10 以简洁为本,它是极力减少不必要工作量的艺术。
    No.11 最好的架构、需求和设计出自自组织团队。
    No.12 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    Principles behind the Agile Manifesto

    项番 详细(英文)
    No.1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    No.2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    No.3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    No.4 Business people and developers must work together daily throughout the project.
    No.5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    No.6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    No.7 Working software is the primary measure of progress.
    No.8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    No.9 Continuous attention to technical excellence and good design enhances agility.
    No.10 Simplicity–the art of maximizing the amount of work not done–is essential.
    No.11 The best architectures, requirements, and designs emerge from self-organizing teams.
    No.12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    SCRUM三大理论基础

    项番 详细
    No.1 透明性(Transparency)
    No.2 检验(Inspection)
    No.3 适应(Adaptation)

    3个角色

    项番 详细
    No.1 产品负责人(Product Owner)
    No.2 Scrum Master
    No.3 Scrum团队

    3个工件(artifacts)

    项番 详细
    No.1 产品Backlog(Product Backlog)
    No.2 SprintBacklog
    No.3 燃尽图(Burn-down Chart)

    5个活动(events)

    项番 详细
    No.1 Sprint计划会议(Sprint Planning Meeting)
    No.2 每日站会(Daily Scrum Meeting)
    No.3 Sprint评审会议(Sprint Review Meeting)
    No.4 Sprint回顾会议(Sprint Retrospective Meeting)
    No.5 产品Backlog梳理会议( Product Backlog Refinement)

    5 core values of scrum

    项番 详细(英文) 详细(中文)
    No.1 Focus 专注
    No.2 Courage 勇气
    No.3 Openness 开放
    No.4 Commitment 承诺
    No.5 Respect 尊重

    常见术语

    英文 中文解释
    Lean 精益
    Agile Manifesto 敏捷宣言
    Empirical Process 经验性过程
    Product Owner 产品负责人 简称PO
    Scrum Master 简称SM, 一般不翻译
    Development Team Scrum开发团队
    Scrum Team 指PO,SM和开发团队
    Scrum Roles Scrum角色,指PO,SM和开发团队
    Product Backlog 产品待办列表,指需求清单
    Sprint Backlog Sprint待办列表,指Sprint任务清单
    Sprint Burn-down Chart Sprint燃尽图,团队用于做Sprint内的进展跟踪
    Release Burn-down Chart 发布燃尽图,产品负责人做发布进展跟踪
    Sprint Planning Meeting Sprint计划会议
    Daily Scrum Meeting 每日站会
    Sprint Review Meeting Sprint评审会议
    Sprint Retrospective Meeting Sprint回顾会议
    Product Backlog Refinement 产品待办列表梳理
    Product Backlog Item 产品待办清单条目,简称PBI
    User Story 用户故事,指一条需求
    Story Point 衡量用户故事的工作量大小的计量单位
    Sprint Task 实现一条需求需要做的一个技术任务
    Definition of Done DoD,完成的定义
    Backlog 待办列表
    Artifact 工件
    Scaling Scrum 大规模Scrum

    诞生

    Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。

    时间 milestone
    1986 竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发
    1993 Jeff Sutherland首次在Easel公司定义了用于了软件开发行业的Scrum流程,并开始实施。
    1995 Jeff Sutherland和Ken Schwaber规范化了Scrum框架,并在OOPSLA 95上公开发布。
    2001 敏捷宣言及原则发布、敏捷联盟成立,Scrum是其中一种敏捷方法。
    2002 Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

    Scrum团队的规模

    开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。
    少于 3 人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。
    小团队在 Sprint 中可能会 受到技能限制,从而导致无法交付可发布的产品增量。
    大于 9 人的团队需要过多的协调沟 通工作。大型团队会产生太多复杂性,不便于经验过程管理。

    User story的3个C(Ron Jeffries的3个C)

    项番 详细
    卡片(Card) 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。
    交谈(Conversation) 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
    确认(Confirmation) 通过验收测试确认用户故事被正确完成。

    User story的6个特性(INVEST)

    INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

    User story的通常表达方式

    英文 中文
    As a , I want to , so that 作为一个<角色>, 我想要<活动>, 以便于<商业价值>
    展开全文
  • Scrum框架详解总结

    千次阅读 2018-06-04 17:03:34
    Scrum中的角色Scrum Master——项目负责人、项目经理保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化...
    接上一篇文章,介绍一下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 过程中它将保持不变。

    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 就会记下一个障碍。

    •完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡


    燃尽图
    •跟踪进度要由团队来完成,燃尽图的横轴表示整个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 条目。

    扑克牌估算
    具体步骤:
    •每个人各自估算后独立出暗牌,听口令一起开牌。
    •数值最大者与最小者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 Meeting)
    会议目的
    •该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

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

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

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

    会议输出
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。

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

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

    千次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...

    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。

    敏捷开发的特点就是下面4句话:

    「个体与交互」胜过「过程与工具」

    「可以工作的软件」胜过「面面俱到的文挡」

    「客户协作」胜过「合同谈判」

    「响应变化」胜过「遵循计划」

    敏捷开发(scrum)适用于竞争激烈,快速变化的市场。 敏捷的客户协作观念,快速迭代能帮助团队以最小成本,最快速度满足客户真正的需求。对比传统开发模式:

    传统开发模式以文档为驱动,而敏捷开发提倡少写文档

    传统开发模式下开发人员按照产品文档进行研发,过程中客户不参与到产品的验收和体验中,这样就会导致最后开发出来的成品并不是客户想要的。 而敏捷开发模式从开始就强调客户协作,分步提供产品模块客户体验。

    敏捷模式采取迭代式开发,传统模式采用瀑布式开发

    敏捷开发采取迭代式开发的形式,即每个阶段有每个阶段需要完成、并且能使用的产品,这一阶段只要开发某几个功能,且这些功能的产品必须是可以使用的,这一阶段产品完成之后与客户进行对接交付,再进行下一阶段的开发。

    敏捷开发更适应变化

    传统开发模式下软件开发过程是执行研发计划,而实际工作中,需求往往在开发过程中会产生巨大变化。敏捷开发更能适应不确定性强的产品和市场。

    接下面我们来具体看一下执行scrum的套路。

    Scrum的三大角色

    产品负责人(Product Owner)

    主要负责和客户沟通确定产品的功能和达到要求的标准,并指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果,一般是由产品经理担任。

    流程管理员(Scrum Master)

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

    开发团队(Scrum Team)

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

    Scrum的组成

    Sprint:指的是一次迭代,而一次迭代的周期最好是1-4个星期,也就是我们要把产品需求分布到各个周期完成,这个过程我们称它为Sprint。

    Story:用户故事,也可以看做是用户需求点。

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

    Backlog:Backlog是Scrum中的一个专用名词,意思是待办工作事项的集合。在开发中需要明确2个Backlog。

    Product Backlog ——产品待办事项列表,产品负责人量化用户需求,逐条列出实际需要开发的需求(Story)。

    Sprint Backlog——任务列表,是一次迭代中需要完成的任务,主要是开发团队细化工作的列表。

    燃尽图(Burn Down Chart)

    是一个展示开发时间的图,但是展示的是每天累加所有任务的剩余时间。

    燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉,最后烧完sprint也就完成了。用蓝色线表示计划走向,红色线则是实际走向,两条线共同组成了燃尽图。如下图,每一个点代表一个用户故事,或者故事点,或者可度量的工作量。所有点组成sprint。

    4个会议

    Sprint计划会

    Sprint 计划会就是大家坐下来,PO 向大家介绍排好序的产品待办事项(Product Backlog),然后大家共同思考决定如何推进计划,梳理出 Sprint Backlog 来完成后续的工作。

    每日站会

    每位开发成员都要交代3点

    昨天完成了什么

    今天计划完成什么

    是否有困难需要帮助

    每日站会

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

    Sprint 评审会

    当一个Sprint完成,这时就要进行最重要的演示会议,也称为评审会议,产品负责人和客户都要参加,每一个开发团队的成员都要演示自己完成的软件产品,然后被判定产品合格、成功、需要修改还是重新做。

    Sprint 总结会

    总结会议以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

    以上的会议都不需要准备PPT或者大量的文档,但要注意会议的时长。

    使用鱼骨Scrum项目的开发步骤

    1.产品负责人使用产品Tab收集产品需求(story)。

    Product Backlog

    2.开发团队根据Product Backlog列表,在Sprint计划会议中做工作量的预估和安排,确定需求提交研发,进入Story看板。

    Story看板

    3.确定Sprint周期(1-4周)和本次开发迭代冲刺的开发需求(Stories)。进入Sprint的story出现在Task看板。 在Task看板,研发团队可以拆分Story到任务进行协作。

    Task看板

    5.每日立会,团队更新Task看板,和Story看板,保持信息的同步。

    功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。

    展开全文
  • 以下的22个问题基本上涵盖了Scrum所涉及的内容,如果你能够正确回答出所有问题,那么你已经具备了作为一名Scrum Master的基本素质;当然,作为一名合格的Scrum Master,更重要的是你的经验,因为Scrum Master更多的...
  • Scrum的概要介绍

    2017-08-07 15:50:04
    Scrum的英文解释为:密集争球。该词来源于英式橄榄球比赛中术语。在橄榄球比赛中出现小的犯规或因为队员受伤等原因中断的时候,一般裁判会判定争球。双方各三名前锋队员相互搂抱,半蹲顶架在一起。由有球权的队投球...
  • 浅谈Scrum(一)-- 什么是Scrum

    千次阅读 2018-11-29 09:23:09
    浅谈Scrum(一)鸡和猪的故事Scrum产生的背景Scrum的角色Scrum的流程Scrum的工具Scrum标准流程 鸡和猪的故事 一天,一只鸡散步时遇见了猪。 鸡对猪说:“嗨,我们合伙开个餐厅吧。” 猪说:“好啊,那准备取什么...
  • scrum 团队开始进行冲刺时, 他们使用的工具包括整个团队在设定目标和跟踪目标方面。虽然这些实践不是核心 scrum 规则的一部分, 但许多 scrum 团队都使用它们来规划工作并将每个人都保留在同一页上。这就是普遍...
  • Scrum

    2019-10-02 10:54:51
    什么是ScrumScrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议...
  • 转载于:https://www.cnblogs.com/14fzf/p/6115724.html
  • ScrumMaster的六大主要职责

    万次阅读 2018-03-13 14:04:12
    ScrumMaster是组成Scrum团队的三个角色之一。产品负责人主要负责构建正确的产品,开发团队负责以正确的方式构建产品,ScrumMaster则主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践...
  • Scrum那些事 - 什么是Scrum?

    千次阅读 2018-12-10 10:38:37
    1. 什么是Scrum? Scrum是敏捷开发方法论里面的一个具体实施框架。 Scrum是一个包括了一系列的实践和预定义角色的过程骨架(是一种流程、计划、模式,用于有效率地开发软件)。 Scrum的框架中包含3种角色,3个...
  • SM主要负责帮助每个人理解并乐于接受Scrum的价值观、原则和实践。 对PO和Dev Team来说,SM履行的是教练的职责。 对团队的Scrum工作流来说,SM履行的是过程领导的职责。 职责 Scrum教练 是Scrum团队的敏捷教练...
  • Scrum敏捷软件开发

    2020-07-30 23:30:27
    Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近...
  • 现在公司在使用敏捷开发模式进行日常的开发和管理工作,所以我看了下Ken Schwaber的《Scrum Guide》这本小册子,原本是英文的,这里提供中文的,以供日后复习和参考。 Scrum简介  自从上世纪90年代初期,Scrum...
  • 何为Scrum? 词条翻译-(橄榄球的) 并列争球; (橄榄球) 并列争球的全体前锋; 相互拥挤的人群; 敏捷项目管理Scrum连载系列——初始Scrum Scrum运动 Scrum源于橄榄球运动,橄榄球最重要的意义就是它的坚强不屈的精神和...
  • Scrum实战——敏捷软件项目管理与开发

    千次下载 热门讨论 2020-07-30 23:30:38
    Scrum实战——敏捷软件项目管理与开发》为软件项目团队提供了如何成功实施敏捷软件框架Scrum的实用指南。本书叙事清晰准确,是第一本由实践者编写的针对现实状况的实用指南。书中描述了如何使项目团队价值最大化,...
  • 图解敏捷教练和 ScrumMaster

    千次阅读 2019-07-05 10:04:12
    敏捷教练和 Scrum Master 是一种专业的职业。其职责是帮助团队和组织做到更好(本课程视 Scrum Master 和敏捷教练为同一职业的不同发展阶段)。敏捷能力的培养并不是简单了解后就可以速成的,但如同任何其他职业一样...
  • 软件开发模式之敏捷开发(scrum

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
1 2 3 4 5 ... 20
收藏数 29,952
精华内容 11,980
关键字:

scrum