领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
超越短期的Scrum项目估算？
作者 Dan Puckett 译者 张龙 发布于 2011年1月5日
近日，Michael Sync提出这样一个问题：如何对大项目或是大特性进行估算：
我知道我们不应该对一个以上的sprint进行估算，因为后面可能会对其进行修改。但真实情况往往并非如此。我们需要提前对整个项目或是一些特性进行估算，这样才能确定目标日期并对特性进行调整或是改变其优先级。 为了能更加精确地进行估算，我们需要在创建sprint之前将用户故事分解为任务。 那该如何处理或是估算呢？
Peter Bell对估算与承诺进行了严格的区分：
是否有人问过你关于估算或是承诺的问题呢？所谓估算，就是根据目前可用的信息做出的合理猜测。估算不是偏高就是偏低，通常在构建复杂软件时估算会偏低。他们不是承诺，也不能当作承诺。
Scrum Development邮件列表上的成员所达成的共识是项目估算并非特别有用，也不值得你花很多时间在这上面。“woynam”写到：
进行估算的组织请不要再忧虑某些东西要花费多少代价了，请转到变化上来吧。如果你知道要花费多少代价、要花费多少时间，那么唯一变化的就是你的这些钱会实现多少个高优先级的特性了。关键在于如果你不再进行估算， 那么你仍旧可以确保首先实现最有价值的那些特性。
George Dinwiddie写到：
如果利润或是损失取决于对花费的精准预测，那么你可能选错产品了。这种产品的升值潜力太低了。
我经常发现组织中的高层很清楚这一点，但中层经理往往不太理解：
对于大多数组织来说，估算都不是什么好事：他们被当作承诺和威胁，还会导致人们机械化地决定工作量、增加故事点或是小时数，而非仔细洞察团队到底能完成什么，如何完成。
我完全不赞成对故事进行估算，除了这样的描述：“几个人干几天”。当然了，这仍然是估算，但却不易被误用。
我喜欢让团队在几周内对大的故事进行估算，然后不断累加。这么做的结果会让人们对项目大小形成一种共识。不能将这当作承诺，但可以作为一个点，你可以提出重要的问题，比如说：在N美元和M月的前提下， 我们能否交付呢？
查看英文原文：Scrum Project Estimation Beyond the Near-Term?
译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。
当老板问你这个软件能什么时候完成。
发表人
see sai
发表于
Re: 当老板问你这个软件能什么时候完成。
发表人
yuhong huang
发表于
Re: 当老板问你这个软件能什么时候完成。
发表人
Lee Moody
发表于
3 条回复
关注此讨论 回复