扩展的回顾
的请求
回顾是我的最爱。我喜欢帮助他们直到今天，并倾向于经常尝试一些新的东西。我发现这是学习促进技巧的沃土。今天我将讨论缩放回顾。在敏捷世界中，关于伸缩性的讨论近来受到了大量媒体的关注，但在我看来，我们忽略了回顾领域。是时候改变了:
设置
考虑以下两个目的:
团队回顾的目的是抓住机会检查自己，并计划在接下来的迭代中改进。
程序团队和投资组合团队的目的是服务于下面的一层，并最大化这些层的价值创造。虽然我将来可能会深入研究项目组合级团队的可选方法，但是现在我将重点放在程序团队上。
球场
考虑到上述两个目的，让我们看看敏捷宣言只要抓住几条指导原则。当我们经历这个过程时，考虑一下程序团队级别的伸缩敏捷团队。作为一个团队，他们如何让每一个都变得更好呢?
简单——最大化未完成工作的艺术——是必不可少的。
制定计划的艺术。规划是通过规模化的敏捷系统进行流动工作的重要组成部分。从组织的策略到交付团队的用户故事，没有有效的计划节奏会扼杀组织。此外，你的计划方式甚至可能不适合你的亚博vip9通道商业模式。每个人，特别是程序团队，负责最大化未完成的工作量，以从系统中获得价值。那么，通过渐进式精化、故事映射等，可以为您的程序团队实现哪些改进呢?他们需要保持或停止哪些实践?
可工作的软件是进度的主要度量。
突击测验。谁负责软件的工作?许多敏捷人员关注scrum交付团队，并把他们的脚放在火焰上。虽然我的开发兄弟(大声说。net开发人员)不应该逃避他们的责任，但我要告诉你的是，程序团队承担了更大的责任，因为他们可以在组织交付解决方案的方式上产生巨大的不同。程序团队负责制定战略决策，决定何时以及何时不采用不理想的软件。这就迫使质量决策到达正确的位置。规划团队应该关注交付团队所提供的价值的最大化，任何好的产品负责人都知道，通过降低质量而获得的短期胜利只是短期的，并且最终代价高昂。
围绕积极的个人建立项目。给他们需要的环境和支持，信任他们能完成工作。
这是关于组织使交付团队做得很好。我会要求所有的项目团队注意最后一句话。您如何能最好地使您的交付团队完成工作?与他们一起工作，让他们对愿景有清晰的理解。切片故事更好。帮助保护团队的能力。找出它是什么，然后做得更好。
的切换
查看所有的原则并为程序团队进行讨论是很容易的。虽然这对我的博客来说太大了，但我将留给你最后一个宣言原则:
团队定期反思如何变得更有效，然后相应地调整和调整其行为。
如果我们已经在上面定义了成为一个成功的程序团队意味着什么，尽管只是一小部分，那么我们可以并且应该很容易地回顾如何才能使团队变得更好。这意味着我们应该建立一个节奏或规则，关于我们何时将回顾或“停止线”，以反映规模扩大的团队的期望结果。
这是我想要你做的。在我认识的人中，没有几个人在测试这东西。让我来测试一下。告诉我你尝试了什么。如果您尝试了程序团队级别的回顾，您发现了什么成功?什么失败了?你需要开始和停止做什么?听起来是不是很熟悉?
评论(4)
Ben Linders
我写了关于我的回顾的经验http://www.benlinders.com/2013/improving-collaboration-in-agile-projects-with-the-retrospective-of-retrospectives/。这样的回顾可以用来改善团队之间的协作，并增加他们在项目中的贡献。
嗨,本,
感谢您的阅读和评论。
虽然我喜欢复古中的复古，尤其是克尼伯格和桑登在Spotify做的开放空间风格，但我想鼓励一种不同的连续节奏，而不是发布或项目级别的节奏。这就是我要找的地方。这对我来说真的很重要，因为我经常(总是?)发现程序或产品负责人团队对最大化价值创造有很大的影响，他们经常没有被指导反思自己。我们中有多少人因为只在组织的团队层级做逆反行为而感到内疚?很长一段时间我都是这样。不了,)
愿一切都好！
埃里森
我也注意到，程序级的回顾要么不会发生，要么只在最初发布的末尾进行，我还看到scrum团队要求在程序级进行更多的回顾，因为他们看到了以更定期的节奏进行回顾的好处。作为一名教练，我认为当我的团队在实践中影响其他人变得更灵活时，这是一件很酷的事情。我们每年还会在整个公司范围内举行几次回顾会议，以从整体上改进。
Allison伟大的东西。我告诉程序团队(和项目组合)，他们在敏捷系统中也是敏捷的。到目前为止，我认为这是最好的结果。看到别人这么做真的很酷，谢谢评论。