敏捷21天打卡--Scrum活动

Sprint(冲刺)是Scrum的核心,持续时间为一个月或更短的时间,在这个时间内构建一个完成、可用的和潜在可发布的产品增量.在整个开发过程期间,其长度应保持一致,前一个Sprint完成后,新的下一个Sprint紧接着就开始,有点像接力棒的游戏。

  1. Sprint计划会议:会议时间不要过长,不要为了会议而会议。通常一个月内的,上线为8小时或更短;依次类推。其主要目的是确定每个参会者都理解会议的目的。敏捷教练要确保会议梳理举行并教导敏捷团队遵守时间盒规则。包含几点:这次做什么?如何完成所选的工作?期间会遇到什么问题?预期可交付的增量?
  2. 每日站会:2W1H,昨天我做了什么?今天准备做什么?是否需要他人协助?注意一点,站会的时间不要太长,其核心的地方,每个人参与,不要开成训导式的,确保每人都可以发言及每人都有机会主持会议;
  3. 开发工作:通过看板、代码测试、代码审核、沟通来确保Sprint正常进行;
  4. Sprint评审会议:在Sprint尾期进行,用于检视所交付的增量并按需调整ProBackLog列表。参会人员:团队成员、客户、利益相关者;会议市场同样不要太长,根据Sprint的大小决定。在会议中集中讨论几个要点:probacklog哪些“完成”、哪些“未完成”、遇到什么问题及如何解决的、演示“完成”的工作并解答增量交付的问题、讨论当前的probacklog的情况,根据当前的速率进行预测可能的目标交付日期(主要要澄清预估并非准确的交付时间)、参会人员讨论下一步的工作,并更新probacklog。注意点:正视问题,解决问题,不是问责大会,注意会议方向!
  5. Sprint回顾会议:回顾及复盘,对当前完成的Sprint进行适当的回顾是一件好的事情,可以让我们总结好的方法和避免踩坑。其会议在sprint评审会议结束后进行。主要点和第4点相同,国内的会议有两种:要么歌功颂德、要么批斗大会。要知道会议的真正目的:确保团队成员目标一致、通过会议可以让工作更加具有成效,实现利益最大化。

Sprint由上述5点组成,在整个冲刺期间,有几个规则来确保冲刺顺利完成。不作出对目标的改变、质量不能降低、随着项目的深入产品负责人和开发团队要对范围内做出的事情可能会做部分的调整。

每个冲刺的长度应限制在一个月内,太长的话,不符合Sprint的精髓,通过小版本的迭代、交付来刺探用户的返回,并作出改变。如果时间太长,其风险就被相应的拉长,同时也不利于可预测性。

在之前的脑图中,我们又看到“取消”,取消的原因有很多:过时、市场发生改变、客户不需要、技术层面等等,如果Sprint被取消,那么,任何“完成”、“待办”的列表事项都需要评审,如果成果部分潜在可以发布的娿,通常会进行一个版本的发布。

原文地址:https://www.cnblogs.com/atun/p/12116916.html

时间: 2024-10-09 08:36:19

敏捷21天打卡--Scrum活动的相关文章

敏捷21天打卡--Scrum角色

Scrum团队由一名产品负责人.开发团队.Scrum Master组成.Scrum团队是跨职能的自组织团队,团队成员自己选择如何以最好的方式完成工作,而不是由团队之外的人来指导.理论上来讲,团队拥有完成工作所需的全部技能,不需要依赖团队之外的人. Scrum团队迭代增量式交付产品,通过这种方式最大的获得反馈的机会,增量式交付”完成“产品保证一个可以工作产品的. 产品负责人PO:Product Owner角色定义,产品负责人的职责是将开发团队研发的产品价值最大化,为产品回报率负责,负责维护Prpd

敏捷21天打卡--用户故事

在远古时代,文字没有出现之前.知识的传承靠口口相传,不管隔了多少代,其准确性很高.文字出现后,我们大脑中的这种技能反而逐步衰退.于是各种软件.各种方法充斥着我们,左右着我们.各位是否也有相同的想法?试想一下,上节课我们讲了什么?每次应允别人的承诺,我们转过头就忘记?比如忘记约会,忘记洗车.忘记写日报? “要想知道栗子的味道,你得咬一口”这个真理朴实,正确.当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的.如果他专业,就没我们啥事了.用户大脑中的需求是离散的,不可

