敏捷模型(7)CA Agile Vision 可以帮助您的十种方式

学习目标

完成这个单位后,你会知道:

  • 将您的技术融合在一起
  • 增强团队的能力和学习能力
  • 让您的商业生活更轻松

CA Agile Vision是当今最强大的在线敏捷开发环境之一。该软件专门为您的组织无缝地提供Scrum技术。本章致力于了解CA Agile Vision软件是否可以为您的业务提供帮助。

改善沟通

当您拥有分布式Scrum团队时,几乎不可能只保留一份重要文档和日程表 – 除非您在线操作。使用CA Agile Vision,您可以在线完成所有计划,日程安排和积压任务,以便在分布式团队成员之间立即进行协调。

节省时间

您的敏捷团队是否花费大量时间向管理层提供有关其进度的报告? CA Agile Vision可帮助您的团队自动创建报告,只需点击几下,即可节省大量时间。通常,报告要求会推动传统的项目管理报告,这些报告是为预先计划的项目而设计的。

CA Agile Vision与CA Clarity on Demand的集成可以提供从敏捷方法和词汇到管理层习惯的术语和报告的翻译。

赋予你的团队权力

传统的项目管理要求团队规划整个项目,并获得对在此过程中遇到的变更的批准。这些变更和原始计划通常要求团队完成现有的治理流程,从而剥夺了Agile建议的功能。

CA Agile Vision和CA Clarity On Demand可以为那些习惯于定义为传统工作分解结构(WBS)的项目提供安慰,并在许多传统项目经理不确定他们是否可以从敏捷项目中获取信息时提供可见性和反馈。

合并产品负责人

CA Agile Vision专注于让产品负责人参与您的项目 – 这对任何Scrum项目都至关重要。产品负责人拥有各种在线工具,可以立即访问项目的所有内容。

由于能够创建和管理产品Backlog,以及通过仪表板的冲刺跟踪产品的进度,产品负责人可以感觉更像是团队的一部分,其中包含专门为开发团队设计的许多其他解决方案。敏捷项目。

发展你的学习

CA Agile Vision在各个级别提供了许多支持Agile的工具。随着您对Agile开发的深入了解,CA Agile Vision随您而来。 CA Agile Vision专为敏捷成熟的各个级别的团队而构建,因此该解决方案适用于所有人。

自动化您的流程

您的敏捷团队是否难以使用手动流程进行积压和Sprint计划? CA Agile Vision中的一切都是自动化且易于使用的。界面直观而自然,使得积压工作和Sprint计划变得轻而易举。

用不同语言与您的团队交流

CA Agile Vision通过为使用德语,意大利语,日语,西班牙语,法语和巴西葡萄牙语的工作人员提供翻译和本地化版本,为非英语用户提供支持。

降低成本

您是否希望零管理和运营成本具有高性能,安全性和可靠性? CA Agile Vision可作为订阅服务提供,不需要您的组织购买和维护昂贵的硬件,从而占用关键的管理资源。

教育你的初学者

您的组织中是否存在不同级别的敏捷成熟度?并非每个开发人员都精通敏捷方法和技术。为了让新手加快速度,预先构建的Agile框架以及所需的所有工具都是非常宝贵的。 CA Agile Vision的设计考虑到了这个问题,对于新手敏捷团队成员来说是平易近人的,并且还可以支持更成熟的团队。

集成解决方案

您是否有团队成员致力于敏捷和传统项目?当团队成员必须在工具和方法之间进行转换时,这在许多大型组织中很常见,能够跟踪和管理您的工作,项目以及最终在一个集成解决方案中的时间可以节省时间和减轻压力。

CA Clarity on Demand和CA Agile Vision的集成解决方案使团队成员可以进行集成,并且资源管理员和项目管理办公室(PMO)员工可以了解一个解决方案中发生的情况。

更有效地管理您的项目

敏捷是一套令人兴奋的原则,可为客户带来价值。 它通过特定的实践和技术来体现,使产品开发更具迭代性和渐进性,并通过在关键步骤中让客户参与,使您更接近客户的需求。 使用迭代方法,客户可以不断提供反馈,以获得他们真正想要的产品,然后他们可能最终购买并建立公司收入。 产品和工具也支持敏捷。 了解CA Agile Vision如何帮助您有效管理实施敏捷的项目。

敏捷模型(6)决定敏捷是否适合你的十种方法

学习目标

完成这个单位后,你会知道:

  • 使敏捷融入您的工作环境
  • 了解您的团队如何使用敏捷
  • 了解您是否满足所有要求

敏捷技术并不适合每个组织。本章中的问题可以帮助您决定是否
敏捷是否适合您的项目开发。

你的团队是否并列?

当团队位于同一个地方时,敏捷和Scrum技术会蓬勃发展 – 分布式团队可能会引入问题,因为没有并置需要团队更加努力地进行沟通和协作。但是,如果您可以将您的团队聚集在一个地方或利用在线解决方案来管理敏捷工件,那么这就是支持敏捷开发的一个重点。

你能容忍一个有能力的团队吗?

敏捷团队必须尽可能自主,才能使敏捷方法发挥作用。个人内化自己的纪律。如果你能够在不需要繁重的外部管理的情况下生活,那么这对Agile有利。

在具有强大管理风格的组织中,CA Clarity PPM和CA Agile Vision等解决方案可以帮助实现管理和敏捷团队的目标。

项目规模大吗?

大型项目可能不适合敏捷和Scrum方法,这些方法针对较小的团队。虽然您可以将较大的项目分解为较小的团队,但您必须为将出现的协调问题(例如Scrums of Scrums的创建)做好准备。 Scrum of Scrums的创建有所帮助。有关Scrum of Scrums的更多信息,请参阅第3章。

使用Agile可以成功实现大型项目。实际上,许多组织使用传统的项目管理方法使用Agile和其他部分运行项目的一部分非常成功。随着更大的项目及其相关的挑战增加,您的团队将需要额外的沟通。

是一种迭代的方法吗?

有些组织需要在项目开始之前从头到尾规划项目的所有方面。敏捷以连续的周期以迭代的方式工作,没有一个全面的,前期的,必须做的计划。

你有经验丰富的开发人员吗?

经验丰富的开发人员知道开发过程中涉及的内容,并且不需要太多的外部指导。他们已经知道了这些绳索并对项目开发非常熟悉,因此他们知道对他们的期望 – 新手开发人员可能不知道的事情。

你的团队是否受到激励和承诺?

敏捷和Scrum团队需要内化项目所需的动力,以便他们能够以最少的外部管理完成工作。如果您的团队有动力并且能够参与项目,那么这是支持敏捷开发的另一个观点。

你有有效的团队领导力吗?

Scrum团队依靠ScrumMaster,团队领导者,通过项目看到他们,处理障碍,并运行每日Scrum。

