敏捷教练和项目经理
上周，当我忙于写其他事情时，有一个有趣的Twitter对话。 （我还发现，Twitter很难与我对话。我需要超过140个字符。）
当Neil Killick发推文时，对话开始了：
组织需要教练不是因为“敏捷是不直观的”，而是因为有效的软件交付是需要最佳状态的团队合作。
我喜欢它，并转发了它。 Mohinder Khosla问（我认为相当合理）：
我们是否有统计数据是真实的？ 只是说
Mohinder，我确定我们没有统计数据。 对于软件产品开发的工作方式，我们很少做我归类为真正的研究。 这是因为我们不断学习，即使与完全相同的人开始一个新项目，我们也已经学会了在以前的项目中一起工作。 如果我们不能将团队保持在一起，我们必须重新学习如何一起工作。 （有关此内容以及对团队的更多了解，请参阅《 Hackman的领导团队》一书。）
敏捷挑战了我们先前有关软件产品开发工作方式的所有假设。
我们考虑产品，而不仅仅是项目。 参见术语发布，产品所有者和MVP。 我们认为流动效率，而不是资源效率。 我们会将我们可能已经分阶段完成的所有工作整合到我们经常发布的小故事中。 我们邀请更改，我们不会试图控制它 以及更多…敏捷是思维方式的改变和文化的改变。 （请参阅什么时候敏捷适合您？ ）
敏捷的一大变化是我们团队合作。 我们团队合作，全面开展工作。 我们不会将工作从开发人员转移到测试人员。 我们不会将工作从建筑师移交给开发人员。 我们不会将工作从测试人员转移到运营部门。
每个团队现在都可以做到吗？ 他们可能不是第一次尝试使用敏捷。 跨职能团队是有争议的团队这一观念挑战了我们，我们的经理和我们的组织“了解”产品开发的一切。
教练可以帮助团队和经理了解创建敏捷思维方式和敏捷文化的感觉。 您需要教练吗？ 也许不会。 当客户问教练对他们是否有用时，我曾问过以下一些问题：
您是否有跨职能团队？ 或者，是开发人员团队，然后是测试人员团队，等等。 您是否可以自己创建一个跨职能团队的功能？ （您可能现在没有这样做，但是可以吗？或者，您是否需要组织中的其他人员？） 团队是否定期进行展示？ （我的指南：每两周至少一次。） 团队是否定期回顾？ （我的指南：每两周至少一次。）请注意，这些问题与团队协作和交付有关。
敏捷创造透明度。 我们可以看到团队何时没有“表现”。 我用引号引起来，因为通常环境是导致团队无法“表现”的原因。
有些团队无法团队合作。 教练可以提供帮助。 其他团队无法回答我的四个问题。 如果是这样，教练可以帮助团队和经理。 该组织可以自助吗？ 当然。 教练会更容易吗？ 大概。
您不需要敏捷的教练即可成功。 你可以自己做。 而且，如果您查看适合您成功定义的人员和团队，他们通常会告诉您他们有教练。 （我做。）
敏捷团队定期且频繁地交付工作产品。 他们可以使用基于流的敏捷或基于迭代的敏捷。 没关系
当团队定期交付时，他们将成为协作团队。 对于组织中的每个人来说，这种想法和实践可能都是很新的。 教练可能会有所帮助。
下一篇文章将是经理在敏捷环境中的教练作用。
翻译自: https://www.javacodegeeks.com/2016/10/coaches-managers-collaboration-agile-part-1.html
敏捷教练和项目经理