在项目角色以及他们的工作产品
主办方仅需负责一件事情：
1.具有取舍优先的任务综述
作为一个集体的团队需要对两个方面负责：
1.团队的构造、工作惯例
2.反思研讨会的结果
在团队的协助下开展工作的协调者则负责以下几个方面：
1.项目规划图
2.发布计划
3.项目状况图表
4.风险列表
5.迭代计划和状况
6.评审进度表
商务专家以及专家用户则要共同负责制定出：
1.角色目标列表
2.用例以及需求档案
3.用户角色模型
4.总设计师要负责编写出
5.架构描述
而设计师兼编程人员（包括总设计师）则对以下内容负责：
1.屏幕草图
2.公共领域模型
3.设计草图及注解
4.源编码
5.迁移代码
6.测试
7.成套系统
测试员（任何在当时扮演此角色的人）负责交出：
1.当前的漏洞报告
而书写人员则负责制定出：
1.用户帮助文本
在水晶项目管理体系中总共存在着8种角色，其中4种角色只能由某些特定的人来担当。而其余的4种角色则处于从属地位，可由项目中大部分的成员充当。前4种角色分别是：
1.执行发起人： 就是那个为项目筹集资金并且保证资金到位的人。执行发起人在具备长远眼光的同时还应当有利用随后的发布及发展或维护系统的团队来平衡短期优先任务的能力。执行发起人向外界告知项目的进展情况并且为团队做出重要的业务水平决定，当存在平衡交付价值与投入资金方面的问题时，执行发起人有权做出决定何时、是否继续进行或停止项目的开发；若决定继续进行开发，那么应当如何调整剩余的系统功能以重新获得商业价值。
2.专家用户： 他应该是非常熟悉操作程序以及使用中的系统（如果已经形成一个系统）的专家。他知道哪些是经常或者不经常使用的操作方式，需要哪些捷径，哪些信息应当同步出现在屏幕上。
3.总设计师： 这是一名在技术方面起领导作用的成员，他拥有丰富的软件开发经验，能够负责重要的系统设计，能够辨别项目团队何时在正确的轨道上，何时偏离了正确的轨道。
4.设计师兼编程员： 将“设计师”和“编程员”这两个词融合为一体，目的是强调扮演这一角色的成员既肩负着“设计”的责任又肩负着“编程”的责任。水晶项目管理体系从来就不会允许这种情况的出现。编程过程中本当包含设计的环节，因此无论是设计师还是编程员都不应该是两个独立的角色，因此应该是“设计师兼编程员”
其它角色
协调者也许是团队某些成员可以兼当的角色：一个只有4~8人的团队不太可能会设置一名专门的项目经理。因此可能会有一名成员同时管理几个项目，并且在每个项目中扮演着协调者的角色。
主办方：具有取舍优先的任务综述
任务综述是一段简短的说明，内容一般从一个自然段到一页纸不等。陈述的内容主要是说明团队应该建立什么，在更大环境中的目的是什么，以及按照先后顺序排列的优先选项，包括那些最重要的选项及可以省略的选项。
团队：团队结构和工作惯例
团队的结构就是将人们分配到各个角色中去。团队工作的惯例就是一系列规则、工作习惯以及团队成员同意采用的惯例的集合团队要形成以下惯例：
1.将人们分配给各种角色
2.编程惯例比如命名、格式化和评论
3.编程所有权惯例
4.设计以及编码评审惯例，无论是针对编码评审还是针对结对编程，或是什么都不针对
5.迭代长度以及报告状况形式，用户评审频率
6.配置管理惯例
团队：反思研讨会成果
反思研讨会成果是团队在反思研讨会后所得结论的信息传播器。他通常是一个活动挂图，包括“我们需要保留的内容”、“需要尝试的内容”以及“尚未解决的问题”。反思研讨会成果图应当放置在显眼的位置，这样团队就能了解当前迭代主旨是哪些公约及惯例。
协调者：项目规划图、发布计划、项目状况、迭代计划和状况、评审进度表、风险列表
主办方、开发团队以及用户必须能对即将开发及发布的系统功能进行相关活动的计划和安排。团队必须清楚开发系统功能以及交付日期的顺序，而用户应当清楚他们必须分配出一些时间对功能进行评价或试用
协调者：项目规划图
项目规划图是表明主要工作以及从属工作的相关性图表。它的目的是展示问题结构以及攻击次序。它没有标明时间日期，部分原因是人们通常只有在了解团队成员以及他们的能力之后才拟订规划图，但教通常的情况是给予团队更多的考虑采用何种成员结构及时间策略的时间
协调者：发布计划
发布计划是一系列标明关于交付以及迭代结束重大的日期。给项目规划图注上日期后，就可获得一份发布计划。发布计划也可以直接转化为项目状况报告。
协调者：项目状况
项目状况是一张根据发布计划显示项目状况的列表。它通常只包括一些显著的状况，状况信息也许包括：当前预计交付日期或原计划完成日期、预计完成日期及预计风险。在一个项目中，我们应要求在这一图表上比较原始和预定的项目造价。项目状况一般不超过半张纸；你可以把风险列表列在另一张纸上，这样你就可以在一张纸上制作一分完整的项目报告了。
协调者：风险列表
风险列表包括以下几个方面的信息：项目面临的最大风险、各个风险的重要性及发生的可能性大小、各种奉献可能造成的损失以及可能采取哪些预防措施或回应。我想对它们进行跟踪，看看近期风险是变大了还是减小了。
协调者：迭代计划→迭代状况
详细的迭代计划列举出在当前迭代正在开发的内容。每一项内容根据迭代周期长度的不同，需要一日至两周不等的开发时间进行开发。迭代计划说明工作项之间的相关性，比如它会独立对待每个工作项（如果它是一份通过闪电计划法制定出的计划），或者它只是用例中团队标识出的某些句子。
协调者：评审进度表
评审进度表是在迭代或者交付周期中一张显示专家用户或者其他用户计划何时加入团队对新开发系统进行计划及关注的进度表。
商务专家与用户专家：角色目标列表
角色目标列表是一张两栏的表格后或者是用例图。在两栏框中，左边的一栏记录做出服务承诺的成员、机构以及开发系统的计算机系统；而右边一栏记录相应的服务承诺，也就是角色根据系统要求而要实现的目标，以及他们想通过系统完成的任务。而用简短动词的目标也成为描述系统具体功能用例的名称。
商务专家：需求文档
需求文档是以下方面信息的集合：
1.要建立什么系统
2.谁将使用这个系统
3.他如何提供价值
4.影响设计的主要因素是什么
完整的需求文档包括以下几点内容：
1.任务综述
2.角色目标列表，附带陪有注解得用例，特别是关于性能需求方面
3.尤其是用例可能使用到的具体商业规则；参考商业规则、法律要件等其他来源
4.数据描述、格式以及确认规则
5.技术要求
6.I/O原型以及外部交流格式
7.商业俗语词汇表
商务专家和专家用户：用例
用例是关于描述外部角色如何利用系统获得某种价值的场景文本集合。他从外部（主要）角色对系统提出要求的成功场景开始。为了满足主要角色的需求，此场景描述了系统和其他各种角色之间的行为以及相互影响。此为它还描述了出现差错时，极有可能是当系统无法满足主要角色的要求时系统的反应。
专家用户:用户角色模型角色模型使用
角色模型是用于展示用户角色模型以及各个角色之间关系的二维平面图。他突出焦点角色，也就是必须使其获得最大满足的角色。用户角色是系统用户可能设置的高水平目标的称呼；相识的角色紧密结合在一起，不相似的角色则分开排放，关联线将角色或角色组团联系在一起。
角色模型用于：
1.对工作进行优先排序，此时角色、商业价值、焦点状况以及使用频率是影响特性开发的优先级别的因素
2.当编写用例的——角色间的协作为用例提供额外的角色和相关性
3.帮助作出关于用户界面以及交互哦具体决定
4.当测试员假定目标以及用户特征进行测试的时候
设计师兼编程员：屏幕草图、系统架构、租源代码、公共领域模型、设计草图与注解
总是会有人提出需要哪些文件之类的问题。在水晶项目管理体系中，答案是：由主办方以及团队决定
设计师兼编程员：屏幕草图
屏幕草图是一种低成本的对屏幕效果进行展示的媒介。人们可以利用屏幕草图来探究用户可能回通过哪些方式与系统发生交互行为，并思考出实现目标的更好方法。
总设计师：系统架构
系统架构描述是说明系统的主要部分以及用户界面的文字和图画内容。人们对于架构的构成，它的建成时间以及对它进行记录的方式等问题，一直存在着很大的争议。系统架构描述是由总设计师在第一次迭代相当早的时期完成的。架构可能会不断发展，特别是当团队采用灵活框架程序以及增量重建策略是，架构更是会不断发展
设计师兼编程员：公共领域模型
公共领域模型是一幅图表，可是一个数据库模式也可以是一张类图。它展示系统使用的只要实体以及类。一些团队依然喜欢用文字直接描述他们的领域模型
设计师兼编程员：源代码和交付包
水晶管理项目不强求团队采用规定的语言、命名方式、格式以及惯例开发项目。这些由你的团队自己来决定
设计师兼编程员：设计注解
根据软件开发理论，设计注解能够起到以下两种中任一种作用，并且能在经济合作竞赛中得到不同的回报。
1.作为贪婪行为体系的一部分，设计注解能够提醒人们交付系统的近期主要目标
2.可在进行投资行为时使用设计注解，以达到为下次竞赛作好准备的二级目标。
设计师兼编程员：测试
测试指的是可对系统某一方面进行测试的可执行码。非执行码测试包括人们根据描述如何对系统进行测试的书面文件对系统进行测试。
测试员：漏洞报告
漏洞报告是一份对漏洞进行登记，并说明造成错误的原因的记录。
书写人员：帮助文本文件、用户手册以及培训手册
团队不仅需要决定谁来编写这些内容，而且还要决定每次迭代和交付我们需要书写的帮助文本文件、用户手册以及培训手册的数量。纸类的用户手册现在正逐渐被在线帮助文档所取代。