理想情况下,您对ScrumMaster的想法应该是Scrum知识渊博的人,以及没有命令和控制风格的有效领导者。

您能否容忍持续的客户存在?

Scrum方法要求持续的客户参与 – 理想情况下,将客户代表(产品负责人)与Scrum团队并置。如果你不能容忍这样一个持续的客户存在,敏捷和Scrum可能不适合你。但是,持续的客户参与是您了解自己为客户构建正确产品的方式。

团队是否有他们需要的一切?

Scrum团队应该拥有完成项目所需的一切。他们不应该与组织的其他人员和组件进行重要的协调来完成他们的工作。

客户代表能否提出所有要求?

在Scrum开发中,产品负责人理想情况下应该是团队的项目要求的首选人。产品负责人是产品方向和要求的最终负责人。

敏捷模型(5)让每个人都保持联系

学习目标

完成这个单位后,你会知道:

  • 检查每日Scrum的最佳实践
  • 与分布式团队沟通
  • 处理大型项目
  • 使用CA Agile Vision中的虚拟墙

沟通是Scrum开发过程的核心。 Scrum实践是关于会议 – 每日Scrum会议,如何处理与分布式团队的会议,Scrum of Scrums详细介绍大型项目(有关Scrum of Scrums的更多信息,请参阅第3章)。本章有助于让每个人保持联系。

在本章的最后,我们将向您展示CA Agile Vision提供的一些工具,以便让每个人保持联系 – 特别是虚拟墙和报告。

作为一个团队进行沟通

沟通对任何Scrum团队都至关重要。团队成员应该与ScrumMaster保持联系。应该在Scrum团队中进行持续的与工作相关的对话。

内部和外部通信都在Scrum团队中进行。本节向您展示两者的活力。

内部沟通

团队成员之间的内部沟通是Scrum流程的核心部分。团队内部必须存在自由和轻松的沟通,因为团队通常由不习惯沟通的跨学科成员组成。这是ScrumMaster的工作,以确保团队成员相处融洽,但ScrumMaster只能做很多 – 沟通完全取决于团队成员。最终,不能很好地沟通的团队成员可能需要更换。

Scrum流程的结构有助于沟通。每日Scrum是一个站立式会议,所有与会者都站起来强调会议的简短性质(大约15分钟),而且都是关于沟通的。每个团队成员都要报告他们前一天所做的事情,他们今天将要做的工作,以及他们面临的障碍。

这里ScrumMaster的工作是确保团队成员充分参与会议,避免对这些问题做出简短的,两个对应的单词回答。理想情况下,每个团队成员必须明白他们的答案必须完整,好像他们的目标对象是需要知道但可能无法快速掌握其特定专长的人,例如产品负责人。

ScrumMaster还应该注意每个团队成员提到的障碍,并努力消除这些障碍;一些关于Scrum的评论员说,这是ScrumMaster所有工作中最重要的,如果团队运作良好,很可能就是这样。

外部沟通

外部沟通意味着团队与客户之间的沟通,这通过产品负责人进行。作为客户的代表,产品负责人必须知道完成项目所需的所有内容,并且始终可以访问 – 甚至可能与Scrum团队并置。

Scrum团队与团队所属的大型组织之间进行了额外的外部沟通。这种沟通主要关注项目资源和边界 – 访问所需的资源,如数据库服务器;边界包括预算问题和时间限制。

这种类型的外部通信几乎总是在需要时通过ScrumMaster进行。换句话说,ScrumMaster通常是Scrum团队与团队所属的大型组织之间的联络人。必须尽可能地允许团队完成其工作,而不必受到无关细节的困扰。

每日Scrum:最佳实践

每日Scrum或每日站立会议是Scrum开发的核心。这次会议就是沟通。请所有与会者在可能的情况下站起来强调会议应该简短。保持会议简短会做两件事:

  • 保持一个新的,专注的会议,不会拖延
  • 当团队成员的工作时间更好时,可以避免过度拖延

让每日Scrum保持新鲜特别重要 – 你可能会遇到永远喋喋不休的会议,浪费时间并向每个人强调会议主要是为了形式而举办,而不是为了功能。 每日Scrum的功能非常强大 – 这个名字很好地取自橄榄球,在开始行动之前,球队会暂时收集橄榄球。 另一个重要方面是所有团队成员都要准时,以确保没有人浪费别人的时间。

每日Scrum的重点在于沟通 – 它让每个团队成员都知道每个人在工作中的位置,他们下一步打算做什么,以及他们面临的障碍。 它为团队保持至少最小量的面对面互动,其成员可能只是消失在小隔间里。

每日Scrum的好处包括

  • 促进承诺
  • 向团队传达进展
  • 识别障碍,以便团队可以删除它们
  • 保持专注
  • 促进团队合作

预计所有Scrum项目都会持有每日Scrums – 这就是方法的名称来源。

每日scrum如何实际运作

每日scrums是在sprint期间发生的每日会议,从第二天到sprint结束(Sprint的第一天用于Sprint计划)。每日Scrums快速,专注,非常协作。 ScrumMaster为他们提供了便利,但每个团队成员都必须参与并发言。每个团队成员和ScrumMaster(以及产品负责人,如果适用)都有责任参加每日Scrum并准时出席。

每个团队成员和ScrumMaster的出席尤为重要,因为每日Scrum也可以作为识别问题的一种方式。一个团队成员面临的特殊挑战可能是另一个团队成员的特殊挑战,这个问题可以启动团队成员之间的正确联系,然后在每日站立后脱机谈话。每日Scrum还让每个团队成员了解每个其他团队成员正在做什么以及他们面临的障碍。

每日Scrums限制为15分钟,但如果一切顺利,它们可以短至5分钟。如果讨论可能会持续超过几分钟,那么它们应该推迟到Scrum结束,所以只有那些感兴趣的人才能在单独的会议中继续讨论。坚持这些会议的短时间框架对Scrum流程来说非常重要,以保持这些会议的新鲜感。

每日Scrum寻求实现许多目标:

  • 促进承诺:在每日Scrum期间,团队成员承诺每天都在做什么。作为一个团队每天做出相互承诺是每日Scrums最重要的目标之一。
  • 沟通进展:认识到团队成员应该对团队负责是很重要的。每日Scrum都会提升责任感 – 而不是向经理报告进度,每个团队成员向团队报告。
  • 识别障碍:当出现障碍时,面对问题的团队成员通常不应该单独奋斗。如果其他团队成员可以提供建议或解决方案,则不会延迟进度。这种协作是Scrum实践的全部。
  • 保持专注:在每日Scrum期间,ScrumMaster将注意力集中在Sprint积压上。 Scrum用于不断提醒团队该方向是什么,以便团队可以专注于这些任务。
  • 促进团队合作:通过定期沟通,协作和互相帮助,建立有效的团队。团队成员的联系越多,他们就越能相互依赖。

