那么你 want to implement Scrum?
您喜欢轻松的想法吗？
然后听。这是我系列的第1步： 如何通过10个简单步骤实施Scrum.
这不仅是第一步。它’是最重要的一步。
除非您可以采取此步骤，否则别无所求。不要跳过它。我答应你 ’如果这样做，我会后悔的。即使您走得更远，此步骤也可能使您，您的团队和组织受益。
所以这是…
首先，您应该从哪里开始？
与业务保持一致
首先，在执行其他任何操作之前，您必须使开发团队与业务保持一致。
如果你’re part of a business unit, that might be natural and straightforward. 如果你’一个服务于多个业务部门，开发多个产品的中央开发组织，可能会更困难。最初，请确保您至少有一个人专门致力于开始实施Scrum的产品，应用程序或产品范围。
您可以 共享一个由多种产品组成的团队。但它’s a little harder and 那里fore is a slightly more advanced technique. If possible, it would be ideal to avoid this situation in your first implementation of Scrum, if you can.
从BAU开始
其次，尽管您可以在项目上使用Scrum取得良好的效果，但我还是建议您从BAU（照常营业）开始，而不是在大型项目上。在您和团队熟悉基础知识的同时，这将使事情变得简单。
那么你’您已经决定要开始使用Scrum的产品。您至少有1个人将致力于该产品（或产品范围）。为使操作简单起见，您选择了处于错误修正和增强功能的BAU周期中的产品。
寻找愿意的产品负责人
下一步是提名产品负责人。您必须找到1个产品负责人。 1位负责产品工作优先级的人员。 1位知道该产品需要什么的人。 1个人是一个很好的沟通者，能够传达要求。 1位致力于产品成功的人员，因此他们愿意并能够在合理的时间内投入产品开发的时间。
如果出于任何原因，此步骤对您来说都是一个问题，请不要通过。
如果你可以的话’完成此步骤后，您的产品开发可能会遇到很多问题。是否实施Scrum。除非您可以采取上述步骤，否则’您很有可能会面临大量的请求，对优先事项的不清楚，对要求的不明确，大量的喧嚣和抱怨，以及从支柱到职位的麻烦。后果？你不’无法实现和/或未能达到期望。每个人都很悲惨。而且以某种方式’都是你的错！不幸的是，这对于世界各地的开发团队来说都是非常普遍的情况。必须先解决此问题，然后再继续。对于您的团队来说，这是至关重要的成功因素。
充当ScrumMaster
因此，现在您已经井井有条。您’重新对齐。您有1个产品，应用程序或产品范围。您至少有1个人致力于该产品（Scrum团队）。您有1个产品所有者。而你，由于你’重新阅读有关实施Scrum的信息后，我将假定可能是ScrumMaster。
作为ScrumMaster，您负责支持Scrum团队，在此过程中指导和指导他们，并消除阻碍其发展的任何障碍。
创建产品待办事项
现在，您必须创建产品待办清单。
当你’重新阅读这篇文章，我’在谈论提名（愿意的）产品负责人时，您可能需要创建或促进产品积压的创建。严格来说，它应该归产品所有者所有。但是你可以使球滚动。
产品待办列表以最简单的形式列出了人们希望按照优先级对产品进行的处理。
任何人都可以将任何内容添加到产品待办列表中。任何人。 Scrum流程和敏捷开发原则通常是协作且包容的。不再需要说不。
但… very importantly –只有产品负责人才能确定产品待办事项的优先级。
产品待办事项列表可以包含任何内容。与产品有关的任何东西。虫子。增强功能。整个项目。问题。风险。没事
话虽如此，理想情况下，产品待办事项列表上的项目应以对用户（或客户或企业）有价值的商业术语表示。不作为技术任务。
功能要求应表示为功能。例如，非功能性需求也可以放在待办事项列表上‘产品需要更快’, ‘我们需要确保产品安全’, ‘我们需要离开旧平台’, ‘there’由于单点故障而导致停机的风险很高’。这样，这些功能可能不是功能部件，但完全可以作为产品待办事项列表中的项目使用。
优先处理待办事项
产品负责人将产品待办事项列为优先事项。他们不’t将优先级1、2、3或类似的内容分类。优先级仅由列表的顺序确定。产品负责人将产品待办事项按优先顺序排列。
列表底部的事情可能遥遥无期，也许永远不会完成。底层的事情很可能是模糊的和不确定的。唐’浪费时间来定义您可能永远不会或一段时间不会去做的事情。如果有什么不好的主意，产品负责人应向要求它的人解释为什么要从积压中删除它。但是，如果有的话’这并不是一个坏主意，尽管几乎不可能做到，但只要将它放在积压案中应有的低位，并向请求者说明它适合优先级的地方即可。
实际上，这就像排队。或站成一排。我们’全部都习惯了。人们通常会接受它。只要已经传达了产品负责人的权限并获得管理支持，人们就会在队列中占据一席之地。
All too often in development teams, 那里 is no clear visibility of the queue. People don’不知道队列多长时间。他们不’不知道前面有多少人。这通常会导致不耐烦和抱怨，因为它’是推动并进一步发展的唯一途径。
产品积压的可见性可以解决此问题。
此外…
以上步骤可以产生深刻而有力的效果…
优先排序现在是一个业务问题。现在，在增加成本与执行更多操作或耐心等待之间进行权衡是一项商业决策。关于成本与收益的成熟对话。它’不再是交付问题。它’s a choice. Shouting loudest is no longer the system for prioritisation. So 那里 is no point shouting.
考虑一下可能导致您入睡的技术问题或风险，但您却没有时间解决。将其放在待办事项列表上。产品负责人可能决定将其他更可见的功能放在首位。但是，如果风险对您不利，则承担风险是明智的商业决策。风险所有权已成功转移。
可以在可预见的将来完成产品待办事项列表顶部的操作。因此，可能会更好地理解它们。而且他们需要足够明确地定义，以便团队可以对其进行工作。这些功能（或待办事项）应单独定义，因此它们可以作为独立的，可交付的工作单独使用。不属于相互依存的庞大网络。而不是大规格文件的一部分。定义，是的。但定义为小块，单个块。积压项目的明确定义只需要保持团队领先一步。没有进一步的。
So 那里 you have it. You now have a Scrum team. A ScrumMaster. A 产品 Owner. And a 产品 Backlog. You’使您的团队与业务保持一致。您’创建了明确的产品所有权。您’ve got your team’工作优先。并且您拥有一个系统，一种机制，一个排队系统，可以持续进行优先级排序。
如果你 do no more, you will be better off for taking this step. 但, until you can take this step, you should go no further.
凯莉
本系列的下一篇： 第2步–如何估算您的产品积压
也可以看看：
如何通过10个简单步骤实施Scrum:
– 步骤1：按顺序整理您的待办事项！
– Step #2:如何估算您的产品积压
– 步骤3：Sprint计划/明确要求
– 步骤4：Sprint计划/估算任务
– 步骤5：创建协作式工作区
– 步骤＃6：冲刺！
– 步骤＃7：站起来，算数！
– 步骤＃8：使用每日燃尽图跟踪进度
– 第9步：完成您说的话
– 步骤10：查看，反映，重复…
