产品待办事项的细化
Scrum

产品待办事项的细化

产品待办事项的细化,也称为修整,已经成为敏捷团队几乎不可或缺的一部分。正如其名称所示,它的作用是细化产品待办事项的内容。 产品待办事项细化过程 这个产品待办事项细化仪式在新一代Scrum中非常流行,通常每周都会在特定时间进行。 通常建议每次仪式的持续时间不要超过一小时;如果产品负责人不需要更多时间,也可以只持续十分钟。 实际上,这次会议对于产品负责人非常有用,因为它将允许他细化产品待办事项的内容,以便为下一个冲刺进行组织。 在产品待办事项细化期间,产品负责人将向开发人员提供用户故事,这些故事符合整个团队先前定义的“准备就绪”的定义。 1/ 理解用户故事 然后,开发人员将试图理解用户故事,并一起讨论它。如果他们对用户故事有疑虑,他们可以利用这个时刻向产品负责人请求更多信息。通常情况下,产品负责人会根据开发人员的意见稍微修改用户故事的内容。 然后,在这次讨论中存在两个结果,有时很快,当从一开始就理解了这张票: 开发人员确认了这张票,然后可以进行估算。 开发人员不理解这张票;产品负责人将不得不在下一次会议之前复查他的材料。 2/ 估算用户故事 开发人员将共同估算用户故事所需的时间或故事点数。敏捷团队通常建议优先考虑故事点的估算。 有一些非常著名的方法,比如扑克规划,用于估算用户故事。 当估算完成后,产品负责人提供下一张票。 产品待办事项细化有哪些好处? 这个仪式为Scrum团队提供了许多好处。 它允许产品负责人在冲刺计划会议上提前准备好冲刺待办事项,以便根据下一个冲刺允许的故事点数量进行组织。 因此,所有这些上游工作都极大地减少了冲刺计划会议的时间,而无需在会议中进行这项估算工作和实时准备冲刺待办事项。 产品待办事项细化的结论 强烈建议在您的Scrum流程中进行产品待办事项的细化;这个仪式已经包括在Scrum指南中,以使其成为100%官方。对于那些参与 #NoEstimate 运动的人来说,估算部分将不再是必要的,但继续进行细化部分仍然是建议的。这个仪式为您的冲刺的顺利进行带来了许多重大的好处。

燃尽图表
敏捷文化

燃尽图表

燃尽图表(有时被称为燃尽图)通常在Scrum团队中使用,它作为一个跟踪工具,用于监控Scrum团队工作的进展。保持最新的燃尽图表可以为潜在障碍提供宝贵的见解,并帮助迅速解决它们。 虽然Scrum团队非常熟悉使用燃尽图的做法,但本文旨在面向对广泛采用的Scrum实践感兴趣的新手。让我们深入探讨如何设置燃尽图。 创建基本的燃尽图表模板 要启动燃尽图表,首先要建立一个垂直轴,表示故事点的数量。总结当前冲刺计划的所有用户故事的故事点(放在上方)。 提示:我强烈建议在您的燃尽图上放置贡献到冲刺目标的冲刺项目的总故事点。并非所有项目都与目标相一致。 接下来,将冲刺的工作日分配到水平轴上。您可以使用数字或字母来表示每一天,后者通常更容易阅读。 有了这个基础,绘制理想轨迹以达到冲刺目标。重要的是要注意,垂直轴代表“剩余的故事点”,而不是“已完成的故事点”。在冲刺开始时从35开始,然后在冲刺结束时逐渐减少到0。 然后,可以绘制一条红色的线性线,代表冲刺的理想进展轨迹,如下所示: 重要的是要承认,目标不是严格遵循这条线。目标是为跟踪冲刺进度提供一个参考点。如果出现问题,Scrum Master可以分析情况并找到解决方案。 一旦模板准备好,每次冲刺都需要在冲刺开始时调整轴值(使用Excel或Google表格等工具)。这样可以避免每次都需要重新创建整个图表。 保持最新的燃尽图表 要保持燃尽图表的最新状态,我建议将其可视化显示(例如,放在墙上)并每天更新一次。 例如,考虑我们的模板:如果一个具有2个故事点的用户故事在星期二完成,更新图表时,绘制一个表示减少2个故事点的蓝色曲线,如下所示: 事实上,这是一个简单的过程。 通过每天重复这个实践,您可以保持对冲刺进展的清晰视图。 然而,即使蓝线出现在红线上方,也要在引发警报之前谨慎行事。如前所述,严格遵循理想轨迹是不可行的。上下文和项目具体情况可能导致各种结果。 当燃尽图表的蓝线上升时 偶尔,您可能会注意到燃尽图表上的线(在一天内)上升。其解释很简单:产品负责人在冲刺中引入了一个新的用户故事。 如果这个新的添加与冲刺目标一致并得到开发团队的认可,线可能会上升。 然而,如果额外的用户故事与目标无关,避免调整曲线。在燃尽图表中简单地忽略这个用户故事。考虑将其标记为“障碍”,以表示其对流程的干扰。 作为Scrum Master,我建议遵循这一准则,特别是在观察到延迟时,蓝色跟踪线不应无故上升。燃尽图应该只反映在冲刺开始时承诺的用户故事(或直接为冲刺目标做出贡献的故事)。 结论:燃尽图 对于Scrum团队来说,燃尽图不是秘密。为什么不考虑在您的团队内使用燃尽图呢?