所以我们已经告诉过你关于会议以及会议的重要性,但你可能会想,“那些会议中发生了什么?”有趣的是你应该问。以下是每日Scrum的详细信息:

  • ScrumMaster每天在同一时间和地点发出定期会议通知。
  • 团队成员准时出现。
  • 每个团队成员回答以下问题:
    1. 昨天我完成了什么?
    2. 今天我会做什么?
    3. 阻碍我进步的障碍是什么?
  • ScrumMaster记录进度并更新sprint burndown图表。列表中添加了任何障碍,以确保它们得到缓解。
  • 任何较长的项目都可以跟那些有兴趣讨论这些项目的团队成员进行跟进。

在每日Scrum期间,团队成员可以查看Sprint积压,燃尽图,虚拟墙和障碍列表,以深入了解进度。

遵守游戏规则

当你年轻的时候,你可能已经知道生活是由一系列规则决定的。那么,作为一个成年人,在一个非常成功的公司工作也没有什么不同。每日Scrum的规则包括以下内容:

  • 每天的Scrum应该在每天的同一时间举行,以提供稳定感和所有权。有兴趣的人应该能够观察每日Scrum,以避免安排其他会议。
  • 团队成员不得强制延迟或更改每日Scrum的位置。
  • 一般而言,任何人都不应该能够更改时间表或地点。这应该是Sprint Planning或回顾期间的团队讨论。
  • 只有整个团队同意,才能修改时间表。
  • 每个人都应该参加。每日Scrum是为了团队的利益,所有Scrum成员都必须参加。
  • 如果有人迟到,会议不会被推迟(Scrum方法非常清楚,不是“奖励”后来者)。
  • 每个团队成员都应与整个团队交流。在会议期间,团队成员轮流发言,有时会通过令牌表示当前有意发言的人。
  • 如果团队成员不能参加Scrum,他应该向代理(例如另一个Scrum团队成员)提供他的信息。
  • 承诺。在每日Scrum中发言的所有人都必须是分配到该项目的Scrum团队成员和Sprint(有时在第3章中说明承诺的故事中称为“猪”)或者
  • 产品拥有者。其他人可能会参加,但不允许发言(这些人被称为“鸡”)。
  • 保持简短。每日站立的目标是简短的。确保它实现了这一目标。

捆绑松散的目标

在每日Scrum会议上发生的事情很多,我们可以在会议上写一整本书。你有一些挥之不去的问题吗?我们希望通过给你一些最后的记忆来回答本节中的一些内容。

如果团队落后会发生什么?

如果团队注意到它落后了,如燃烧图表所示,它应该将这个事实引入ScrumMaster的注意力而不是简单地希望它能够在没有任何纠正措施的情况下赶上。

一些加班时间可能会纠正这个问题,但不推荐长时间和极端加班 – 至少部分是因为它会影响团队速度的真实衡量标准(未来的项目可能期望加速速度相同)。可以在回顾中讨论进度和速度问题,并在下一个Sprint的下一个Sprint计划会话中进行调整。

如果某些加班时间不足以纠正问题,ScrumMaster应该调查添加临时团队成员的可能性。额外的临时团队成员应尽可能与项目结盟,项目目标应属于他们的专业领域。

如果团队确定了其他任务怎么办?

您的团队可能会识别Sprint计划中未出现的其他必要任务。如果您有这个问题,答案取决于新任务是否延迟项目或影响冲刺。如果新任务不会引入重大延迟,团队成员应该承诺并执行任务。

如果新任务在项目完成时引入延迟或影响sprint,则必须由ScrumMaster将其输入到Sprint backlog中,并将其视为任何其他任务。可以向产品负责人请求确认新任务。

每日Scrum不被视为解决问题的会话。每日Scrum是一个沟通会议 – 如果有需要更多关注的问题,有兴趣的各方应该在每日Scrum之外见面。

保持分布式团队的联系

传统上,Scrum团队在同一地点并置。它们共享相同的物理工作环境,包括列出Sprint积压任务的相同图表和电路板。这些项目可以放在共享的团队空间中,每个人都可以平等访问它们。

分布式团队实现统一要困难得多。在这种情况下,您没有共享的物理团队空间 – 没有并置,没有物理图表,也没有列出Sprint任务的板。相反,您需要建立一个在线协作空间,并使用CA Agile Vision等敏捷规划工具来共享信息和文档。

特别是,分布式Scrum团队面临两个重大挑战:

  • 缺乏有效的会议:对于其他地方的部分或大部分团队而言,举行高效,协调的会议是一项挑战。
  • 文档复制:如果每个团队网站都有自己的项目文档副本,例如燃尽图,积压工具等,那么这些文档很快就会变得不协调。

本节将详细介绍解决这两个问题。

创建高效的分布式会议

如果每天Scrum的一半发生在加利福尼亚州的圣地亚哥,另一半发生在印度孟买,那么你将面临一些沟通问题。

简单地将每日Scrum分成两个独立的会议是最不具吸引力的选择。这有效地减少了团队之间的沟通,这显然是不可取的。

幸运的是,有大量的网络工具可以提供帮助,以及其他一些要点:

  • 使用简短,专注的会议。短期会议比长会议更好。可以运行会议以仅包含关键信息。应在会议召开前至少24小时向所有团队成员提供会议支持文档。
  • 使用Web会议工具。微软LiveMeeting等工具非常适合为远程团队成员提供服务。分布式团队可以使用基于Web的会议软件的正确组合来体验并置的每日Scrums的体验。
  • 尽量缩短时间和地区差异。尽你所能选择最适合每个人的会议时间。团队应避免根据会议安排会议
  • 单一地点,并了解时间表中的地区差异,例如当地假期。
  • 记录所有内容:应使用基于Web的工具(如CA Agile Vision)来支持信息和详细信息。

协调文件虚拟

发展取决于与团队共享文档 – 产品积压,Sprint积压,燃尽图,发布计划积压。

当存在多个文档副本时,共享此类文档会变得更加困难。伊利诺伊州芝加哥市的燃烧图表存在与中国北京类似燃烧图表不同步的风险。如果它们是两个独立的图表,它们应该代表相同的进展,那么它们会慢慢地彼此不同步(可能)都不是真相。那时,你必须在sprint结束时调和。

该解决方案涉及在Web上托管共享文档,图表和计划。这些解决方案包括以下功能:

  • 积压管理:如果所有积压项目描述,优先级,验收标准和状态都保存在一个地方,那么对于要完成的工作范围和规模的错误沟通的可能性就会降低。
  • Sprint管理:此工具使用通用任务板,因此每个团队成员都知道其他团队成员正在做什么。
  • Sprint报告:Burndown图表和其他sprint报告指标可以让整个团队快速了解团队和团队成员的进度。
  • 时间跟踪:为了使图表和报告中的指标有意义,团队成员需要跟踪他们的时间。
  • 用于团队沟通的虚拟墙:团队成员可以随时在墙上张贴,当墙在世界各地立即共享时,该沟通可以保持团队的协调。

