• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

DA-Disciplined Agile 规范敏捷

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。DADDA的基础层级,向上一层为规范DevOps,第三层是规范敏捷IT(DAIT)。这些层分别讨论了如何在企业级环境中处理DevOps和IT流程。

规范敏捷3.x于2017年8月发布,引入了第四层,企业级规范敏捷(DAE),以在全流程范围解决组织的业务敏捷问题

2018年12月,规范敏捷4(现在被称为规范敏捷工具包)发布。它专注于对DAD的全面改进描述和一种基于团队的改进策略,称为有指导的持续改进(GCI)。

2019年8月,Discipined Agile被项目管理协会(PMI)收购。

规范敏捷(DA)的思维理念包含原则、承诺和指导方针三个方面:

  • 原则。DA基于精益和流概念为业务敏捷提供了理论基础。
  • 承诺。团队、利益相关者以及与团队互动的组织内其他人达成的协议。这些承诺定义了一系列规范化的行为,使团队能够有效以及高效地协作
  • 指导方针。DA中的指导方针有助于团队在所定义的工作方式内更有效地工作,并随着时间的推移改进工作方式

八个原则

  • 取悦客户。我们需要以超出客户需求以及期望的方式尽可能取悦他们。如果我们不这样做,那么其他人会这样取悦他们,抢走我们的客户。这既适用于外部客户,也适用于内部客户。
  • 做到最好我们应该一直努力做到最好,并不断变得更好。谁不想在一个了不起的组织的了不起的团队中和了不起的人一起工作呢?
  • 源于实际每个人、每个团队、每个组织都是独一无二的,并且随着时间的推移环境回不断演变。这意味着必须选择合适的工作方式(WoW)来反映所面临的实际情境,然后随着形势的发展而演进WoW。
  • 讲求实效敏捷本身不是目标,而是尽可能地高效,并从中改进。要做到这一点,关键要务实,在对所处环境最有意义的时候采取适用的敏捷、精益或者传统的策略。过去,我们把这一原则称为“实用主义”
  • 好的抉择。基于环境因素驱动、实用主义选择工作方式要根据所面临的情况选择最适合的技术。构建一系列选项明确这些选项之间的利弊,对于选择最适合环境的工作方式至关重要。
  • 优化流流的优化需要在团队的价值流中实施最好在组织层面进行优化,而不仅仅是在团队中局部优化工作方式在某些方面有时可能带来不便,但总的来说,团队将能够更有效地回应客户。
  • 围绕产品/服务进行组织。为了取悦客户,需要围绕生产他们所需产品和服务来组织。但组织实际上是围绕价值流进行组织的,因为价值流以产品和服务的形式为外部和内部客户创造价值。而之所以在这里选择描述为围绕产品/服务进行组织,而不是产品或价值流,因为这样看起来会直接
  • 企业意识。规范敏捷主义者超越团队的需求,将组织的长期需求考虑在内。通常会利用组织级指导手册,并且根据反馈制定组织路线图,应用组织现有资产,实施对组织最有利的事情。

七项承诺

规范敏捷®(DA)的承诺是与队友、利益相关者以及与互动的组织内其他人达成的协议。定义了一系列有规范的行为,使我们能够有效、专业地合作。这七个承诺分别是:

  1. 创造心理安全,拥抱差异化心理安全意味着能够展示和自己,而不必担心地位、职业或自我价值感所产生的负面后果,团队的环境应该允许团队成员在工作环境中自在地做自己。心理安全与差异性密不可分,承认每个人都是独一无二的,可以以不同的方式输出价值,并且对团队的成功至关重要,因为它能带来更大的创新。团队组成越多元化,产出的想法就越好,也能促进成员间互相学习以及协作。
  2. 加快价值交付在DA中价值一词来指代客户价值以及业务价值。敏捷主义者通常关注的是客户价值,即团队所提供产品/服务的最终客户的利益。这显然很重要,但在规范敏捷中,关注的是团队众多干系人其中也包括外部终端客户。业务价值解决了那些对我们的组织有益,只是间接地对客户有价值的事情的计划和安排问题。例如,投资于企业架构、可重复使用的基础设施以及在整个组织中共享创新,有可能长期提高一致性、质量、可靠性并降低成本。
  3. 主动协作。与仅仅关注个人与团队工作相比,规范敏捷主义者努力为整体增加价值。这意味着需要更积极主动地与团队内以及团队外部的人协作。等待别人的帮助以及等待帮助的请求都是被动的表现要积极地在看到别人需要帮助时就主动伸出援手以及主动请求别人的协助。
  4. 透明所有工作和工作流。DA团队通常会在个人以及团队层面上展示所开展的工作。专注于在制品是至关重要的,这是团队正在进行的工作加上排队等待完成的任何工作。基于此,DA团队还要让工作流程透明可见,因此有明确的工作流准则,这样每个人都知道其他人是如何工作的。
  5. 提高可预测性。DA团队不遗余力地提高交付的可预测性,使他们能够更有效地协作和自管理,从而增加他们履行对利益相关者做出的任何承诺的机会。
  6. 将工作负载保持在交付容量范围内。不论从个人还是生产力的角度来看,超出能力进行工作都是有问题的。在个人层面上,超负荷工作往往会增加挫败感。从生产力的角度来看,过载会导致多任务处理,从而增加总体开销。
  7. 持续改进诸如苹果、亚马逊、eBay、脸书、谷歌等等这类真正成功的组织都离不开持续改进。为了保持竞争力,需要不断寻找流程、客户交付以及组织结构等方面改进的方法。