敏捷21天打卡-敏捷项目管理(终章)

软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理).敏捷项目管理: 传统项目管理(预测型项目管理):瀑布式.部分迭代开发模式,要求在项目一开始,需求足够明确.文档足够规范.迭代过程需求变更越频繁,其对项目造成的遭难往往越大.相信很多IT团队都尝试过,这里不赘述. 敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来.但并不代表敏捷不做计划,有很多人的观念“敏捷不做计划”这是错误,否“probacklog.scrum.看板.燃起图.燃尽图.用户故

敏捷21天打卡-精益产品开发最佳实践 之 “AB测试"

”一个错误的背后往往存在一个正确的假设,对假设的肯定程度越高引发的错误越严重!“ 从上章节中“MVP”中一文中我们了解到,最低限度的可用的产品是MVP的精髓,其目的在于迅速验证产品的可用性及市场用户的反馈:不能市场用户需要一辆汽车,我们给对方一辆自行车,典型的违背市场的原则. 伟人曾说过“实践出真知”,对于软件行业亦是如此,有了最低限度的可用产品,这是就需要收集市场的反馈,根据反馈调整产品策略,A/B测试是众多工具/方法中的一种. “推出一个代步工具.节约用户上下班时间,从而让用户有更多的时间来

敏捷21天打卡-AARRR模型

介绍下AARRR模型,AARRR模型是Acquisition(获取).Activation(活跃).Retention(留存).Revenue(收入).Refer(传播)的缩写,对应了产品生命周期的每个阶段.而无论是那个阶段,都是围绕着中间的用户展开,为用户提供有价值的产品和服务. 获取:对于一款产品,首先要获取用户,即拉新.如果没有新用户,产品就如一潭死水,即为死水,何来繁荣之说. 活跃:产品有了用户之后,就要考虑如何让用户活跃起来.”久别重逢的老友聚会,缅怀过去光辉岁月之时,有人提议创建个群

敏捷开发(九)- Scrum Sprint计划会议2

本文主要是为了检测你对SCRUM Sprint 计划会议二的了解和使用程度, 通过本文你可以检测一下     1.你们的SCRUM Sprint 计划会议二的过程和步骤    2.SCRUM Sprint 计划会议二的输出结果该会议是在Sprint 计划会议一的基础上进行的.一.会议目的     该会议的工作以设计为主.产品开发团队可以为他们要实现的解决方案完成设计工作.在会议的结束,团队知道如何构建他们在当前 Sprint中要开发的功能      1.  确定 sprint 长度       

瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别

瀑布式开发.迭代开发,区别[都属于,生命周期模型]         两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说. 传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好.特别是前期阶段,设计的越完美,提交后的成本损失就越少.我现在从事的外包项目就是这样的流程. 迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目

敏捷开发(七)- SCRUM评估会议

本文主要是为了检测你对SCRUM 评估会议的了解和使用程度, 通过本文你可以检测一下     1.你们的SCRUM 评估会议的过程和步骤    2.SCRUM 评估的输出结果一.会议目的      1.  确定 Backlog 中各项的大小.     2.  确定团队在一个Sprint中能够完成多少工作.      3.  团队成员可以从会议中知道项目接下来的阶段会发生哪些事情.      4.  修整Backlog内容:以合理方式分解Backlog各个项目,从而获得更深入的理解       基

敏捷开发(八)- Scrum Sprint计划会议1

本文主要是为了检测你对SCRUM Sprint 计划会议的了解和使用程度, 通过本文你可以检测一下     1.你们的SCRUM Sprint 计划会议的过程和步骤    2.会议的输出结果    Sprint 计划会议非常关键,应该算是 Scrum中最重要的活动(这当然是我的主观意见).要是它执行的不好,整个 sprint 甚至都会被毁掉.      举办 Sprint计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰地工作,也是为了让产品负责人能对此有充分的信心一.会议目的