所有这些分布式Scrum团队成员之间的即时通信都可以通过CA Agile Vision等基于Web的工具立即实现。 CA Agile Vision为您提供了托管Scrum团队在线所需的所有共享文档的工具,以使每个人都能够处于循环中。

内部审视CA Agile Vision:将任务添加到虚拟墙

当团队首先使用Scrum时,他们会使用记事卡来捕获用户故事和任务。然后他们将它们放在墙上并在那里管理它们。使用CA Agile Vision,任务墙变得虚拟,可供各地团队使用 – 并且清洁人员不会意外地将卡刷掉。

CA Agile Vision专注于保持团队成员和其他人的联系。虚拟墙作为一个中心焦点,让人们了解冲刺的方式。虚拟墙使团队成员能够以图形方式管理任务。

虚拟墙遵循一个比喻,许多团队手动工作将遵循。这些团队在记录卡上创建用户故事和/或任务,并通过将它们附加到按状态划分的墙来跟踪其优先级和进度。

团队成员可以查看为sprint提交的所有用户故事和任务,并可以在页面中编辑任务并更新其状态。通过这种方式,团队中的每个人 – 以及产品负责人等其他感兴趣的团队 – 都可以一目了然地看到冲刺的方式。

您可以快速将任务添加到CA Agile Vision中的虚拟墙;只需按以下步骤操作:

  1. 单击“导航”菜单,从“计划”菜单中选择“Sprint详细信息”。
  2. .显示用户故事所属的sprint的详细信息,然后转到Virtual Wall。
  3. 单击要添加任务的用户素材的“新建任务”。
    用户素材中添加了一个新的任务窗口。
  4. 双击名称下方的任务窗口。
    任务窗口将重新显示您可以编辑的字段。
  5. 填写字段,其中包括以下内容:
    清除顶部字段并输入任务标题。
    在第二个字段中输入将分配给任务的团队成员的名称。
    在第三个字段中输入估计完成任务的小时数。
    如果任务已启动,请输入工作小时数。
    如果任务已启动,请单击向右箭头按钮将任务状态从“计划”更改为“正在进行”。
  6. 单击复选按钮以保存设置。
    您可以在图中的虚拟墙上看到示例任务。

敏捷模型(4)满足您的Sprint 规划目标

学习目标

完成这个单位后,你会知道:

  • 发现Sprint Planning的细节
  • 将Sprint计划划分为多个细分市场
  • 审查整个过程
  • 在实际示例中使用CA Agile Vision

sprint规划对Scrum至关重要。 Scrum在一系列称为sprint的迭代中攻击一个项目,并且在sprint期间工作完成。这就是为什么确保正确规划冲刺的重要原因 – 这就是您设置冲刺目标和选择故事的地方。在sprint结束时,团队应该有一个潜在的可交付产品呈现给客户。

这就是Scrum中项目的完成方式 – 您通过从产品积压中剥离任务开始Sprint Planning并将其移至Sprint积压 – 然后团队执行这些任务,然后在结束时向客户和产品负责人演示可交付成果。 -Sprint Review然后这个循环再次从sprint开始到sprint。以这种迭代方式,产品发展。

本章是关于规划sprint的。

设定您的目标:Sprint计划

Sprint是在Scrum开发中完成工作的地方,在开始sprint之前,您花了一天时间来规划sprint。这是Scrum的一项规则 – 每个sprint都以Sprint Planning会话开始。

Sprint Planning背后的想法是确定团队在该sprint期间将准确处理哪些故事。 Sprint Planning完成了以下事情:

  • 它确保你知道你在sprint中关注的是什么。
  • 结合Sprint End Sprint,Sprint Planning确保团队提供的服务与客户的需求和需求更紧密地结合在一起。
  • 它可以及时做出决策。将Sprint计划与有效的故事编写实践相结合意味着可以在项目中更快地交付产品。

如果没有Sprint Planning,您将面临风险

  • 显着降低对工作重点的关注,这可能导致优先级较低的工作取代优先级较高的工作
  • 减少团队对工作的理解,并限制经常发生的澄清量
  • 冲刺期间的澄清数量增加,降低团队速度和实际承诺的交付
  • 缺乏对团队燃烧速度和估算数据的理解

Sprint Planning是所有与项目有关的人员(从产品负责人到团队成员)之间进行交流的绝佳场所。本次交流的参与者应遵循以下几条规则:

  • 产品负责人不应强迫团队承诺更多的故事点,而不是他们对承诺感到满意。经过一系列冲刺后,团队的速度变得清晰。
  • 在团队承诺冲刺后,冲刺不会改变:团队组成没有变化,冲刺要求也没有变化。当然,可以提供澄清。
  • 团队可以执行任务并将其分解为两个或更多任务。团队可能会发现不需要给定任务,可以取消此任务。对于添加,编辑或删除的每项任务,团队会在Sprint Review期间讨论更改的原因,尤其是在他们无法完成sprint目标的情况下。

Sprint Planning看起来似乎有很多规则,因此在下一节中,我们会打破规划以帮助描绘流程。

两个不同细分的规划

Sprint计划发生在冲刺的第一天 – 您计划在开始冲刺工作之前。每个Sprint计划会议通常持续一整天,或八个小时。

每个Sprint计划会话由两个部分组成。每个细分市场设计为持续约半天,大约或约四小时。 (这样可以节省两个段之间方便的午休时间。)

虽然Scrum指南说Sprint Planning通常需要8个小时,并且分为两个四小时段,但这些时间可能会有所不同。许多因素会影响规划sprint的实际时间:

  • sprint中要进行的复杂性和深度工作
  • 团队的成熟程度(并且已经合作)
  • 冲刺的长度
  • 团队规模
  • 积压的故事准备得多好

细分#1:从产品待办事项中移动商品

Sprint Planning的第一部分专注于从Product积压中选择高优先级积压项目,并将其移至Sprint积压并定义Sprint目标。将Sprint Planning的这一部分限制为四小时,可确保有效地实现这两个目的。

谁来参加会议?

谁参加了Sprint规划的第一部分?产品负责人,Scrum Master,Scrum团队以及其他人员:

  • 产品负责人:产品负责人必须出现在Sprint计划会议的第一部分。产品负责人负责根据团队的建议设置sprint目标。产品负责人还负责向团队提供产品积压中最高优先级的项目。
  • Scrum Master:使计划会议按计划进行。 Scrum Master促进了产品负责人和Scrum团队之间的会议,确保不熟悉Scrum实践的任何人都能加快速度。
  • Scrum团队:团队审查产品所有者优先考虑的产品积压项目,并询问有关不清楚项目的问题。最终,该团队的目的是估计每个故事所需的时间并承诺Sprint积压,因此他们必须知道他们正在做什么。他们必须分析每个故事并将其分解为可以执行的任务。整个团队必须承诺进行此迭代的工作,因此尽管产品负责人提供了产品待办事项中的项目,但团队需要对其进行适当的估算和提交。
  • 其他:如果有其他人可以提供信息,其他人可以参加Sprint计划会议。他们只能以顾问身份行事,不能分配工作或指导。

