ACP敏捷4.规模敏捷.多团队多迭代多产品.敏捷框架

908486905

已于 2023-01-31 18:14:11 修改

阅读量1.1k

点赞数

分类专栏：敏捷开发ACP 文章标签：敏捷开发

于 2022-06-19 02:24:24 首次发布

本文链接：https://blog.csdn.net/u010025781/article/details/125354034

版权

敏捷开发ACP 专栏收录该内容

22 篇文章 8 订阅

订阅专栏

规模敏捷就是要解决多并发敏捷开发的问题。

1. 多团队Scrum要素扩展

团队要素纵向扩展（单团队->多团队扩展）:

规模化敏捷团队人数上限150.

Robin Dunbar数；

英国人类学家罗宾.邓巴 (Robin Dunbar)提出，基于人类智力，所能拥有稳定的社交网络的人数，大约是150人。所以，一个规模化敏捷团队的人数上限，设定为150人。

1. 一个产品就一个PO，团队多时候，考虑分层TPO(团队PO)；1个总PO可以管理3-7个TPO.

2. SM的分层，SM不一定有总SM。

3. 团队；其他角色按需设置，如系统架构师；

工件要素纵向扩展（单团队->多团队扩展）：

需求的三个层次，在一个sprint中执行的是task, task不能跨团队。

一个产品有一个产品待办列表；拆分为多个团队Sprint待办列表；形成团队增量发布；合在一起形成一个产品的增量。

仪式Ceremonies

/事件Event -横线扩展

(单迭代->多迭代扩展)

原则保持PDCA闭环

一个Release时长建议不超过1个季度；

滚动规划，渐进明细；

承诺1个版本，规划2个版本。

路线图--Epic级别颗粒度；发布--功能级别颗粒度；迭代--用户故事颗粒度；

1. Release planning 发布计划会

2. SOS-Scrum of Scrums，团队间的同步会；

SOS vs 每日站会：SOS同步的级别是用户故事之间的；每日站会解决的是任务之间的。不需要每天开；一周2/3次即可；每个团队排代表参与；不限定15分钟，一般30-60分钟；可解决问题，也可以会后专题会。

3. System Review 系统评审会，不是发布的时候做一次，而是每个迭代版本都可以做一次，原则还是尽早发现问题原则；

4. 联合回顾会Inspect & Adapt--检查和调整

2. 规模化敏捷的框架

2.1 Scrum of Scrums -SOS框架，非商用化框架

一位APM（敏捷方案管理者Agile program manager）指的是一位管理多个小型项目（不管这些项目是不是实施Scrum，甚至不是开发类的项目）的ScrumMaster。在一个大型组织当中，一位APM可能各种软件开发和操作团队共同协作，甚至还会有负责市场推广的团队、分布式团队和离岸外包团队的参与。APM需要清晰地知道并不是所有团队都使用Scrum或者敏捷流程，因此要协调团队之间的期望值。APM同时也需要理解，并不是所有的敏捷团队都能够创造出同样的价值。

2.2 Nexus Framework--商用化框架

Nexus的定义是Scrum的外骨骼扩展。

单个团队Scrum工件集成在Nexus工件中（Nexus Sprint Backlog，Integrated Increment）。通过识别和解决依赖关系来管理集成的事件会驱动现有的Scrum事件，例如Nexus Sprint计划，Nexus Daily Scrum，Nexus Sprint回顾，并在适当情况下进行替换（Nexus Sprint评论）。集成责任不再是偶然性，而是正式嵌入了新角色Nexus集成团队。
https://blog.csdn.net/chktsang/article/details/103350440

Nexus Framework Poster | Scrum.org

Nexus是一个敏捷框架，用于规模敏捷项目，其中大约有三到九个Scrum开发团队，每个团队由五到九个成员组成，并且所有团队都使用一个共同的产品待办事项。

Nexus框架是对现有规模敏捷框架 (Scaled Agile Framework)的补充和覆盖。它是“Scrum的生态框架”。

