总是展望未来
读：
总是展望未来
我总是向前看下一次规划或下一次估计会议。每当我指导一个新的ScrumMaster或产品负责人时，我都会把这种行为教给我的客户。我一开始会让他们参与到我正在做的事情中，展示需要做什么，并解释我的想法。教学是非常经验性的，但在某种程度上不完整。如果我在脑海中解释所有事情，所有我想要的事情，我就会说得太多，而没有足够的参与。
告诉我，我会忘记的。
告诉我，我可能会记得。
让我涉及，我会理解。
——孔子(公元前450年
然而，我即将将它们从巢中推开，让他们独自飞行，当我更明确地教导我的思考时，让他们飞。这让我丢弃了要记住的清单，以便稍后，始终定制到本地背景。经验告诉你要寻找的内容，这在每种情况下都有一些不同别期望这对您的组织来说是一个有效的检查表。但总的来说，我记住了下面的问题。
我看那些没有被估计的新闻:
- 团队能否估计这个故事？
- 这个故事太大了吗？
我看看下一个值得的故事：
- 团队可以计划这个故事吗？
- 描述是好的吗？
- 验收标准是否充足？
- 这个故事太大了吗？
- 球队需要先扣球吗?
我着眼于下一个sprint:
- 点太多了？不够？
- 里面是否有未知的故事?
- 这些故事是优先考虑的吗？
- 我们是否给了团队一些提前通知我们在下一个冲刺所需的内容？
- 如果我们有专业化或多个球队的一个积压，我们应该考虑哪个团队应该拿走每个故事？下一次迭代是否在团队/专业之间均衡？
我期待下一个部署和下一个发布周期:
- 我们的释放烧毁的外观如何？
- 发布版计划安排看起来如何?
- 我们会在下一个版本发布之前准备好故事并进行评估吗?
- 我们需要多少交付时间？
我在积压中寻找被忽视的项目：
- 如果我正在使用在线缓冲管理工具，我忽略了一些不在我的标准过滤器中的故事，因为他们还没有被播出到迭代或分配给团队？
- 当使用在线工具来管理待办事项时，我会设置视图或查询来帮助我们回答这些问题:(这是由一些工具自然提供的，在其他工具中可以通过少量工作来设置，而在其他工具中是完全不可能的)。
- 没有估计
- 没有团队
- 没有冲刺
- 这个冲刺
- 下一个Sprint.
- 发布计划
我看了看日历:
- 寻找不止一个迭代，是那里的假期会落在定期定期估算或计划日（或预先计划/预估计日）？
Scrummaster可以帮助密切关注事物并指出缺乏的东西，但大部分决策当然属于产品所有者。
希望这个对你有帮助。我还应该添加什么？
评论(7)
Derek Huether.
安德鲁，我喜欢这个名单。在细化过程的每一步，我问团队：这个故事依赖于什么吗？在使用在线缓冲管理工具时，我使用查询列出“具有依赖性的故事”，因为我不断拥有团队寻求和打破依赖性。如果有任何业务，组织或技术依赖项，亚博vip9通道我要求团队考虑重写故事以消除它们。
很难相信我没有在我的列表中包含依赖关系。不确定如何忽视那个！谢谢德里克。
约翰有着
我对您向下一个Sprint的展望有一些问题。如果PO确定优先事项是什么，并且这些优先事项随时可以改变，为什么/您如何知道这些东西？
“•太多了？不够？
•其中是否有未知的故事?
•故事是否有优先顺序?
•我们是否给出了团队的一些提前通知，即我们在下一个冲刺的内容？“
你提前规划Sprint吗？如果是这样，你为什么要这样做？我理解积压的细化会议发生，你可以谈论你认为在下一个冲刺中你可能会在上面的冲刺中做些什么，同时大调这些故事。但只有您实际完成了Sprint规划，只能确定列出的这些内容。这应该在完成的冲刺后和下一个初开始之前进行，并且应该参与团队。这对我来说是项目管理。
约翰，你和我可能有不同的背景需要考虑。谢谢你对此挑战。我需要进行一些澄清：
如果我有一个具有依赖性的大型敏捷团队，是一个更大的程序的一部分，组织几个月的承诺，其中有多个利益相关者远远遍布，系统并不简单，在那里主题是复杂，那么经常有一定量的延期时间（天或数周），使一些用户故事准备好了。在这样的上下文中，单个PO通常不会以隔离运行，并且不能随时进行戏剧优先级。这就是为什么我关心（鉴于我的上下文）总是始终在任何时候都有3次准备回车。If I’m bringing a dozen people into a sprint planning meeting, I don’t want to risk spending many minutes in that session talking about a story that we ultimately decide to toss out because it isn’t ready and can’t be made ready during this sprint. Project management in such a context isn’t a dirty word. Nor is it anti-agile.
现在让我解决这个问题，你制作了：“但是只有您实际完成了Sprint规划，只能确定列出的这些东西。”如果我知道我的团队的速度并有一个优先的积压，我可以看看积压的顶部，看看我是否有2或3个Sprints的估计故事。有时这就是我需要知道的一切。我并没有提前规划冲刺 - 我并没有提前与整个团队一起做“冲刺计划” - 我不会提前打破故事。我准备了。我确保当我们计划计划时，如果没有挂钩，它会下车。
这有帮助吗？
约翰有着
上下文有所帮助，是的。在积压的细化会议期间可以处理其他事情，以在Sprint计划会议之前准备积压。我想使用故事映射或类似于保持整个事情的东西在一起可能是需要考虑的一个大的项目。但是你的评论让我想到了我在试图通过转变教练大型企业的努力。至少我努力与整个用户故事概念进行调和：“依赖性”。我们经常被告知使用i.n.v.e.s.t.要创建我们的故事，但故事如何独立于其他团队建立服务的大型项目？而且，如果您正在以这种方式拆分（按组件），整个项目往往沿建筑边界分裂。这意味着在路上的某个地方，我们必须整合所有这些作品。这是恕我直言，就像它一样瀑布。 So in these large projects you describe, and that I am working in now, how do we keep stories independent? If we can’t, how do we deliver an MVP without facing all the old issues associated with component based construction and delivery? (I know this is going off on a tangent, but giving the context you provided, I am hoping it is okay to extend the conversation in this direction.)
更改您的组织和架构以消除依赖项。但那很难，需要很长时间，对吧？因此，在平均时刻，依赖性是许多组织的生命事实。因此，切勿在较低级别的团队中注入依赖关系。更高级别的团队（即，像功能团队）必须始终接受（使用）现有服务提供的能力。不包括您的发布计划中的内容，依赖于服务团队进行同一版本帧的更改。与服务团队合作，包括在他们的路线图上包括您想要的东西，并努力将事物纳入其发布计划，但不要依赖于他们的计划。也许这两个博客帖子可能有所帮助？
http://leadingagile.wpengine.com/2011/10/depectencies-break-agile/
http://leadingagile.wpengine.com/2013/07/use-feature-teams-component-teams/
让我们继续讨论其中一个帖子，这篇文章或其他地方。再次感谢参与这一点。
我应该提到的另一件事是，如果您无法消除或推迟依赖项，则拥有ORG策略，每个团队必须在每个版本开始之前在其上工作之前解决任何依赖项。依赖性解析是整个企业的首要任务。这样，所有工作都可以在第一个Sprint或两个后依赖依赖性。计划释放以可视化和前负载依赖性分辨率。