识别高优先级产品待办事项

Sprint计划会议的第一部分将以产品负责人为中心开始。产品负责人必须在Sprint计划会话开始之前准备产品待办事项中的故事并确定其优先级。

产品负责人以故事格式向团队提供高优先级产品积压项目(这些故事可以分解为产品积压中的任务,通常将分解为Sprint积压中的任务)。这促进了产品负责人和Scrum团队之间的开放式沟通。

通常情况下,产品负责人需要准备并优先考虑比预期使用的Sprint计划会话多50%的故事。

每个故事都应附有一套验收标准(产品负责人应明确说明每个故事成功完成的内容,因为故事会呈现给团队)。估计实施每个故事的时间尚未进入图片中,除非粗略地说 – 在Sprint计划会议的第二部分中,Scrum团队负责完善这些估算(请参阅“第2部分:估算积压项目”一节) “)。

第一部分是关于产品负责人和Scrum团队之间的面对面沟通,ScrumMaster充当促进者。这个机会让团队有机会了解产品负责人在此sprint中的期望。

重要的是,每一方都要在这里理解另一方 – 尤其是在冲刺中实现每个故事的期望。如果合适,预计该团队会提出许多问题并提出建议。

因此,例如,产品负责人可能会出现这样的故事,“作为客户,我想将我的卡插入自动柜员机。”验收标准可以指定在一定的秒数内读取卡,并在某个特定的秒内验证秒数(并且可以指定如果客户无法验证卡片该怎么做),并且卡片会在另一秒钟内被推回给客户。
 

定义sprint的目标

有关sprint的所有内容必须尽可能在Sprint计划会议期间进行布局,包括sprint本身的目标。如果想要创建产品负责人想要的东西,了解Sprint目标对团队至关重要。始终坚持冲刺的目标对团队来说非常重要。

sprint可能有不止一个目标,但产品负责人应该将任何sprint的目标数量限制为三个 – 比这更多,sprint可能变得没有重点。

Sprint的目标在Sprint End的最终评论中进行了审核,以确保它已得到满足。因此,例如,sprint的目标可能是“通过使用客户的PIN与ATM完成卡验证过程”。

团队中的测试人员应特别关注sprint的目标,以确保迭代符合该目标,然后才能进行充分测试。

细分#2: 估算积压物品

Sprint Planning的第二部分是关于磨练Sprint Backlog并更详细地了解积压项目。该部分有三个主要目的:

  • 团队精心准备要传递的故事
  • 团队估计工作
  • 团队致力于工作和冲刺

全力以赴:团队精炼要传递的故事

此时,团队会考虑所有Sprint目标以及要从Product积压转移到Sprint积压的故事。这里的一个重要问题是,在为sprint分配的时间内是否可以满足sprint的总体目标。

我必须参加这次会议吗?

谁参加Sprint计划会议的第二部分?看看这个列表,看看你是否在上面:

  • Scrum团队:团队在创建Sprint积压时改进积压项目,并将每个故事分解为任务。它还必须估计工作。该团队还致力于这一领域的工作。它从产品负责人和该细分市场中的其他来源寻求信息,但此时所有方向都取决于团队和Scrum Master。
  • Scrum Master:Scrum Master确保流程顺利进行 – 创建Sprint积压,团队承诺冲刺,等等。如果团队需要更多信息,Scrum Master还可以充当其他人的联络人。
  • 产品负责人:产品负责人的出席非常重要,并且需要根据团队的澄清需求而定。

该团队查看优先级积压项目,确保他们了解每个故事。成员通常将每个故事分解为Sprint积压中的任务。

故事或任务的每个接受标准也会转移到Sprint积压。如果团队认为需要进一步澄清任何验收标准,则可以与产品负责人进行协商。随着故事被分解为任务,接受标准也可能会发生变化。

在这个阶段完成后,Sprint的积压已经开始成为焦点,积压的故事和任务已经到位。如果故事足够清晰且范围足够小,故事可以从产品积压转移到Sprint积压 – 否则,它们将被分解为任务。

拿出你的时间表:团队估计工作

Sprint积压已经形成,团队必须知道在分配给sprint的时间内完成工作是否切合实际。

估计工作时间是一个棘手的过程,但却是必要的过程。 Scrum实践依赖于随着时间的推移而变得高效,并且团队越接近估计sprint中的所有任务所花费的时间越多越好。经验丰富的球队将比新手队更好。

时间估计的首选方法是在Scrum团队中使用Story Points。故事点是可以分配给每个任务的时间单位 – 通常,故事点是一个人工作的一天,但这是适应性的。大多数组织实际上使用相对大小来决定故事点。

在名为Planning Poker的过程中,团队成员估计每个故事或任务的故事点。这为每项任务分配了特定数量的工作和时间。

在计划会议的这个阶段之前,团队成员应该考虑:

  • 他们在最后一次冲刺中提供了多少个故事点?这有助于设置在此sprint中可以完成多少工作的基线。
  • 即将到来的冲刺计划是否有任何假期?这可以调整团队在冲刺中完成的总分数。
  • 是否存在可能影响流程的重大里程碑/事件?这可能会影响可以交付的工作量。

然后该团队考虑冲刺速度目标。冲刺速度是完成冲刺所需的时间,并指示团队的开发能力。

在此尝试计划当前冲刺的速度时,查看团队的历史冲刺速度非常有帮助。通过将预测速度设置得过高,团队不应该过于雄心勃勃,这会让产品负责人(和团队)感到失望。

每个任务都会估计一段时间,通常是在故事点中,直到达到潜在的Sprint速度。通常,团队将首先从最高优先级的故事和任务开始,估计他们将花费的时间,然后继续使用较低优先级的故事和任务。
 
一些团队让每个成员负责故事或任务,估计故事或任务将采用多少故事点(或小时),然后比较他们的独立估计。如果估计数不够充分,则需要进行讨论。让我们这样做:团队致力于工作和冲刺

这一阶段是Sprint Planning第二部分的最后一步。在将故事添加到Sprint积压工作之后,团队根据速度估算确定了什么适合冲刺,现在是团队承诺执行任务的时候了。

致力于工作是在逐个成员的基础上完成的。第二部分的这一部分由ScrumMaster提供便利,ScrumMaster审核每项任务并将其呈现给团队。

当提交任务时,团队成员自愿承担任务。如果多个团队成员承诺执行特定任务,ScrumMaster应该促进讨论(并且任务可能最终被共享)。