原文链接：https://blog.csdn.net/chktsang/article/details/97006184

2.3 DAD(Disciplined Agile Delivery)--商用敏捷,IBM的首席敏捷教练ScottAmber提炼--PMI收购DA推广规范敏捷知识体系

规范敏捷工具箱是一整套工具。DA Toolkit的全貌，包括4层，1. 基础概念层、2. 企业DA层、3. 价值流层、4.示教DevOps层

PMI的规范敏捷交付（DAD，Disciplined Agile Delivery）,美国项目管理学会(PMI)收购Disciplined Agile (DA)。DA工具包是全球唯一全面的敏捷知识体系(BOK)，通过提供简单实用的指导，帮助个人、团队和企业在特定环境中选择他们的“工作方式”。

DA的主要原则包括：以客户为中心；务实而非纯粹主义；提供一系列敏捷和精益选择方案；运用基于特定环境的实践做法；以及优化整个企业的流程。运用DA工具包有助于组织定制任何方法或框架（如传统、Scrum或SAFe框架），推动实现区别于竞争对手的结果。

DAD--

基于IBM的IPD流程构建的敏捷方法

Mainstream agile approaches that are indeed suitable for small projects require significant tailoring for larger, complex enterprise projects. In Disciplined Agile Delivery, Scott W. Ambler and Mark Lines introduce IBM's breakthrough Disciplined Agile Delivery (DAD) process framework, which describes how to do this tailoring.

1. Inception概念阶段

2. Construction建设阶段

3. Transaction 移交阶段

规范敏捷交付（DAD）的内容非常全面，体现集大成者，又对得起PMI和IBM的强强联合。

指导企业级敏捷的规范敏捷交付（DAD）｜讲师分享

2.4 Less -Large Scale Scrum -

LeSS是单团队Scrum的放大版本，它保留了单团队Scrum的许多实践和思想。在LeSS中，您会发现：

一个产品待办事项列表（因为它是针对一个产品，而不是团队），
一个针对所有团队的完成定义，
在每个Sprint结束时增加一个潜在的可交付产品增量，
一个（总体）产品负责人，
许多完整的，跨职能的团队（无专业团队），
一个Sprint：在LeSS中，所有团队都处于一个共同的Sprint中，以提供一个共同的PSPI。

LeSS提供了两种不同的大规模Scrum框架。LeSS的大多数扩展要素都集中于将所有团队的注意力转移到整个产品上，而不是“我的一部分”。全局和“端到端”的关注可能是扩展中要解决的主要问题。这两个框架（基本上是Scrum扩展的单团队）是：

LeSS：最多八个团队（每个八个人）。
LeSS Huge：一种产品最多可容纳数千人。

大型Scrum（LeSS）是Scrum应用于许多团队共同开发一种产品。类似于一队Scrum。对于大型团体，LeSS试图在定义的具体元素和经验过程控制之间达到最佳平衡。就像一站式Scrum一样，LeSS具有（1）轻巧，（2）易于理解和（3）难以掌握的能力，这是由于其本质上的复杂性。

https://www.visual-paradigm.com/scrum/scaling-agile-frameworks-comparison/

2.5 SAFe -Scaled Agile Framework-面向业务的分层敏捷框架

www.scaledagile.com

SAFe全景视图中提供了5层结构：团队层、项目群层、价值流层、投资组合层、基础层，覆盖整个运营价值生命周期，多产品多团队规模化敏捷实践框架。

2.6 DSDM -Dynamic Systems Development Method动态系统开发方法--2/8原则

动态系统开发方法(DSDM),也称业务中心框架开发方法,它倡导以业务为核心,快速而有效地进行系统开发。DSDM描述了在快速开发以业务为中心的环境中包含的各个方面—一项目管理、预估、原型建立、时光盒法、配置管理、测试、质量保证、角色和职责、项目组结构、工具环境、风险管理、可维护性、重用,以及供货商和购买者之间的关系。