敏捷金字塔:从思维方式到实践!
敏捷文化

敏捷金字塔:从思维方式到实践!

我非常喜欢敏捷金字塔的这种简化表现方式,它提醒我们在推动企业敏捷化过程中绝不能跳过任何步骤。我采用了由Nicolas Delahaye和其他敏捷教练制作的图示。 敏捷金字塔 敏捷金字塔的表现方式提醒我们,要从顶部开始,逐步向下发展,才能真正实现敏捷化,无论是在敏捷转型还是培训的情况下。 这就是敏捷金字塔的外观: 我们永远不能说得太多,但在实施敏捷实践甚至敏捷框架之前,首先要理解敏捷思维方式。正是这种敏捷思维方式将帮助您理解执行这些实践的重要性,或者为您提供指导,使您能够进行“敏捷”的Scrum。 从敏捷思维方式到敏捷宣言 当正确理解敏捷思维方式时,重要的是要充分理解敏捷宣言的四个价值观,这是由17位计算机项目管理专家创建的宣言。这四个价值观还提供了12个基本原则,以更好地理解从中产生的各种敏捷方法的预期结果。 正是这些价值观将使团队更好地理解Scrum、Scumban等框架的存在原因。要正确应用它们,需要理解其背后的理念。 有时候我们看到团队提前六个月准备了详细的待办事项清单…有时候我们看到他们将大型需求拆分为多个用户故事(成功与否不一),这通常是因为这些团队没有理解敏捷思维方式和敏捷宣言的价值观。 您可以随时查看我们的完整文章,以更好地理解这四个价值观。 从敏捷宣言到框架(然后到实践) 当敏捷宣言被充分消化后,团队可以选择他们认为最适合其情境的框架;实际上,对于更成熟的团队,完全有可能自行创建框架。 只有在完全理解敏捷思维方式和敏捷宣言的情况下,团队才能真正从实施敏捷方法中获得各种好处。 然后,团队可以选择适当的实践,以补充已制定的框架。这时,团队才真正变得敏捷。 正确遵循这个敏捷金字塔有助于避免只是进行一场大型瀑布模型内的实施阶段,这就是所谓的“水瀑布敏捷”。 敏捷金字塔总结 尽管有些人可能认为这种表现方式过于简单,但它的好处在于提醒我们不要在不理解其用途和基础的情况下实施所谓的敏捷方法。 请随时使用这种表现方式,以便身边的所有参与者都明白,投资于采用敏捷思维方式是实现成功的前提。