八个指导方针

规范敏捷的指导方针其理念是帮助更有效地落实新的工作方式以及随着时间的推移不断演进,如下:

  1. 验证式学习

变得优秀至极的唯一办法就是不断试验、反馈并且应用新的工作方式。如下图的持续改进指引,识别问题、定义潜在的改进方向、试验一种新的工作方式、评估它的运作情况,然后分享过程中的发现,循环往复,这个过程称为验证性学习。

在这个过程中可以就某个工作方式是否适用于某个环境进行试验,不论结果如何,我们都对其进行了实际的验证。所以有意愿以及能够落实试验是流程改进很重要的部分。

当然,验证性学习也不仅仅用于流程改进。也能用于产品或者服务的验证策略。首先构建一个很薄的产品切片,通过向干系人掩饰或者更好的是把这些内容发布给实际的终端用户来度量这些变更内容的真实效果。

  1. 运用设计思维。

取悦客户意味着所创造的运营价值流要以客户为中心进行设计,也就是要引入设计思维。设计思维要求与客户共情,在构建一个解决方案之前首先要理解用户的环境以及需求。也代表了构建产品和服务的基础视角向解决用户问题方面转变,甚至可以满足那些客户原本没有意识到的需求。

设计思维是一个探索方法,需要迭代式逐步探索问题域以及定义潜在的问题解决方案。其源于用户为中心的设计以及用途为中心的设计,两者都影响了敏捷模型这一规范敏捷工具组应用的实践之一。

  1. 基于价值流管理成员关系

敏捷宣言的第一句就是“个体和互动高于流程和工具。”但这句话不应被理解为仅限于敏捷团队内部,而是包括完成价值交付过程中的每一个敏捷团队内、外的成员。需要积极在各个职能的成员间促进协作关系以促进手头上整体交付。

对协作过程运作情况的关注和维护需要组织领导层需要重点支持,有一个领导力策略就称之为“自中而上再下”的管理。此策略中管理层关注价值流层面以识别需求,赋能团队满足这些需求并且和下游团队一起高效协作。

  1. 创造愉悦、高效协作环境。

套用敏捷宣言的话,优异的团队是围绕着有动力的个人建立的,他们得到了实现目标所需的环境和支持,而其中一部分是享受乐趣和快乐。可以通过创造一个让团队能够很好地合作的环境来让工作更加愉快。实现这一目标的一个关键策略是允许团队自组织,例如自主选择和演进自己的工作方式、组织结构和工作环境。团队必须以组织视角开展,这意味着团队需要与其他团队合作,所以必须遵循组织流程准则,并对团队所能做的事情进行限制。领导的工作是为团队提供一个良好的初始环境,然后支持并使团队在学习过程中不断进步。

  1. 通过改进系统来改变文化。

彼得·德鲁克(Peter Drucker)以“文化战略当早餐”而闻名。这是敏捷社区所铭记的,这一理念在敏捷宣言以人为本的本质中得到了明确的体现。虽然文化很重要,文化变革是任何组织敏捷转型的关键组成部分,但不幸的是,我们无法直接改变它。这是因为文化反映了现有的管理体系,所以要改变我们的文化,我们需要演进我们的整个系统

