译者序:在很多敏捷项目中,秩序诞生的标志之一是有了成文的DoR。但是项目组和需求方的折中往往也无可奈何地始于将没有就绪的需求纳入到Sprint待办事项列表,并为Sprint实施阶段带来一系列的不可控因素。为什么市场和产品人员时常要求技术人员在Sprint里实施一些没有充分精炼过的需求?如何制定DoR,并使之解决市场和技术之间的断层问题?推动DoR的过程中出现问题要怎么办?本文作者立足于自己的经验,分享了对以上问题的看法,对正在踌躇是否制定、正在制定和推动DoR的团队有一定的借鉴意义。

原文:

您有一个精炼过的产品待办事项列表,或者说是非常接近精炼的。与此同时,您正在准备做Sprint计划。万不得已的情况下,产品待办事项列表上的某些项目依旧太模糊,开发团队无法对它们进行实施。然而Sprint待办事项体现了实现Sprint目标所必需的工作,同时它指导开发。因此,“ Sprint待办事项”中的项目必须是具体的。它们不可以是模糊的。但是,开发团队需要多“具体”才能开始他们的工作呢?

如果开发团队不能完全理解产品待办事项(PBI),开发工作和开发时间往往会激增,从而导致Sprint目标未能达成,或者是交付无法符合利益相关者的期望。

开发的挑战在于获得新的想法并使它们变为现实,这实际上是在开发这些想法。这是思想从根本上的一个改变:一个想法开始时很抽象,但是开发要求这个想法在每个细节中都很具体化。这种思想上的改变最终只有在开始开发的时刻才会真正的发生。但是,如果您希望可以进行详细的计划(并且您需要详细的短期计划以使您的流程保持清晰明确),那么这些需要开发的想法必须足够具体,才能回答设计的问题。具体到什么程度?具体到足以让团队可以充满信心,来进行详细的计划。

我曾经作为自由顾问为一家小公司做一段程序。有一次,首席执行官要求我编写一些软件,并提出了固定价格。“我们可以达成一致了吗?” 他问。“不,”我说。“该软件的定义不够精确,我无法评估完成它需要多长时间。”

换句话说,在市场的世界和设计的世界之间,存在着一个断层。他们各自创造的认知以不一样的量级演进:市场了解逐步而缓慢,而设计往往会迅速聚焦(参考《实现规范 Enabling Specifications》)。它们之间需要一个组织级的边界。否则,您会同时削弱了对市场和项目的焦点。理论上,您可以通过流程的边界来实现这种分离。然而组织人员关系跨越了整个过程,因此您仍然面临着一个问题:是关注业务和价值领域,还是关注产品和技术领域,在这两者之间,人们可能依旧会举棋不定。反过来,要解决该问题,您可以从时间上来划分人员在这两个领域之间的关注点。但这会导致人员在任务上下文之间切换,众所周知,这会导致效率的降低。Scrum将这些问题从组织级别上区分开来,分成产品负责人和开发团队。而它成功的关键点在于,在这两个领域之间有一个接触点。

当您处于计划的困境中时,有一种强烈的诱惑让您想要快速做出假设,并将棘手的问题(例如详细的估算)推迟到以后。而当一个小组一起计划时,往往会面临一些隐性的同僚压力,为了使计划过程能够顺利进行而将困难的问题推迟。要解决这个问题,团队必须达成一致,最先解决最棘手的问题。为了避免在不确定的情况下开始工作,团队对截止点需要有一个明确的共识,并共同遵守这个客观标准。

在精益的思维中,反复不定是造成浪费的原因之一。如果开发团队不足以理解某些产品待办事项的真正含义,或者不能很好的理解如何开发或评估它,那么Sprint交付成果的偏差就会增加,同时这种工作还可能会导致成本,风险和不确定性增加。

因此:

每个产品待办列表上的项目必须至少满足以下条件,开发团队才能在Sprint计划会议上将其选为Sprint待办列表的候选项:

1.团队可以针对这项工作立即采取行动。

2.预计的交付物具有价值。

3.产品负责人和开发团队对它进行过讨论。

4.开发团队对它估算过。

5.它是可测试的,并且产品负责人对此测试有具体说明。

6. Scrum团队已经把它调整到合适的大小(请参阅缩小项目Small Items)。

