如何用敏捷开发的12个原则，搞定数据治理？
Posted 谈数据
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何用敏捷开发的12个原则，搞定数据治理？相关的知识，希望对你有一定的参考价值。
任何一个企业提出数据要进行数据治理的时候都是满怀期望的，并且常常以为只要实施数据治理，就能实现供应链、生产、销售、物流、财务等业务的打通，就能实现数据的分析、挖掘、预测了。但往往期望越高、失望越大，数据治理哪有那么容易？
企业数据治理项目从调研梳理、标准制定到宣贯培训、落地执行，整个范围广，周期长，响应速度慢，往往项目标准流程刚刚落地，业务又发生了变化。数据治理常常忙的不可开交，却难为业务带来可观的价值。
既然数据治理这么难，业务变化这么快，价值也难以体现，那就任由数据“自由生长”？这显然是不行的！
治还是要治的，不过我们可以换种思路，换种方法，或许会有意想不到的收获！
敏捷并不是一个新概念，敏捷开发早在20多年前的就开始被逐步关注了。提到敏捷，人们大多数想到的并不是成套的复杂理论，而是一个个简单而有效的成功实践。事实上，
实践是敏捷的本质
，这在“敏捷宣言中”也可以充分体现。
个体与交互，胜过过程与工具
可以工作的软件，胜过面面俱到的文档
客户协作，胜过合同谈判
响应变化，胜过遵循计划
敏捷宣言告诉我们敏捷的价值在于通过个体之间的协助和沟通、实现持续不断的交付价值；通过加强客户的参与感和参与度，以便快速获得客户的反馈，以快速响应客户需求的变化。敏捷的核心思想强调面向结果，而非过程，“敏捷”是一种注重价值实现和以客户为中心的协作与创新理念。
敏捷开发核心思想第一条是“以人为本”。
强调了个体（人）以及个体间的沟通与协作的重要性，重视个体的潜能充分激发和团队的高效协作。
按照2/8原则，企业80%的数据问题产生于企业中20%的人，找的这20%的人，贯彻数据标准、纠正数据问题、激发他们的潜能，能够让企业数据治理事半功倍。
敏捷开发核心思想第二条是“目标导向”。
敏捷开发与其他众多的管理理论一样，认为目标导向是其成功的关键，因为没有目标也就无所谓成功。
对数据治理来讲，没有一个企业说是为了治理数据而治理数据，都是为了数据背后的业务和管理需要。
而遗憾的是，很多数据治理项目已经在繁杂的理数据、清数据、管数据中迷失了方向和目标。
敏捷开发核心思想第三条是“客户为先”。
敏捷开发的中强调的“客户为先”既不是简单把客户当做“上帝”、刻板的推崇“客户至上”，客户要求什么、我们就做什么；也不是把客户当作“谈判桌上的对手”、甚至“敌人”，去斗智斗勇。而是要将客户当成是合作伙伴，把自己的使命定位是“帮助客户取得成功”。因此说，
敏捷的思想同样适用于数据治理，这是让业务和技术紧密协作的基础
。
敏捷开发核心思想第四条是“拥抱变化”。
与传统软件项目总是试图用详尽的计划和流程，去预先控制项目的变化的发生，而结果往往是被不断变化的涌现的变化而击垮。敏捷开发认为承认变化是软件项目的一部分，相信真正的客户需求正式在不断的变化过程中明晰出来的。
数据治理也同样需要欢迎变化、拥抱变化，只有这样才能真正为客户创造价值
。
为什么需要“敏捷”？
为区分敏捷数据治理，我们姑且将通过整体规划、组织调整、标准建设、数据管理等与数据治理策略相关的常规做法统称为传统数据治理。
数字化时代，数字世界如同现实世界一样，每时每刻都在发生在变化，对数据治理来讲，数据需求在变，数据结构和形式在变，数据的采集、存储、处理、使用的技术和方式也在变，唯一不变的就是“变”。
规划很“丰满”，落地“很伤感”——这是多年以来，IT界大型项目从咨询规划到落地实施的一个真实写照，以前的ERP项目是这样，CRM项目是这样，现在的数据中台是这样，数据治理也如是。
需求管理问题、组织协同问题、项目沟通问题、时间安排问题、资源配合问题、业务流程问题、标准成熟度问题、文化适配问题、技术工具问题等等因素的不完美、不理想，造成了数据治理规划和落地的两层皮。
数据治理是一个典型的涉及范围广、工作量大且见效慢的项目。很多企业做数据治理大张旗鼓，咨询规划、协调组织、动员员工、梳理流程、清理数据，系统改造、接口开发……，花费了巨大的力气和成本，但最终实现的效果却不是特别明显。辛辛苦苦开发出来的数据看板，还是无人问津。领导依然觉得，系统中统计出来的数据与实际有偏差，对不上。
企业开启数据治理，一定要将范围框的小一些，目标明确一些，迭代节奏快一些，快速见效以增强各方的信心，再不断持续推进。
不论是数据运营还是数据治理，业务和技术总被认为是一对天生的冤家，他们每天都进行着一些差别不大，但是看起来很神奇的对话。
数据在应用过程中，总会遇到这样的问题：想要的数据拿不到，或不知道从哪取；拿到数据的时间长，等数据拿到了，发现业务已经过时了。因此，数据治理的一个重点是如何让业务及时且快速拿到想要的数据。而传统数据治理比较重视流程，试图通过严密的流程确保数据的安全合规使用，但正因如此也造成了数据的响应比较慢，难以满足业务所需。
之前某开发者论坛有这么一个调查，问程序员最怕的是什么？
A、改bug
B、开会
C、需求不断变化
D、加班
其中，选择“需求不断变化”的占了高达78.2%。于是，有一则笑话：程序员不怕交付的程序有bug，就怕bug改完了，需求变了！
对于数据工作者来说，也存在同样的问题，不论是经验丰富的“大表哥”，还是刚刚入坑的“茶树菇”，他们不怕不停的跑数、取数的繁琐，也不怕写SQL、建模型的枯燥，最怕的就是业务人员说“你这数据不对，不是我想要的”。
出现这问题，有两种原因，一是需求没有沟通清楚，二是需求发生了变更！而敏捷是应对变化的一剂良方！
2016年的一项数据治理研究发现，有46％的开发团队认为他们的数据组没有什么价值，甚至不知道数据组整天在忙什么。数据工作者真的是太冤了，理数、清数、跑数、取数每天忙得昏天暗地的，还被人说成是最没有价值的，┭┮﹏┭┮。
有没有一种方式，让领导、业务、技术等相关人员快速并持续感受数据治理的效果和价值？！
敏捷数据治理，笔者理解就是用敏捷的核心思想来管理数据，实现数据的持续、高质量交付，以应对业务的不断变化。敏捷的核心思想重点体现在4条敏捷宣言和敏捷开发的12个原则中，敏捷宣言在上文提到了，敏捷开发的12个原则如下：
原则1：尽早并持续的交付有价值的软件以满足客户需求。
对数据治理来讲，如何让业务快速拿到想要的数据是需要重点考虑的问题。业务人员应当参与数据需求分析，甚至取数的过程中，实现业务的自助取数、自助探索、自助分析，是解决数据持续交付的重点。
原则2：敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。
对数据治理来讲，从业务端数据的需求，到技术端数据的采、存、管、用，都在时刻发生着变化，数据治理人员应当认识到这一点，并且保持开放和学习的心态，欢迎变更，迎接变化，才能了解市场、理解业务，从而不断赋能业务，以支持业务的持续创新。
原则3：经常发布可用的软件而不是文档，发布间隔可以从几周到几个月，能短则短。
对数据治理来讲，数据标准是基础，只有将数据标准在各个业务流程、各个业务系统中使用起来才能检验出标准的适用性，并为标准的修订提供实践参考。数据标准是干出来的，不是写出来的，发布再多的标准文档、管理规范，不如将其中的一个或几个先用起来，再考虑如何用得好。
原则4：业务人员和开发人员在项目开发过程中应该每天共同工作。
对数据治理来讲，业务和技术应是紧密的合作伙伴，而非敌对的“冤家”，团队之间需要相互协作和协同配合。
业务人员制定的规则、定义的标准要和技术人员沟通如何有效落地，技术人员的数据建模、跑数规则、计算方法、数据结果也需要和业务人员验证是否满足业务的用数需求。
原则5：以有进取心的人为项目核心，充分支持信任他们。
对数据治理来讲，需要一个懂业务、懂技术、擅沟通、会管理、有意愿、有进取心的数据治理项目负责人，设法找到他并给他充分的授权，是数据治理项目取得成功的关键。我当然知道这样的人才是稀缺的，但这个原则的关键在于领导的充分信任和支持，技术弱一点、业务差一点，是可以慢慢培养的吗，要给数据工作人员一定的试错空间，通过不断的迭代、持续的优化，来逐步实现目标。
原则6：无论团队内外，面对面的交流始终是最有效的沟通方式。
这是一条通用的原则，不论是软件开发还是数据治理，或是其他任何类型的项目，面对面沟通依然是最有效的沟通方式，尽管视频会议、语音电话已经非常普及了，但是隔着屏幕的沟通，总会给人一种隔阂感，让人不能畅所欲言，并且容易引起误解。
这个原则的关键思想在于“以终为始”，对于软件开发项目的“终”就是交付可用的软件。对于数据治理来讲，不可能一步到位就将数据治理的“完美无缺”，与其追求完美的数据管理策略，不如将重点放在如何让用户快速拿到满足业务需求的数据，再根据用户的反馈逐步优化。
原则8：敏捷开发倡导可持续的发展。领导，团队和用户应该能按照目前的步调持续合作下去。
这一原则用在数据治理上太适合了！我们看到很多企业数据治理的失败案例，其原因并不是数据标准没能建起来，也不是数据管理工具不完善，而更多的是将数据治理作为一个项目在运行。当项目一旦结束，项目团队解散，定义的数据治理策略、标准常常被束之高阁，时间一久，便无人问津了。因此，企业数据治理必须要建立起长治久安、持续运行的机制。
原则9：持续关注卓越的技术和优良的设计，会增强敏捷能力。
这一原则强调了先进技术的应用，对数据治理来讲，使用云计算、大数据、人工智能、机器学习等先进技术的使用，能够让数据治理变得高效而智能。在数据梳理和识别、数据建模、元数据管理、主数据管理、数据质量管理、数据安全管理等领域均可使用先进的技术来赋能数据管理。可参考《》、《》
原则10：简明为本——它是极力简化不必要的工作量的技艺。
“简化”是一种数据思维模式。当今世界，信息爆炸、数据繁杂、真伪并存，不完整、不准确、不真实的数据带来不仅不是明智的洞察力，还有可能是误导！
在纷繁的信息中我们思考问题要善于简化，抓住重点，聚焦核心问题，以终为始、抽丝剥茧、多维度收集信息、多角度思考问题，找到高效的解决方案
。
原则11：最好的架构、需求和设计出自于自组织团队。
很多企业做数据治理，总是寄希望于供应商和外部专家，希望通过借用外部的力量解决企业内部的数据管理和使用上的问题。殊不知，“打铁还需自身硬”，从数据标准的制定到治理策略的执行，从数据整理、清洗、编码等基础工作到数据质量稽查、报告和整改等等，这一切都必须由企业自己来做，外部资源能支持更多的是经验和方法。“数据治理80%靠企业自身”，这个观点在之前的文章
《
》
也有提到过。
这也是一条通用的原则，不仅仅是软件开发需要“code review”，我们做任何事情都需要进行总结和复盘，不断积累经验，提升发现和解决问题的能力。对数据治理来讲，通过不断的Review，能够找到哪些策略没有被执行；哪些策略执行过程中遇到了问题，都遇到了什么样问题，问题能否解决；哪些策略为业务带来了价值，而哪些策略还有调整和优化的空间。
敏捷开发的原则是对敏捷价值观和解释和实践，他将敏捷和价值观落实到具体的可操作的原则之上。对于数据治理来讲，并不只是简单的套用敏捷的原则它就能“敏捷”了。
而是要真正理解敏捷的价值观，以“使用需求”为驱动，针对企业高价值的数据资产开展治理。
有人认为敏捷的对面是CMM，它是为解决CMM的过程复杂性而生，这种观点将敏捷放到了CMM的对立面，我个人认为是欠妥的，敏捷也好，CMM也好，其目标都是确保项目的按时、高质量交付。也有人认为敏捷和CMM是互补的，大型项目适用CMM，小型的项目适合敏捷，但如何界定项目大或者小呢？
事实上，不论是敏捷还是CMM，目前都是普遍应用的体系。于是，在知乎一个有关“你知道什么是敏捷开发吗”的讨论，其中的一条回答很简短，但却获得很多人的点赞，他是这么回答的：“我知道什么是敏捷开发，但我不知道什么不是敏捷开发”。由此也可以看出，
随着“敏捷”广泛的应用，概念之间的界线已经不是十分明显了，敏捷与CMM的融合使用也未尝不可
。
数字化环境下，企业需要的不仅仅是管理数据，他们更需要一个“合适”数据管理体系，通过该体系设置数据治理活动的参与规则，以实现企业的数据价值，减少成本和复杂性，规避风险，并确保数据的使用符合的法律、监管和其他要求。一个好的数据治理框架能够帮我们对复杂和模糊的概念做出清晰的梳理，以便明确目标和行动计划，从而提高项目成功率。
国内外，成熟的数据治理框架有很多，诸如：DAMA数据治理框架、DGI数据治理框架、DMM数据治理成熟度模型、DCMM数据治理成熟度模型等。这些数据治理框架体系，有一个共同特点：“大而全”，他们基本都涵盖了数据管理的多个专业领域，例如：数据战略、数据模型、元数据、数据质量、数据安全、数据集成、数据存储等内容。我们姑且称之为“传统数据治理框架”。（注：以上数据治理框架在本公众号的历史文章都有详细介绍和解读，可以从历史文章中查看）
业界成熟数据治理框架为企业的数据治理提供了体系化的理论支撑，指导企业开展数据治理活动。但是，企业数据治理并非“一日之功”，尽管有成熟的数据治理框架参考，也不要试图“一口吃个胖子”。拿DCMM数据治理模型来说，它包含了8大过程域，28个过程项，441项评价指标，你希望通过一个项目将每个过程域都做一遍，每个指标项都去实现，这几乎是不可能的。
一定切忌：企业的数据治理，必须结合企业的实际需求，“从大处着眼，从小处着手”。“传统”成熟的数据治理框架能够帮助我们建立数据治理的全局视角，立足数据战略，做好整体规划。而敏捷数据治理方法，能够我们我们有效的开展数据治理实践，从而实现数据的持续治理、不断优化。因此，对企业数据治理来讲，敏捷数据治理方法、传统数据治理框架并不矛盾，而且可以融合使用。
最后强调：再完善的知识体系都不能直接照搬。随着企业的变化、数据治理的挑战也随之变化，每个企业独特的解决方案都应该是数据治理理论框架中的一个特定实现，是无限变化的，企业应当结合传统数据治理框架、敏捷数据治理方法探索出一条数据企业自身的数据治理之路。
中国敏捷软件开发联盟《敏捷开发知识体系》