成功组建规范敏捷交付团队的 5 大技巧

简介

敏捷宣言（Agile Manifesto）自 2001 年发布以来就定义了敏捷方法的核心精髓。最近，IBM 以 “规范敏捷交付” 之名提出了一组最佳实践，帮助较大型软件开发团队取得与较小型团队在过去 10 年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的；事实上，大部分敏捷方法都需要比传统或临时的方法更加规范和严格。但是，并不总是有处理复杂企业环境中的大型敏捷项目的指南。

DAD（规范敏捷交付- Disciplined Agile Delivery，是 IBM 提出的一组实践，旨在帮助较大型软件开发团队像较小型团队一样成功实现敏捷开发） 提供了一个混合框架，将来自各种现有的成熟敏捷方法（比如 Scrum、XP、Crystal、FDD 和 DSDM）的最佳指南结合在一起。尽管这些方法中的每一种都有价值，但每种方法在各个方面都是不完整的，因为从业者通常会将来自不同方法的技术堆叠起来，获得某种相对集中的产物。来自 IBM 的敏捷/精益 IT 首席方法学者 Scott Ambler 收集了来自多种方法的最佳指南，并得到了 DAD 框架。我非常幸运能够与 Scott 合作，并能够在我自己的项目中使用这些实践。

DAD 还为常见的敏捷方法补充了企业指南。例如，DAD 会向团队展示如何将 “积压” 等主流概念带到下一个层次，让它们更适合更大规模的企业环境。它可帮助您与直接开发团队以外的企业权威合作，比如企业架构师或数据库管理员。一些开发人员错误地认为，采用敏捷方法后，您就不再需要处理这些个性特征和准则。事实不是这样的。大部分敏捷团队都必须放眼于团队外部，尤其是在参与其他项目和与组织中的其他权威人员合作时。

基于我个人作为大量敏捷项目的开发人员和团队领导的经验，我提出了以下建议，帮助您思考与敏捷开发原则指导下的项目相关的大型团队管理问题。这些只是在组建拥有 20 或更多位开发人员的敏捷项目团队时要考虑的部分因素，但它们可帮助您朝正确的方向发展。

技巧 1：欢迎通才专家

传统方法倾向于假设一个拥有非常专业人员的团队会为客户带来更出色的产品。事实上，我们发现事实正好相反。在许多情况下，参与项目的人员越专业，他们会越想尝试生成完美的文档、完美的代码和完美的模型。此外，如果团队依靠只拥有自己专长技能的专家，则效率就会降低。例如，如果团队中只有一个人理解数据库，那么不仅该团队的工作会延误，而且将有效的解决方案交到利益相关者手上的整个过程也会延长。

DAD 促进了拥有 “通才专家” 的团队的形成，通才专家也就是具有一项专长，但还对软件开发生命周期中的多个领域拥有基本知识的人。例如，一位分析师可能是需求方面的专家，但还对测试具有基本知识，如果团队测试进度落后了，该分析师可以提供帮助。

在我现在参与的项目中，开发人员除了传统的编码专长外，还花了大量时间来帮助编写部署和持续集成脚本。结果，他们都获得了有关基础架构和配置管理的基本知识。另一个示例：测试人员在传统上主要负责从黑盒角度测试用户界面和软件工作原理。但敏捷领域中的测试人员日渐需要变得更加技术性，考虑开发人员所做的工作。如果他们能够将测试编写为代码，而不仅是从用户界面测试功能，他们会对团队更有用。

技巧 2：更多地专注于协作技能，而不是智囊团

聪明的人组建的团队常常无法得到预期的结果。一组聪明的人不一定就会组建成一个优秀的团队。只有在这些人朝一个共同目标协同工作时，才有可能成功。我看到过不想协同工作的非常聪明的人，他们更喜欢独立工作。您的组织中可能有适合这样一个人的职位，但在敏捷开发和交付团队中可能没有。