DSDM的基本观点是,任何事情都不可能一次性地圆满完成,应该用20%的时间完成80%的有用功能,以适合商业目的为准。
实施的思路是,在时间进度和可用资源预先固定的情况下,力争最大化地满足业务需求(传统方法一般是需求固定,时间和资源可变)交付所需要的系统。对于交付的系统,必须达到足够的稳定程度以在实际环境中运行;对于业务方面的某些紧急需求,也要求能够在短时间内得到满足,然后在以后冲刺阶段中对功能进行进一步完善。
核心理念：DSDM开发的时间是固定的，功能的划定和资源的配置得配合着实际开发效果进行规划。也就是如果两周为一个周期迭代，那么这个规定就得定死，如果是人员不够，影响了开发时间，就增加人员；如果是功能太多影响了开发时间，就得砍掉部分功能，保留到下一版；而不是将计划时间一拖再拖，不断延期。下不定决心砍需求，最终就变成了几个月，或者半年开发一版的传统开发。

DSDM 重点是交付的业务解决方案，而不是只是团队活动。在它被创建之前会通过流程确保项目的可行性和业务逻辑。DSDM重在利用原型设计，确保有关各方清楚地了解系统的所有方面。

2.6.1 背景知识

1994年，英国国内来自各个工业领域不同规模企业里的信息系统工作人员，以及来自IT行业中的一-些大公司的顾问和项目经理聚集在一起，形成了一个非赢利性的联盟。该联盟专注于理解应用程序开发过程中的实践方法，并尝试建立- -种独立于任何工具的、公开的、公认的方法。DSDM联盟提供了一个过程，这个过程能够在可控的项目环境中，在满足紧迫时间的约束下，建立和维护系统。DSDM联盟创立之初有17名会员。现在联盟已经有上千名会员，在全球范围内有多个社团:英国、北美、比荷卢经济联盟、丹麦、法国和瑞典。社团式的发展，是DSDM与其他- -些敏捷型方法的不同，它有专门的组织支持，有手册，培训课程，认证程序等。在英国，由于在各种规模的软件组织中的成功，DSDM已经成为应用的最为广泛的快速软件开发方法。

DSDM框架能够同时实现敏捷和传统开发过程。

在传统开发方法中，功能是固定的，时间和人力资源是可变的，而在DSDM中，时间是固定的，功能和资源是可变的。

2.6.2 DSDM过程

DSDM开发过程被形象地称作“两张比萨和一块奶酪”,如图下图所示。

DSDM周期有以下7个阶段：
1)、项目准备阶段。2)、可行性研究阶段。3)、业务研究阶段。 4)、功能建模阶段(冲刺式) 5)、系统设计编程阶段(冲刺式)。
6)、实施阶段 7)、项目后期。

项目准备阶段确保启动、建立正确的项目。可行性研究阶段和业务研究阶段是顺序进行的,它们为后面的冲刺、增量式的开发制定了基本规则。也就是说,在这两个阶段的工作充分完成后,才能进入后面的冲刺阶段,而后续冲刺阶段具体的冲刺方式、冲刺周期如何确定、整合,则需要视项目具体情况来定。比如:有些项目需要首先完成功能建模的全部冲刺,其次进入设计和编码阶段进行冲刺,最后进入实施阶段,这种方式是顺序的,是各阶段内部独立完成冲刺;有些项目将功能建模、设计和编码这两个阶段的每一次相关的活动作为一次冲刺,通过不断地冲刺,完成项目开发,最后进入项目实施;有些项目将功能建模、设计和编码、实施这一个过程作为一次冲刺,通过不断地冲刺,不断地呈现给用户满足他们需求的软件。因此,DSDM框架是极其灵活的,在应用DSDM之前,必须定义和评估使用DSDM的方式,在项目过程中,也可以随需而变,进行动态调整,以便能够更好地支持商业需求。DSDM“动态系统开发方法”的名称可能也是由此得来的吧!