ScrumMaster通常以最高优先级的故事或任务开始,要求团队成员依次提交每个故障,然后在优先级较低的项目中继续执行优先级较高的项目。

通过这种方式,任务不会简单地分配给团队成员 – 团队成员必须前进才能接受任务。
这个承诺过程尽可能地对Scrum很重要。团队成员应该觉得他们做了一个
选择“拥有”某项特定任务,接受对其负责。

承诺过程有助于团队自治,确保团队可以对sprint的任务负责。自治对Scrum团队很重要,让成员选择承诺协助这个过程的任务。

一些低优先级的任务可能仍未提交 – 接近这个阶段的结束,并且由Scrum Master决定是否将它们分配给团队成员。如果这里有问题,团队应该讨论它们;任何团队成员都不应该公开强迫他们承担比他们认为他们在冲刺期间可以管理的工作更多的工作。

当Sprint积压中的所有故事和任务都已提交时,Sprint计划会话的第二部分结束。

为了获得额外的责任,每天都有一个站立式会议(Scrum),其中团队成员将他们所做的事情,他们将要做的事情以及他们面临的障碍联系起来。每日Scrum用于保持团队协调和正常进行。关于Daily Scrums的更多讨论可以在第5章找到。

该团队还通过在燃尽图上绘制完整的故事点来跟踪其进度。这些图表是设计的
显示团队在实现目标方面的表现。如燃烧图表所示,任何与预期速度的偏差都必须由ScrumMaster解决。

在Sprint计划会话结束时,团队应该能够检查表4-1中核对表中的所有项目。

表 4-1    Sprint计划清单
清单项目完成?Y / N
清除冲刺目标
Sprint Backlog中的积压项目(又名,故事)
每个故事/任务的接受标准
估计的故事/任务
团队成员对故事/任务的承诺

所有事情都被考虑:Sprint的最终评论

当Sprint完成后,会有一个Sprint结束时的审查会议。 ScrumMaster,Scrum团队和产品负责人都参加了。产品负责人还排列了几位可以参加的客户。

该过程如下:

  1. 在End-of Sprint会议上审查sprint的目标,以查看是否已满足sprint。
    列出每个故事和/或任务及其验收标准,以查看是否已满足这些标准。
  2. Sprint的结果将呈现给产品负责人(以及可用的客户)。
    理想情况下,这是所需产品的潜在可交付成果。产品负责人确定Sprint End-End Review的结果是否可接受。
  3. 如果一切都可以接受,则计算Sprint速度作为未来冲刺的指导。

内部审视CA Agile Vision

使用CA Agile Vision进行Sprint计划非常简单。本节将向您介绍CA Agile Vision的内部视图,以及如何将故事从待办事项拖动到sprint以及如何跟踪Sprint进度。

如何将故事移至Sprint积压

您可以轻松地从产品backlog创建Sprint积压。只需按以下步骤操作:

  1. 在“待办事项”页面中,显示要使用的项目的待办事项。
  2. 单击“显示Sprint”链接以显示Sprint待办事项,并过滤视图以显示要使用的sprint的待办事项。
  3. 选择您计划的发布,冲刺和团队。
  4. 从项目待办事项中单击并拖动用户素材,然后将其放入sprint backlog中

用户素材将添加到sprint backlog并分配给选定的团队。团队的速度反映了新故事给团队的分配。

您可以在图4-1中的CA Agile Vision中看到Sprint待办事项创建的示例。

跟踪Sprint进度

CA Agile Vision为您提供了许多方法来跟踪Sprint进度并在团队的所有成员之间共享该信息。团队成员,产品负责人和管理人员可以通过执行以下操作来监控sprint任务并跟踪团队成员进度:

  • 在“CA Agile Vision仪表板”页面中查看Sprint进度图表和报告,在“Sprint详细信息”页面中查看用户故事和图表
  • 查看和更新​​Sprint信息和用户故事详细信息页面中的注释和注释。
  • 监控项目虚拟墙的进度(见第5章)

Sprint详细信息页面上的故事和图表显示了图表,以提供冲刺进度的综合报告。视图可以通过项目,sprint和团队进行过滤。

例如,Sprint燃尽图表比较了团队在用户故事上燃烧的实际小时数与sprint的预期燃尽率。

x轴显示sprint中的天数。包括周末在内的所有日子都被视为有效的工作日。 y轴显示sprint中的任务小时数。剩余实际小时数显示为绿线。预期的燃尽或指南以红色显示。线上的每个点都是表示冲刺中一天的数据点;你可以在图4-2中看到一个例子。


敏捷模型(3)理解Scrum中的角色

学习目标

完成这个单位后,你会知道:

  • 获得承诺
  • 确定关键人物
  • 确定单个或多个Scrum团队是否适合您
  • 使用CA Agile Vision创建团队

任何Scrum项目的重点都是Scrum团队。 Scrum团队使项目成为现实 – 团队是需要完成工作的引擎。

构建Scrum团队的条件很少是理想的,这就是Scrum开发结构的所在.Scrum开发的整个结构有助于将团队成员聚集在一起并激励他们。团队成员知道他们不是在真空中运作;他们对整个团队和客户负责。

本章让您熟悉Scrum团队及其代表。您可以探索小型团队和大型团队,以及如何应对每个团队的挑战和胜利。

承诺的需要

在构建Scrum团队时,对承诺的需求至关重要。 Scrum团队对团队成员做出了很多承诺。团队需要将学科和驱动内部化,以便看到项目完成。如果团队成员无法提交,Scrum流程就会面临危险。

你是火腿还是鸡肉?

Scrum团队涉及两种类型的人:那些忠诚的团队成员和那些仅仅参与其中的人(需要偶尔的专业知识)。
Scrum人员讲述了一个笑话,说明了犯罪与参与之间的区别:有一天,一头猪和一只鸡在路上行走,鸡说:“嘿,让我们开一家餐馆吧。”
“当然,”猪说。 “我们应该怎么称呼它?
“怎么样’火腿和鸡蛋’?”
“不要这么认为,”猪说。 “我会坚持,但你只会参与其中。”

提交能力是团队自我赋权的直接结果。

当然,这假定团队成员有一些事情需要承诺。虽然可以鼓励承诺
ScrumMaster(详见“了解关键人员”),每个团队成员的实际承诺取决于该成员。与团队其他成员一起提交和拥有项目的能力是成为优秀团队成员的一部分(需要大量指导和观看时钟的人可能不是Scrum团队的优秀候选人)。

欢迎来到Scrum团队

Scrum团队是项目开发的引擎。当团队运作良好时,其效率和动力是无与伦比的。当团队运作不良时,它可能会带来重大挑战,其中可能包括更换团队成员。

