菜单
菜单
DA基于敏捷软件开发倡导者所支持的许多实践构建，利用数百种敏捷、精益以及传统战略来指导团队或组织找到最佳工作方式（Way of Works）。主要参考文献是由Scott Ambler和Mark Lines撰写的《Choose Your WoW!》一书。
DA非常在意环境因素，它不是定义好的一系列“最佳实践”组合，而是教团队和组织如何选择并定义出一个在他们所面对的境地下最适合的工作方式。
DA工具包（DA Toolkit）帮助组织以环境因素敏感的方式简化流程，为业务敏捷奠定了坚实的基础。它通过展示各种业务职能（如财务、投资组合管理、解决方案交付（软件开发）、IT运营、企业架构师、供应商管理等）如何协同工作来实现这一点。DA还描述了这些业务职能应该解决的问题，提供了一系列选项以及如何在其中权衡的思路。
Scott Ambler和Mark Lines引领了DAD最初的开发以及其后续的发展。开发DAD是为了为敏捷软件开发提供一种整体性的方法：一方面试图填补Scrum（有意为之）忽略的流程空白，另一个是实现企业级规模化敏捷能力。Ambler表示，“许多敏捷方法论——包括Scrum、XP、AM、敏捷数据、看板等——都专注于从项目启动到交付解决方案所需的一个子集活动。在DAD出现之前，你需要拼凑自己的敏捷方法论来完成任务。”DAD是对于敏捷在规模化场景钟成功应用的常见模式的观察结果。
2015年，规范敏捷（DA）框架被开发出来，后来发展成为规范敏捷工具包，也被称为规范敏捷2.x。DAD是DA的基础层级，向上一层为规范DevOps，第三层是规范敏捷IT（DAIT）。这些层分别讨论了如何在企业级环境中处理DevOps和IT流程。
规范敏捷3.x于2017年8月发布，引入了第四层，企业级规范敏捷（DAE），以在全流程范围解决组织的业务敏捷问题。
2018年12月，规范敏捷4（现在被称为规范敏捷工具包）发布。它专注于对DAD的全面改进描述和一种基于团队的改进策略，称为有指导的持续改进（GCI）。
2019年8月，Discipined Agile被项目管理协会（PMI）收购。
规范敏捷（DA）的思维理念包含原则、承诺和指导方针三个方面：：
规范敏捷®（DA）的承诺是与队友、利益相关者以及参与互动的组织内其他人达成的协议。其定义了一系列有规范的行为，使我们能够有效、专业地合作。这七个承诺分别是：
规范敏捷的指导方针其理念是帮助更有效地落实新的工作方式以及随着时间的推移不断演进，如下：
变得优秀至极的唯一办法就是不断试验、反馈并且应用新的工作方式。如下图的持续改进指引，识别问题、定义潜在的改进方向、试验一种新的工作方式、评估它的运作情况，然后分享过程中的发现，循环往复，这个过程称为验证性学习。
在这个过程中可以就某个工作方式是否适用于某个环境进行试验，不论结果如何，我们都对其进行了实际的验证。所以有意愿以及能够落实试验是流程改进很重要的部分。
当然，验证性学习也不仅仅用于流程改进。也能用于产品或者服务的验证策略。首先构建一个很薄的产品切片，通过向干系人掩饰或者更好的是把这些内容发布给实际的终端用户来度量这些变更内容的真实效果。
取悦客户意味着所创造的运营价值流要以客户为中心进行设计，也就是要引入设计思维。设计思维要求与客户共情，在构建一个解决方案之前首先要理解用户的环境以及需求。也代表了构建产品和服务的基础视角向解决用户问题方面转变，甚至可以满足那些客户原本没有意识到的需求。
设计思维是一个探索方法，需要迭代式逐步探索问题域以及定义潜在的问题解决方案。其源于用户为中心的设计以及用途为中心的设计，两者都影响了敏捷模型这一规范敏捷工具组应用的实践之一。
敏捷宣言的第一句就是“个体和互动高于流程和工具。”但这句话不应被理解为仅限于敏捷团队内部，而是包括完成价值交付过程中的每一个敏捷团队内、外的成员。需要积极在各个职能的成员间促进协作关系以促进手头上整体交付。
对协作过程运作情况的关注和维护需要组织领导层需要重点支持，有一个领导力策略就称之为“自中而上再下”的管理。此策略中管理层关注价值流层面以识别需求，赋能团队满足这些需求并且和下游团队一起高效协作。
套用敏捷宣言的话，优异的团队是围绕着有驱动力的个人建立的，他们得到了实现目标所需的环境和支持，而其中一部分是享受乐趣和快乐。可以通过创造一个让团队能够很好地合作的环境来让工作更加愉快。实现这一目标的一个关键策略是允许团队自组织，例如自主选择和演进自己的工作方式、组织结构和工作环境。团队必须以组织视角开展，这意味着团队需要与其他团队合作，所以必须遵循组织流程和准则，并对团队所能做的事情进行限制。领导的工作是为团队提供一个良好的初始环境，然后支持并使团队在学习过程中不断进步。
彼得·德鲁克（Peter Drucker）以“文化把战略当早餐”而闻名。这是敏捷社区所铭记的，这一理念在敏捷宣言以人为本的本质中得到了明确的体现。虽然文化很重要，文化变革是任何组织敏捷转型的关键组成部分，但不幸的是，我们无法直接改变它。这是因为文化反映了现有的管理体系，所以要改变我们的文化，我们需要演进我们的整个系统。
Daniella Meadows在《系统思维》（2015）一书中认为，系统既是其组成部分的总和，也是它们相互作用的方式。就一个组织而言，组成部分是其内部的团队/小组，以及他们使用的工具以及数字和物理资产。互动是相关人员的合作，由他们所承担的角色和责任以及他们的工作方式驱动（WoW）。为了改进一个系统，我们需要同步地演进它的组件以及这些组件之间的交互。
为了改进组织系统的组成部分，就需要演进团队结构和用于工作的工具或者资产。规范敏捷®（DA™)思维理念的指导方针是创建半自主、自组织的团队，解决了团队方面的问题。“提高质量”过程目标涵盖了提高基础设施质量，这通常是一项需要长期、大量投资的工作。
总之，如果要做系统的变革，那么文化变革就会随之而来。为了确保文化变革是积极的，我们需要采取经过验证的学习方法来实施这些改进。
组织是复杂的适应性系统（CAS），由团队以及团队所组成的网络组成。尽管主流敏捷要求创建“完整的团队”，拥有实现任务所需的技能和资源，但现实是没有一个团队是孤岛。自治团队是理想的，但我们上游和下游总是依赖于其他团队。当然，产品或服务之间也存在依赖关系，这需要负责它们的团队进行协作。Stephen Denning在其《网络法则》（the Age of the Agile，2018）、Mik Kersten在其关于从项目到产品团队转变的建议（project to product，2018）中、John Kotter在《Accelerate》（2014）中、Stanley McChrystal在其团队战略（2015）中以及其他许多人中都推荐了这种团队网络组织结构。
优秀的团队是跨职能且尽可能完整的，拥有交付产品所需的技能、资源和授权。此外，团队是围绕其所属价值流提供的产品/服务进行组织的。当我们有专门针对业务利益相关者的团队时，预算编制会变得简单得多，因为我们只需要为与每种产品/服务相关的人员进行预算。
创建半自治团队是一个很好的开始，但在价值流的背景下进行自组织也是一件需要注意的事情。团队将是自组织的，但他们必须在他们所属的整体工作流程的背景下这样做。记住优化流和企业意识的原则，因为团队必须努力做对整个组织正确的事情，而不仅仅是对他们方便的事情。当其他团队也以这种方式工作时，我们都会因此变得更好。
度量需要考虑背景因素，希望改进什么？质量上市时间到了？员工士气？客户满意度？每个人、团队和组织都有自己的改进重点和工作方式，因此他们将有自己的一套措施，收集这些措施来深入了解自己的工作方式。随着时间的推移，形势和优先级发生了变化，这些措施也会随之演变。这意味着我们的度量策略必须灵活且符合目的，而且不同团队的度量策略也会有所不同。治理团队过程目标提供了几种策略，包括目标问题度量（GQM）和目标与关键结果（OKR），以推动背景驱动的度量。
团队应使用度量标准来深入了解其工作方式，并向以可视化的方式向领导层提供管理信息。如果做得好，度量标准将带来更好的决策，进而带来更好的结果。如果做得不对，我们的度量策略将增加团队面临的官僚主义，并将向试图管理团队提供不准确的信息。在决定度量团队的方法时，需要考虑以下几种启发式方法：
组织有许多资产，诸如信息系统、信息源、工具、模板、程序、学习经验等。团队可以采用以及改进这些资产来提高效率，使它们对团队以及其他选择使用这些资产的团队更好。之所以重要，有几个原因：
流程刀片有时也被称之为流程领域、关键领域（KPAs）或者业务职能模块。
一个流程刀片提供了一组总体的组织级工作方式，能够处理某个特定的组织能力领域上的事务，如企业级架构、产品管理、供应商管理等。这些是按照以下4个视角被组织起来的：
1、思维方式。 Process Blade 延伸了规范敏捷（DA）思维方式中与该 “刀片” 特定相关的原则、承诺和指导方针。举例来说，销售 Process Blade 探索了与成功售卖的特定相关概念。
2、人员。 Process Blade 指出了该 “刀片” 特有的专家角色，有时也阐述了可能的团队结构。举例来说，销售 Process Blade 包括的专家角色有销售经理、销售人员和销售支持工程师。
3、流。每个 Process Blade 描述了业务流程或业务流，这对于刚开始尝试敏捷工作方式的组织是一个通用的起点。
4、实践。DA 提供了流程选项（process options）的集合，例如实践和策略。团队选择合适的实践并以情境敏感的方式应用。这些流程选项在过程目标导图（process goal diagram）中有概述。
如上图展示了4个层面的流程刀片：
1、基石。这个层级为DA工具包的关键提供了包括原则、承诺、DA思维理念的指导方针、敏捷和精益等支持性基础观念。
2、规范DevOps层。DevOps提高了软件开发以及IT运营活动的效率。规范DevOps基于传统的DevOps以提供企业级方法为目标进行了延伸，集成了安全以及数据治理以为组织提供更有效的产出。对于某一些组织还同时有成百上千个系统投产，需要大量的服务支持以及发布管理活动来保持稳定。
3、价值流。
价值流层如上述将实际价值流可视化出来的工作流程图所示，将组织战略和在进行中的工作紧密相连，使管理层可以基于整体视角来制定组织的改进决策。仅仅是有创新力是不够的，还需要提升实际价值，在价值流层针对企业所面临的实际问题给出了具体的详细指导。
4、规范敏捷的企业。
规范敏捷的企业（DAE）通过敏捷的组织文化和结构能够感知并快速响应市场的变化，并且有助于在其面临的情况下进行变革。这样的组织需要主流业务中的学习心态以及底层的精益和敏捷流程来推动创新。DAE层侧重于支持组织价值流的其他企业活动。
为了有效实施DAD，要拥抱下述信条：
可消费的解决方案。采用规范敏捷方法一个方面使团队注意力从仅仅生产“潜在的可交付”软件成熟到提供潜在的可消费的解决方案。可消费意味着它是可用的、可取的和实用的。解决方案可能包括软件、（升级的）硬件、流程更改、组织结构更改和支持文档。
增量式价值交付。价值是以称为最小业务增量（MBI）的小部分增量交付给利益相关者的。MBI是可以提供的对利益相关者具有潜在价值的最小功能。
向左移动。验证和确认（V&V）技术包括但不限于在生命周期中尽早地执行测试实践、评审和协作工作策略。在敏捷社区中，称之为“左移”。V&V对有规范敏捷主义者来说非常重要，目标是尽早获得反馈，从而降低变更成本，增加生产利益相关者所需产品的机会。
向右移动。如建模和规划这样的思维策略，在生命周期中将向后推。我们的计划，包括时间表、范围和架构策略，应该随着过程中的发现以及情况的发展而变化。这些工作不应只是在阶段早期发生，而是贯穿始终。
用代码证明。认为一个架构是可行的和见到它确实可行之间有很大的区别。这一点在解决方案的第一次发布、重新设计或替换现有解决方案的核心部分过程中需要做出重要的架构决策时尤为重要。DAD生命周期包括经验证的架构里程碑，明确指出需要证明架构在生命周期的前期是可行的。
自动化、自动化、自动化。DAD的活动中有很大的自动化空间，如验收测试驱动开发（ATDD）和可持续测试驱动开发（STDD）、持续集成（CI）和持续部署（CD）技术等对交付团队的工作进行自动检查。
规范敏捷®交付（DAD）包括一组用于敏捷解决方案交付的有力角色，主要包括以下两方面：
主要角色。这些角色通常出现在DAD团队中，与团队的规模水平无关。
辅助角色。这些职位通常是临时补足的，以解决规模化问题。
无论团队的规模大小，通常都可以找到主要角色。有五个主要角色：
1. 利益相关者。
利益相关者是指受到解决方案结果实质性影响的人。在这方面，利益相关者显然不仅仅是最终用户，也可以是直接用户、间接用户、用户经理、高级经理、运营工作人员、为项目提供资金的“黄金所有者”、支持（服务台）工作人员、审计员、项目/投资组合经理、在与正在开发的系统集成或交互的其他系统上工作的开发人员，可能受到软件项目开发和/或部署影响的运维人员。DAD团队在整个项目中最好每天与利益相关者一起工作。
2. 团队成员。
团队成员的工作重点是为利益相关者制定实际的解决方案。团队成员将在整个项目中根据实际情况执行测试、分析、架构、设计、编程、规划、评估等活动。团队成员在各自的领域都是专家，不过随着时间的推移，他们会通过努力获得更多的技能。在交付的过程中，团队成员将自主识别、评估、认领、执行任务并跟踪其完成状态。
3. 团队负责人。
团队领导不直接参与而是促进或指导团队执行技术管理活动是自组织团队的一个显著表象。团队负责人是团队的服务式领导者，创造并维护能帮助团队成功的环境。其也是一名敏捷教练，帮助团队专注于交付工作项目，并实现他们对产品负责人的迭代目标和承诺。还是一个真正的领导者，促进团队沟通、授权以使团队自主优化流程、确保团队拥有所需的资源，并及时消除团队的任何障碍。当团队处于自组织状态时，有效的领导对你的成功至关重要。
4. 产品负责人。
在一个有数百或数千个需求的系统中，通常很难得到和需求相关问题的答案。产品负责人是团队中作为“客户的唯一声音”说话的个人，代表了利益相关者群体的需求和期望。因此，需要澄清有关解决方案的任何细节，并负责维护团队将实施以交付解决方案的工作项目的优先列表。虽然产品负责人可能无法回答所有问题，但有责任及时找到答案，以便团队能够专注于交付任务。让产品负责人与团队密切合作，在项目实施过程中回答有关工作项目的任何问题，大大减少了对需求、测试和设计文档的需求。当然，仍然需要可交付的文档，如操作手册、支持手册和用户指南等。每个DAD团队，或者在大型项目组织成团队的情况下的子团队，都有一个产品负责人。其第二个目标是向利益相关者群体展示敏捷团队的工作。这包括在解决方案演进过程中安排演示，并向关键利益相关者传达项目状态。
5. 架构负责人。
架构是项目风险的关键来源，需要有专人负责以确保团队减轻这种风险。因此，DAD明确包含了敏捷建模架构负责人的角色，是团队架构决策的负责人，也是整体解决方案设计的创建和演进的推动者。在小型团队中，担任团队领导的人通常也会担任架构负责人的角色。这种情况多出现在小团队中，规模化场景钟并不常见。尽管架构负责人通常是团队中的高级开发人员，有时可能被称为技术架构师、软件架构师或解决方案架构师，但应该注意的是，这不是其他团队成员报告的分层位置。他或她和其他团队成员一样，也应该像其他团队成员那样认领并交付与任务相关的工作。架构负责人应该具有技术背景，并对业务领域有扎实的了解。
尽管大多数敏捷团队成员是通识专家，但有时，特别是大规模场景中需要对应的专业人员。例如，在大型团队或复杂领域中，一个或多个敏捷业务分析师可能会加入团队，帮助团队探索将要构建的需求。
要想变得敏捷需要组织内部的文化变革，而所有文化都有或明确或隐晦的规则，以便于每个人了解组织对自己行为的期望，而明确这种期望的一种方法就是是协商敏捷团队中的人员所拥有的权利和责任。与宣讲既定的权利和责任相比，让团队聚在一起讨论这些潜在的权利和责任，并共同演进这些内容以满足组织的期望是非常有效的。
下述是一些可能会敏捷团队所包含的权利和责任：
作为敏捷团队成员，我们有权：
敏捷团队成员有责任：
硬实力让你在当下和未来的职业生涯中脱颖而出。规范敏捷®（DA™),将硬实力分为两类：基本技能和领导力。基本技能是在工作中执行和学习所必要的能力。领导力是指如何指导、激励、教练、引导和管理他人。
以下的基本技能对规范敏捷主义者至关重要：
下方是常见的领导力：
虽然系统其它方面的生命周期对交付生命周期影响也有所提及，但是DAD重点关注的是交付。一个完整的系统/产品生命周期从产品的最初想法到交付，再到运营和服务支持，通常有许多交付生命周期的迭代。下图是系统生命周期的顶层视图，指出了DAD项目团队关注的交付三个阶段（DAD产品团队通常不是分阶段开展工作）以及DevOps阶段。
基于上述顶层视图，规范敏捷提供了以下六个版本的生命周期：
这个生命周期主要基于Scrum和XP，一组时间框迭代（sprint）是构建阶段的核心。采用此版本生命周期的常见场景包括扩展Scrum以满足您的需求的情况，或者您希望运行“敏捷项目”的情况
DAD的精益生命周期提倡精益原则，如最大限度地减少在制品数量、极致的流、工作流的连续性（而不是固定的迭代）、减少瓶颈，以及当团队有能力时从工作项池中以拉动的方式领取新工作。
Scrum规定使用如日常协调会议（Scrum）、迭代（sprint）计划会议、在迭代（sprints）中按某种节奏进行的回顾活动等一系列“仪式”。但精益中没有规定这一类型的团队开销，而是建议在必要时进行。
然而这是一种被认为是比较高阶的生命周期，因其需要一定程度的纪律性和自我意识，所以在刚初入敏捷的团队中不常见。由此可见，虽然精益及其使用的看板系统的概念很容易学习，但精益流程和最大化系统吞吐量的原则却很难掌握。
基于敏捷的持续交付生命周期通常采用一周或更短的迭代长度，是从敏捷生命周期发展而来。这与敏捷生命周期之间的关键区别在于，连续交付生命周期导致新功能在每次迭代结束时发布，而不是在一组迭代之后发布。团队需要围绕持续集成和持续部署以及其他规范DevOps战略制定一套成熟的实践。
基于精益的持续交付生命周期支持以比其他生命周期更频繁的方式提供解决方案增量的目标，是精益生命周期自然发展的结果。团队通常会从精益生命周期或基于敏捷的持续交付生命周期演变到这个生命周期。因为需要一套围绕持续集成和部署的成熟实践才能具有实用性。另外，还需要支持这种方法的技术基础设施和先进的规范DevOps实践。
此生命周期基于Eric Ries倡导的精益创业原则，并通过Cynefin的复杂自适应系统策略进行了改进。目的是最大限度地减少对解决方案的前期投资，支持在项目早期经常进行市场测试和小型实验。随着解决方案的开发，交付团队有机会根据实际使用情况的反馈交付用户真正需要的东西。
DAD的项目组合生命周期如描述了如何组织一个规模化敏捷团队，这也正是SAFe、LeSS和Nexus等规模化框架所解决的问题。
DAD团队将采用最适合其情况的生命周期，然后进行适当的调整。
https://www.pmi.org/disciplined-agile