Daniella Meadows在《系统思维》(2015)一书中认为,系统既是其组成部分的总和,也是它们相互作用的方式。就一个组织而言,组成部分是其内部的团队/小组,以及他们使用的工具以及数字和物理资产。互动是相关人员的合作,由他们所承担的角色和责任以及他们的工作方式驱动(WoW)。为了改进一个系统,我们需要同步地演进它的组件以及这些组件之间的交互。

为了改进组织系统的组成部分,需要演进团队结构和用于工作的工具或者资产。规范敏捷®(DA™)思维理念的指导方针创建半自主、自组织的团队,解决了团队方面的问题。“提高质量”过程目标涵盖了提高基础设施质量,这通常是一项需要长期、大量投资的工作

总之,如果要做系统的变革,那么文化变革就会随之而来。为了确保文化变革是积极的,我们需要采取经过验证的学习方法来实施这些改进。

  1. 创建半自主的自组织团队。

组织是复杂的适应性系统(CAS),由团队以及团队所组成的网络组成。尽管主流敏捷要求创建“完整的团队”,拥有实现任务所需的技能和资源,但现实是没有一个团队是孤岛。自治团队是理想的,但我们上游和下游总是依赖于其他团队。当然,产品或服务之间也存在依赖关系,这需要负责它们的团队进行协作。Stephen Denning在其《网络法则》(the Age of the Agile,2018)、Mik Kersten在其关于从项目到产品团队转变的建议(project to product,2018)中、John Kotter在《Accelerate》(2014)中、Stanley McChrystal在其团队战略(2015)中以及其他许多人中都推荐了这种团队网络组织结构。

优秀的团队是跨职能且尽可能完整的拥有交付产品所需的技能、资源和授权。此外,团队是围绕其所属价值流提供的产品/服务进行组织的。当我们有专门针对业务利益相关者的团队时,预算编制会变得简单得多,因为我们只需要为与每种产品/服务相关的人员进行预算。

创建半自治团队是一个很好的开始,但在价值流的背景下进行自组织也是一件需要注意的事情。团队将是自组织的,但他们必须在他们所属的整体工作流程的背景下这样做。记住优化流和企业意识的原则,因为团队必须努力做对整个组织正确的事情,而不仅仅是对他们方便的事情。当其他团队也以这种方式工作时,我们都会因此变得更好。

  1. 应用度量改善成果。

度量需要考虑背景因素,希望改进什么?质量上市时间到了?员工士气?客户满意度?每个人、团队和组织都有自己的改进重点和工作方式,因此他们将有自己的一套措施,收集这些措施来深入了解自己的工作方式。随着时间的推移,形势和优先级发生了变化,这些措施也会随之演变。这意味着我们的量策略必须灵活且符合目的,而且不同团队的量策略也会有所不同。治理团队过程目标提供了几种策略,包括目标问题度量(GQM)和目标与关键结果(OKR),以推动背景驱动的度量。

团队应使用度量标准来深入了解其工作方式,并向以可视化的方式向领导层提供管理信息。如果做得好,量标准将带来更好的决策,进而带来更好的结果。如果做得不对,我们的量策略将增加团队面临的官僚主义,并将向试图管理团队提供不准确的信息。在决定量团队的方法时,需要考虑以下几种启发式方法:

  • 从结果开始。
  • 衡量与交付价值直接相关的内容。
  • 没有通用的方法,团队需要符合目的的度量标准。
  • 每个指标都有优缺点。
  • 使用指标来激励,而不是进行评比
  • 量入为出。
  • 团队使用指标进行自我组织。
  • 在团队层面量结果。
  • 每个团队都需要一组独特的指标。
  • 度量以改进——需要所遭受的,这样才能看到收获。
  • 具有跨团队的通用度量类别,而不是通用度量指标
  • 信任但要核实。
  • 不要以设法达到指标为目的
  • 尽可能实现自动化。
  • 倾向于趋势而非标量。
  • 首选领先指标而非落后指标。
  • 与其推,不如拉。
  1. 利用和强化组织资产。

