冲刺计划:冲刺计划是Scrum的一个活动,它定义了在即将到来的 | IDCF DevOps 共
3346字,需浏览
7分钟
·
2020-12-04 12:17
原文网址:https://www.atlassian.com/agile/scrum/sprint-planning
Dave West是Scrum.org的产品负责人和CEO。他经常在主流的行业会议上作主旨分享,并且广泛发表文章和研究报告。他还是《TheNexus Framework For Scaling Scrum》和《Head FirstObject-Oriented Analysis and Design》这2本书的合著者。在Twitter上可以联系Dave@DavidJWest。 在这篇文章中,Scrum.org的CEO 戴夫韦斯特Dave West概括描述了 冲刺计划的仪式, 正如他在Scrum.org上描述的一样。Scrum.org根据Scrum指南教授Scrum。该指南被认为是敏捷世界中Scrum框架的官方指南。Atlassian的Megan Cook在下面的视频中分享了她对冲刺计划的看法:https://www.youtube.com/watch?v=yvFcRcmrMaU 冲刺计划是Scrum的一个启动冲刺的活动。冲刺计划的目的是为了定义冲刺的交付内容和完成工作的方式。 冲刺计划是由整个Scrum团队合作完成的。 与体育运动不同,Scrum鼓励你始终保持冲刺的状态,以便你可以在不断学习和改进过程中交付可工作的软件。 在Scrum中,冲刺是一个完成所有工作的固定时间段。 但是,在你采取行动之前,你必须设置冲刺周期。你需要确认实施的时间盒的长度、冲刺目标以及开始的时间。 冲刺计划通过设置议程和重点来开始冲刺。 如果把冲刺计划做得好,它还将为团队创造具有动力、挑战并取得成功的环境。做的不好的冲刺计划,可能会因为设定不切实际的期望而使得团队失去控制。 What --产品负责人描述冲刺的目的(或目标)以及用哪些待办事项来实现目标。Scrum团队决定接下来的冲刺中可以做什么,以及在冲刺中将如何做来实现这一点。 How --开发团队计划实现冲刺目标所需的工作。最终输出的冲刺计划是开发团队和产品负责人基于价值和工作量协商一致的结果。 Who --没有产品负责人和开发团队,你将无法完成冲刺计划。产品负责人通过他们寻找的价值来定义冲刺目标。开发团队需要了解他们如何实现或者如何无法实现目标。如果缺少活动中的任何一项角色,都不可能完成冲刺计划。 输入 --产品待办事项列表可以作为冲刺计划的一个好起点,它提供了一个可能成为当前冲刺一部分的“材料“列表。团队还需要以增量的方式查看现有的工作,并考虑团队的能力。 输出 --冲刺计划会最重要的输出是团队能够描述冲刺的目标以及他们如何开始朝该目标努力。这在冲刺待办事项列表中是可见的。 组织一场好的冲刺计划会议需要一定的纪律。 产品负责人必须做好准备,并结合之前冲刺评审的经验教训、干系人反馈以及他们的产品愿景,以便他们为冲刺做好准备。为了透明性,产品待办事项列表应该实时更新和改进。待办事项列表的优化是一个可选活动,因为一些待办事项列表并不需要优化。但是对于大多数团队来说,最好是在冲刺计划之前评审和改进待办事项列表的优先级。 如果你有1个两周的迭代,请在冲刺的中期进行待办事项列表的评审会议。对于团队来说,暂时放下冲刺来查看下一步的工作是很好的,它不仅能帮助准备冲刺计划,而且给当前的工作提供了不同的见解。 冲刺计划应该被限制在冲刺每周2个小时的时间范围内。 因此,例如,一个2周的冲刺,冲刺计划会议将不超过4个小时。这叫做“时间盒”,或者是为团队完成任务设置最大的时间长度。ScrumMaster有责任确保会议的时间盒概念被理解。如果团队很高兴地在时间盒结束前完成,那么活动就正常结束了。时间盒有一个最长的时间限制,但没有最短时间的要求。 将冲刺计划第一部分的重点放在冲刺目标而不是待办事项列表的细节上。通过专注于目标而不是工作本身,可以找到实现目标的明智选择。 在冲刺计划过程中,关注在先执行哪个任务、谁应该执行它以及需要多长时间,这很容易使工作“陷入困境”。 对于复杂的工作来说,在开始时你了解到的信息级别很低,大部分的信息都是基于假设的。 Scrum是一个以实践经验为依据的过程,这意味着你无法预先计划,只能通过实践进行学习,然后将这些信息反馈到实践过程中。 冲刺目标从高维度描述了冲刺的目的,但是要牢记,待办事项列表的条目也应该将结果描述在其中。 用户故事是一种很好的从客户视角来描述工作的方法。像下面这样写的用户故事,将缺陷、问题和改进集中在客户正在寻找的结果上,而不是观察到的问题上。 作为<什么类型的用户>,我想要<实现什么目标>为的是<什么原因>。 通过给用户故事增加清晰的、可衡量的结果,成果可以清晰地被衡量,这样你就能知道什么时候才算真正的完成。通过尽可能清楚地了解团队正在关注的问题,每个人在开始工作的时候都能获得所需要的透明信息。例如,在冲刺过程中让事情的描述模糊不清,比像回答一个问题一样描述事情,要糟糕得多。 不知道某件事情和含糊其辞不一样,不要忽略未知事项,他们才是实际上的工作难度。但是不要通过含糊其辞的方式掩藏它们。相反地,你应该在不清楚一些事情的时候弄清楚它们,并根据了解的信息来搭建工作的框架。 冲刺计划需要一定程度的估算能力。 团队需要定义在冲刺中能做什么和不能做什么:估算工作量和能力。估算经常和承诺相混淆。估算本质上是根据现有的知识进行的预测。例如故事点和T恤尺寸的技术给团队提供了一种解决问题的不同方式,从而增加了流程的价值。但是,它们并不是能在没有真相的情况下找出真相的神奇工具。未知数越多,估算正确的可能性就越小。 好的估算需要有一个基于信任的环境,在这个环境中,可以自由地提供信息,并且可以在追求学习和改进上进行讨论假设。如果在工作完成之后以消极的、对抗性的方式进行估算,那么很有可能未来的估算要么很大,以确保它们不会再出错,要么创建估算的时间,由于担心失败的暗示,随着团队的第二次使用而延长。 作可以探索不同的估算技术,例如T恤尺寸和故事点。不同的估算技术可能会提供看待问题的不同看法。 冲刺计划很容易陷入到细节之中,以至于你忘了冲刺计划的重点是给接下来的冲刺创建“正好的”计划。这个计划不应该成为团队后援的猴子,而应该使团队专注于有价值的产出并允许有自组织的护栏。 一个好的冲刺计划,通过定义成果和明确获得成功的计划,来激励所有人。 但是,特别注意计划太超前的问题。与其构建完整的、“冲刺每一分钟都被考虑在内”的冲刺计划,不如着眼于目标并构建足够的冲刺待办事项列表来开始冲刺。接下来,确保产品待办事项列表能够允许团队认领任务,使得团队能尽早的完成冲刺目标。 Scrum是一个旨在解决复杂问题的流程框架。复杂问题需要一个以实践为经验的过程(通过实践学习)。经验主义的过程很难计划,所以不要自欺欺人--你无法创建完美的计划。相反地,应该专注于成果并不断实践。这样即使是你正在解决的问题,它也不会很困难。 【leansoftX.com招贤令】 你不必对DevOps和敏捷已经具备很深的认知。最难的恐怕是通过我们的面试,在整个面试过程中,对每一名面试者我们都将投入超过20小时的时间与你沟通,一同工作和讨论未来发展方向。如果你能通过如此严苛的面试,就证明你已经是同行中的佼佼者。我们也不会让“专业”的HR来审核你的简历,因为一个不懂技术的人是无法判断一个技术人员的能力的,和你进行面试交流的都是业内的技术大牛和专家。 我们相信只有技术人可以懂得技术人。 扫描下方⬇️海报中二维码,输入关键词:job
请发送您的简历至:wanglin@idcf.io
浏览
113 点赞
评论
收藏
分享
手机扫一扫分享
分享
举报
点赞
评论
收藏
分享
手机扫一扫分享
分享
举报