DSDM的可行性研究阶段主要侧重评估DSDM方法是否适用于本项目,笔者认为这点比较与众不同,因为在很多的可行性研究结果中,已经把瀑布模型默认为软件开发方法了。在可行性研究阶段需要得到一些结论:“该系统技术上可行吗?”“对当前业务流程带来的影响可接受吗?”“DSDM是开发这个系统最好的方法吗?”……必须把这些问题弄清楚,以便确定“这样去做值得吗”。然后需要制定一份全面的可行性报告,对于风险很高的方面,还需要提供应对和控制风险的策略。除了可行性报告之外,还需要提供开发的框架计划( Outline Plan),证明预期的结果是可实现的。另外,也可以提供一个快速原型,目的是证明项目从技术上是可行的。当然,如果对业务已经有了一定程度的理解,相应的技术也已经用过,那么生成原型的价值也就不大了,可以不需要。DSDM的哲学就是:“足够就好,无须过多!”

业务研究阶段主要是对业务流程进行分析和定义。首先需要开展一系列的讨论会,对业务流程及其相关信息、用户群进行定义,这些定义的结果被称作业务区定义,经过管理层同意后,需要从使用业务的用户群中选出代表参与到开发过程中。其次在进行业务区定义时,可以采用结构化分析方法,定义主要的数据流程图;也可以采用面向对象的方法,定义重要的用户案例。对于业务区定义的功能,必须区分出是功能性需求还是非功能性需求并且划分优先级,因为DSDM是以业务为导向的,所有制定优先级的原则也必须要以业务为导向,但是也需要从技术实现需要的角度来考虑,把技术上要求先实现的功能作为高优先级。这样就可以清晰地理解需要开发的功能和它们实现的优先级,从而引导我们对系统架构的定义,系统架构定义实际上定义了软件开发、运行的平台,软件模块和接口的结构。最后,根据可行性研究阶段的开发框架计划和业务区定义可以制订出开发计划,这个开发计划应该包含功能建模阶段和设计编程阶段的开发策略、测试策略和配置管理计划。

功能建模阶段主要是深入分析业务区定义的功能并进行细化,在分析模型的基础上构建软件模块,将创建的原型交付用户评审,经过用户评审后进一步充实和改进,这样经过不断冲刺,原型逐渐演化成可工作的软件。在功能建模阶段,还会产生以下产物。

1)、带有优先级的功能。随着业务的细化,业务研究阶段定义的优先级需要调整,从而保证本次冲刺中包含用户最需要的核心功能。

2)、功能性原型的评审文档。用户每次对原型评审时提出的改进建议都需要被记录下来,并需要根据这些评审结果对业务定义、建模进行修正。

3)、非功能性需求。在功能建模阶段对非功能需要也需要记录下来。(但是,这里会出现一个问题:因为在前期建模阶段,主要注重了对业务流程的分析建模和对高优先级需求的原型实现,倡导快速实现、交付用户评审,因此,这个过程一直注重功能性需求,对于性能方面关注不多,因为无法从全局考虑,并更深入地考虑到整个系统的性能瓶颈,特别是前期架构设计若存在缺陷将导致后期出现性能隐患,这是很难解决的;另外,若前期冲刺功能与后期冲刺关联功能存在性能制约,也存在一定风险。因此,在这一阶段,进行建模时也必须要考虑到各种可能的性能需求的技术实现,并且也需要制定优先级,在不同的冲刺中处理必要的性能需求。)

4)、实施计划。在功能建模阶段,就应该规划这一阶段的实施计划了。包括业务方案的准备,培训用户的计划,各种知识、技能的准备。

设计编程阶段主要根据功能建模的标准建造实际系统并通过测试。这里的测试和瀑布模型的测试是不同的,它不是一项单独活动,测试应该是贯穿于整个功能建模和设计编码过程的。实施阶段主要是培训用户,完成系统从开发环境向运行环境的交接,然后评估这一阶段哪些需求做完了,下一阶段需要做哪些工作。有时候开发环境(包括测试环境)不可能完全仿真用户运行环境,因此在系统移交过程中,也可能会出现一些实施问题;另外,在这个阶段,部分隐藏的系统性能问题也可能会暴露出来,也需要关注。项目后期应评审当前使用的方案并评估是否达到预期的效果。