组织有许多资产,诸如信息系统、信息源、工具、模板、程序、学习经验等。团队可以采用以及改进这些资产来提高效率,使它们对团队以及其他选择使用这些资产的团队更好。之所以重要,有几个原因:

  • 好的历史工作成果。团队可以利用组织内的各种资产。需要首先发展现有资产,使其满足当下的需求,这通常比从头开始构建更快、更便宜。
  • 周围还有很多好的工作要做。敏捷组织是一个半自治、自组织的团队网络。可以与这些团队合作并向他们学习,主动与他们合作,从而加快价值交付。在《敏捷时代》(2018)中,Stephen Denning强调了组织业务运营方面的需求,如供应商管理、财务和人员管理,以支持团队执行组织的价值流。如果想取悦客户,必须以企业意识的方式共同工作和学习。
  • 减少整体技术债务。不幸的现实是,正如我们前面讨论的那样,许多组织都在巨大的技术债务负担下挣扎。通过选择重复使用现有资产,并投资偿还我们在这样做时遇到的一些技术债务,我们将慢慢走出技术债务陷阱。
  • 更快地提供更大的价值。复用使我们能够专注于实现新功能,通过偿还技术债务,团队提高了构建基础设施的基本质量,使更快地提供新功能随着时间的推移变得可行
  • 支持其他人。在组织层面,我们可以通过创建卓越中心(CoE)和实践社区(CoP)来加强互相学习,以在整个组织中获取和共享所学知识。

