团队组建与管理的成功案例_组建成功的纪律敏捷交付团队的五个技巧

自从2001年发布以来，敏捷宣言就定义了敏捷方法的核心精神。最近，IBM以“有纪律的敏捷交付”（DAD）的名义提出了一系列实践，以帮助大型软件开发团队获得与在过去的十年中，较小的团队拥有敏捷技术。 并不是说现有的，通用的敏捷方法是不受约束的； 实际上，大多数敏捷方法比传统或临时方法需要更多的纪律和严格性。 但是，对于复杂的企业环境中大型敏捷项目的实际情况，并不总是有指导。

DAD提供了一个混合框架，该框架结合了来自各种现有的和成熟的敏捷方法（例如Scrum，XP，Crystal，FDD和DSDM）的最佳指导。 尽管每种方法都很有价值，但是每种方法在各种方面都是不完整的，因为从业人员通常将来自不同方法的技术拼凑在一起，以获得相对内聚的东西。 IBM敏捷/精益IT首席方法专家Scott Ambler致力于将多种方法的最佳指南整合在一起，从而形成了DAD框架。 我很幸运能够与Scott合作，并能够将这些实践用于我自己的项目。

DAD还通过企业指导来补充常见的敏捷方法。 例如，DAD向团队展示了如何将主流概念（例如积压订单）提高到一个新的水平，并使它们更适合于大型企业环境。 它可以帮助您与直接开发团队之外的企业机构合作，例如企业架构师或数据库管理员。 一些开发人员错误地认为，采用敏捷方法后，您不再需要处理这些个性和纪律。 不是这种情况。 大多数敏捷团队必须将目光投向团队之外，尤其是在与组织中的其他项目和其他机构合作时。

根据我在各种敏捷项目中作为开发人员和团队负责人的个人经验，我提供以下建议，以帮助您仔细思考以敏捷开发原则为指导的项目的大团队管理问题。 这些只是组织具有20个或更多开发人员的敏捷项目团队时要考虑的一些注意事项，但它们可以使您步入正轨。

提示1：欢迎推广专家

传统方法有一种趋势，即假设一个非常专业的团队可以为客户带来更好的产品。 实际上，我们发现事实恰恰相反。 在许多情况下，人们对项目的专业程度越高，他们越会尝试产生完美的文档，完美的代码，完美的模型。 此外，对于依赖于没有专业技能的专家的团队来说，效率可能会降低。 例如，如果团队中只有一个人了解数据库，那么不仅会延误团队的工作，还会延误将工作解决方案交付利益相关者的整个过程。

DAD促进与“一般专家”组成的团队的建立； 也就是说，既具有专业知识，又具有软件开发生命周期中多个学科的常识的人员。 例如，分析师可能是需求方面的专家，但也具有测试方面的一般知识，如果团队在测试方面落伍了，那么分析师可以卷起袖子并提供帮助。

通过我现在正在从事的项目，开发人员将时间花在传统的编写代码方面，以帮助构建部署和持续集成脚本。 结果，他们都获得了有关基础结构和配置管理的常识。 另一个例子：测试人员传统上专注于用户界面以及从黑匣子角度来看软件的工作方式。 但是，越来越多的敏捷世界中的测试人员需要变得更加技术化，并考虑开发人员的工作方式。 如果他们能够将测试以代码形式编写，而不仅仅是从用户界面测试功能，那么它们对团队来说更有用。

提示2：更注重协作技能，而不是脑力

有时，才华横溢的团队无法产生预期的结果。 一群聪明的人不一定能组成一个好的团队。 只有当这些人为实现共同目标而共同努力时，才会取得成功。 我见过非常聪明的人，他们不想一起工作。 他们喜欢独立工作。 这样的人在您的组织中可能会扮演一个角色，但在敏捷开发和交付团队中可能没有。

此外，现实情况是我们不能为每个项目团队配备超级巨星。 我们需要学习如何与中等，可预测的能力的人一起提高生产力和效率，而不仅仅是超级程序员。 因此，当我为团队配备人员时，我所寻找的是能够一起工作的人们，他们能够同时发挥能力和信心。 他们在门口检查自己的自我，因为他们意识到，实际上，他们不可能一无所知，并且彼此之间有一些需要学习的东西。

提示3：为手头的项目创建合适的团队

DAD描述了三种不同的团队级别：经典的小型团队，中型团队和大型团队。 当然，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团队时，请牢记以下提示：拥抱一般专家，专注于协作技能，创建适合您项目规模的团队，了解敏捷团队原则和团队组织，但要灵活并且对自组织团队要谨慎。

---

翻译自: https://www.ibm.com/developerworks/library/ag-forming-dad-teams/index.html