DSDM的基本原则：

活动用户必须参与，使用产品的人积极参与其发展，是产品对用户有用的一个重要举措。
必须授权DSDM团队进行决策。
注重频繁交付产品。
判断产品是否可接受的一个基本标准是符合业务目的。
对准确的业务解决方案需要采用循环和增量开发。
开发期间的所有更改都是可逆的。
基本要求是高层次的并区分优先级（以在低优先级的项目上获得一定的灵活性）。
在整个生命周期集成测试。
协作和合作是关键。
20/80原则：DSDM认为，项目80%的解决方案将是用项目20%的时间形成的，DSDM会侧重于这80%，将剩余20%的解决方案保留到下一版本。这是因为DSDM认为不是所有要求对最终的解决方案都是已知的，最后20%的非必要功能反正可能存在缺陷。

DSDM应用MosCow优先级排序方法，将项目任务分解为四种不同类型的要求，那么，为了顺利完成“80%”的有用功能，可以首要完成Must、Should项，或者说在完成Must、Should项的基础上酌情考虑完成Could项。

2.7 Crystal-水晶方法

Crystal——水晶方法论是由Alistair Cockburn和Jim Highsmith建立的敏捷方法系列。Alistair Cockburn将水晶方法细化为透明水晶方法论（Crystal Clear）、黄色水晶方法论（Crystal Yellow）、橙色水晶方法论（Crystal Orange）以及红色水晶方法论（Crystal Red）。

这几种水晶方法论按照项目重要性，人员规模，项目优先级进行划分。

水晶方法，其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

水晶系列与XP一样，都有以人为中心的理念，但在实践上有所不同。Alistair 考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

Crystal方法是一种敏捷框架, 被认为是关注个人和交互的轻量级方法或敏捷方法。它主要用于由单个工作区中的- -组开发人员组成的短期项目。

一般来讲，透明水晶方法，适用于一个小团队来进行敏捷开发，人数在6人以下为宜。相比于同样适用于小规模团队的XP，水晶方法的纪律性较弱，但其管理运作与团队产出相协调。

项目可以按照参加的人员和重要性划分。重要性根据项目中的错误引发的后果分为:
■C : Loss of comfort (某些不舒适)
■D: Loss of discretionary money (经济损失)
●E:Loss of Essential Money (严重经济损失)
●L: Life Critical (生命危险)

一个项目称为C6说明参加人员在6人以下，重要性是C级，D20说明人员在6-20人，重要性是D级。

2.8 XP极限编程

XP极限编程强调以下原则：

结对编程可持续集成不断自动测试有效沟通简单性反馈勇气集体所有权持续集成激励工作共享工作空间现场客户代表使用隐喻说明概念

XP极限编程用语中“caves和common”指的是，为团队成员创造的两个分区。 common是一个公共的空间，在此常有渗透沟通和协作。 caves是一个私人的交易预留空间，需要一个孤立且安静的环境。

于XP实践中持续集成的最佳定义，在集成到完整的代码库前被广泛的测试，其次是完整的代码测试以确保成功的软件增量开发。持续集成是指定期检查每位团队成员工作进展并进行整个系统编译和测试的开发实践。最严格的做法是每天以迅速找出可能引入的系统错误为目标进行操作。

代码建立后即刻集成到代码库。由此集成后，对代码库和整个系统进行测试。

3. 规模化敏捷框架图谱

Agile UP--Agile Unified Process 敏捷的统一过程；

DSDM-Dynamic Systems Development Method动态系统开发方法, 是在快速应用程序开发（RAD）方法的基础上改进的。作为敏捷方法论的一种，DSDM方法倡导以业务为核心，进行快速、有效的系统开发，不仅适用于敏捷开发模式，也同样适用于传统的开发模式。它既能满足单个团队同一地点的简单产品开发，还能满足多个团队不同地点、不同时区的复杂项目开发。