当你开发任何团队时,请记住团队应具备几个一般品质。这些都是理想的要求 – 当然任何组织都必须使用它拥有的东西。 ScrumMaster的责任之一就是向那些尚未达到速度的人传授Scrum方法。有关ScrumMaster的更多信息,请参阅本章后面的“了解关键人员”。

团队属性包括存在

  • 经验丰富
  • 动力
  • 承诺(全职)
  • 主管
  • 为自己的工作感到自豪
  • 能够与他人合作
  • 负责任
  • 愿意团队合作
  • 自治

自主是团队中最重要的部分之一。创建一个运作良好的团队的一部分涉及为成员提供项目所需的自主权。 Scrum将决策水平向下推进,团队成员必须感到自己有自主权才能真正投入到项目中。

自治与许多重治组织中普遍存在的环境相矛盾。自治通常是开发人员缺乏的一件事,也是阻碍他们完全投资于项目的因素。在某些组织中,程序员必须获得对代码的每次修改的批准,无论多么小,来自经理。这种控制通常会对团队产生不利影响。

Scrum团队需要很好的衡量真正的自主权。在某种程度上,团队成员必须相信他们“拥有”项目,然后才能引以为傲,完全承诺并内化项目的目标。如果您无法授予Scrum团队足够的自主权以使流程有效,那么在转换到Scrum时您将面临挑战。对项目负责意味着拥有它,这就是Scrum团队的工作方式。

了解关键人员

Scrum围绕Scrum团队展开。 Scrum团队让这一切成为现实;他们立刻成为Scrum的能量和承诺的源泉。预计Scrum团队将举行每日面对面会议,团队成员将讨论他们前一天所做的事情以及他们下一步要做的事情。

Scrum团队由三个部分组成:ScrumMaster,Scrum团队本身和产品负责人(客户代表)。

团队负责人:ScrumMaster

ScrumMaster是Scrum团队的团队领导者。由ScrumMaster确保团队满足产品负责人定义的冲刺目标。 ScrumMaster使项目顺利进行,并使其保持正常运行。以下是ScrumMaster需要的一些属性:

  • 负责实施Scrum方法,价值观和实践
  • 负责向产品负责人和团队传授Scrum
  • 担任团队负责人(又名项目经理或团队负责人)
  • 促进每日Scrum会议,团队成员面对面地互相报告
  • 消除团队路径中的障碍和障碍
  • 处理团队成员问题/问题
  • 最终负责项目的成功

理想情况下,经验丰富的团队聚集在一起,化学工作将使项目开始实施。但ScrumMaster是团队领导者,而ScrumMaster的工作就是确保所有团队成员都有动力。正如您所料,使用经验丰富的ScrumMaster比使用第一次使用ScrumMaster更容易,就像与经验丰富的团队成员一起工作更容易。
 
在Scrum新手中,ScrumMaster可能会花费大量时间向团队(和产品负责人)教授Scrum方法,目标和价值观。

客户代表:产品负责人

在Agile和Scrum中,客户始终通过称为产品负责人的代表出现。产品负责人负责为Scrum团队提供项目要求。

产品负责人应该随时可用,最好与Scrum团队并置。通常是产品负责人

  • 是产品经理本人,并根据要求进行讨论并有效地收集要求
  • 了解项目的所有要求-不应该不断地引用第三方
  • 是客户的声音
  • 了解客户希望产品做什么,并能够立即提供该信息
  • 团队始终可以访问
  • 管理产品积压
  • 收集客户的要求/故事
  • 提供要求/故事的验收标准
  • 优先考虑要求/故事(Backlog Grooming)
  • 决定实际交付的内容
  • 验证评论中提供的功能/产品(Sprint末尾评论)

产品负责人可能是一个具有挑战性的角色,因为它涉及对Scrum团队和客户的承诺。这也是一个艰难的角色,因为产品负责人有责任正确地获得项目要求;如果这些要求是错误的,那么团队就会进入
因此,错误的方向,责任在于产品负责人。
 

重要的是,团队可以将产品负责人视为项目要求的最终来源 – 当出现问题时,他就是最佳人选。很多时候,缺乏知识是标准项目的瓶颈,因为客户代表不确定答案,需要引用其他人,这通常涉及电话留言,会议以及不可避免的延迟。

虽然不是强制性的,但产品负责人也可以参加每日的Scrums。这可以极大地帮助维持客户与Scrum团队之间的有效沟通。

团队本身

组成团队的人是Scrum团队的推动力。他们应该是经验丰富的自我驱动的专业人士,能够与他人合作,但也有足够的自主权来承担项目的责任并拥有它。

团队需要体现成功完成项目所需的一切。团队的属性通常涉及以下内容:

  • 通常约7至12人
  • 跨职能处理所有必要的任务(例如,包括程序员,架构师,设计师,QA/测试人员,技术作家和CM/构建工程师)
  • 全职(承诺)
  • 自我组织和自我指导
  • 自治
  • 动力
  • 拥有该项目
  • 理想情况下并置(虽然分布式团队是可能的,但它们可能会使流程复杂化)

团队从产品待办事项中获取项目,并根据产品负责人设置的优先级将其移至sprint backlogs。他们估计短跑中每件物品需要多长时间。他们跟踪燃尽图表的进度。他们完成了工作并获得了项目的所有权。

一起工作还是分开?

Scrum旨在非常面对面。团队成员应该与ScrumMaster保持联系。预计将在Scrum团队中进行持续的与工作相关的对话。但这种情况可能并非总是可能发生。

沟通对任何Scrum团队都至关重要 – 包括内部和外部沟通。有关团队内部沟通的更多信息,请参阅第5章。

并肩队伍

理想情况下,您需要一个并置的Scrum团队。在Scrum方面,面对面交流是最好的。团队成员之间的沟通应该没有障碍,这意味着身体和专业障碍。

如果开发人员有设计问题,他应该能够立即得到设计师的回答,例如,没有电话标签,未退回的电子邮件等引入的延迟。

出于这个原因,Scrum专家经常说Scrum团队不仅应该住在同一栋楼里,而且应该住在那栋楼内的同一个房间里。如果有人需要答案,他们应该可以自由地走到某个人的位置或隔间,并迅速得到答案。

搭配也培养了团队精神。例如,如果你有一些人在一起工作很晚,也许他们可以一起吃披萨。休息一下工作并进行非工作相关的互动也很重要。我们的想法是让所有团队成员进行面对面的混合,以最大限度地提高工作效率,让所有团队成员保持参与和沟通。

处理分布式Scrum团队

有时,不可能并置整个Scrum团队(参见前面关于配置的部分)。虽然不一定理想,但可以与分布式Scrum团队合作。  

分布式团队发生在大型组织内时,团队成员可能遍布世界各地,尽管这对Scrum流程提出了一些挑战,但仍有办法尽可能地应对这些挑战。

