领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Amr Elssamadisy 译者 姚九强 发布于 2011年6月21日
Glen Alleman介绍了他们使用的业务管理流程——称为Afterburner——及其它对个人成功责任的依赖。Glen接着描述了他对团队责任而非个人承担责任的想法感到不适。根据本月Afterburner的视频通讯,在四步过程:1)计划,2)简介,3)执行,4)汇报中,如果我们无法回答“谁对失败负责?”这个问题,汇报无法做到有效。
Glen质疑了团队责任,这意味着没有个体对成功和失败负责。Andrew Joiner给出了一个回应:
Scrum或敏捷都没说个体不负责任。他们当然负责任;在一个sprint中,每次他们做一个任务时他们都是向团队做出承诺,并且有责任完成这个任务,无论是否需要帮助。
此外,作为团队整体也对在sprint计划会上承诺的可交付物负责。如果情况有变,那么这种责任要求通过重要的对话来重新估算并确认或改变早先的承诺。
“集体所有权”是一个经常用在代码库上的术语,最早来自于XP。它意味着没有一个人“拥有”代码的任何一部分。任何有足够技巧的人都可以负责任的修改代码。它和XP的其它实践相互支撑,比如持续集成、结对编程等等。
但Glen的观点也是有根据的,因为“集体责任”难以理解和实施:
只能有一个人负有最终责任(accountability)。其他人也可以负责(responsible)。许多最终责任与管理的核心原则相矛盾。负最终责任的人可以分解责任。这些原则不仅来自项目管理,也来自GAAP、SOX和业务治理。
当然代码的集体责任与领域及上下文背景高度相关。
这是理解自组织团队特别是实施敏捷开发的团队中比较困难的部分。我们在2009年敏捷大会对Christopher Avery的采访中,深入的讨论过这个话题。我们问了Avery关于个人责任和自组织团队的关系是怎样的:
我试图教给聪明的人如何建设团队,我记得在采访的开始,(我问)什么是精髓?精髓就是要求团队成员分担责任,当人们觉得一些大事能够为大家所分担,那么他们的行为就自动的转变,是有机的转变。我有一些技巧教给人们如何做到。
......如果我们专注于我们在一条船上并且能获得更大的成功,那么就意味 着这是我们每个人的意愿,如果我们有主人翁意识意味着我们会有机的填补上空白、补上缺陷、改进流程。他们说团队中的角色都是新的,究其原因是因为团队总是 临时的而且是由更大的任务决定的,当人们有一种能要把事情搞定的感觉时,他们就会投身其中做需要完成的事情。
Avery教给我们的是因为没有个人的失败,也没有个人的成功,所以个人的责任是不够的。因此虽然仍然有个人责任,一个人的失败也是团队的失败(“不是我的翅膀着火”原则)。团队需要对项目的成功集体负责而不是追究是谁的错误。
组织责任是不是与你产生共鸣?是不是我们模糊了“最终责任(accountability)”,“职责(responsibility)”和“所有权”的使用方法?而且,最重要的是,它会如何影响你的结果?
查看英文原文:Questioning Team Accountability
译者 姚九强 是一名业务分析师,机器人爱好者,目前在ThoughtWorks。关注敏捷方法、运维和业务模型。
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
没有回复
关注此讨论 回复