如果产品待办事项列表的顶部具有满足这些条件的产品待办事项,而这些产品待办事项多到足以填充一个Sprint,那么它就是“就绪”的。

良好的就绪定义可以帮助指导团队处理外部依赖性。如果某个待办项取决于团队无法控制的外部事件,将其放入Sprint待办事项列表中会大大增加在Sprint结束时不能交付潜在的定期产品增量(Regular Product Increment)的风险,而您对此无能为力!您需要自始至终的在产品待办项级别上进行依赖性分析,而不能仅仅在定期产品增量级别上粗糙的管理依赖性;团队最终都需要了解产品待办项级别的依赖性,才能在生产过程中对工作进行排序。您需要考虑将涉及外部依赖性的标准作为“就绪定义”的一部分。

定义就绪与实现规范之间存在重要的相互作用。下一个Sprint的待办候选项必须最迟在该Sprint计划期间准备就绪。Sprint计划的产出物,包括产品待办事项连同产品负责人的说明和澄清,必须能让团队无所畏惧地开始实施。

Scrum团队的目标是要满足所有就绪标准,因为它致力于精炼产品待办列表,并争取在Sprint计划之前制定实现规范。这项活动的目的是使PBI不受干扰地通过“就绪门”,每个待办项仅需遵守简短的清单即可。清单对于不成熟的团队来说,允许他们能够“停止生产线”,这很重要,但更大的好处来自于可预期的约束条件,以及提前筹备PBI,让它们在Sprint开始时已完全准备就绪,从而使得整个流程畅通无阻 。

请注意,并非产品待办事项列表中的所有PBI都需要准备就绪,但随着它们在产品待办列表中的上移,它们应该朝着就绪状态迈进。“就绪”定义了那些可以进入Sprint的PBI; 与此相对,“完成”定义了那些在Sprint期间或结束时可以交付的PBI。

如果PBI没有准备好怎么办?尽管整个团队都致力于PBIs,产品负责人有责任充分做好Sprint Planning的准备,以使得团队能够不受阻碍地为当前Sprint的开发PBI候选项。在大多数情况下,“未准备就绪”表示产品负责人必须回去做更多的分析,再将PBI带回团队。Scrum的传统是,如果在Sprint计划时没有准备就绪的产品待办列表,则开发团队有权“去海边度假”,就如同于Jeff Sutherland在《 Scrum:一半的时间内完成两倍工作的艺术》(第137页,“准备完成”)中所描述的一样。这让产品负责人没有把待办列表准备好的事实变得显而易见。如果您总是“在海滩上”,则可能是工作流出了问题。您对未就绪的产品待办列表有何贡献?团队能如何帮助产品负责人?

为了区分Scrum中的就绪概念是一种与语言中的“就绪”不同的术语,Scrum的人有时会使用短语“ 就绪的就绪(Ready-Ready)”,而不是单个单词“ 就绪”。理查德·科隆法尔特(RichardKronfält)在2008年最先发布了关于“就绪定义”的正式描述。25

非常感谢Peter Gfader的评论!

【25】. Richard Kronfält. “就绪的就绪: 为可以进入Sprint计划的用户故事定义就绪.” Blogspot.dk, 2008年10月, http://scrumftw.blogspot.nl/2008/10/ready-ready-definitionof-

ready-for.html (访问于2017年11月1日).

译者:Emma

校对:Suzzi

参考资料:

(1)A Scrum Book:65 Definition of Ready