此外，还有一个事实是，我们无法在每个项目团队中都配备超级明星。我们需要学习如何在具有普通、可预测能力的人中变得富有成效，而不只是明星编程人员。所以，我在组建团队时寻找的是既能良好协作，又展现出竞争力和自信的人。他们谦恭有礼，因为他们认识到事实上他们无法知晓全部内容，他们需要彼此学习一些东西。

技巧 3：为手头的项目组建规模适中的团队

DAD 描述了 3 种不同的团队级别：经典的小型团队、中型团队和大型团队。当然，DAD 主要针对大中型团队而创建。对于可能有多个子项目同时处理共享组件的较大型团队，一定要考虑各队人马与其各自团队领导如何协同工作。一个问题是，经典敏捷理论建议组建小型、自给自足的团队，假设他们应该能够自行实现完整的解决方案。但在我们的队伍不断壮大时，我们需要从团队外引入其他具有专业技能的人。

例如，在我当前的项目中，我们将十几项技术集中起来实现一个非常大的系统。我们明确地应用了 “通才专家” 的原则，但事实上不是团队中的每个人都能够了解所有这 12 种不同的技术的每个细节。所以我们为团队补充了一些基础架构人员，比如 Linux 专家、两个数据库权威人员以及安全性和防火墙专家。

在像这样较大型项目中，当您过渡到生产环境时，您将必须与（举例而言）您的 DevOps 团队或企业现代化团队合作。换句话说，您的系统不会孤立地存在。我当前参与的项目将与一个现有的系统相集成。要移到生产环境的所有要素都会受到严格的变更控制流程的紧密控制，所以我们会定期与团队外部的这些人互动，以让这些要素正常工作。

DAD 还包含在启动项目时执行某种初始规划的指南，这可能对于让不同团队协同工作很有用。对于较重的项目，您需要在要解决的商业问题和要得到的解决方案方面获得初步愿景。这个愿景可能包含业务案例的总体概述、提议的技术架构、风险摘要以及其他的摘要信息，让利益相关者相信该项目真正有用。

技巧 4：理解敏捷领导原则和团队组织，灵活处理手头的项目

小型团队的敏捷方法（比如 Scrum）解决了这样一种事实，在软件开发中，领导阶层的指挥控制方式（经理创建详细的工作细分结构、向团队分配任务，并告诉他们每项任务要花多长时间完成的方式）存在问题。敏捷方法从业者认识到，实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务，他们执行自己的评估，他们自愿挑选任务，他们自行分担工作量。在本质上，他们就像一个高效运转、自行组建的团队，没有明确定义项目经理职位。相反，该团队指派某个人作为团队领导，帮助推进整个流程。
DAD 使用了产品所有者 的概念，这个概念直接来自于 Scrum；DAD 事实上完全没有更改这个角色。产品所有者负责确定工作范围、优先级并阐明他们需要完成的工作的需求。作为产品所有者，他们拥有解决方案的产品愿景。但是，参与 DAD 实践的人认识到，对于较大型、更复杂的项目，可能必须向团队增加领域专家来协助产品所有者。

DAD 还有另一个类似于产品所有者的角色，称为架构所有者。团队拥有天才开发人员固然很好，但同样重要的是，让某个人 “拥有” 交付解决方案的架构愿景和负责关键技术决策。架构所有者也可以与团队外部的重要权威人员协作，比如企业 DBA 或企业架构师，以确保开发团队所做的决策不会与企业整体的标准和指导原则相冲突。他或她是项目的技术专家，定期与这些利益相关者合作。

作为自己团队的领导，我大量依赖于架构所有者。我目前的情况是，在一个房间里拥有 25 个工作人员。这是一个比经典敏捷项目人数更多的团队，但这是将一个项目升级为 DAD 项目的不错示例。紧挨着我左侧的是架构所有者，所以我总是可以向他咨询问题，比如：
我们是否有合适的人在参与合适的任务？

