有时，年轻的开发团队会陷入混乱。
当他们还没有完全了解什么是优势时，就会发生这种情况。 该项目和产品争辩他们中的谁是谁，每个人都自己执行任务。 或每个人都已经知道了一切，但无法计划冲刺-任务无法完成，演示和复古活动不定期。
我们也有类似的故事，但是我们找到了自己的路。
这是Yandex.Kassa个人客户团队的一个故事，对想要改进其计划的人员进行了详细说明。
怎么样了
Yandex.Kassa个人帐户团队负责将新商人连接到收银员并提供账单服务。 按照Yandex的标准，团队还很年轻-6个开发人员中有4个工作六个月或更短的时间，而我作为项目经理的3个月前加入了该团队。
在新冲刺的第一天，团队与产品负责人（以下简称PO）聚集在一起，并计划了大约两个小时的冲刺。 这种方法有明显的缺点：
- 需求阐述少。 PO没有足够的时间回答所有问题。 我们要么将此类任务纳入冲刺，要么让分析人员评估该任务，然后将其实施推迟到下一个冲刺开始。
- 在冲刺如火如荼的情况下，有些情况下会记住利益相关者，我们迫切需要相关团队的一些改进或解决方案。
- 缺乏风险管理。
经过他们的考虑，出现了对新流程的要求：
- 产品的所有者和所有有关方面都应制定任务要求。
- 每个活动的已实施的dod（完成的定义是一组标准，使您可以了解是否完成了开发的目的）。 他们开始确定利益相关者，以便在开始新冲刺的一周前，他们将工作进度告知他们并收集反馈。
- 最少开会以关注当前的冲刺。 在两个星期内仅限于两次会议，每个会议一个小时。
- 他们开始以团队为单位定期进行内部产品培训，因为今天的主要风险之一是对产品的了解不足。
新概念
我们引入了新的命令容器（列表）：
除第一个列表外，所有列表中任务的优先级均由PO确定。
如果任务在sprint中完成，则团队成员可以将“估计”中的任务投入工作，并会了解它们已完全准备就绪，可以接受并执行。
第一周
通过单击-完整版本。
星期一
产品负责人将活动从“任务列表”容器移动到“整理”，并尽可能清晰地划分优先级并描述“完成”。
PM对照清单检查Grooming容器中的活动：
- 新活动是否需要布局？如果需要，是否需要布局？
- 是否已包含最重要项目的所有活动？
- 是否指示任务之间的链接？
如果出了点问题，PM会与PO沟通以澄清细节，并通知团队整理清单是最新的。
一个例子：
- 承担任务“延迟发送夜间开具的发票信”。 测试人员将其添加到修饰列表的末尾。
- PO将该任务列入清单。
- PM检查是否已执行与PO一起使用容器的活动，并已通知团队。
周二
该团队熟悉新活动，并撰写评论，问题和提出建议。 PO会自动接收所有新评论（我们使用Jira，因此很容易做到），他有时间在明天之前准备答案。
团队成员指定了任务是否相关。 事实证明，该任务是相关的，测试人员找到了问题的原因并进行了报告。 但是，从业务逻辑的角度来看，这个问题仍然悬而未决。
星期三
我们与PO开会，PO回答了团队的问题。 会议的目的：修复国防部。 会议之后，部分活动将进入“定义的”容器，部分活动-立即变得“估计”（如果很明显），该活动将花费多长时间。 定义依赖关系和利益相关者。
PM和PO之间的对话，随后明确了需要做什么。 通常，此对话不是固定的，但是由于此活动，PO在会议期间不可用，因此通信以书面记录。
星期四
PM将“估计和已定义”列表中附近活动的列表发送给感兴趣的各方，并要求查看和评论。
星期五
PM回答利益相关者的问题，如有必要，请团队或PO参与。
作为示例，我们没有收到有关任务的评论，但总的来说，它看起来像这样：
反馈可以通过使者来实现。
第一周的结果是活动，根据活动，考虑到相关方的意愿，可以清楚地知道需要做什么（确定了dod）。
第二周
星期一
该团队独立地评估“已定义”列表中的活动和“估计”列表中的活动分解。 采购订单不在此处，因为他负责制定业务目标，并且不负责评估计划的完成方式。
周二
与PO进行的第二次会议，团队可以澄清细节并传达其评分。 PO可以通知您过去一周内可能发生的新的介绍性事件，并阐明为什么活动正是这样的估算，而不是更少。
星期三
当前的sprint有一个演示。 作为演示的结果，通常会形成新的活动，其中一些活动必须在一周结束前完成，其余活动必须在下一个冲刺中完成。 该演示的目的是收集反馈。 该团队介绍了他们的工作成果，并收到了有关新功能工作的早期反馈。
该演示是内部的和外部的 。
内部演示用于PO，他在PO评估团队是否达到了预期的结果，或者是否需要改进。 它由测试人员在测试环境中执行。
外部演示面向有兴趣的人士。 在计算新功能“上阵”之后发生，将其带到PO。
演示之后，新活动将添加到待办事项中，并且根据它们的优先级和等级，可以将其添加到当前的sprint中。 我们专门在第二周中进行了演示，以便有时间进行改进，直到冲刺结束。
星期四
PO优先考虑“已定义”列表（如果在sprint中完成活动的时间比预期的要早，则可以从该列表中进行新活动的工作）和“估计”（将列表中的活动转移到新的sprint）。
星期五
进行Sprint计划，PM和PO开发团队将参与其中。
在一个回顾中，我们讨论了当前sprint的工作方式以及我们是否为下一个sprint做好了准备：我们交换意见，对于即将到来的sprint一切都很清楚，我们资源中是否仍然有足够的资源来修复意外的错误。
正在进行风险管理会议。 目前，我们正致力于此产品的研究，因为对产品的深入了解可以大大降低风险。 PM在一周内与测试人员一起分配时间来研究产品并与团队分享结果。 邀请各单位代表参加会议，以补充图片。
每个第二个星期五不仅是工作周的结束，也是冲刺的结束。 这是交流和反馈的一天。 因此，新工作周的星期一开始时要有清晰而赏心悦目的任务，这对于团队来说也是合乎逻辑且舒适的。
结论和下一步
在此过程的帮助下，可以在采购订单和团队之间建立高质量的互动，过去的冲突和误解已经过去。 团队的气氛有所改善，并且出现了和谐的节奏感。 当然，仍然存在许多问题，但是团队或PM不得不保存项目的紧急情况和不可预见的情况要少得多。
像所有生物一样，我们的过程不时需要更新。 现在我们看到值得在以下领域完成：
- 虫子。 还需要计划使用错误。 我们无法在sprint计划过程中执行新出现的错误，这里需要进行更多的操作工作。 我们正在考虑如何做。
- 我们希望制作一张典型风险表，以便将其考虑在内并减少在sprint实施过程中出错的可能性。
- 在计划冲刺时，我们希望以冲刺的目标为基础，以保持工作重点。 团队还很年轻，所以有很多困难。
希望我们的经验能对您的团队有所帮助。 我们准备在评论中讨论我们的方法，回答问题或提供建议。