RACI矩阵 - 我的建议
敏捷文化

RACI矩阵 – 我的建议

RACI矩阵(Responsible, Accountable, Consulted, Informed)是项目和流程责任管理的有力工具。它提供了每个涉及个人或组的角色的清晰概览,从而澄清了治理结构。 以下是一个简单的RACI矩阵示例(仅作参考)。您可以查阅我们更详细解释这一概念的文章:RACI概念。 然而,为了真正有效,定期对其进行优化是至关重要的。 在本文中,我们将探讨优化RACI矩阵的方法,将其转化为项目和流程管理中的战略资产。 RACI矩阵的建议 澄清角色和责任 优化RACI矩阵的第一步是确保每个角色都有明确定义。通过明确定义每个人或组的责任,避免模糊不清,这将有助于建立团队的信任和理解。 吸引利益相关者 有效的RACI矩阵需要所有利益相关者的积极参与。与他们密切合作,以确定适当的角色,并确保每个人都理解他们被分配的期望。利益相关者的参与增强了承诺和责任。 考虑技能和专业知识 每个个人或组都应分配适合其技能和专业知识的任务。确保分配到特定角色的人具备成功所需的技能。必要时,提供培训或额外资源。 对工作负载保持现实 避免让一个人承担过多责任。平衡分配的责任有助于防止超负荷工作,并保持团队内的健康工作平衡。确保每个人能够有效地专注于自己的任务。 定期更新 RACI矩阵不是静态的。它必须随项目或流程的发展而演变。计划定期审查以确保它与不断变化的需求保持一致;这可以通过回顾等方式来实现。新的利益相关者或范围调整应纳入考虑。 促进沟通 将RACI矩阵用作沟通工具。确保所有利益相关者理解它的运作方式以及对项目或流程成功的重要性。开放的沟通加强了理解和承诺。 避免过于复杂 过于复杂的RACI矩阵可能适得其反。保持简单易懂。集中精力于要点,以避免不必要的混淆。 使用项目管理工具 使用项目管理软件,如Microsoft Project(用于传统项目管理)或Jira(用于敏捷项目管理),可以将RACI矩阵的创建和管理集成到项目工作流中,从而简化工作。这些工具有助于实时协作和更新。 正式化协议 确保每个人或组都理解并接受他们在RACI矩阵中的角色。通过会议、签名或文件来正式化协议,以加强承诺和责任。 保持灵活 根据项目或流程的发展,准备调整RACI矩阵中的角色和责任,以反映实际情况。灵活性是效率的关键。 结论 – RACI矩阵的建议 一个构建良好的RACI矩阵是项目和流程管理的重要资产。对治理的明确定义将有助于减少项目生命周期中的冲突和时间浪费。 通过遵循这些建议,您可以改进RACI矩阵,使其成为一种战略工具,促进沟通、透明度和团队在责任管理中的成功。

不要忘记SAFe中的IP迭代
SAFe

不要忘记SAFe中的IP迭代

许多企业往往忽略了IP(迭代计划)迭代的重要性,但它对于SAFe应用的正常运行至关重要。将其视为普通迭代可能会导致许多问题。 IP迭代 正如人们在SAFe培训中学到的,标准PI(程序增量)由五个两周的迭代组成,其中最后一个是IP迭代。 正如您所看到的,第五个迭代不主要用于直接在产品上工作。但是,如果PI的目标延迟达成,它也可以用于此目的。 以下是SAFe提供的关于此特定迭代中包括的工作的示例: 这个迭代允许您: 在必要时完成剩下的工作。 进行为期2天的PI计划(以及准备工作)。 利用这段时间培训团队。 参与创新活动。 绕过填充此迭代,就像许多企业一样,可能会给团队带来额外的压力。这种失去动力可能会导致生产率降低。 此迭代对于团队的整体平衡至关重要,有助于避免由于项目进展不顺利而增加的压力。此迭代还作为一个缓冲区,用于完成PI的初始目标,当这些目标未完全实现时。如果团队将此迭代用于任务,那么就没有了缓冲区,而未达到的目标通常会导致极大的失望。 结论 如果您的公司没有遵循SAFe旨在实现的无缝运行的第五个IP迭代,请提醒他们它是框架的正式组成部分,具有许多积极的方面。还强调观察到的延迟和与未实现的目标相关的失望(通常在不执行时发生)。

