领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Vikas Hazrati 译者 郑柯 发布于 2008年7月5日
大多数敏捷实践都非常重视简单。XP强调做最简单的事情,只要够用就行。然而,要想做到简单却并不容易,有多种原因会让事情变得更加复杂。敏捷社区的众多成员们讨论了“简单”这个概念,并试图解释为什么想让事情保持简单如此困难。
敏捷强调简单,却总是带来复杂。在一个有趣的帖子中,作者试图揭示该现象背后的原因。他引用了管理科学的最新议题:
很多软件设计者有意创建具有不必要复杂性的产品,以拓展自己的职业发展空间,而不是为了更好地为公司和客户服务。
……
能力强的设计者为了证明自己的才能,会选择不易实现的设计;而能力稍差的设计者因为不想让别人知道自己没有才能,会选择高难度的设计。这是Siemsen教授的结论。
对于将事情复杂化的倾向,George Ambler提到一个类似的原因:
由于想把事情做得更多、更快,我们花费了太多时间,将我们的生活复杂化了。想把某事做得正确,时间似乎老是不够用,可却总有时间把它再做一遍!考虑到管理技术的复杂性,我们总是喜欢将复杂的解决方案视为更好的。
社区其他成员认为:大家有时为了图省事,才会考虑简单,这反而会带来复杂性。Damon W. Carr在他的blog中,质疑敏捷运动是不是把简单强调得过头了。他问道:
敏捷爱好者们好像患上了严重的“简单强迫症”,极力避免各种开发流程和形式,无论其必要与否。不经意间,团队已将优秀面向对象设计的常识抛在脑后,只是做“够用就好”的事情。在这条路上,敏捷运动是不是走的太远了?
Damon觉得:由于敏捷过分强调可以工作的软件,很多开发人员选择忽略可维护性、可扩展性、代码重用、内部健壮性、组件使用等这些重要的方面。
有些人认为,对于简单与复杂的判断是很主观的。一个人认为简单的事情,另一个人可能会觉得很复杂。Andrew Johnston 说道 :
简单性和复杂性都是相对而言的,一个人觉得简单的东西,换个角度来看可能就意味着复杂。好比一只鸭子在水面上优雅地滑行,而它的脚蹼却在水下做着复杂而卖力的摆动。那到底什么是“简单”?又该如何理解“简单”呢?
Brad Appleton在他的博客上提到,他对“简单”做了很多研究,最后得到了如下结论:
我觉得,要说“简单”可能是“简明易懂”的,嗯,这没什么问题;但是要真正理解“简单”却是非常困难的!
Brad认为:系统开发中的简单,意味着要有整体的观念,同时还要能够知道重点何在,而且要知道重点部分对系统其他部分的影响。他强调:真正的简单,是要将整体的复杂性管理起来并尽量将其降到最低的。Brad提到,虽然业界已经在简单上投入了大量精力,然而围绕着它还是有很多神话。他列举出了一些有助于理解简单的言论:
“简单”并不等同于“易于实施/和理解”——要想搞懂更为简单的解决方案,团队可能需要学习新的知识,同时要接纳新的想法。
“简单”并不等同于“足够好”——简单的解决方案也许还不够用。它也许可以暂时满足目前的要求,但是需要进一步改善。
“简单”并不等同于“单纯”——单纯可能只是错误的表象。一个解决方案可能看起来很简单,但是仅仅看起来简单还不够,它必须可以发挥应有的作用。
实现某个要求的简单方式,从全局来看不一定简单——试图简化系统的某个部分,有可能使得系统其他部分更加复杂。要从全局的观点来观察系统。
综上所述,看来在“简单”的周围,有相当多的“复杂”环伺。关键在于要力图澄清围绕着简单的神话,而且要避免“复杂的解决方案更优秀”这样的认知。
查看英文原文: The Complexity Around Simplicity
在infoq英文站的新闻后,读者Jim Leonardo这样评论:
“简单”并不是“第一时间浮现在脑海中的、可以工作的解决方案”。
实际上,要产生简单的解决方案要比复杂方案花费更多的功夫。必须要把所有的佐料放到锅里,再精心烹制,才能做出简单的菜肴。所以经常要用多个迭代才能产生达到这个境界。正如文中指出的,要搞清楚想让什么变得简单。是要让编码变简单?还是使用简单?或是扩展简单、维护起来简单?
使用简单最不容易在众人之间达成一致,特别是涉及到UI的时候。扩展简单与维护简单通常连在一起。这些都需要更多的编码工作,但并不是说自动会让编码变得更复杂。
另一名读者Frederic Monjo建议读者去阅读John Maeda的“The laws of Simplicity”这本书,其中谈到了如何做到简单的产品设计,但同时提出了一些关于简单的原则和概念。虽然这些原则不是直接用于软件开发的,但可能会激发读者对简单的思考。例如,本文中也提到了一个原则:简单与复杂相生相伴。它们都是相对而言的,必须要同时考虑这二者,并让它们各归其位。
译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
4 条回复
关注此讨论 回复