流程刀片有时也被称之为流程领域、关键领域(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明确包含了敏捷建模架构负责人的角色是团队架构决策的负责人,也是整体解决方案设计的创建和演进的推动者。在小型团队中,担任团队领导的人通常也会担任架构负责人的角色。这种情况多出现在小团队中,规模化场景钟并不常见。尽架构负责人通常是团队中的高级开发人员,有时可能被称为技术架构师、软件架构师或解决方案架构师,但应该注意的是,这不是其他团队成员报告的分层位置。他或她和其他团队成员一样,也应该像其他团队成员那样认领并交付与任务相关的工作。架构负责人应该具有技术背景,并对业务领域有扎实的了解。

五个辅助角色:

  1. 专业人员。

尽管大多数敏捷团队成员是通识专,但有时,特别是大规模场景中需要对应的专业人员。例如,在大型团队或复杂领域中,一个或多个敏捷业务分析师可能会加入团队,帮助团队探索将要构建的需求。

  1. 领域专家(或主题专家)。产品负责人代表了广泛的利益相关者,而不仅仅是最终用户,因此期望他们成为每个领域的专家是不合理的,这在复杂领域尤其如此。产品负责人有时会引入领域专家与团队合作,例如,税务专家解释要求的细节,或项目出资人解释项目愿景。
  2. 技术专家。有时团队需要技术专家的帮助,例如敏捷数据库管理员来帮助设计和测试数据库用户体验专家来帮助设计用户界面,或者安全专家来提供编写安全系统的建议。根据需要,临时引入技术专家帮助团队解决难题,并将他们的技能传授给团队中的一个或多个开发人员。技术专家通常在负责企业级技术问题的其他团队中工作,或者只是从其他交付团队借调到团队。
  3. 独立测试人员。尽管大多数测试是由DAD团队中的人员自己完成的,但一些DAD团队得到了一个独立的测试团队在整个生命周期中并行验证交付质量的支持。这个独立的测试团队通常是在复杂领域内使用复杂技术或解决合规性问题的大规模情况下实现敏捷性所必需的。
  4. 集成负责人。对于已经组织成子团队的大型DAD团队,子团队通常负责一个或多个子系统或功能。团队规模越大,通常构建的系统就越大、越复杂。在这些情况下,整个团队可能需要一个或多个人员负责集成,负责各个子系统构建整个系统。经常与独立的测试团队(如果有的话)密切合作,在整个项目中定期执行系统集成测试通常只在规模化场景中复杂技术解决方案上需要。

 

权利和责任

要想变得敏捷需要组织内部的文化变革,所有文化都有或明确或隐晦的规则,以便于每个人了解组织对自己行为的期望,而明确这种期望的一种方法就是是协商敏捷团队中的人员所拥有的权利和责任。与宣讲既定的权利和责任相比,让团队聚在一起讨论这些潜在的权利和责任,并共同演进这些内容以满足组织的期望是非常有效

下述是一些可能会敏捷团队所包含的权利和责任:

敏捷团队成员的潜在权利

作为敏捷团队成员,我们有权:

  1. 受到尊重。这包括了倾听他人、不谈论别人倾听他人的意见不指名道姓等等一系列行为。你的每一位队友都会给团队带来价值,尊重他们你也将得到尊重。
  2. 在“安全的环境”中工作。这与尊重他人是相辅相成的。每个人都需要在一个能让自己感到不会被嘲笑以及讥讽的心理安全环境中表达自己,这也是为了让每个人能够自由、自主地协作,并且认可自己输入的价值。
  3. 根据商定的标准生产和验收合乎质量的成果提前制定工作标准。确保团队中的每个人都理解标准且认同这些标准,没有一个人可以符合一个不断变化的标准
  4. 拥有估算过程。由干活的人估算他们要干的活,才能得出比较合乎实际的估算结果,别异想天开地拍脑袋然后强加给别人。
  5. 确定团队将如何合作。团队有权决定在什么时候完成什么任务。团队比任何人都更了解团队的优势和劣势,因此他们最了解如何实现团队目标
  6. 及时提供善意的信息和决定。团队需要得到及时、正确的信息以高效协作,任何需求沟通以及对问题响应的延迟都将降低团队的生产力。
  7. 选择并演进团队工作方式团队需要基于实际情况选择合适的工作方式。DA帮助团队了解他们需要做出的与流程相关的决策、可供选择的潜在选项以及如何在这些选项中进行权衡

敏捷团队成员的潜在责任

敏捷团队成员有责任:

  1. 优化团队工作方式应该从长期的视角来对待优化这件事,比如让某个专业领域的同事负责专项任务看起来眼下是好的,因为可以快速完成,但从长远来看更好的做法是结对工作,这样虽然段时间交付效能可能受影响,但是整个团队在过程中可以相互学到新技能。
  2. 积极与内部和外部人员协作。开发人员可以躲在角落里破解代码的日子已经一去不复返了所有团队成员都需要协作。
  3. 共享所有信息,包括“正在进行的工作”。敏捷实施成功的关键之一是透明度。透明所有问题、进度、风险等与交付和协作相关的信息,这样团队能第一时间进行处理和解决,以便于更好地开展下一步工作,也就是说每个人都应该知道团队中的每个人一直在做什么
  4. 指导他人掌握你的技能和经验。提升团队能力的之一标是提高团队中每个人的技能,所以要准备好将你的技能传授给其他团队成员。过去人们的表现主要是根据他们执行专业任务的能力来评估的,而当下的评估重转移到一个人合作、分享和提高团队表现能力上。
  5. 拓展专业之外的知识和技能。提升团队能力的目标之一是提高包括每个人的技能,所以要求每个人都需要对学习新技能持开放态度,这样才能助团队完成被要求的每一项任务。
  6. 与他人一起尽早验证完成的工作。所有代码或者交付成果都应该由另一个开发人员审查,结对或者蜂涌式工作在过程中就保证了多人协同从而最大可能地减少了反馈环,并且所有代码或者交付成果都需要根据用户故事中的验收条件进行测试。确保质量是团队的责任。
  7. 参加每日协同会每日协同会议是当天最重要的会议,注意准时参加会议,不要耽误整个团队的时间
  8. 积极寻找提高团队效能的方法。回顾旨在修和改进团队的流程。准备好参加会议,讨论最近的工作进展情况出现的问题以及制定解决方案和行动计划
  9. 避免在未经团队同意的情况下接受当前迭代之外的工作。对于遵循敏捷生命周期的团队,在开始迭代时针对完成一组特定的工作进行承诺如果作为团队成员接受迭代之外的工作,就意味着没有为迭代目标执行任务,应该拒绝直接接受所有插入的需求。团队负责人产品负责人帮助成员阻挡,但提出将其写下来,并将其放入积压工作清单中进行考虑。

 

硬实力

硬实力让你在当下和未来的职业生涯中脱颖而出。规范敏捷®(DA™),将硬实力分为两类:基本技能和领导。基本技能是在工作中执行和学习所必要的能力。领导是指如何指导、激励、教练引导和管理他人。

以下的基本技能对规范敏捷主义者至关重要:

  1. 积极倾听。是指可以被讲话的人感知到的你对其表述内容的全神贯注倾听的状态。
  2. 沟通。沟通技巧使能够提供和接收不同类型的信息,通过面对面交谈、视频会议、电子邮件、文档等沟通策略来实施听、说、观察和共情等沟通行为
  3. 冲突管理。可以帮助管理和解决对团队的影响。
  4. 情商(EI)。情商是理解、使用和管理情绪的能力有四个方面:自我管理、自我意识、社会意识和关系管理。高情商能够使人缓解压力、有效沟通、与他人感同身受、克服挑战和管理冲突。
  5. 移情同理心是一种从情感上理解他人感受、从他人的角度看待事物并设身处地想象的能力。
  6. 谈判谈判是为了多方之间达成协议而进行的往复沟通,当无法独自实现目标时,就需要进行谈判。
  7. 解决问题。这是识别问题的过程:首先确定根因,然后识别、排序,并且从备选方案中选择解决方案,最后执行该解决方案。
  8. 团队合作团队合作是与一群人合作以实现共同目标的行为。

下方是常见的领导

  1. 教练包括识别团队成员的优势、劣势和动机,以帮助团队改进。
  2. 授权。领导者向成员提供全面的愿景,基于信任团队能实现预期的目标,从而赋予团队自管理的权力。
  3. 指导即便已经授权赋予员工独立完成工作的权力和责任仍然会根据需要提供指导和支持,以确保对方了解要完成的任务以及拥有必要的资源。
  4. 主持。在引导者和服务者之间无缝切换,引导行为包括事前准备、规划、邀请、介绍和提供资源。服务行为包括退居幕后、鼓励、给予空间和参与
  5. 服务。关注所领导的团队的成长和福利待遇
  6. 支持帮助团队有能力自主处理任务与人们一起工作,直到团队获得足够的权力和技能,并在需要时提供支持。
  7. 奖惩。团队在成功时会得到奖励,在失败时会受到斥责或惩罚。
  8. 变革致力推动个人和制度的变革创造了有价值的积极变革,将追随者培养成领导者视为最终目标。

虽然系统其它方面的生命周期对交付生命周期影响也有所提及,但是DAD重点关注的是交付一个完整的系统/产品生命周期从产品的最初想法到交付,再到运营和服务支持,通常有许多交付生命周期的迭代。下图是系统生命周期的顶层视图,指出了DAD项目团队关注的交付三个阶段(DAD产品团队通常不分阶段开展工作)以及DevOps阶段。

基于上述顶层视图,规范敏捷提供了以下六个版本的生命周期:

1.  敏捷生命周期。

这个生命周期主要基于Scrum和XP,一组时间框迭代(sprint)是构建阶段的核心。采用此版本生命周期的常见场景包括扩展Scrum以满足您的需求的情况,或者您希望运行“敏捷项目”的情况

 

敏捷生命周期的特点

  1. 基于迭代。像包括Scrum和XP许多敏捷方法一样,在此生命周期中解决方案是以固定时间盒的方式逐步构建的,而这些时间盒就称为迭代(Scrum称之为sprint)。
  2. 使用了非Scrum术语。尽管生命周期是基于Scrum的,对其中的术语进行了去品牌化,如应用迭代而不是sprint。术语并非关键,如果对Scrum术语更熟悉的话可以自行改动
  3. 体现了交付生命周期之外的输入生命周期中包含了在项目启动之前发生的事情,敏捷团队通常会从生产环境中获得新的需求(以需求变更和缺陷报告的形式),这些输入为整个交付生命周期提供了重要的上下文信息
  4. 这是一个工作项列表,而不是产品积压。工作项包括需求、缺陷和其他与交付功能无关的工作,如培训、休假和协助其他团队。所有这些工作都需要以某种方式进行优先级排序,而不仅仅是需求的实现。
  5. 包含明确的里程碑。在生命周期图的底部,有一个交付团队应当努力实现的轻量级里程碑,这是敏捷治理的重要方面

敏捷生命周期适用场景

  1. 工作内容以强化或新功能为主
  2. 工作内容可以在项目早期确定范围、优先级并进行评估
  3. 新敏捷团队成立时
  4. 团队熟悉Scrum和XP
  5. 一个项目正在执行时

 

2.  精益生命周期以看板为基础。

DAD的精益生命周期提倡精益原则,如最大限度地减少在制品数量极致的流、工作流的连续性(而不是固定的迭代)减少瓶颈,以及当团队有能力时从工作项池中以拉动的方式领取新工作

Scrum规定使用如日常协调会议(Scrum)、迭代(sprint)计划会议、在迭代(sprints)中按某种节奏进行的回顾活动等一系列“仪式”精益中没有规定这一类型的团队开销,而是建议在必要时进行。

然而是一种被认为是比较高阶的生命周期,因其需要一定程度的纪律和自我意识,所以在刚初入敏捷的团队中不常见。由此可见,虽然精益及其使用的看板系统的概念很容易学习,但精益流程和最大化系统吞吐量的原则很难掌握。

精益生命周期的特

  1. 支持持续的开发流。在这个生命周期中,决方案无论何时在任何被认为合理的情况下被可能频繁地部署。当有能力做到这一点时,工作就会被拉到团队中,而不是在迭代的正常心跳中。
  2. 按团队自己的节奏实践通过迭代/sprint,许多实践(详细规划、回顾、演示、详细建模等)都有效地按固定节奏迭代式地运行可见采用精益的方法决定做一件事的基础是是否合理,而不是按计划定日子地落实
  3. 有一个工作项池。并非所有工作项都是平等创建的。尽管可以采用Scrum建议的价值驱动的方法或者DA和RUP建议的风险价值驱动的方法等“标准”的方式对工作进行排序不过这种方式可能适合某些工作但另一些诸如因法规变更产生的工作,或者是生产环境的问题是日期驱动或者需要紧急处理的。因此基于这些现实因素,工作项池优先级堆栈更有意义。

精益生命周期适用场景

  1. 工作可以分解为大小大致相同的非常小工作项
  2. 工作很难提前预测。例如,专注于修复缺陷或处理支持问题的团队是该生命周期的很好的对象
  3. 团队倾向于尽量减少批处理(这有助于减少正在进行的工作)以及工作之前的计划的精益方法
  4. 团队正在进行一个项目

3.  基于敏捷的持续交付生命周期。

基于敏捷的持续交付生命周期通常采用一周或更短的迭代长度,是从敏捷生命周期发展而来。这与敏捷生命周期之间的关键区别在于,连续交付生命周期导致新功能在每次迭代结束时发布,而不是在一组迭代之后发布。团队需要围绕持续集成和持续部署以及其他规范DevOps战略制定一套成熟的实践。

基于敏捷的持续交付生命周期适用场景

  1. 解决方案可以频繁和增量地向利益相关者提供
  2. 工作在一个迭代中保持相对稳定
  3. 组织具有通畅的部署实践流程
  4. 在解决方案完全交付前需要持续为利益相关者交付价值的项目
  5. 团队拥有成熟的DevOps实践,包括持续集成、持续部署和自动化回归测试
  6. 团队长期稳定,随着时间的推移进行一系列发布

4.  基于精益的持续交付生命周期。

基于精益的持续交付生命周期支持以比其他生命周期更频繁的方式提供解决方案增量的目标是精益生命周期自然发展的结果。团队通常会从精益生命周期或基于敏捷的持续交付生命周期演变到这个生命周期。因为需要一套围绕持续集成和部署的成熟实践才能具有实用性。另外,还需要支持这种方法的技术基础设施和先进的规范DevOps实践。

基于精益的持续交付生命周期适用场景

  1. 解决方案可以频繁和增量地向利益相关者提供
  2. 经常涌现新的工作新的需求和缺陷
  3. 组织具有通畅的部署实践流程
  4. 在解决方案完全交付前需要持续为利益相关者交付价值的项目
  5. 团队拥有成熟的DevOps实践,包括持续集成、持续部署和自动化回归测试
  6. 团队长期稳定,随着时间的推移进行一系列发布

 

5.  基于精益创业战略探索型/精益创业生命周期。

生命周期基于Eric Ries倡导的精益创业原则,并通过Cynefin的复杂自适应系统策略进行了改进。目的是最大限度地减少对解决方案的前期投资,支持在项目早期经常进行市场测试和小型实验。随着解决方案的开发,交付团队有机会根据实际使用情况的反馈交付用户真正需要的东西。

此生命周期有六项活动:

  1. 设想。您的团队将探索一个创意,并确定一个或多个潜在的实施策略。可以简单地让几个人聚在一个房间里,在白板和纸上对业务愿景和技术方案进行建模头脑风暴。目标是为客户实际想要的东西做刚刚好足够的思考来确定可行、可测试的假设,并且需要制定计划衡量所生产的新功能的有效性。
  2. 轻量构建团队应该投入足够的精力来构建测试每个假设的潜在解决方案用精益的说法就是要构建最可行产品(MVP)。目标是在几天到几周内快速提供一些东西,这样你就可以检验假设。
  3. 部署每个就绪的MVP都部署到个环境中以检验人们是如何与之交互的可以针对部分客户,例如执行“阿尔法”或“贝塔”版本验证,目的是确定用户对解决方案的态度并获得反馈
  4. 观察并度量针对每个MVP测试目的是确定用户群的期望,所以需要为MVP提供可以记录关键事件的工和方法,例如记录页面访问时间哪个环节触发销售行为、某些业务功能什么时候被用到等等。目的是了解对终端用户有用可以留住客户,带来更大的销售额的功能。通过分析这些数据能够监控、观察和测量用户群对新功能的接受程度,并且有力支持下一步的决策。例如对于广受欢迎的功能可以选择继续使用现有策略并添加更多功能,甚至决定准备将此功能产品化。反之团队可能会选择转向另一个方向,甚至完全放弃。
  5. 撤销。调研阶段和初创企业中发现一些不切实际无法推进的想法是很普遍的现象。针对这点,敏捷主义者的观点是如果一个想法要失败,那么最好能很快了解到某个想法或者解决方案行不通。这样团队就可以及时止损,把精力投入到其他待验证的策略中。
  6. 产品化。经过几个迭代的轻量构建、部署、观测度量,团队已经识别出哪些在市场上可以获得成功的功能(针对组织内部用户开发的产品被最终用户认可)

探索生命周期适用场景:

  1. 该解决方案是要解决高度不确定性的情况,如新的未开发市场或新产品
  2. 利益相关者和交付团队对于正在开发的解决方案比较灵活
  3. 有一个或多个合理的假设/策略需要测试,并在对于测试结果有明确的通过/不通过标准
  4. 团队愿意基于发现尝试和演进创意

 

6.  适用于规模化敏捷团队的项目组合生命周期

DAD的项目组合生命周期如描述了如何组织一个规模化敏捷团队正是SAFe、LeSS和Nexus等规模化框架所解决的问题。

项目组合生命周期的特征

  1. 有一个明确的“项目初期”阶段。通常面对一个新团队需要提前投入一些时间来完成组建,考虑到在大规模团队场景下我们需要面临更多的风险,这个阶段的工作尤为重要。为了更好地完成这个阶段,最好的方法是明确我们需要做什么以及我们将如何做。
  2. 子团队/小队自行选择和演进其工作方式子团队有时被称为小队)应该被允许像其他团队一样选择自己的工作方式(包括选择他们自己的生命周期以及他们自己的实践同时,从组织基于项目的协同层面可能会选择对团队施加一些限制,例如遵循共同的指导规范和共同的战略,在项目内进行协调。
  3. 子团队可以是功能团队,也可以是组件团队。功能团队工作于功能的垂直切片,实现故事或处理从用户界面一直到数据库的变更请求。组件团队负责系统的特定部分,如安全功能、事务处理或日志记录。这两种类型的团队都有自己的位置,也有自己适应的情景,可以在实践中结合起来。
  4. 三个层面的协同子团队协同需要关注三个问题:要完成的工作、技术/架构问题和人员问题。分别由产品负责人、架构负责人和团队负责人执行。每个子团队的产品负责人们自组织解决子团队之间的工作/需求管理问题,确保每个团队在适当的时间进行适当的工作。类似地,架构负责人团队将自组织以随着时间的推移演进架构。团队负责人们将自组织来管理跨团队发生的人员问题。三个领导小组就这样持续随着时间的推移不断做小的调整以适应外部的变化。
  5. 系统集成和测试并行进行。有一个单独的团队来执行整体系统集成和跨团队的功能测试。理想情况下,这部分工的工作量应该很小,并且完全自动化。起初,由于缺乏自动化通常需要一个单独的团队,但目标应该是尽可能多地自动化这项工作,并将无法自动化的工作到子团队中执行。话虽如此,由于一些实际原因我们发现整个产品的可用性测试,以及类似的用户接受测试(UAT)仍然需一支单独的团队
  6. 子团队是尽可能完整的。持续集成(CI)和持续部署(CD)以及大部分测试工作就像应该在子团队中进行,如同大家认知中的敏捷团队中一样。
  7. 具备随时部署的能力通常刚接触敏捷开发的团队可能会从每季度发布一次(甚至不太频繁)开始,然后随着时间的推移改进发布节奏。新的团队大多需要一个过渡阶段,有些团队将最初的几个冲刺称为“强化冲刺”或“部署冲刺”。

项目组合生命周期适用场景

  1. 你需要一个庞大的团队。有些问题需要一个大团队,在某些情况下,你甚至可能决定将这个大团队组织成一个团队。当这种情况发生时,你需要一个这样的生命周期。
  2. 你具备大规模敏捷的技能。要想成功,你需要知道自己在做什么——如果你正在为小团队敏捷而挣扎,那么你还没有为大团队敏捷做好准备。

DAD团队将采用最适合其情况的生命周期,然后进行适当的调整。

引用

https://www.pmi.org/disciplined-agile

https://en.wikipedia.org/wiki/Disciplined_agile_delivery

https://dabrowser.pmi.org/#item:549

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280