持续交付在软件开发中的应用
开发运营

持续交付在软件开发中的应用

持续交付是现代软件开发的重要组成部分,它允许团队更频繁、更高效地发布高质量的软件。这一实践包括自动化软件交付过程的各个阶段,确保代码更改始终处于可部署状态。通常,持续交付与持续部署混淆在一起,但这两个概念之间存在明显的区别。 持续交付 持续交付是敏捷软件开发的一种方法,其主要关注点是随时保持软件在可发布状态。以下是持续交付的一些关键方面: 目标 持续交付的主要目标是维护一个开发环境,其中任何代码更改都可以轻松部署到生产环境,尽管它们并不会自动部署。 人工干预 持续交付需要人工干预,以决定何时启动发布,通常在经过充分测试后。 测试环境 自动化对于持续交付至关重要。代码更改将自动部署到测试环境(例如,预发布环境或预生产环境),以确保它们准备好进入生产环境。但它们不会自动部署到实际的生产环境中。 质量控制 质量在持续交付中至关重要。在考虑发布之前进行严格测试。如果测试失败,更新将不会被推广到生产环境。 与持续部署的区别 持续部署经常与持续交付混为一谈,但它们之间的区别至关重要: 目标 持续部署的主要目标是自动化整个代码更改的部署过程,无需人工干预。代码更改将在通过测试后立即部署到生产环境。 全面自动化 持续部署涉及全面自动化。一旦代码更改经过验证和批准,它们将立即在生产环境中发布。不需要人工干预来决定何时进行部署。 立即部署到生产环境 一旦代码更改符合质量标准,它们将立即在生产环境中部署,使新功能立即可供用户使用。 速度和频率 持续部署的目标是加速发布流程,频繁交付新功能或错误修复。更改可以多次每天或甚至更频繁地部署。 总之,持续交付确保代码更改始终处于可部署状态,准备好进入生产环境,但将部署的决定留给了开发团队。另一方面,持续部署自动化了整个过程,并在通过测试后立即将代码更改部署到生产环境。选择这两种方法之间取决于组织的具体需求、对风险的容忍度和开发文化。

项目管理的三重制约
敏捷文化

项目管理的三重制约

