领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Sadek Drobi 译者 赵劼,郭晓刚 发布于 2008年1月13日
软件项目中有许多决策是出于生产力方面的考虑而决定的,尤其是在项目比较成功的情况下,市场发展了,与此同时领域知识和客户需求也变得愈发复杂。产品的目标范围很可能会发生无法预料的改变,而且需要更进一步按照用户的需求来定制。就像Lispy所特别指出的那样,很多团队通过“使出丑陋的招数”来快速适应新需求,“哄着客户高兴了,钱就滚滚而来”。他把这种对软件的质量的影响称为“成功之痛”。
Bob Martin描述了这些影响,并且认为这种“快速而拙劣”的做法不可能长时间维持下去,因为它最终会不可避免地使项目进展速度变慢。
我最近刚见过一个客户,他们是一家成功的初创企业,一开始可以说是突飞猛进。他们的软件发展得飞快,不过从头到尾都是不择手段拼凑出来的。现在这个一团乱麻的软件让他们寸步难行。任务失败率很高,修改引起的非预期副作用很多,生产效率很低。
[……]“快速而拙劣”这个词是自相矛盾的,拙劣总是意味着慢。
常有人觉得不管怎样业务软件都会是一团糟,并以此来作为不择手段的正当理由,Bob Martin非常不同意。他认为虽然业务规则有着“复杂、武断、不通用”的趋向,但代码与之相反,必须尽可能整洁:
要是再把业务规则的烂摊子丢进另一个烂摊子,你就更没办法理清它们了。要想从规则的乱麻中理出一个头绪,唯一的方法就是用最最清晰的代码来表达它们。
Roland Kaufmann在Martin的文章后评论说,把生产力摆到首位的想法,其解释可以归结到“一个荒唐的内部收益率(IRR),令短期的节省比长期的收益更有利”。尤其有许多经理总是假定任何项目只要存续的时间够长,肯定免不了周期性地完全推倒,再重新设计和实现。其中一条评论还认为这种短视的、以生产力为导向的合理性,正是计算机科学专业的毕业生被责怪不会写软件的原因。
David Chisnell说得没错,“计算机科学和软件工程是非常不同的两种训练”。后者“从工具和过程两个方面教授开发软件的方法”,而计算机科学课程只“简要地接触这些主题”,且计算机科学并不是“职业训练”。毕业生对许多语言走马观花,而得不到这些语言及相关工具的任何深入的知识。因此,他们很可能没法高效率地编码并遵守紧迫的期限。但正如一位博客作者所说的,“毕业生们的不称职谁都看得到”,但有些人“没什么大规模设计/架构的智慧”却大干快上,反倒并不会“因糟糕的设计决策令整个系统慢慢变得不可维护而遭受责难”,因为“他们初期的成功让管理层觉得最后的失败是非人力所能避免的。”
不过,Lispy认为,生产力低下的计算机科学毕业生却具备一些技能,会随着项目的大小和复杂性的增长,而成为开发成功的关键。“增加数之不尽的特性,或者每张单子都要进行昂贵的定制工作”,这些都是“规模增长之大敌”,Lispy认为,就算很努力而且运气很好,“没受过训练的野路子程序员”也只能把项目扛到某个程度,超过之后他们就会需要“帮助他们编写他们的工具的工具”。Lispy相信计算机科学是提供这样的工具所必需的,因为那需要更深一个层面的理解才行。爱因斯坦曾说,“我们面对的重大问题无法在我们创造出这些问题的同一个思维层面上解决。”要解决现实的开发工作中所面对的问题,我们可能需要计算机科学的毕业生,虽然他们显然没法在现实世界中以生产力为导向的要求下编写代码。
查看英文原文:Decisions driven by productivity concerns: Reasons, implications and limitations
『但正如一位博客作者所说的,“毕业生们的不称职谁都看得到”,但有些人“没什么大规模设计/架构的智慧”却大干快上,反倒并不会“因糟糕的设计决策令整个系统慢慢变得不可维护而遭受责难”,因为“他们初期的成功让管理层觉得最后的失败是不可避免的。”』
这句话,我有点不太明白,尤其是最后一句:为什么“初期的成功让管理层觉得最后的失败是不可避免的”?
初期的成功不代表架构的成功以及最后结果的成功。失败往往是在第一步决定的
初期的成功令管理层以为失败是自然规律,不关设计者的事。
译得看不懂吗--b,要检讨……
那又怎么能够根据初期的成功来判断架构和结果是否能够成功呢?那么成功的架构和项目,初期是什么样的?难道不应该是成功的么?
我是说,此处管理层根据“初期的成功”就来判断“最后的失败不可避免”似乎有些逻辑上不能自圆其说。
嗯,“他们初期的成功让管理层觉得最后的失败是不可避免的”和“ 初期的成功令管理层以为失败是自然规律,不关设计者的事”分明是两个意思……
这里的意思是说“他们初期的成功让管理层觉得最终到来的失败是非人力所能避免的”,就是说他们初期的成功让不甚了解架构重要性的管理层充分信任了他们的个人能力,如果最后失败了,他们会认为这本来就是mission impossible,无需怪罪个人和整个开发过程。
"是非人力所能避免的",就是要找这几个字,thanks!
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
7 条回复
关注此讨论 回复