简介
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发现,小胜利有助于团队发展力量和信心。当团队急需时可以在项目的相对早期安排。这就是早期胜利战略。
在软件项目中,要寻找的早期胜利是第一段明显运行、经过测试的代码。这通常是行走的骨架(一个很小的可用系统功能,通常只不过是向系统数据库中添加一个项目,然后查看它的能力)。尽管这听起来可能不多,但团队成员从这场小小的胜利中学习了彼此的工作风格,用户对系统有了早期的了解,投资人也能看到团队的交付成果。
行走的骨架
行走的骨架是一个系统小型端到端功能的更微小实现。它不需要使用最终架构,但应该将主架构的组件连接在一起并行演进。
需要注意的是:
- 行走的骨架并不完整或健壮(请原谅,它只是能行走),而且它是缺少应用程序功能的血肉。基础设施将随着时间推移逐步完成,并最终将添加全部功能。
- 行走的骨架不同于探针。探针是“证明看似技术成功的最小实现”。其通常需要几个小时到几天的时间才能完成,之后就会被丢弃,因为它是用非生产编码习惯构建的。
- 行走的骨架是一种永久代码。它是用生产编码规范并通过回归测试,旨在随着系统的发展而发展。一旦系统启动并运行,它将在项目的剩余时间内保持运行。
演进式架构
系统架构需要从“行走的骨架”演变而来,也需要随着时间的推移处理技术和业务需求的变化。用停止开发的方式来执行架构变更的做法收效甚微。团队要保持系统运行的前提下分阶段演进架构。
信息雷达
信息雷达是张贴在人们工作或走过时可以看到的显示器。展示团队关心的信息,而不必问任何人问题。这意味着更多的信息交通、更少的中断。
一个好的信息雷达具备一下特征:
- 足够大以确保容易被随意的、感兴趣的观察者看到;
- 展示的内容一眼就能理解;
- 周期性地变化,因此值得去看一下
- 很容易更新内容
实践技术
- 方法塑造,收集关于先前经验的信息,并使用它来制定初始约定。
- 反思工作坊,一种针对反思改进的特殊工作坊形式。
- 闪电规划,我有时也将其称为项目规划“即兴会议”,以强调其协作性。质,这是一种快速协作的项目规划技术。
- 德尔菲估算,一种对整个项目进行初步估算的方法。
- 每日站会,这是一种每天在团队中快速高效地传递信息的方式。
- 核心交互设计。以用途为中心的快速设计。
- 流程微缩,一种帮助新成员快速掌握流程的技术。
- 并行编程(Side-by-Side Programming),其是对编程的不那么激烈的替代方案,
- 燃尽图,一种规划和报告进度的有效方法,特别适合在信息雷达上使用。
Crystal框架
Crystal Clear使用不同长度的嵌套循环过程:开发阶段、迭代、交付和整个项目。人们在任何时候做什么取决于他们在每个周期中所处的位置。
项目周期
Crystal Clear的项目周期有三个部分:
- 项目组建活动。打造核心团队,进行360度探索,形成项目管理方法论,指定初步计划。
- 一系列(两个或更多个)交付周期。
- 竣工仪式:项目总结
交付周期
交付包含了以下三部分内容
- 重新校准发布计划。
- 一系列迭代活动。每个迭代都会产生集成的、经过测试的代码交付给真实用户。
- 交付周期完成仪式,包括对正在创建的产品和当前项目约定的回顾。
迭代周期
迭代的长度和形式因不同的团队而异,通常是1周~2个月之间。迭代有三个部分组成:
- 迭代规划活动
- 每日和集成周期活动
- 迭代完成仪式(回顾研讨会和庆祝活动)
在迭代周期内,团队将处理包括尝试用户界面设计、扩展系统的基础设施、新增功能、向用户演示系统、新增测试并添加到其工作环境的自动化功能等工作内容。
集成周期
集成周期可以从半小时到几天不等,具体取决于团队的实践。有些团队有独立的机器可以持续运行构建和测试脚本, 还有的团队每隔几天就集成设计。虽然一般来说越短越好,但Crystal Clear并没有规定使用时间的长短。
周/日周期
在各种周期中,只有日周期和周周期是日历节奏。许多小组活动每周进行一次。其中可能包括周一上午的全体员工或部门会议、团队领导报告会议、定期自带午餐的技术讨论(“棕色袋子”)研讨会,或周五下午的葡萄酒奶酪派对或啤酒会(取决于您的文化!)。
日周期也有自己的节奏。它可能从每天的站会开始,然后由完成一个或多组设计工作组成,并在某个时候安排午休时间。
开发片段
Ward Cunningham创造了“片段”一词来描述敏捷开发中程序员工作的基本单元。在一个事件中,一个人拿起一些小的设计任务,对其进行编程以完成(最好是通过单元测试),并将其检查到配置管理系统中。这可能需要15分钟到几天的时间,具体取决于程序员和项目约定。将一集的长度控制在一天以内通常效果最好。
角色以及产出
Crystal Clear有八个命名角色,其中执行发起人、大使用户、首席设计师、设计-程序员这四个必须是不同的人。其他四个可以作为额外角色分配给项目组人员。其对应的角色和产出如下:
执行发起人:
- 具有优先级的使命清单
团队:
- 团队结构和工作约定
- 回顾研讨会的结果
协调员:
- 项目地图、发布计划、项目状态、风险清单
- 迭代计划和状态
- 检查时间表
商务专家和大使用户。:
- 角色-目标列表
- 用例和需求文件以及用户角色模型
首席设计师:
- 架构描述
设计师-程序员(包括首席设计师):
- 产品草图
- 公共领域模型设计草图和注释
- 源代码
- 代码迁移
- 测试
- 系统集成
测试人员:
- 实时的错误报告
撰写人:
- 用户帮助文档
Crystal家族
Cockburn为适应不同规模的团队延伸了Crystal的整个家族,不同的Crystal方法帮助这些团队用不同的策略来解决问题。
Crystal系列方法使用不同的颜色来表示要使用的方法的“重量”。如果一个项目规模较小,则可以使用Crystal Clear、Crystal Orange或Crystal Yellow等方法,或者如果该项目是一个可能危及人类生命的关键任务项目,则将使用Crystal Diamond或Crystal Sapphire等方法。这个家族中不同方法以颜色区分,例如:
- Crystal Clear。该团队仅由1-6名成员组成,适用于短期项目,其中成员在一个工作空间中工作。
- Crystal Yellow。它有一个7-20名成员的小团队,其中的反馈来自真实用户。开始引入自动化测试,可以更快地解决错误,并减少过多文档的使用。
- Crystal Orange。它的团队规模为21-40人,团队根据他们的职能进行划分。这里的项目通常持续1-2年,每3到4个月需要发布一次。
- Crystal Orange Web。它的团队规模也有21-40名成员,这些项目拥有可供集体使用的不断发展的代码库。它也类似于Crystal Orange,但在这里不是处理单个项目,而是处理一系列需要编程的工作。
- Crystal Red。软件开发由40-80名成员组成,可以根据需求组建和划分团队。
- Crystal Maroon它涉及到大型项目,团队规模为80-200人。团队组建的方法根据软件需求不同而不同。
- Crystal Diamond & Crystal Sapphire。这种变体可以用于对人类生命有潜在风险的大型项目。
舒适度(C),可自由支配资金(D),基本资金(E)和项目生命周期(L)是垂直因素。水平因素是“团队规模”。 例如,对于规模为40人的项目,在提交发布日期之前,开发人员将考虑以下因素:
- 适合工作多少小时(C);
- 可用于该项目的资金(D);
- 完成该项目需要多少资金(E);
- 如果这些要求中的任何一个不满足,则可以增加 /减少项目的团队规模和寿命(L);
最后,选择最可行的方法。
或根据团队规模,开发人员可以根据提供的资金(E),可用的资金(D)和资源的舒适度(C)估算项目完成情况(L)。
例如:
Crystal Orange
面向D40区域项目:
最多40人,同一栋楼办公,可自由支配资金损失(可拓展至E50)
角色:
发起人、业务专家、使用专家、技术促进者、业务分析师/设计师、项目经理、架构师、首席设计师/程序员、设计师/程序员,设计导师、重用点、作家、测试人员、UI设计师。
团队划分:
系统规划,项目监控,架构,技术,功能,基础设施,外部测试。
Crystal Clear
面向D6类型的项目:
规模3-6人,近距离或在同一房间,可自由支配资金。(可扩展到:E8区域项目)
角色:
必须具备:发起人、资深设计师、设计师/程序员、用户(兼职)
组合角色:协调员、业务专家、需求采集者
团队:设计师/程序员的单一团队
座位:单人间或相邻办公室
引用
Crystal clear a human-powered methodology for small team,2004, Alistair Cockburn
Crystal | Do You Know the Seven Characteristics of the Crystal Method? – Weekly Sharing – ZenTao
Crystal methods in Agile Development/Framework – GeeksforGeeks