印度班加罗尔
我是 Red Hat 卓越开发者计划的成员，并担任首席敏捷教练领导敏捷转型。 我们的目标是提供工具，使开发人员更容易在日常工作中取得成功，从计划到生产。 请务必查看 developers.redhat.com 以探索我们的产品和我们最新的服务 OpenShift.io，该服务允许所有开发人员仅通过 Web 浏览器即可计划、开发、测试、构建和部署到生产环境。
我们是一个由大约 250 名开发人员组成的团队，居住在 16 个以上的国家/地区，分布在 6 个以上的时区。 我们在以这种高度分布式的方式工作和协作时，正在实践和学习规模化敏捷。 我们已经成功实现了“持续交付”，我们的团队几乎每天都将代码合并到生产环境中。 由于我们所有的项目都是开源的，因此您可以在 Github 上查看我们的工作。 例如 github.com/openshiftio/openshift.io 和 github.com/eclipse/che
撰写的评论
感谢您的关注，我将详细说明它是如何提供帮助的，然后再回答问题的第二部分。 通过采用这种理念，我们已经证明了对团队同化和承担敏捷转型的能力的内在信任。 这创造了一个更好的环境来进行公开对话，这在以前仅基于团队的速度时是很困难的。 这是因为我们承担的项目的性质非常复杂，并且使用开源环境会增加其复杂性。 因为我们依赖于其他项目和社区来推进我们的工作，而我们对这些项目和社区几乎没有控制权。
说到第二个问题，我个人认为，一旦团队接受了敏捷的思维方式，他们就会变得更有能力生产高质量的工作成果。 因此对我们来说，我们意识到如果输出与业务目标或利益相关者的期望不完全一致，那么仅衡量生产力就没什么价值。 我们更希望专注于建设团队的能力，使其能够在快速变化的环境中执行任务，在这种环境中，优先级可能会在相对较短的时间内迅速变化。
例如，围绕利益相关者满意度的敏捷原则引发了一场充满活力和热情的讨论，以识别利益相关者。 不用说，该团队很快就超越了产品经理、业务部门、组织，并考虑了社区和最终用户。 你可以想象，当团队中的每个开发人员都能够扩展他们的想法，以了解他们的部分如何融入全局时，他们生成的软件质量就会更高，并且与整体愿景紧密结合。
在这些讨论结束时生成的工件有助于我们可视化团队所识别的内容以及他们在重新审视敏捷原则之前的几个月或几周内的进展情况。 这就像我们在走向真正敏捷的旅程中的足迹。 为了衡量绩效，我们观察并检查每次迭代结束时交付物的质量以及它在市场和社区中产生的影响。
例如，当我们发布新版本的产品时，我们会看到它产生的反应和情绪，无论是通过博客文章上的评论或问题、问题的报告还是下载次数。 由于这些是显而易见的，并且直接与业务驱动因素相关联，因此它可以让我们更全面地了解团队的工作情况。