如何以敏捷开发人员的身份编写“ SMART”目标？

与许多公司一样，我工作的公司正在过渡到基于SMART目标的绩效评估系统。我的团队是一个高效的敏捷开发团队，采用了Extreme Programming的实践。为了使我们受益匪浅，我们在敏捷实践中的使用得到了直接和高层管理人员的全面支持。

为了完成工作，我们的团队利用了三周的迭代时间。除了立即迭代之外，我们还制定了一个总体计划。这意味着我们从现在开始的几个季度将要完成的工作比我们在最近一个季度将要完成的工作要模糊得多。我们当然对项目的发展方向有一个大致的了解，但是这里的关键字是general。

考虑到我们对团队中项目规划人员的态度，包括我自己在内，发现很难写出具体，可测量，可实现，相关且有时限的目标（SMART）。

关于SoftwareEngineering.se的两个现有问题很好地解决了我们的一些担忧：

• 对程序员来说，一个好的SMART目标的例子是什么？
• SMART目标对程序员有用吗？

但是，在敏捷开发团队中工作时，这些问题在处理SMART目标方面引起了比具体问题更多的一般回答。作为敏捷开发人员，您如何编写五到七个长达一年的目标，这些目标是特定的，可测量的，可实现的，相关的且有时间限制的？

这个答案是从某人围绕敏捷团队建立了这样的绩效管理系统的角度出发而写的；像您一样，团队中的每个人都意识到将长达一年的SMART目标应用到敏捷团队的困难/无用，在该团队中，当功能全面发挥作用时，可以将其实施视为固有的/已经是SMART。

不完全是！如果需要，可以将以下合理化称为（如果逻辑是半生不熟的……），但是向直接组织外部的审阅者解释它为我们放入绩效管理系统中的实际“目标”奠定了基础。

• 对于特定的S：在每个sprint计划期间，团队同意要实现的一组特定任务，并致力于完成这些任务。任务（和用户故事）回答了我要完成什么，实现目标的目的/利益，涉及的对象，目标发生的位置以及约束等问题。
• M可衡量：这些任务的清单，以及整个sprint中的票证移动，从开发到代码审查再到质量检查再到发布（或任何流程），回答了有关多少工作以及何时完成的问题。 。
• 一个可实现的：运作中的敏捷团队通常不会在计划阶段就致力于某件事，除非它是明显可实现的-所有这些都是要知道如何实现的
• R代表相关问题：像这样的问题是否值得，是否时机合适，是否与我们的其他努力相匹配-故事和任务不会陷入冲刺而不会被执行，除非所有这些问题的答案都是肯定的（通常... YMMV）
• T表示时间限制：冲刺必定是有时间限制的，无论是2周，3周或多或少。

如果您了解/说服自己，季度工作（以及您全年的工作）本身就是SMART的一项大目标，并且您知道自己正在实现目标，因为团队表现良好，速度是积极的，正在发布，那么您到了问题的重点，那就是最终如何将SMART流程转化为一组SMART目标，以使他人受益。

过去，我通过写一些对我来说似乎很模糊的东西（虽然不是很聪明），但实际上对其他人来说完全可以接受，成功地做到了这一点。

对我来说，已经通过了其他几个例子：

• “我希望通过遵循我们的内部软件开发流程，在明年每三个月发布一个新版本的WidgetMaker，以与整体产品开发进度保持一致（等等）。”

• “我希望通过专注于积压疏导流程的增量更改，使团队从版本A到版本B的开发速度提高n％，以提高我们的效率并减少产品交付的延迟。”

您知道，我知道，这些并不是您实际的开发团队的指导原则，但是它们并不是完全无关的，以我的经验，这些事情看起来确实很聪明，并且对您直属组织外部的人员有​​用（没有完全是谎言或完全la脚）。