当您拥有分布式团队时,您将面临几个重大挑战:

  • 时区差异:相隔11.5小时的时区(例如加利福尼亚和海德拉巴)的开发人员无法快速轻松地分享想法和信息或提供即时反馈。
  • 语言和地区差异:语言和地区假日,交通和通信基础设施的差异也限制了会议的召开时间和方式。
  • 多个文档副本:Scrum开发取决于记录任务以及产品和sprint积压,燃尽图,任务列表等的进度。当您为团队维护多个位置时,这些文档的多个副本很容易变得不协调。
  • 每日站立会议的不可能性:如果开发人员位于分布广泛的地理位置,则可能无法实现每日Scrum。

有关如何处理其中一些挑战的更多详细信息,请转到第5章。

与分布式Scrum团队合作的基础是文档协调。文档为Scrum团队设定目标并跟踪进度,并确保每个人都拥有所有计划和图表的当前副本,这对于以分布式方式工作至关重要。

与多个Scrum团队合作:Scrum of Scrum

可能会发生这样的情况:在较大的项目中,一个Scrum团队是不够的。假设你正在设计一个完整的软件操作系统,例如,有数百万行代码。这样一个项目需要一个7人的Scrum团队很长一段时间才能完成。
所以你创建了一个100人的Scrum团队。 。 。等待,等待,等待 – 这与Scrum哲学相反,后者坚持Scrum团队保持小规模。那么解决方案呢?

应该在多个Scrum团队之间划分较大的项目以完成工作。为了让更大的项目顺利进行,Scrum专家建议组建三个额外的scrums,或“Scrum of scrums:”

  • 项目进展Scrum的Scrum
  • Scrums的架构Scrum
  • 产品所有者Scrum的Scrum

这些中的每一个都是“scrum的scrum”,因为它们可以由来自每个从事该项目的Scrum团队的团队成员组成。每个Scrum of Scrums都有不同的用途。

介绍项目进展Scrum的Scrum

Scrum的主要Scrum通常关注Scrum团队的项目进度和依赖关系。这个小组确保scrum团队为sprint选择高优先级故事并有效地分解它们。
它使整个项目保持正轨 – 这在大型项目中尤为重要。

Scrum of Scrums通常由ScrumMaster,开发和QA主管以及负责整体发布的产品所有者组成。 Scrum的Project Progress Scrum负责以下事项:

  • 监控每个Scrum团队的进度和整体发布
  • 监控每个Scrum团队和整个项目的速度
  • 识别并处理超出单个Scrum团队范围的任何阻塞问题

Scrum的项目进展Scrum负责这一点 – 整个项目的进展。他们应该找到

在Scrum团队遇到问题之前阻塞并修复它们。 Scrum of Scrums也可以作为整个项目的“指导委员会”,使项目保持正轨。

理想情况下, 项目 进展情况 的Scrum 的 Scrums 满足 日常 的 从每个Scrum的一个代表15分钟 队。

理想情况下,Project Progress Scrum of Scrum每天与每个Scrum团队的代表会面15分钟。

介绍Scrums的架构Scrum

Scrum的Scrum Scrum与在整个项目中维护通用架构的标准有关。

这个Scrum通常由整个项目的技术领导者和首席架构师组成。 Scrums职责的架构Scrum包括

  • Scrum团队的决策会影响整个产品架构的整体方向
  • 制定所有Scrum团队运作的共同战略或标准
  • 确定可避免Scrum团队重复工作的领域
  • 作为一般的跨团队沟通的焦点架构Scrums包括以下最佳实践:
  • 对于Sprint持续时间为2到4周的项目,每周见面一小时。
  • 在会议开始前2天发布会议议程以及该会议要涵盖的主题。
  • 收集问题并分配给较小的工作团队。

介绍产品负责人Scrum

产品所有者Scrum的Scrum(也称为需求Scrum)是一个Scrum,旨在保持Scrum团队之间协调项目的总体需求。

此Scrum通常由项目中每个Scrum团队的产品所有者组成。其职责包括

  • 传达需要添加到各种Scrum团队的产品或发布积压的故事
  • 解释产品积压的变化,因为Scrum团队一直在为这些Scrum团队的成员提供服务
  • 确定Scrum团队之间故事的重叠依赖关系,并努力减轻这种重叠
  • 根据需要将故事从一个Scrum团队的产品积压转移到另一个团队的产品积压

产品所有者Scrum的Scrum就是要确保各个Scrum团队正在开展的工作要求保持协调并反映客户的需求。

理想情况下,产品所有者Scrum of Scrums应该在所有Scrum团队的Sprint计划会议前一周召开2到4个小时,目标是每个团队的Backlog优先并准备好进行规划,同时避免不必要的重叠。

内部审视CA Agile愿景:创建团队

在CA Agile Vision中,可以轻松创建新的Scrum团队并添加新成员。通过并置或分布式团队,CA Agile Vision使团队成员之间的协调和沟通变得简单。

要创建新的Scrum团队,请按照下列步骤操作:

  1. 单击“导航器”菜单,然后从“资源管理”菜单中选择“团队”。
    出现“团队”页面。
  2. 单击“新建团队”。
    将出现New Scrum Team页面。
  3. 填写以下字段:
    •Scrum团队名称
    •活动(指定团队是否处于活动状态)
    •预期速度(定义Scrum团队认为在冲刺期间可以实际完成的估计总故事点)
    •故事点比例(定义团队使用的故事点比例。输入以逗号分隔的数字列表;默认为斐波那契序列1到21)。
    •项目(项目的唯一名称)
    •Scrum会议时间和地点(指定每日Scrum会议的时间和地点)
    •每天的小时数(定义所有团队成员每天为团队积极工作的基本小时数)
    •Scrum团队域(指定团队的URL)
  4. 单击“保存”。
    将出现“Sprint分配”页面。
  5. 单击“跳过此步骤”,您可以稍后将团队分配给冲刺。
    将出现Scrum Team Detail页面。在此页面中,您可以向团队添加成员。
  6. 转到Scrum Team Members部分,然后单击New Scrum Team Member。
    将出现Scrum团队成员编辑页面。
  7. 编辑以下字段:
    •成员名字
    •角色(指定成员在团队中的角色)
    可能的值包括Member,ScrumMaster和Product Owner。
    •开始日期(指定成员在团队中开始的日期)
    •团队成员备注(指定有关团队成员的其他相关信息)
    •Scrum Team(指定要添加成员的Scrum团队的名称)
    默认是当前的Scrum团队。
    •活动(指定团队成员是否是团队的活跃部分)
    •分配(%)(指定成员分配给此团队或项目的时间百分比)
    •结束日期(指定成员参加团队的日期)
  8. 要将此人添加到团队,请单击“保存”。
    重复其他团队成员的过程。

有关CA Agile Vision中成功创建的团队,请查看图3-1。设置团队成员后,编辑或删除它们很简单 – 只需单击名称旁边的匹配链接即可。