我们是否减轻了技术风险？
哪些团队成员需要帮助？我们是否为他们安排一个搭档，以便他们在执行任务时可获得帮助？
企业中是否有现有的技术资产或模式可供我们使用？

作为团队领导，尤其是在像这样的大型团队中，我很难详细地了解每个开发人员是如何工作的。所以我选择架构所有者作为我的搭档，帮助提高团队效率。
从另一方面讲，架构所有者也很重要。架构是项目风险的一个巨大的潜在来源，因为存在超越项目边界的依赖关系，比如生产环境、业务需求、遗留数据、旧有系统等。架构所有者确定要在早期迭代中实现哪些工作项，以尽可能早地减轻这些风险。这种 DAD 实践称为 “风险价值生命周期”，它不同于其他仅依靠商业价值来确定工作优先级的敏捷方法。架构所有者帮助团队理解关键技术风险，以及必须捕获和满足哪些需求才能减轻这些风险，在项目后期，修复这些风险可能非常困难且成本极高。

技巧 5：提防自行组建的团队，尤其是如果团队缺乏经验

自行组建的团队是一个非常美妙的敏捷概念。团队成员最了解如何自定义他们的流程，以保持最高效率。他们可以协作，是因为已学会了如何协同工作。例如，Hal 知道他是否可向 Julie 发送电子邮件，或者他是否需要面对面地讨论以提高效率。在理想情况下，团队拥有他们履行构建所需软件任务所必备的技能。在实践中，自行组建的团队非常适合技术牢固、透彻理解软件开发最佳实践且对敏捷方法有一定了解的人。

对于较新的或更年轻的团队，可能不具备这些条件。他们可能不理解如何针对架构或需求建模解决方案。或者更基本来讲，他们可能不熟悉敏捷方法，不理解不同的实践。

因此，在自行组建团队时，您需要考虑技能和经验成分。技能和经验的缺乏可能导致混乱且散漫的团队环境。还有一种个性特征成分。一些团队成员不习惯于决定他们应该执行哪些任务或按何种顺序执行。一些人可能实际上更喜欢采用更加传统的方式。如果您是团队领导，您必须对这些态度和习惯产生警觉，理解某个人何时需要诱导或引导他们的日常活动。

此处传达的基本信息是，自行组建的团队可以运转，但团队领导让团队自行管理的程度取决于团队的成熟度和能力。优秀的团队领导不会简单地相信团队，全权委托权威专家来完成他们想要的任何事情。相反，优秀的团队领导应该了解团队的进展，密切关注以确保他们朝正确的方向发展。

最后的思考

主流的敏捷理论在向客户交付具有较高商业价值软件方面奠定了牢固的基础，但它可能有点理想化。它并不总是代表 Scott Ambler 和我每天在较大型项目中的经历。我们的目标不是推翻前人的成果，重新发明敏捷方法，因为如果正确实现敏捷方法，那么这些成果是很有用的。我们只是尝试填补所存在的一些空白。

毋庸置疑，对于 DAD，我们没有打算规范化。例如，尽管我们更喜欢在工作项列表中通过用户案例来表示需求，但如果您希望应用用例场景，完全没问题。DAD 是一个框架。您应该选择其中最适合您的敏捷项目需求的技术。

结束语

DAD 可帮助大型软件开发团队成功实现敏捷开发项目。DAD 将来自各种现有的成熟敏捷方法结合到一个框架中，为常见的敏捷方法补充了企业指南。因此，它可帮助具有超过 20 人团队的组织充分利用敏捷开发方法。当组建 DAD 团队时，请记住以下这些技巧：欢迎通才专家，专注于协作技能，为您的项目组建规模适中的团队，理解敏捷团队原则和团队组织，但保持灵活并提防自行组建的团队。

原文来自：http://www.ibm.com/developerworks/cn/rational/agile/forming-dad-teams/