领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Boris Lublinsky 译者 马国耀 发布于 2010年10月12日
许多刊物已明确指出,保证业务流程管理(BPM)成功的主要前提之一是业务和IT的紧密协作。业务流程管理标注(BPMN)的发展是保证这种合作的途径之一,其最初目标是——成为IT和业务共用的业务流程定义语言。BPMN2.0引入了许多新结构,它们可用于直接定义流程的执行方式,因此,许多供应商采用它作为BPM的运行时语言。但是很多分析师认为,从业务的角度看,执行方面的增强使它更加复杂。Jim Sinur坚称,BPMN对业务的要求太高:
BPMN对于业务的复杂程度并不取决于业务需求。有些人认为,因为BPMN对IT已足够好,所以对业务也应该足够好。我认为,前半句没有问题,后半句与事实之间存在差距。IT无法期望业务真正理解那些加密的/标准的格式,因为业务希望看到的业务流程的真实描述,用他们期待的那些图标,而非工程图标。好比某人说“让他们吃蛋糕啊”(译注:参考let them eat cake,最初可能源自法国的某位公主,当她听到农民没有面包吃时说,“让他们吃蛋糕啊”,而蛋糕是用高级面包和鸡蛋做成的,此处表示IT不了解业务对BPMN图标的理解水平),正是这种IT的傲慢让BPM技术沉没……BPMN其实是“业务人员无法理解”(译注:“Business People May Not...understand”,前面四个单词的首字母缩写也是BPMN)。
Sinur的博文引起了洪水般的回复。其中,Scott Frances认为,我们可以要求业务掌握一些新技能,正如他们要求IT提高他们的技能一样:
尊敬地说,我理解Jim的愿望是让业务摆脱困境。业务不需要学习任何新技能,只在餐纸巾上画点东西就期待它能像流程一样运行?随意画点陈旧的图形,如果不要求别人理解还不成问题(诚然,标准的价值在于不单单是某个人或某个团队才能够理解它所产出的东西)……如今,在我们要求IT学习新技能、变得更加面向业务的同时,让业务学习一些新技能以支持流程的改进,这点要求过分吗?……问题不在于标注语言BPMN本身有多难,而是太多人认为BPM开始于BPMN,结束于BPMN。较之BPMN,人们更需要业务流程的管理并改进。
Keth Swenson提到,BPMN新版本的大多数增强都是针对开发人员而非业务人员的,它将图形化编程语言转换成流程。针对侧重于建模而非执行的厂商是否会从BPMN1.2升级到2.0,他表示怀疑。在他看来:
对服务器整合型BPM,或者EAI或Web服务编排而言,它们的确能从BPMN2.0的新增特性中获得不少益处。而对于用图形描述人工活动的工作流而非服务器整合,BPMN2.0中增加的那些特性也许只能给我们带来更多复杂性,却不能带来充分的好处。
Sandy Kemsley在回答Swenson的评论是说,他强烈反对他的意见:
我认为Keth的说法是“将婴儿与洗澡水一起倒掉”(译注:这是一则习语,意指丢弃无用物时将珍贵的东西也一并丢弃了),尽管许多新增的特性使得BMPN对于开发人员更加有价值,但这不能否认那些原有的基础结构集对于业务的价值,因为业务已经使用这些基础结构将业务流程映射成流图。在没有任何引导的情况下,我经常看到业务(和业务分析员)用流图表示他们的业务流程;将他们引导向这些最简单的BPMN结构集合至少能让那些流图变得标准化,从而减少对流图中各种的图标的误解,减少流图事件出现混乱局面的可能性。
Neil Ward-Dutton持中庸立场:
……BPMN的应用性取决于众多因素;简单地说BPMN(特别是BPMN2.0)适用于业务或不适用于业务太过轻率和绝对,这就像说云计算将是(或否)IT的未来一样。这其中的第一个假设是,必须要对BPMN作出个非此即彼的定位;第二个假设是,“业务是某种单一组织,只有单一的技能、经验和偏好”……很多事实表明,一个有高层分析和设计经验的业务分析员绝对能使用BPMN的核心图标集描述业务流程,从而在交叉团队间形成便于交流的共通语言。
是的,BPMN2.0中大部分新特性的目标都使它成为一门可执行语言,而且,完整的标准的确相当复杂。但是,正如Bruce Silver的书中的解释,BPMN2.0可用在三个层级上——描述、分析和执行。如果我们假定业务从只包含10个主要图标的第一层开始,这样就不会太复杂。但是,形式化的标准语言能使业务和IT在理解和解释上达成一致,这一优势是巨大的。
查看英文原文:Will Business Adopt BPMN 2.0?
译者 马国耀 关注企业级应用开发与架构,有多年SOA项目实施和咨询经验,专注于SOA及云计算的融合。
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
2 条回复
关注此讨论 回复