Crystal方法被认为是“轻量级方法论”。“水晶”一词的使用来自于宝石，在软件术语中代表对原则和价值观“潜在核心”的看法。Alistair Cockburn在20世纪90年代中期开发了Crystal家族。这些方法来自Cockburn多年的研究和对团队的采访。Cockburn发现这些团队没有遵循“正式”的方法，但他们仍然交付了成功的项目。Cockburn发现过程虽然很重要，但应该作为次要重点来考虑。Crystal Methods背后的理念是，参与软件开发的团队通常具有不同的技能和天赋，因此Process元素不是主要因素。由于团队可以以不同的方式执行类似的任务，Crystal系列方法对此非常宽容，这使Crystal系列成为最容易应用的敏捷方法之一。
发展历史Alistair Cockburn被认为是敏捷最初的普及者之一，他在1991年为IBM开发了Crystal方法。他决定不专注于为参与任何项目的团队制定具体的逐步发展战略，而是制定团队合作和沟通的指导方针。因此，Cockburn的Crystal方法的特点都是基于团队本身：
被授权的团队（意味着项目应具有灵活性，并根据相关人员的需求和首选工作模式进行调整）自适应（意味着该方法不使用固定工具，但可以进行更改以满足团队的特定需求）超轻量（意味着这种方法不需要太多文件或报告）七个特性一、频繁交付项目无论大小、敏捷与否，最重要的一个点是每隔几个月要向真正的用户交付一次运行的、经过测试的代码。这么做会有以下几个好处：
投资者会得到关于团队进展的关键反馈。用户有机会修正初始需求，并将他们的发现反馈到开发的产品中。开发人员保持专注，打破犹豫不决的僵局。团队可以调试他们的开发和部署过程，并通过取得的成就鼓舞士气。二、反思和改进如果团队能够共同列出哪些做法是有效的、哪些是无效的、哪些可能更有效，并在下一次迭代中做出这些改变，那么就可以将一个项目的命运从灾难性的失败逆转为成功。并且团队每隔几周或几个月花一个小时来进行就可以了。从混乱的日常开发工作中抽出时间思考什么可以帮助团队更好地工作，这一事情本身已经很有效了。
三、渗透式沟通渗透式沟通是指信息流入团队成员可以听到的背景环境中，使他们像接收广播一样获得相关信息。这通常是通过让他们坐在同一个房间来完成的。然后，当一个人提出问题时，房间里的其他人可以收听或不收听，参与讨论或继续他们自己的工作。如下述场景：
我们有四个人在做结对编程。老板走进来问了我的搭档一个问题。我开始回答但给了一个模块错误的名称。此时另两个伙伴在一起结对编程，其中一人纠正了我的错误，另一人却从来没有注意到自己的搭档说话了，也没有注意到有人问题。当渗透沟通到位时，问题和答案自然流畅，团队之间的干扰出奇地小。渗透式的沟通和频繁的交付促进了快速而丰富的反馈，使项目可以非常轻松地运行。
四、心理安全指当一个人被困扰时不用担心报复地勇于表达。这可能包括告诉经理时间表不现实、告诉同事的设计需要改进，甚至让同事知道需要更频繁地洗澡。心理安全感很重要，这是团队可以发现并修复自己的弱点的源头。否则团队就不会说话，而被隐藏的问题将继续损害团队。
五、聚焦首先是知道该做什么，然后有时间和安心地做。了解该做什么来自于关于目标方向和优先事项的沟通，通常来自于项目发起人。时间和心灵的平静来自于一个环境，在这个环境中，人们不会被剥夺任务，去做其他不相容的事情。
六、专家用户易触达对专家用户的持续沟通帮助团队：1.针对频繁交付的产品增量可以部署和测试2.获得产品增量质量方面的快速反馈3.获得产品设计决策的快速反馈4.来自用户的最新需求
七、具备自动化测试、配置管理和频繁集成的技术环境自动化测试。团队确实使用手动测试成功交付，因此这不能被视为关键的成功因素。但是，团队日常会修改代码的各个部分，自动化测试可以快速检查在这一过程中是否无意中破坏了某些内容。
配置管理。配置管理系统允许人们异步签入他们的工作、备份更改、包装特定的配置以供发布，并在以后出现问题时回滚到该配置。它允许开发人员单独或一起开发代码，被团队视为最关键的非编译器工具。
频繁集成。许多团队每天对系统进行多次集成。集成的频率越高，检测错误的速度就越快、累积的额外错误就越少、必须搜索的错误代码区域就越小。最好的团队将这三者结合到带有测试的持续集成中，会在几分钟内发现集成级别的错误。
Crystal实践实践策略360度探索在新项目开始时，通常是在设立活动期间，团队需要确定项目既有意义，又可以使用预期的技术交付。他们环顾四周，对项目进行采样
商业价值用户需求领域模型技术计划项目计划团队组成过程方法如果要使用一些新的特殊技术，Crystal Clear项目的整个360°探索需要几天到一两周的时间。基于过程中的发现来决定项目继续下去是否有意义。
初期就胜利胜利是一种力量，它将团队联系在一起，并有助于增强团队成员的自信心。社会学家Karl Weick发现，小胜利有助于团队发展力量和信心。当团队急需时可以在项目的相对早期安排。这就是早期胜利战略。在软件项目中，要寻找的早期胜利是第一段明显运行、经过测试的代码。这通常是行走的骨架（一个很小的可用系统功能，通常只不过是向系统数据库中添加一个项目，然后查看它的能力）。尽管这听起来可能不多，但团队成员从这场小小的胜利中学习了彼此的工作风格，用户对系统有了早期的了解，投资人也能看到团队的交付成果。
行走的骨架行走的骨架是一个系统小型端到端功能的更微小实现。它不需要使用最终架构，但应该将主架构的组件连接在一起并行演进。需要注意的是：
行走的骨架并不完整或健壮（请原谅，它只是能行走），而且它是缺少应用程序功能的血肉。基础设施将随着时间推移逐步完成，并最终将添加全部功能。行走的骨架不同于探针。探针是“证明看似技术成功的最小实现”。其通常需要几个小时到几天的时间才能完成，之后就会被丢弃，因为它是用非生产编码习惯构建的。行走的骨架是一种永久代码。它是用生产编码规范并通过回归测试，旨在随着系统的发展而发展。一旦系统启动并运行，它将在项目的剩余时间内保持运行。演进式架构系统架构需要从“行走的骨架”演变而来，也需要随着时间的推移处理技术和业务需求的变化。用停止开发的方式来执行架构变更的做法收效甚微。团队要保持系统运行的前提下分阶段演进架构。
信息雷达信息雷达是张贴在人们工作或走过时可以看到的显示器。展示团队关心的信息，而不必问任何人问题。这意味着