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过程框架提供了清晰的、行之有效的建议,敏捷团队可以利用它们,从而避免或至少减少前面描述的那些风险。