【Scrum模式语言9】准备就绪的定义(Definition of Ready - DoR )相关推荐

  1. 准备就绪的定义被认为是有害的

    本周早些时候,我和一个团队一起,讨论转向了"准备就绪的定义". 在过去的几年中,这个小想法越来越普遍,尽管我喜欢这个概念,但我不建议这样做. 实际上,我认为这很可能会降低敏捷性. ...

  2. 就绪函数的定义_准备就绪的定义被认为是有害的

    就绪函数的定义 本周早些时候,我和一个团队一起,讨论转向了"准备就绪的定义". 在过去的几年中,这个小想法越来越普遍,尽管我喜欢这个概念,但我不建议这样做. 实际上,我认为这很可能 ...

  3. 【Scrum模式语言3】完成的定义

    由团队中的一名成员给PO演示代办列表中已经"完成"的一个条目.当PO问开发团队从用户角度功能何时准备就绪时,开发团队会告诉他们已经完成了所有工作,但是非常有必要去做更多的测试,并且 ...

  4. 【Scrum模式语言5】Scrum of Scrums

    译者序:在规模化敏捷中常强调的有效沟通和交付对齐.Scrum of Scrums是一种最早的规模化敏捷技术,简单且有效,用于集成多个(建议不超过3-9个)在同一产品上工作的Scrum团队的工作.Scr ...

  5. 【Scrum模式语言4】游戏精神 (The Spirit of the Game )

    译者序:["游戏精神"在Scrum所有模式语言中占首位,它为其它模式语言奠定了基础,更重要的是游戏精神将带给我们关于如何理解Scrum的新见解和如何使用Scrum.在游戏中,游戏精 ...

  6. 简单明了的区分C++ C语言中声明(declaration)、定义(definition)、签名(signature)的区别

    无论是在C或者C++中,我们常常把声明和定义给弄混淆了,分不清楚,天真的认为这个两个东西是没有任何的区别,但是其实不以为然.下面我们来简单的阐述这两者的区别. 何为声明(declaration)? 声 ...

  7. Latex 定义definition

    1. 导入宏包 \usepackage{amsthm} 注:如果已经导入了宏包 amsmath, 则跳过这一步骤,因为 amsmath 中包含了 amsthm 2. 定义 在 preamble(use ...

  8. 定义Definition、公理、定理、推论、命题和引理的区别

    WHAT IS THE DIFFERENCE BETWEEN A THEOREM(定理), LEMMA(引理),AND A COROLLARY(推论)? PROF. DAVE RICHESON (1) ...

  9. 【Scrum模式语言8】Scrum白板

    译者序:本文说到的Scrum白板是一个重要的Scrum工具,是以物理或电子的方式展示当前Sprint范围及其状态.在Sprint计划期间,当前Sprint计划的产品增量被分解为可执行任务.Scrum白 ...

  10. 【概率论】1-1:概率定义(Definition of Probability)

    原文地址1:https://www.face2ai.com/Math-Probability-1-1-Definition-of-Probability转载请标明出处 Abstract: 本文介绍样本 ...

最新文章

  1. 《Visual Studio Hacks 》(十)
  2. Ubuntu下安装Qt全部过程
  3. RabbitMq如何确保消息不丢失
  4. 2021牛客暑期多校训练营4 E - Tree Xor 线段树 + 拆分区间
  5. 删除某个字段_Android中Room的使用4_删除一个字段
  6. 《设计模式之禅》之——六大设计原则解读
  7. B站校招面试官“炫耀资产、贬低应试者”?当事人发长文回应,北邮学子要求向学校道歉...
  8. PCL 1.8.1 在VS2015中配置 包含目录、库目录和附加依赖项
  9. python诞生日期_Python中的时间与日期
  10. 第五章平稳过程(1)
  11. BOOST升压电路PCB布局布线
  12. 一个简单的开源PHP爬虫框架『Phpfetcher』
  13. 神器vimium:比同级程序员成长更快,我主要靠它
  14. 2021-04-12——新特性Lambda表达式和Function函数式接口编程
  15. 【原创】技术员 Ghost Win 10 X86 企业贺岁版2018
  16. NeRF论文解析 - Neural Radiance Field
  17. 高级面试题--SpringBoot启动流程解析
  18. 2023年全国最新会计专业技术资格精选真题及答案16
  19. 常见app抓包软件对比
  20. 现代软件工程讲义 1 软件工程概论

热门文章

  1. 目前流行的装修风格_目前什么装修风格最流行?
  2. 浊音、清音、爆破音音频分析
  3. 5分绩点转4分_泪目!老詹儿子凌晨5点起身训练,科比女儿4点,魔术师叹息退出群聊...
  4. 2022.6月四级作文预测
  5. 再读王垠的《编程的智慧》,有怎样的感想?
  6. 老婆,我竟在婚礼上失去了你!-_-!!
  7. vue.js not detected问题解决
  8. 解决报错Duplicate keys detected
  9. 如何用Web Scraper抓取巨潮资讯网全站乐视相关pdf文件
  10. 云点域名-(域名解析、域名转向、二级域名、动态域名)的功能介绍