我们不需要另一个英雄
敏捷宣言告诉我们，保持稳定，可预测的工作节奏是成功团队的关键特征。 事实证明，英雄般的努力，漫长的时间和偷偷摸摸的努力并不能使团队高兴。
另一方面，如果您低估目标，则可以始终如一地实现目标。 但是那样您就不会从团队中得到最大的收获。 找到最佳位置是关键。 高绩效团队通过实验和学习来发现并优化其吞吐能力。 但是要从失败中吸取教训，就需要对其进行衡量。
Scrum是最流行的敏捷框架，建议团队需要两个组件来衡量其可预测性：工作的规模和团队的速度（或交付价值的能力）。 Scrum团队通过将工作分解成称为故事的小片段，然后将它们彼此确定大小来找到工作的规模。 最受欢迎的大小调整机制是故事点。 首先，Scrum团队会在列表中找到最小的故事，并给出一点。 然后，团队选择列表中的另一个故事，并确定其相对于单点故事的大小-相同大小（1分），两倍大（2分），五倍大（5分），依此类推。所有故事都重复进行。 规模从个人对“多长时间”的估计转变为众包的“多大”估计。
团队通过选择一致的迭代节奏（例如两周）并查看在此期间可以完成多少操作来找到自己的速度。 如果他们完成20个故事点，那就是他们的速度。 如果在下一次迭代中，他们完成30分，那么他们的速度将为25分。
通过与整个团队进行协作，不仅可以获取准确的信息，还可以得到每个人的支持和投资。 人们知道自己有时间和资源来履行自己的承诺，因此焦虑水平下降。 与团队外部的利益相关者进行交流变得不那么繁琐，因为您可以兑现您的承诺，并拥有明确的理由来拒绝超出您能力范围的工作。 计划变得平静，理性，而且我敢说，这是愉快的经历。
跨职能团队的一种更好的方法-进入和退出技术
在技术队伍中，我经常听到一个问题：“速度仅适用于开发人员和测试人员吗？”对于跨职能的敏捷团队来说，这是一个特别相关的问题，这些团队可能拥有流程和数据分析师，UX设计人员，开发人员，测试人员等。 （扰流板警报：否）
假设您有一个跨职能团队从事大型Salesforce实施。 为了使业务经理能够搜索机会列表，需要一个开发人员，数据分析师和测试人员的帮助（这个故事是敏捷的，代表着大量工作）。
分配分数时，应考虑任何有助于故事完成的工作。 当团队一起评估故事时，他们会考虑两个因素：
- 我对这个故事的贡献是多少？
- 当我们考虑其他人的贡献，整体复杂性和潜在的未知因素时，故事有多大？
随着团队规模的扩大，当开发人员为一个故事提出三点建议而测试人员估计为八分时，我们已经大为惊讶。 并非每个人都可能意识到其他人的工作的复杂性。 调整团队规模是进行关键团队对话的机会。 这种对话可以节省团队的工作时间，因为每个人都可以更好地了解完成每个任务需要什么以及整个项目。
这个过程不仅可以改变技术团队，还可以改变业务团队。 我曾经执教过的营销团队曾经在孤岛上工作。 每个项目都需要每个团队成员做出独特的贡献，而这些团队成员将同时进行多个工作，并且需要其他人来完成他们的工作。 领导者设定了任意日期来完成某些工作，而与团队的能力无关—这是未知的，因为它没有度量。 人们度过了疯狂的时光，变得越来越沮丧，影响了工作质量和整体士气。
使用积分系统应用Scrum并一起计划解决了许多挑战。 他们将每个故事的大小调整为一个团队，并保持反映整个团队可交付成果的速度。 这使他们更具可预测性，并且可以管理执行人员对可以实现的目标以及何时实现的期望。 士气提高了，团队变得更加统一。
无论我们是在软件开发团队，市场营销团队，甚至是财务团队中，当您以团队的形式工作，以团队为单位规模并以团队形式交付时，都会发生一系列美好的事情。
感谢 敏捷/精益教练兼Slalom认证Scrum大师 Jeff Brinkerhoff 对本文的贡献。