项目管理是一个复杂的过程,需要平衡各种因素,以确保成功完成项目。在这些因素中,“三重约束”通常被认为是项目管理领域的一个关键概念。这些约束通常被描述为必须平衡以实现项目目标的三个关键元素。在本文中,我们将探讨项目管理中的三重约束及其重要性。 三重约束 范围 范围指的是必须完成的具体目标、可交付成果、任务和特性,以使项目成功。项目的范围提供了一个详细的描述,说明了必须实现的内容,并作为项目团队的参考点。对范围的任何更改或添加都可能直接影响项目的时间和成本。 时间 时间是项目管理中的一个关键约束。它涉及设定一个特定的时间框架,必须在其中完成项目。项目的时间表确定了里程碑、期限和任务的持续时间。项目时间表的任何延迟都可能影响项目的范围和成本,因此有效的时间管理对项目成功至关重要。 成本 成本是指分配给项目的预算。它涵盖了与项目相关的所有费用,包括劳动力、材料、设备和一般开支。项目经理必须确保项目保持在预算内,因为任何超支都可能影响项目的范围和时间。有效的成本管理对实现项目目标至关重要。 三重约束之间的关系 通常使用项目管理三角形来表示三重约束之间的相互关系。在这个三角形中,每个约束被表示为一个角,显示改变一个约束将不可避免地影响其他两个约束。例如: 如果范围增加(增加了更多的工作),时间和成本可能会增加。 如果项目的时间缩短(时间紧迫),成本可能会增加,范围可能会减少。 如果降低成本(削减预算),可能需要调整范围,并可能需要更长的时间来完成项目。 平衡三重约束 项目经理负责在三重约束之间找到微妙的平衡。实现这种平衡对于实现项目目标以及确保各方满意至关重要。以下是一些有效实现这种平衡的策略: 优先考虑范围:清晰地定义项目的范围,并确保与项目目标一致。在批准范围的任何更改时要小心,并评估其对时间和成本的潜在影响。 有效的时间管理:制定详细的项目时间表,考虑任务依赖关系、关键路径和潜在风险。及时监测进展,并立即解决任何延误,以保持项目按计划进行。 严格的成本控制:实施强大的成本管理体系。跟踪开支,保持准确的记录,并寻找降低成本的机会,同时确保不影响质量。 沟通与利益相关者管理:确保将所有利益相关者及时告知有关三重约束的任何更改或问题。管理他们的期望,并让他们参与决策过程。 结论 理解项目管理的三重约束,即范围、时间和成本,对于成功交付项目至关重要。这些约束之间的微妙平衡确保项目达到其目标,同时保持质量和利益相关者的满意度。项目经理在有效管理这些约束方面起着至关重要的作用,使他们成为项目管理领域的关键人物。

敏捷和 Scrum 之间的区别
Scrum

敏捷和 Scrum 之间的区别

敏捷已经成为软件开发和项目管理领域不可或缺的一部分。在这一背景下,两个最常用的概念是Scrum和Agile。尽管它们经常相互关联,但这两个术语并不代表相同的事物。 在本文中,我们将探讨Scrum和Agile之间的区别和关系,以帮助您更好地理解它们如何共同发挥作用。 敏捷和 Scrum 之间的区别 敏捷:一个概念框架 敏捷首先是一组原则和价值观,强调灵活性、协作和适应软件开发中的变化;然而,目前,敏捷越来越涵盖整个企业。 敏捷出现在开发领域,作为对传统的重型和高度计划的开发方法的反应。它倡导持续交付、用户的频繁反馈以及团队内部和与利益相关者之间的透明沟通。 Scrum:一种工作框架 Scrum是项目管理中最常用的敏捷框架之一;然而,它强调基于精益和经验的方法。 与敏捷不同,敏捷是一组价值观和原则,而Scrum是一个具体的工作框架,以有条理的方式实施这些价值观和原则。以下是Scrum的主要组成部分: Scrum角色 产品负责人:负责定义需求和优先处理待办事项。 Scrum大师:作为Scrum团队的协调者,负责清除障碍和应用Scrum原则。 开发人员:一组专业人员,致力于完成需求。 Scrum事件 冲刺:定义的时间段(通常为2到4周),团队在其中完成待办事项。 冲刺计划会议:团队在冲刺期间选择要完成的项目。 Scrum日常会议:开发人员每日协调会议,讨论进展和障碍。 冲刺回顾:回顾冲刺期间产品的进展(可能包括演示)。 冲刺总结:评估团队关于已完成冲刺的看法,并确定可能的改进。 Scrum文档 产品待办事项清单:待开发功能的有序列表。 冲刺待办事项清单:当前冲刺中要完成的项目列表。 增量:每次完成后不断演化的产品的功能版本。 Scrum与敏捷的关系 Scrum是常用于项目管理的工作框架,它存在于更广泛的敏捷背景中。敏捷提供了基本原则和价值观,Scrum在总体上响应这些原则和价值观。Scrum通过为产品开发提供特定的结构和角色来实施这些价值观和原则。 Scrum最重要的特点之一是它的适应性。Scrum团队鼓励根据优先事项的变化和用户反馈进行适应,这是与敏捷的价值观完全一致,例如对变化的敏感性和协作。 结论 – Scrum与敏捷 总之,Scrum是一种符合敏捷原则和价值观的工作框架。敏捷是一个全面的概念,指导了在软件开发中的灵活性和适应性。Scrum提供了实现这些敏捷目标的具体结构和实践。需要理解的是,敏捷不仅限于Scrum,还有许多其他敏捷方法和方法,每种方法都有其自身的优点和缺点。选择Scrum还是其他框架取决于团队和组织的需求和文化。

