1.3 以人为核心
阿利斯·泰尔科伯恩指出，人是软件开发过程中的第一非线性要素。根据多年从事民族志工作的经验，他观察到，人以及人与人的合作方式是IT解决方案成功交付的主要决定因素。这一哲理渗透在DAD中，也正是《敏捷宣言》第一条价值观所要反映的理念。DAD的团队成员应该自律、自组织且具有自我意识。DAD团队可以充分利用DAD过程框架所提供的指导原则，提高其工作效率，但它并没有为此规定强制性的实施程序。
不同的规程（discipline），如需求、分析、设计、测试和开发，之间需要有正式的工作产品（主要是文档）交接过程，传统的方法在传递知识时显得差强人意，易形成瓶颈，在实践中证明它会对时间和金钱造成巨大的浪费。浪费表现在创建临时文件所花的精力、评审文档的成本以及更新文档的代价。不可否认，有些文档是必需的，但并不像传统方法所主张的那么多。人与人之间在进行文档传递时，更有可能造成误解和滋生问题，这是精益软件开发所描述的7大浪费源之一。在创建文档时，我们很难完全记录下自己对描述对象的理解，不可避免地遗漏有些知识，因而它变为隐性知识而无法传递下去。而且我们很容易发现，经过多次传递，最终交付的文档与最初的意图可能已差之千里。在敏捷环境中，规程之间的界限应该拆除，文档交接工作应该减到最小，并以团队的工作利益为主，而不是个人的专业知识为主。
在DAD中，我们倡导跨职能团队策略，即跨职能的团队由跨职能的人员来组成。团队中没有层次结构，团队成员的技能是跨职能的，所以在实际工作中，并不是按他们的专业特长，而是按不同的规程或开发阶段来组织团队。这样，团队成员之间就可以增进理解，并且他们可以超越他们各自的专长。最终带来的结果是，资源得到了更有效的利用，对正式文档和文档交接的依赖程度得到了降低。
因此，敏捷方法淡化了特定角色的概念。例如，在Scrum中只有三个角色：ScrumMaster、产品负责人（Product Owner）和团队成员。非团队角色包括利益相关者和经理人员。而在DAD中设置的主要角色是利益相关者、团队领导、团队成员、产品负责人（Architect Owner）和架构负责人。第4章会对这些角色进行详细描述。
注意，在DAD过程框架中，测试人员和业务分析师并不是主要角色。相反，普通团队成员都应该有能力做各种角色可以做的事情。具有测试专长的团队成员可以志愿地帮助需求分析，甚至轮流做ScrumMaster（团队领导）。这并不意味着每个人都需要在各个方面成为专家，但它确实意味着，团队作为整体，应该涵盖各种技能，并应该根据需要学习任何缺失的技能。另外，DAD还定义了几个次级角色，在可伸缩环境中，这些角色经常发挥着重要的作用，第4章将对此进行描述。
遍常情况下，团队成员应该是通用型专家（generalizing specialist），因为他们可能是一个或多个规程方面的专家，但他们对其他规程也应该有一些基本的了解。更重要的是，通用型专家愿意和别人密切合作，分享他们的经验和技能，向一起工作的同事学习新技能。由通用型专家组成的团队，很少需要传递文档，相反，他们更愿意改善个人合作，因为成员各自有各自的背景技能和各种IT领域的优势，他们有能力专注于要完成的事情，而不在意各自的强项。
然而，仍然需要专家，专家仍有自己的发挥空间。例如，团队可能会需要设置和配置数据库服务器。虽然自己也可以琢磨出来怎么做，但如果有一位很有经验的人在旁边和自己一起来做这个工作，那该工作就会变得更容易、更快速、代价更小。这个人可能就是数据库管理专家。在规模较大的环境下，构建版本可能会变得非常复杂，以至于需要有专人甚至多人专门来承担这个工作。或者，可能需要请一个或多个业务分析师专家，到团队来帮助分析团队所遇到的问题空间。
DAD团队和团队成员应该做到以下几方面。
自律，他们只承诺自己可以完成的工作，然后尽可能有效地执行工作。
自组织，他们自己估计和规划工作，然后在迭代周期内进行合作。
自觉，他们努力找出哪些地方做得好，哪些地方做得不好，然后不断学习，并做出相应的调整。
虽然人是IT解决方案项目成功交付的主要决定因素，但在大多数情况下，简单地组织一个团队，即便是所谓的好团队，若让大家放任手边的问题，显然也不是一种有效的做法。如果这样，团队的运行就会面临风险，例如，投入大量的时间去开发自己的流程和实践，或者热衷于某些流程或实践，而实际上，成熟的敏捷团队早已发现这些流程或实践不再有效或者不再高效，或者团队从来不调整他们自己的流程和实践，努力使之变得更为有效。我们大家可以更聪明地思考：虽然人是成功的主要决定因素，但它并不是唯一的决定因素。DAD过程框架提供了清晰的、行之有效的建议，敏捷团队可以利用它们，从而避免或至少减少前面描述的那些风险。
