领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Mark Figley 译者 孙向晖 发布于 2007年9月10日
在横跨5天的5篇博文中,数据治理博客提供了一个开发数据成熟度模型的快速入门指南。与先前建立数据治理成熟模型的方法的有趣的不同点是:它提倡一个为给定的组织量身定做适当的模型,而不是试图为了统一而应用标准模型。在这个5部分组成的数据治理系列中,开始部分关注定义范围,建立基线。在给你的数据建立一个成熟度模型时,首先在你的企业数据中划定要治理的那部分数据是非常有必要的。一旦数据的范围定义好了,就需要给它建立一个基线。见专题中的:
什么是你的数据集中成熟度级别最低的数据?你的回答可能是沿袭这条思路:未被审查的、没有被建模的,没有元数据、不知道它是什么的”,“它虽然在我们的协助数据模型中,但是除了字段名外没有其他信息,没有元数据”,或者“它在我们的模型中,我们有一些过时的定义,而且我们也不再认为它是可信赖的”
这可能会花费很多的时间,但最重要的是为它建立一个基线。需要捕获的主要内容是:
- 它在你的数据模型中吗?
- 你给它的元数据了吗?
- 如果有元数据,你信任元数据中的信息吗?
在第2天,介绍了数据成熟度模型的自然级数:
你现在要寻找的是你能看到的数据当前所处于的级别。从最低的级别开始,你能够看到的在成熟度中的下一个位置在哪里?如果你的起始级别是“未建模的、没有元数据、不知道它是什么的”,你的数据所能看到的下一步可能是“属于我们的数据模型但是我们对它获得不了其他的辅助信息”……与其建立一个需要强制我们的数据去适应它的数据成熟度模型,不如让我们用数据已经存在的不同的阶段来定义成熟度的路径。
第3篇blog把关注重点从最低级的成熟度转向最高级的成熟度,并试图使用一致的术语来架越鸿沟:
其实,我想让你做的是拿出你在第一天得到的内容并写下与它完全相反的内容,这个会帮助你确定最高的成熟度级别。所以,如果你的最低级别是:“未建模的,未被评审的,没有元数据的”,那么最适宜的最高级别应该是“数据模型经过了数据治理委员会评审和治理过的,验证过了数据模型并进行了及时更新”。这样做会让你的成熟度模型框定相同的项目。如果你在讨论你的最低级别的数据模型,你应该讨论包括最高级别在内的其他级别。
在第4篇博文中提供了成熟度模型可用的模板, 第4、5两篇博文带你领略如何为你的组织量身定制合适的成熟度模型。
先从最重要的事情开始,完成下列内容:填写你的数据治理成熟度模型模板,找出你的程序中的范围内数据。 下面要做的是从你的数据中取样,并确保你能从成熟度模型中轻松的为其进行定位。如果再让我我来做这步工作的话,我会随机的挑选出40个字段并逐一进行检查。我会查看这些字段,检查模型,检查它们是否拥有元数据等,并看它们是否可以属于某个级别。你需要确保所有这些数据字段都在成熟度模型中找到了归属位置。如果在这其中发生了生命问题,说明你还没有完全清晰的定义好了你的等级。如果它们同时被分到了两个级别中,你需要定义一个新的级别来说明其中的不同,或者根据它的特征合并到你其中一个已经存在的级别中。查看英文原文:Building a Data Maturity Model for Data Governance
在实施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概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
没有回复
关注此讨论 回复