领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 李楠 发布于 2010年10月16日
10月14日至15日举行的第五届敏捷中国大会由ThoughtWorks主办、InfoQ全程负责票务。自敏捷宣言提出到现在已经10年,敏捷在中国也已经走过了普及宣传期,进入了实践和推广阶段。本次大会主要对在企业中推行敏捷实践、敏捷转型等方面作更为深入的探讨。InfoQ编辑在大会现场就敏捷、云计算等相关话题和ThoughtWorks中国区总经理郭晓、中国移动研究院项目经理张为民等进行了简短的交流。
受访者介绍:
郭晓,ThoughtWorks中国区总经理。郭晓致力于ThoughtWorks在中国市场的发展,建立ThoughtWorks在中国IT行业的思想领袖地位,并为中国及全球的客户交付商业价值。郭晓自2004年起协助创建并领导了ThoughtWorks中国分公司,并先后担任过技术总监,中国区副总经理等职务。
张为民,曾任爱立信(中国)的项目经理和市场经理,现任中国移动通信研究院业务拓展经理。在移动通信行业拥有超过16年的从业经验,在GSM/WCDMA/TDSCDMA、移动增值业务等领域具有丰富的经验。目前从事云计算的业务拓展和外部协作工作,是中国云计算专委会的主要发起人之一。著有《云计算——深刻改变未来》一书。在云计算领域有着独到的见解。
InfoQ:中国移动在大云中用了一些敏捷的方法,能不能谈一些具体施行的方面?
张为民:我们从一开始研发软件系统就在进行大规模节点的部署,这实际上就是敏捷的,就是要不断地测试、实践、尝试,然后找到不足、反馈、修改、甚至是架构更改。谷歌的云计算的架构发生了7次剧痛一样的改变,这说明在经历这些挑战的过程中,一定要在实践中摸爬滚打,比如常规性的测试,预先的测试,还有那些上线服务等等。
InfoQ:云计算现在是给我们带来了一种便捷信息的商业模式,对于在云技术上和商业上的转变上,对开发者和用户需要做哪些变化?
张为民:我想跟诸位解释一下,中国移动是一个大的国企,所以今天我是以云计算专委会的成员来参加采访,可以讲一些代表我个人的观点。对于众多的开发者目前都在面临最大的转型,他们会发现这个时代可能会让他们梦想成真,对于开发者来说,信息运营商在不断地把平台开放给他们。所以我想对于开发者,可以很轻易地尝试研发,发表自己的软件作品,让大家能实践。有这样的平台,同时也会有这样的机会使开发者们变成一个创始者,来创造他自己的未来和奇迹。所以对于开发者更多的是需要掌握适合互联网运营平台和它开放的一些工具,以及软件包所需要的这些技能,同时还需要创新的想法。这里头不妨提起,我觉得开源的一些组织和一些资源对于开发者们是需要掌握到的,这对他们来说是一个减小风险的好方法。
InfoQ:对于大多数的小团队,或者个人开发者,您觉得敏捷开发对他们来说,比如对于个人开发者,他们需要有什么样的想法?
郭晓:因为敏捷在最开始的时候,有一个普遍的观点,就是敏捷只适合于小团队,不适合于大团队。在过去的十年里敏捷有很大的变化,这个时候做了很多的调整和修改。比如说出去压马路,一个人不会有问题,两个人就需要共享,如果一百个人、一千个人会有什么问题。这是一个很成熟的领域,作为个人、小开发团队完全可以放心地使用敏捷的各种方法,不会受到很多限制,因为这套东西在敏捷开发的初期就已经很成熟了,最近几年才开始往大团队发展。
InfoQ:从敏捷宣言到现在已经十年了,在中国,敏捷的发展也不是一帆风顺的,您认为在敏捷实践这方面,企业应该怎么去做?我们应该怎么样去实现敏捷转型?
郭晓:过去十年里,从2000年到现在,其实敏捷本身的具体技术、方法没有太多变化。这个阶段其实在很多行业里面做的最大的努力是解决把敏捷在企业内范围进行推广这个难题。实际上很多问题,如果说最终归结的话,都可以算作文化问题,这个很难彻底改变。首先作为一个企业,一定要有足够的耐心。作为一个组织,从管理者到员工,所有人都要形成一个共识,并不要以为只要认真的从头开始做敏捷,十年以后肯定见效。反而从心理上接受是一个很缓慢的过程。在操作过程中一定要注意实效,刚开始做敏捷的时候,没有必要把所有的员工培训一遍,反而是要找到一个合适的事件,针对自己本身的情况,让一个小的团队在一个合适的项目上迅速地尝试适合自己的组织流程。在这个过程当中要有一批对企业内部非常熟悉,思维敏捷并能够迅速学习的种子,通过他们再不断地把成功的经验复制到团队内部其他的项目当中。利用这种方式不断地学习,相信在一定时间之内,就会慢慢看到适合他自己团队的敏捷体系,这个过程可以不断地增长,继而给企业带来价值。需要注意的是,一定不能急功近利,但是也不能放任自由。
InfoQ:在实行敏捷开发的时候,很容易到最后变成“伪敏捷”这种情况,造成这样的原因是什么呢?
郭晓:很有可能他是太注重了某一个方面,实际上刚才说到需要不断地成熟。但是过程当中交付的时候,发现差错,也没有人想去提高,问题就很严重了!如果说这个团队不去思考这个问题,不想办法解决这个问题,那是肯定不行的。因为有大量的实践要配合在一起的,所以过于偏激地使用某一个方法,而遇到问题不会去思考,自然会觉得这里面的东西我做了,完成了,怎么还不行。
InfoQ:敏捷在国内的推广,可能会是一个很漫长的过程,刚才说ThoughtWorks就像个传教士的角色,未来您期望的是扮演什么样的角色呢?
郭晓:实际上敏捷在中国被完全接受的时间没有人知道,也许明年整个社区都开始敏捷了。我们的希望并不是它有多快,多长时间内能接受,我们的希望,是在这个过程当中让大家能够少走些弯路。因为尤其在国外,其实走了很多弯路,我们在接受过程当中有一个可能会比较容易犯的错误,就是什么容易先做什么。那么这种心态比较可怕,所以希望大家心态要放端正,我们在接受过程中更重要的是思考过程,怎么去学习,怎么能够不断地把自己提高,把这些当做自己学习的过程。
InfoQ:未来ThoughtWorks发展会不会也会把咨询作为一个一体化服务中的一部分?
郭晓:我个人很多时候把软件开发服务商分成几个阶段,第一个阶段是低附加值的人力,第二阶段是能够做整体的开发,第三个阶段就是能够把自己的解决方案和产品做出来,第四个阶段就是咨询、高附加值的服务。我们现在主要做的是第二个阶段,做一部分咨询是因为我们的敏捷方法足够好,所以我们会不会走这条路做产品?这个很难说,而且我们的规模实际上没有太多,2000人,我相信软件开发随之而来必然会有一体化的服务。
InfoQ:关于Thougthworks全球,因为可能遇到开发团队与管理团队相距很远的问题。这涉及到一个团队的分布式敏捷开发,不知道Thougthworks有什么经验?
郭晓:这确实是一个很专业的问题,thoughtworks其实做了很多,包括在印度,这时候遇到一个问题,需求在那边,业务也在那边,开发团队在另外一个地方,这个时候怎么合作?实际上我们走了一个弯路,在4、5年以前的一个概念叫做分布式敏捷,实际上这个理念最后被证明是不成熟的。因为第一个阶段提出来的时候,认为完全可以把敏捷团队分为两大块儿,一边是需求、项目管理,开发团队在另外一边,完全可以用这种方式。实际上在这个过程中,发现一刀切的方式其实是不非常适合的。后来逐渐开始思考敏捷本身,后来发现分布式敏捷实际上违背了敏捷最重要的一个原则,因为就敏捷来就说,大家必须都要在一张桌子上合作,面对面的沟通,充分地交流。那么一旦使用分布式,又要变成回成零散的。所以它实际上是违背了我们敏捷的原则,换句话说没有分布式敏捷这种东西,只能说在分布的情况下,需要对敏捷的方法进行调整。能够使用很多具体的手段,包括格沟通,包括资源控制。实际上有些分布式的代码,让分布式可以共享,能有效地缓解分布式带来的麻烦。但是如果能够在一起做敏捷的时候,最好能够走在一起做敏捷,不得不分布的时候就需要想办法解决沟通的问题。那么为什么很多时候要做分布式敏捷,实际上有很多其他的问题存在,包括商务上的成本,或者是这些专家的地点,逼着团队去执行分布。当不得不分布的时候就分布,分布之后就需要考虑怎么改变流程。想把敏捷做好就不要分布,不得不分布的时候只能把敏捷做得还可以。
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
没有回复
关注此讨论 回复