Enable javascript in your browser for better experience. Need to know to enable it? Go here.
本页面中的信息并不完全以您的首选语言展示,我们正在完善其他语言版本。想要以您的首选语言了解相关信息,可以点击这里下载PDF。
更新于 : Jan 28, 2015
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。 了解更多
Jan 2015
暂缓 ? 谨慎行事

We continue to see teams and organizations equating velocity with productivity. When properly used, velocity allows the incorporation of \”yesterday's weather\” into a team’s internal iteration planning process. The key here is that velocity is an internal measure for a team, it is just a capacity estimate for that given team at that given time. Organizations and managers who equate internal velocity with external productivity start to set targets for velocity, forgetting that what actually matters is working software in production. Treating velocity as productivity leads to unproductive team behaviors that optimize this metric at the expense of actual working software.

Jul 2014
暂缓 ? 谨慎行事
Of all the approaches that we might disagree with, equating velocity with productivity has become so prevalent that we felt it important to call it out in our hold ring. When properly used, velocity allows the incorporation of "yesterday's weather" into the iteration planning process. Velocity is simply a capacity estimate for a given team at a given time. It can improve as a team gels or by fixing problems like technical debt or a flaky build server. However, like all metrics, it can be misused. For example, over-zealous project managers attempt to insist on continual improvement of velocity. Treating velocity as productivity leads to unproductive team behaviors that optimize the metric at the expense of actual working software.
Jan 2014
暂缓 ? 谨慎行事
发布于 : Jan 28, 2014

下载第27期技术雷达

English | Español | Português | 中文

获取最新技术洞见

 

立即订阅

查看存档并阅读往期内容