该网站提供了广泛的哲学，经过验证的技术，以及关于软件开发的数据导向方面的有效方法的一两个合理的理论。它没有做的是讨论你需要做些什么来取得成功。到现在。在本文中，我将介绍您的组织如何采用此站点中描述的敏捷数据库技术。我的期望是，许多组织很难采用敏捷数据库技术。这并不是因为它们本身就存在任何复杂性，问题主要在于文化惯性。要成功采用这些哲学和技术，您必须：
- 改变你对软件开发的看法
- 了解您面临的挑战
- 实际上试试吧
- 阻止非敏捷的同事
- 现实点
- 让我们帮助您变得敏捷
1.改变你对软件开发的看法
本网站描述的理念和技术对您的组织有几个重要的影响。我的经验是你必须接受：
- 每个人都需要紧密合作。软件开发是一种通信游戏，正如Cockburn（2002）所说，文档是最糟糕的通信形式，而站在白板周围的面对面交流是最好的。简单的事情，例如将团队放在一个工作空间中，使用白板和纸张等简单工具，以及让项目利益相关者成为团队的活跃成员，可以将您的工作效率提高至少一个数量级。
- 软件发布时，模型和文档完成。它现在是一个迭代和渐进的世界，而不是一个连续的世界。只有在软件准备好进行最终验收测试之前，才会完全定义系统发布的要求。在那之前他们可能会改变。如果你甚至创建了一个逻辑数据模型和物理数据模型，那么可以说同样的事情。这些工作产品随着系统工作的进展而发展，甚至可能在系统生产基线完成前几个小时就会发生变化。
- 敏捷需要更严格的纪律。虽然这不是传统主义者想要听到的，但实际情况是，与传统方法相比，敏捷方法需要从业者更多的纪律。
- IT部门的权力将发生变化。流程的变化总是需要在组织的权力结构内进行转变，敏捷数据也不例外。敏捷数据库技术改变了企业关注的方式，特别是与数据相关的方式。建筑模型评论已经成为过去，因为您的模型会随着时间的推移而发展，因为评论是敏捷开发中的“过程气味”，表明您在项目的早期就犯了组织错误。一种看待它的方法是，如果某人有资格审查工作产品，为什么不让他们参与其最初的开发？现有的组织结构，特别是基于专业技能或指挥和控制结构的组织结构，需要重新设计，以支持更有机的结构。
- 每个人都需要积极参与。参加评审的专家或提交给他们审查和反馈的工作产品的那一天结束了。官僚主义者只是推动纸张并且对系统的创建，维护，操作或支持没有直接影响的那一天应该永远不会出现。官僚们不能再隐藏他们繁重和规范的流程，相反他们必须卷起袖子，与项目团队密切合作，实际上为你的IT工作增加价值。反对这一概念的人可能是重新教育的良好候选人，在极端情况下可能需要了解其他组织的机会（如果你明白我的意思）。我们现在需要概括专家。
- 每个人都需要重新思考他们的方法和信念。在这个网站上有许多发人深思的想法。可以采用渐进的方法进行数据库设计。建模比UML或数据更多。您可以通过许多不同的方式进行开发，其中一种方法并不适合所有方法。许多技术问题通常被认为是数据库的唯一领域，包括参照完整性和事务控制，在您的对象中也是相关的。您可以使用许多技术选项，它们都有自己的优点和缺点。关键是这些想法很可能违背您目前的想法，或者您目前更喜欢的工作方式。克服它。
2.了解您面临的挑战
您还需要了解在将敏捷数据技术引入组织时可能遇到的挑战。我的经验是，您需要克服的最困难的挑战不是技术性的，而是以人为本。冒着刻板印象的风险，我发现有经验的IT专业人员，新手开发人员和经理似乎都有自己独特的挑战需要克服。让我们一次看一组。
经验丰富的IT专业人士，通常是业内二十多年的人，可能：
- 没有花时间去理解敏捷软件开发。
- 没有采取或被允许的时间尝试本网站描述的技术和哲学。
- 对变革感到不舒服，尤其是那些极大地改变IT部门政治权力结构的变化。
- 确信他们现有的方法有效（他们在某些情况下会这样做），因此不需要改变他们的方式。
- 过去使用“代码和修复”（CAF）方法有过糟糕的经历。因为他们不了解敏捷软件开发，所以他们经常将其与CAF等同起来，因此认为敏捷技术是一个坏主意。文章你是多么敏捷？描述了如何确定团队是否敏捷。
- 有一些非常好的观点，敏捷社区没有很好地解决这些问题，例如面向数据和企业问题，因此他们认为敏捷技术不足以满足他们的需求。
- 相信他们的情况是独一无二的，也许他们在财富50强公司（虽然其他49个组织也处于这种情况下）或政府机构工作，因此敏捷技术对他们不起作用。
- 关注症状，而不是IT组织内问题的根本原因，因此他们没有质疑他们的首选开发方法。
- 多年没有编码，也没有意识到开发人员目前使用的新技术和工具的含义。 Java / C＃开发与COBOL开发有很大不同。
- 听过他们所尊重的其他经验丰富的IT专业人士所提出的神话和误解，不幸的是，他们也在努力克服敏捷概念，并且可能会告诉他们他们想听到什么，结果感觉他们不需要继续研究敏捷性。
- 是狭隘的专家，通常具有数年甚至数十年的经验，因此难以理解更大的发展情况。
- 很可能害怕他们不适合敏捷开发（并且很可能不会，因为他们目前的技能组合）。我在2006年6月的Dobbs Journal博士专栏中提到了传统主义者如何成为敏捷团队的高效成员的问题。
新手IT专业人员也在努力学习敏捷技术，尽管他们面临着不同的挑战。他们可能：
- 感知敏捷性意味着他们没有模型，他们不必编写文档。
- 作为程序员，有非常狭隘的经验，如果有的话。
- 没有经验可以欣赏大局，或者至少欣赏它的细微差别。
- 专注于单一技术或编程语言。
组织内的管理人员在敏捷性方面有自己独特的问题。他们经常：
- 无法为您的团队提供足够的资源（或根本不理解他们是什么）。
- 过去曾经用新技术做过不好的经历，并且不愿意再试一次。
- 相信敏捷软件开发是另一种时尚，并将在几年后消失。
- 没有意识到敏捷开发团队需要组织的其他部分，包括企业架构师和数据管理/管理等IT团队，以及在与团队交互时以敏捷方式工作。
- 敏捷数据库技术
每个人都需要以开放的心态接近敏捷，理想情况下没有任何先入之见。他们需要审视大局，认识到他们有严重的问题，除非他们采取行动，否则不会消失。理想情况下，每个人都需要与经验丰富的敏捷开发人员合作并进行指导，以便学习这些新方法。虽然可以将您的项目团队甚至整个组织引导到敏捷软件开发中，但我们建议您寻求那些已经走在您面前的人的帮助。敏捷软件开发的教育和培训也很重要，尽管不如良好的指导那么重要。
经验丰富的开发人员和管理人员需要有机会尝试这些新方法，更重要的是要有时间来摆脱他们“坏”的非敏捷习惯。新手开发人员需要专注于教育/指导以及获得经验。新手开发人员可能比经验丰富的开发人员更容易学习敏捷技术，因为他们在此过程中丢弃的行李较少。
3.实际尝试一下
理论与实践之间存在显着差异。你可以阅读所有你想要的东西，但在你尝试某些东西之前，你真的不会理解它及其含义。在某些时候，你将不得不在一个真实的项目中尝试这些东西。
记住格言
“理论上，理论和实践都是一样的，
但在实践中，他们不是。“
4.阻止非敏捷员工
一个常见的策略是从一个试点项目开始，该项目在实践中尝试新技术，这样您就可以深入了解它们在组织中的运作方式。虽然这可以使个人团队保持敏捷，但挑战在于您的组织的其他成员仍在遵循现有的非敏捷方法。这意味着他们可能希望某些模型或可交付成果在特定时间以特定格式提供，或者他们可能需要状态报告或其他管理工件，或者他们可能要求您遵循其非敏捷程序。理想情况下，你应该谈判冒险进入这种官僚主义的泥潭，实际上你往往不能，因此你的试点项目面临失败的风险（正是许多官僚所希望的）。
解决此问题的一种方法是将团队中的一两个人分配为阻止者。在北美足球中，阻挡者的主要目标是防止其他球队解雇你的四分卫或者攻击你的接球手，其中任何一个都会导致你的比赛失败。在软件开发中，阻截者参加官僚会议并生成他们需要的工作产品，从而释放团队的其他成员，专注于实际构建系统的活动。阻截者有效地在您的团队周围实施“流程外观”，使组织的其他成员看到您的团队正在遵循他们现有的程序。这满足了官僚，但却阻止他们干涉正在做实际工作的人。虽然这听起来像是一个浪费的开销，但这是因为将阻挡者和官僚转移到产生某种价值的努力会更有效，其优点是它可以让团队的其他成员完成工作。阻挡者的角色通常由你的团队的项目经理或教练承担，尽管在过去我已经让这成为项目的循环角色，以分散处理纸张推动者的痛苦。
5.要现实
以下列表描述了将敏捷数据库技术引入组织时需要考虑的几个重要因素。
- 要有耐心，需要一代人。我相信敏捷软件开发的采用曲线，包括敏捷数据库技术，将与对象技术类似。对象技术在20世纪80年代后期首次被商业界考虑，在撰写本文时，许多组织（通常被称为技术采用曲线上的后期多数或落后者）（Moore 2002）仍在努力采用面向对象（OO）。这是我手表的十五年，我希望敏捷软件开发没有什么不同（这意味着它可能是在您的组织最终赶上之前的2020年）。
- 不要太狂热。使某人远离敏捷技术的最可靠方法是试图让他们相信敏捷是唯一的方法。记住敏捷数据的第六个哲学 - 认识到你应该努力在极端之间找到合适的最佳位置。这意味着你可能不会立刻变得像你想的那样灵活，但你很可能会变得比现在更敏捷。
- 不要盲目进入。阅读本书是迈向数据导向活动更加敏捷的第一步，但这只是第一步。在尝试采用本网站描述的技术和理念之前，请进行更多阅读，www.agilealliance.com和www.agilemodeling.com是您应该利用的重要资源。与在自己的项目中遵循敏捷技术的人交谈，以发现他们所经历的事情。参与敏捷数据社区，邮件列表页面列出了良好的在线资源，并分享您自己的经验。
- 不要低估政治。流程就是政治，当你像我在这个网站描述的那样彻底地改变流程时
- 许多人显然会对必要的变化提出质疑。
- 准备好在别处找工作。您的组织可能还没有为敏捷做好准备，更糟糕但可能不会持续一段时间。这意味着你做出了一个非常艰难的决定 - 你是否继续等待并希望你的组织内有机会，你是否试图创造这样的机会，或者你是否更新你的简历并开始在其他地方寻找工作。正如Ron Jeffries喜欢说“改变你的组织或改变你的组织。”这是你的生活，控制它。
原文：http://www.agiledata.org/essays/adopting.html
本文：
讨论：请加入知识星球或者小红圈【首席架构师圈】