领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Mike Bria 译者 郑柯 发布于 2008年2月1日
Michael Dubakov的公司最近发布了Target Process——一个针对敏捷项目管理和生命周期的产品。作为对该产品用户的问题和要求的回应,Dubakov对于敏捷项目中测算个人开发速率和个人估算准确率的活动提出了警告。他认为:由于已经有了针对团队的等价物,对于个人的测算标准和活动不但无法获取更多有价值的信息,而且有可能使得团队做出影响生产力和效率的行为。
在一篇2007年岁末的帖子中,Dubakov提出了关于敏捷团队希望测算个人开发速率的议题。他以两个开发人员——Ted和Jerry——为例说明:一系列的历史“个人开发速率”测算数据,对于团队未来的迭代规划以及团队的整体开发速率测算,没有任何帮助作用:
在一个迭代中,如果Ted完成了预估要花费40个小时的多个任务,而Jerry只完成了预估25个小时的多个任务,我们就可以说在该迭代中Ted的开发速率要更快。那么是不是意味着Ted是一个更快、更好的开发人员呢?不尽然。有无数原因可以解释Jerry为什么完成的任务量较少……好吧,那么多个迭代核算下来,两人的平均开发速率各是多少呢?令人惊讶的是,Jerry的平均开发速率是每个迭代完成54个小时的工作量。天哪!Jerry在上两周里怎么了?他的平均开发速率能够帮助我们制定准确的迭代计划吗?如果我们把团队的全部个人开发速率累加在一起,是不是可以帮我们制定更好的迭代计划呢?不行,因为我们已经有了“迭代开发速率(Iteration Velocity)”这个测量标准,而且它是不会发生变化的。
为了进一步说明他的观点,Dubakov指出,针对个人进行测算这种行为,会对敏捷团队的理想运作目标造成两种危害:
受到Michael的观点和最近一个论坛讨论贴的激发,James Carr很快就提醒大家开发速率的通常用法:
使用开发速率不是为了(评估)绩效……是要让客户更清晰准确地知道当前的迭代可以完成多少个功能“点数”。要牢记这一点。
最近的一个帖子中,Dubakov回顾了这个话题,这次他加入了对于测算个人估算准确率这一活动的警告。他首先指出这个测量标准不具备可行性,除非做到以下两点:一、估算由个人给出;二、团队追踪记录所有任务的完成时间。正像敏捷社区反复强调的,这两个条件的主要问题在于它们都违反了敏捷的基本原则:促进团队合作以及让工作变得更简单。
为了例证测算个人估算准确率会导致的错误后果,Dubakov又以假设的开发人员Ted为例:
我们可以计算Ted的全部任务分配和花费时间,并计算出下个迭代的估算准确率,假定为0.7。
好,那我们又该如何使用这个测算标准呢?如果Ted估算这个迭代的任务要花费60个小时,就是说他将会实际花费85个小时,对时长为两周的迭代来说,他至少要加班5个小时。Ted应该考虑这个因素,并从他的ToDo列表中去掉一些任务。如果Ted的估算准确率不变,这样做没有问题,可是真能这样理想吗?在现实中,Ted的估算准确率从0.5到0.9浮动不等,在下个迭代中,准确率可能为0.9,这样他就可以及时完成所有的工作。
InfoQ的Deborah Hartmann进一步阐述了Michael的观点,她质疑任何针对基于时间的估算准确率进行测算的有效性,无论这样的测算是针对团队还是个人:
要计算这样的估算准确率,团队必须要耗费精力获得详细的“实际”工作小时数,我可从没有见过哪个敏捷实践倡议说要这样做。经典的“规划的工作计量单位”与“全部完成的工作计量单位”,是以对客户更有价值的工作单位——交付的工作(故事点数、理想工作小时数、香蕉等等)进行估算准确率测算的。
通过追踪实际工作小时数来追踪估算准确率,不能为团队提供更多有价值的信息,而且造成了一种新形式的浪费。我同意Dubakov、Carr和其他人的观点:对大多数团队来说,我认为这种测算毫无价值,而且很高兴看到:由于该观点的提出,它很快就从TargetProcess中移除掉了。此种负责任的改变,正是我们期待敏捷团队所展示出来的行为。
Dubakov、Carr和Hartmann都同意:针对敏捷项目中个人开发速率和个人估算准确率进行测量活动,不但无法获取更多有价值的信息,而且有可能使得团队做出与敏捷核心思想相违背的行为。
查看英文原文:Measure Teams, Not Individuals译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。
多名敏捷社区最有影响力人物将出席Scrum Gathering上海站大会
大众点评网诚聘:Java、架构/性能优化、Hadoop等职位
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
论道WP第三篇专栏,以应用程序栏的使用为中心,包括了软键盘带来的问题、应用程序栏介绍、如何绑定应用程序栏的属性等几个方面的具体话题,为开发者顺利使用应用程序栏开发提供了具体指导。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
没有回复
关注此讨论 回复