CSPO (Certified Scrum Product Owner)
Scrum

CSPO 认证(Certified Scrum Product Owner)

CSPO 认证,即 Certified Scrum Product Owner,是关于 Scrum 团队中的产品管理领域的能力和知识的认证。随着企业寻求实施敏捷实践以提高效率并应对不断变化的市场需求,它变得越来越受欢迎。在本文中,我们将更仔细地研究 CSPO 认证,它包括什么以及为什么如此有价值。 什么是 CSPO 认证? CSPO 认证是由 Scrum Alliance 颁发的,这是一个国际组织,支持全球范围内 Scrum 方法的实施。Scrum 产品负责人在 Scrum 团队内发挥着关键作用,负责管理产品待办事项并将客户需求传达给开发团队。产品负责人对确保 Scrum 团队创建高质量的产品,以满足客户要求至关重要。 CSPO 认证旨在帮助专业人士获得在这一领域出色的技能。它侧重于产品负责人的责任、产品待办事项管理、与 Scrum 团队和利益相关方的协作,以及对 Scrum 基本原则的理解。 如何获得 CSPO 认证? 要获得 […]

什么是SAFe中的团队教练
敏捷文化

什么是SAFe中的团队教练?

SAFe,即Scaled Agile Framework,是一种敏捷方法,旨在有效协调和管理大型项目。在这一框架中,有许多关键角色,用于确保敏捷开发的成功。其中一个重要的角色是团队教练。 团队教练是一位经验丰富的专业人士,他在指导敏捷团队和实施SAFe实践方面发挥着至关重要的作用。他的主要目标是支持团队采纳敏捷原则和价值观,以便他们能够高效、自主和高产地工作。 团队教练的职责 促进敏捷仪式 团队教练组织和引导敏捷仪式,如冲刺审查、冲刺计划、回顾等。他确保这些会议高效进行,确保所有团队成员积极参与。 教授敏捷原则 团队教练扮演了关键的教育角色。他向团队教授敏捷原则、软件开发最佳实践和SAFe的价值观。他帮助团队成员理解如何将这些原则应用到他们的日常工作中。 促进协作 团队教练促进团队内部和与其他团队之间的协作。他确保团队成员和谐合作,并能够有效地进行沟通。 消除障碍 当团队面临障碍时,团队教练会介入并解决问题。这些障碍可以是技术问题、团队内的冲突或任何妨碍工作进展的因素。 监控绩效 团队教练使用敏捷指标,如速度,来监控团队的绩效。这有助于衡量团队的进展并识别需要改进的领域。他必须关注整个程序递增(PI)的绩效,而不仅仅是单个团队的层面。 导师 团队教练作为团队成员的导师。他指导他们的职业发展,鼓励他们获得新技能并不断提高自己。 支持敏捷过渡 当组织决定过渡到敏捷方法时,团队教练通过与团队合作,以确保他们充分采纳敏捷实践和价值观,帮助促进这一过渡。 协助PI计划 他协助解救火车工程师(RTE)在PI计划方面的工作,这需要高效的协助。 团队教练所需的技能 出色的沟通和协调能力。 对敏捷原则的深刻理解。 能够与团队中的不同成员一起工作,包括开发人员、测试人员和产品负责人。 高度的同理心和解决冲突的能力。 熟悉SAFe框架和相关的敏捷方法。 总之,团队教练的角色是引导团队成功采纳敏捷实践,确保他们以协作、透明和高效的方式工作。团队教练在实施SAFe框架的组织成功中扮演着关键的角色。