概述

In 项目管理蓝图的第一部分 我们涵盖了项目管理方法, 比如精益软件开发, 敏捷, Scrum, 和看板, 以及它们是如何追溯到精益生产的. 这些方法通常部署在单个团队级别. 然而, 随着项目和项目团队变得更大，复杂性也在增长，需要新的方法来实现大规模的敏捷.

在第2部分中，我们将首先深入了解如何 项目经理 使用瀑布方法, 传统公司最常用的软件开发框架是什么. 和那个并列, 我们将介绍最流行的框架，这些框架试图大规模地整合敏捷原则——有纪律的敏捷交付(爸爸), 规模化敏捷框架(安全)，大规模Scrum (少)，以及Scrum@Scale.

瀑布

瀑布方法(也称为软件开发生命周期模型(SDLC))是一种更传统的方法，其中软件开发像瀑布一样从一个阶段级联到下一个阶段. 这些阶段不重叠，并且从一个阶段移动到下一个阶段有特定的入口和出口标准.

原始瀑布模型的六个生命周期阶段是:

1. 要求: 在这个阶段, 定义了项目的期望和目标, 需求被广泛地分析和记录, 通常由业务分析师负责. 在退出此阶段之前，对需求进行审查和批准.
2. 设计: 在需求被批准后, 开始构建和设计产品以满足批准的需求. 物理架构, 组件体系结构, 数据库设计, 详细的组件, 模块设计, 设计的其他方面由软件架构师或设计人员记录. 然后在开始实施之前对其进行审查和批准.
3. 实现: 在设计被批准后, 软件开发人员根据需求和设计对软件进行实现或编码.
4. 验证: 实现完成后, 软件由测试或QA团队进行测试，以确保满足需求和设计，并达到所需的质量水平. 缺陷被发现、记录、分类，并在许多情况下被修复.
5. 发布与维护: 后 测试 调试完成后，将产品发布给客户端进行安装. 通常，会进行一轮测试以确保安装成功. 产品发货后, 进行持续的维护和支持，以确保产品继续按设计工作.

瀑布的优点

瀑布有一些优点，它适用于某些类型的项目, 但也有一些严重的缺点. 瀑布法最适合于需求较短的项目, 技术很好理解，不太可能发生任何重大变化.

如果应用到正确的项目类型，瀑布模型的一些优点:

• 简单性: 瀑布法执行起来很简单，因为它预先确定了范围，并且有严格的阶段和从一个阶段到下一个阶段的清晰过渡.
• 可见性: 随着项目从一个阶段过渡到下一个阶段，工作的全部范围提前已知，涉众更容易衡量和看到进展.
• 文档: 范围, 需求, 计划可以经过深思熟虑，并有充分的文件记录, 这使得缺乏经验的团队更容易在项目中工作.
• 分阶段工作: 由于角色的刚性和阶段之间的转换, 当其他项目的主要阶段尚未进行时，项目资源可能会用于其他项目.

瀑布的缺点

瀑布法不适用于需求不被很好地理解和/或可能发生变化和/或存在重大技术风险的较长项目. 在当今这个市场条件不断变化的时代，市场时间至关重要, 这适用于大多数软件项目.

瀑布模型的缺点, 主要围绕着它无法适应变化, 包括:

• 单片范围: 它鼓励涉众在定义项目范围时考虑到一切, 导致一个单一的范围.
• 后期客户反馈: 利益相关者，尤其是客户，很难想象一个项目的全部详细范围. 因为瀑布法主要是在项目的最后阶段向客户展示项目结果, 然后不可避免地，将客户反馈纳入项目变得困难
• 需求变更: 长期项目的市场条件, 因此项目目标和需求, 在项目期间是否有很高的变更风险.
• 最后创建的值: 瀑布式开发需要大量的前期工作, 这意味着直到项目后期才产生价值.
• 相互依存阶段: 合并变更通常会导致需求和/或设计返工，这可能会影响项目的其他领域. 后期阶段对早期阶段的依赖可能会使项目中的小变更不成比例地具有挑战性.

有纪律的敏捷交付(爸爸)

有纪律的敏捷交付(爸爸) 被正式定义为 Scott Ambler 并扩展了敏捷和scrum框架, 认识到组织的非敏捷部分通常参与交付软件项目的某些能力. 这个框架明确地包括来自IT操作的活动, 企业架构, 项目组合管理, 金融, 将采购纳入整个交付周期. 爸爸旨在以实用的方式提高整体业务敏捷性.

主要原理及组成

角色

爸爸比scrum有更多的角色，并被分为两类团队角色. 主要角色由经常与项目一起工作的人担任. 次要角色通常是临时引入的，以帮助团队解决扩展或其他问题. 爸爸具有这些额外的角色，因为它处理整个解决方案交付生命周期，并且它识别现实世界中所需的各种类型的临时和支持角色

主要角色:

1. 利益相关者: 依赖于你的团队完成项目的人:客户、最终用户或内部同事.
2. 团队成员: 团队中实际执行计划工作的人员:开发人员、设计师、测试人员等.
3. 团队领导: 类似于scrum管理员, 团队领导作为团队的仆人式领导者，通过消除障碍, 促进团队凝聚力和传播敏捷价值观.
4. 产品负责人: 有时被称为“顾客的声音”.“产品负责人代表涉众，并维护需要完成的工作的优先级列表.
5. 建筑的所有者: 负责大规模地降低架构风险. 这个角色通常由团队中的高级开发人员担任，因为它需要深厚的技术背景和扎实的业务领域知识.

次要角色:

1. 专家: 临时加入团队以担任特定角色的人. 例如, 数据分析师可能会加入，在项目的早期阶段提供研究能力.
2. 领域专家: 税务咨询顾问, 法律顾问, 以及其他拥有领域专业知识并帮助团队解决相关挑战的人.
3. 技术专家: 数据库管理员、安全专家、构建大师等. 这些人在生命周期的关键时刻帮助更一般化的团队成员.
4. 独立测试人员: 而测试人员通常是主要团队的一部分, 在某些情况下，生命管理要求或非常复杂的系统, 独立的测试人员并行工作以验证交付的工作.
5. 积分器: 在规模上，不同的团队负责整个系统的不同部分. 集成商帮助团队将他们的部分与整个系统集成，并管理依赖关系.

生命周期支持

爸爸促进了完整的交付生命周期, 不仅仅是敏捷/scrum所涵盖的编程和发布部分, 还有定义和批准项目愿景的初始阶段，以及发布后的支持和退出阶段. 目前，爸爸支持 6个不同的生命周期:

• 敏捷生命周期:基于scrum的生命周期 项目生命周期
• 的 精益的生命周期基于看板的项目生命周期
• 持续交付:敏捷生命周期
• 持续交付:精益生命周期
• 探索性(精益创业)生命周期
• 团队的项目生命周期

这些生命周期说明了不同的工作风格, 公司敏捷性水平, 以及团队可能遇到的其他情况. 主要的一点是这些生命周期作为建议. 爸爸提倡实用主义而不是纯粹主义，因为每种情况都是独特的，有纪律的敏捷实践者应该根据自己的需要采用敏捷过程.

过程目标

爸爸使用目标驱动的方法来创建和适应敏捷过程. 该方法的作者概述了大多数团队在其生命周期中将面临的21个最重要和最常见的过程.

所有这些过程都有文档化的决策点，这些决策点将要求团队决定他们将如何构建该过程. 每个决策点提供可用于实现决策的建议技术或实践. 你可以在下面的图片中看到一个例子. 一个“发展共同愿景”的过程有6个应该做出的决定. 每个决策都有2到5个建议的实践. 箭头表示爸爸作者对列表进行了排序，列表中最上面的项目是最佳实践，最下面的项目是最糟糕的实践. 的_粗体斜体_ 文本对于刚开始使用爸爸的新团队来说意味着良好的起点.

爸爸的缩放

有纪律的敏捷交付从两个不同的角度进行扩展:

• 大规模战术敏捷性  

• 大规模战略敏捷性

战术敏捷性试图解决单个团队的规模因素，比如规模, 地理分布, 项目的复杂性, 等, 通过过程目标的情景应用及其建议的实践.

战略敏捷试图通过在整个组织中广泛应用敏捷和精益战略，扩展框架以解决组织的不同领域，从而解决可扩展性问题:

• 训练有素的DevOps:涵盖了使用DevOps为组织提供更有效的结果.

• 有纪律的敏捷IT (DAIT):涵盖如何将敏捷和精益策略应用于IT的各个方面.

• 有纪律的敏捷企业:.  介绍如何在整个企业中应用精益和敏捷.

安全

规模化敏捷框架(安全) 是最流行的，也是最复杂和全面的规模 敏捷框架 现在. 29%的受访者 年度敏捷状态报告 声称他们在组织中使用这个框架. 反过来，也有很多 安全项目经理 在市场上.

安全敏捷框架的开始是Dean Leffingwell的书“扩展软件敏捷性:大型企业的最佳实践，出版于2007年. Leffingwell现在是外管局的首席方法学家, 但是许多其他人也为这个框架做出了贡献. 目前，在版本4.6, 这个框架类似于带有版本控制的软件产品, 向后兼容性, 以及各种成分.

主要原理及组成

安全项目管理的主要目标是促进精益企业的创建和发展，因为它认识到许多不同类型的公司都是精益企业, 在某种程度上, 需要在最短时间内持续交付价值的软件公司, 可持续时间段.

精益企业安全试图通过提供经过验证的原则的知识库来创建精益企业, 能力, 最佳实践.

安全4.6定义了精益企业的五大核心竞争力. 每项能力都是一组相关的知识, 技能, 和行为, 它们共同使组织脱颖而出:

1. Lean-敏捷领导描述领导者如何通过学习来推动和维持组织变革, 教学, 实施外管局的精益-敏捷思维.

2. 团队和技术敏捷性:描述技能, 原则, 以及创建高绩效敏捷团队所需的实践.

3. DevOps和按需发布描述实现DevOps和持续交付管道如何为组织提供在任何必要时间发布产品增量以满足需求的能力.

4. 业务解决方案和精益系统工程描述如何将精益敏捷原则和实践应用于规范, 发展, 部署, 大的进化, 复杂的软件应用

5. 精益投资组合管理通过将精益和系统思维方法应用于战略和投资融资，使战略和执行保持一致, 敏捷投资组合运营, 和治理.

每个核心竞争力都直接映射到安全过程图中各自的级别，除了包含整个过程的精益敏捷领导.

精益敏捷领导能力

的主要目标 精益敏捷领导能力 是帮助组织转变为精益敏捷企业. 这是通过学习、实践和教学来实现的 安全的精益敏捷思维模式价值观、原则和实践.

外管局的核心价值 引导企业向精益化转型. 在每一次机会中，领导者的行为都在提升他们的能力方面发挥着关键作用. 核心价值是:

1. 对齐:沟通任务、投资组合策略和解决方案远景. 进行相关简报, 参与项目增量(PI)计划和待办事项维护.

2. 透明度设想所有相关的工作.

3. 内置的质量:参与实践以在整个生命周期中交付质量. 拒绝接受低质量的工作. 支持维护投资和减少技术债务.

4. 程序执行作为业务所有者参与PI执行并建立业务价值. 确保范围与需求和能力相一致. 积极消除障碍和消极因素.

敏捷安全方法的核心价值是通过采用 Lean-敏捷心态 和应用 安全的原则:

1. 从经济角度看问题

2. 运用系统思维

3. Assume variability; preserve options

4. 使用快速、集成的学习周期进行增量构建

5. 将里程碑建立在对工作系统的客观评估之上

6. 可视化和限制在制品，减少批大小，并管理队列长度

7. 应用节奏，与跨域规划同步

8. 释放知识型员工的内在动力

9. 分散决策

这些原则类似于精益和敏捷原则. 最后，通过以下方法完成组织的转换 安全实施路线图.

团队和技术敏捷性能力/团队水平

的 团队和技术敏捷性能力 描述技能, 原则, 并且需要实践来创建能够创建高质量解决方案的高绩效敏捷团队. 两个关键特征至关重要:

• 团队的敏捷性:团队采用敏捷实践和原则, 是什么使他们能够工作, 学习, 并适应一个可靠的节奏

• 技术灵活性团队应用确保代码和组件质量的敏捷技术实践, 以及它们生成的代码的可维护性 质量是团队和技术敏捷性能力的重点. 为了实现这个目标, 敏捷工程技术，如行为驱动开发(BDD)和测试驱动开发(TDD)被用于提高质量和流程. 快速流程依赖于整个系统的构建质量，因为错误会严重影响流程并延迟发布.

安全的团队级别描述了单个敏捷团队如何运作. 所有团队都是敏捷发布训练的一部分，致力于交付产品增量. 大多数传统的敏捷/scrum流程都适用, 团队在何处进行迭代以交付可工作的系统. scrum管理员的角色, 产品负责人, 和团队成员在安全中使用，大多数scrum活动和工件也是如此. 团队还由项目级别的角色(如产品管理)提供支持, 系统架构师, 以及其他共享服务. 看板 是否用于帮助可视化通过交付生命周期的特性流，以及团队之间的交互和移交.

开发运维和按需发布能力/项目水平

的 开发运维和按需发布能力 描述了“实现DevOps和持续交付管道如何为企业提供释放价值的能力”, 全部地或部分地, 随时满足市场和客户的需要.”

DevOps致力于协调开发, 操作, 业务, 和其他领域共同努力，取得商业成果. 虽然不是每个组织都需要像DevOps运动的一些行业领导者那样经常发布(Amazon每隔几秒钟发布一次)。, 所有组织都需要能够按需发布.

• DevOps提供了文化, 自动化, lean-flow, 测量, 和恢复(CALMR)方法，使持续交付和按需发布成为可能

• 敏捷发布训练(ARTs)是由敏捷团队组成的团队，它们被组织起来，通过持续交付管道按需交付价值

项目层次描述了通过项目持续交付所需的角色和活动 敏捷发布训练(ART). 这个级别的工作方式与团队级别类似，但是集成了多个敏捷团队，包含了更多的周期. ART是一个由5到12个团队(50到125人)组成的敏捷团队，包括传统的 敏捷的角色 以及关键的项目角色，比如 放行列车工程师(RTE) 及产品管理. 抗逆转录病毒治疗在8-12周内完成 项目增量(PI) 这些都是通过 π规划 由一个 产品经理.

PI特性、史诗等的进度通过程序看板板进行跟踪和管理. RTE在ART上充当Scrum Master. 每日同步会议包括团队每日站立会议、scrum -of- scrum (RTE) & Scrum master)， PO Sync(产品管理) & 产品负责人)和ART同步(scrum -of- scrum和PO同步在一起). 每个PI都有一个系统演示和回顾.

商业解决方案和精益系统工程能力/大型解决方案水平

的 商业解决方案和精益系统工程能力 描述了“如何将精益敏捷原则和实践应用于规范”, 发展, 部署, 大的进化, 复杂软件应用和网络物理系统”.

除了外管局的原则, 在处理大型解决方案时应用以下8条原则是这种能力的关键:

的 大解决方案级别 包含构建大型复杂解决方案所需的角色、工件和过程. 多个art正在合作 解决方案培训 交付 解决方案. 主要目标是:

• 管理频繁的集成

• 持续地处理合规性问题

• 为规模、模块化、可发布性和可服务性构建架构

解决方案管理 控件的内容 解决方案和解决方案培训工程师(STE) 指导工作. 解决方案架构师 负责维护解决方案中所有art的良好架构. 项目前期和后期计划 用于计划通过多个项目增量交付的解决方案. A 解决方案待定 包含 功能 和 解决方案的史诗 并通过a进行跟踪 解决方案看板 董事会

项目组合水平/精益项目组合管理能力

的 精益投资组合管理能力 “通过将精益和系统思维方法应用于战略和投资融资，使战略和执行保持一致, 敏捷投资组合运营, 和治理.”

精益投资组合管理主要关注以下几个方面:

1. 战略和投资资金:将投资组合与企业战略联系起来, 基金价值流, 建立投资组合流程

2. 敏捷投资组合操作:协调价值流, 支持项目执行, 以及卓越的运营

3. 精益治理:预测预算、度量组合绩效并强制执行

的 投资组合水平 包含原则, 实践, 以及启动和管理一组开发价值流所需的角色. A 投资组合积压 包含 业务史诗 和 推动者史诗 并通过a进行跟踪 组合看板. **精益投资组合管理(LPM) 决定投资组合中的价值流是什么，并包括企业中最高的决策者. An 企业架构师 指导工作并协调价值流.

少

大规模scrum (少) 框架是由Craig Larman和Bas Vodde创建的, 是谁根据他们在金融和电信行业的经验制定的. 顾名思义, 少提倡尽可能少的流程和程序，以便让多个Scrum团队一起工作. 扩展很难，因为人们让它变得复杂，所以这里的目标是让它尽可能简单.

主要原理及组成

少是Scrum，应用于许多团队，一起工作，开发一个产品.少项目管理基于10条原则，对于熟悉精益敏捷原则的人来说，这些原则似乎很熟悉:

1. 大规模Scrum就是Scrum

2. 经验过程控制

3. 透明度

4. 少花钱多办事

5. 产品的关注

6. 以客户为中心的

7. 不断改进，追求完美

8. 系统思考

9. 精益思想

10. 排队论

少只有两个主要角色，这两个角色都是从Scrum中借来的:

1. 产品负责人: 与2-8个团队合作.
2. Scrum master: 与1-3个团队合作.

所有的团队都是一样的 产品待办事项列表 1-4周的冲刺. 团队并行工作，这意味着他们同时开始和结束sprint. 在sprint结束时，团队共同交付一个 产品增加. 一个产品负责人与8个团队一起工作似乎几乎是不可能的. 少促进将产品待办事项列表项澄清的责任转移给团队. 反过来, 团队必须是跨职能的，并且不仅仅包含编码, 设计, 测试能力和商业领域的知识. 更重要的是，团队必须被授权能够接触到客户.

Sprint计划

规划分为两个部分:

1. Sprint计划1: 团队的代表在哪里与产品所有者会面，决定他们将承担哪些待办事项，并讨论在sprint期间团队之间可能需要的任何潜在合作.
2. Sprint计划2: 和传统的scrum一样, 每个团队分别聚集在一起，为如何完成待办事项制定计划.

产品待办事项列表细化

产品待办事项列表细化(PBR)是在冲刺期间完成的，目的是为冲刺计划准备产品待办事项列表项. 少没有提供如何进行PBR的规则，而是让公司自己找出最有效的流程. PBR涉及三个关键活动:

1. 分割大件物品.
2. 详细描述物品直到准备就绪.
3. 估计.

Sprint结束

每次冲刺结束时，会发生三件事:

1. 冲刺评审: 共享的Sprint演示, 团队和客户探讨在Sprint期间做了什么以及下一步应该做什么.
2. 回顾: 每个团队都举行他们自己的回顾会议来改进他们的流程.
3. 总体回顾: 团队, 产品负责人, scrum管理员聚在一起检查和调整组织实践以提高效率.

Scrum@Scale

大规模的Scrum和 Scrum@Scale 是否可以互换使用. 这种方法是由 Jeff Sutherl和 2014年，他创建了Scrum方法，并且是敏捷宣言的签署人之一.

Scrum@Scale以Scrum为出发点，提供了一个简单的, 轻量级框架，用“最小可行官僚”来扩展Scrum. 它不像其他可伸缩敏捷方法那样具有规定性，可以看作是一个元框架. 它强调了可扩展性问题和领域，并提供了如何解决这些问题的心理框架.

主要原理及组成

Scrum@Scale是一个框架，通过使用Scrum来扩展Scrum，从根本上简化了扩展. 在Scrum中，“做什么”(产品所有者)和“怎么做”(Scrum管理员)是明显分开的。. Scrum@Scale也采用了同样的策略，以便很好地理解管辖权和问责制, 消除浪费和冲突.

Scrum@Scale包含两个循环，以明确区分管辖范围: Scrum Master 周期 和 产品负责人周期 有两个接触点:团队层面的过程和产品发布反馈.

Scrum Master周期

的 Scrum管理周期 负责产品所有者周期确定的东西将如何构建. 在Scrum@Scale, 每个Scrum团队都有相同的角色, 工件, 活动, 和传统Scrum的仪式.

Scrum团队被分为 Scrum of Scrum (SoS) 谁共同负责生产共同的产品增量.  他们共同参与待办事项梳理和优先排序, 举行回顾, 维护障碍积压, 他们有一个 规模化的每日Scrum (SDS) (类似于每日scrum的形式)来协调团队并消除障碍.  SDS由每个参与团队的至少一名代表(通常是团队的scrum主管)参加，并由团队经理领导 Scrum of Scrum大师(SoSM) 谁负责协调scrum团队和产品负责人.

如果需要进一步缩放，有一个 scrum of scrum (SoSoS) 由多个组织组成，这些组织也会每天见面，以此类推.  整体的领导者是 行政行动小组(EAT) 谁负责在组织中推广敏捷, 根据需要协调Scrum团队, 也是消除障碍的最后一站.

产品负责人周期

的 产品负责人周期 负责将要创建的产品或服务以及支持该产品或服务所需的所有活动. 产品负责人被分配到Scrum团队，执行Scrum中定义的他们角色的所有活动.  产品负责人分为 产品负责人团队 哪个地图指向SoS小组.  产品负责人团队每天开会一次 元Scrum 讨论团队的高级策略, 并根据需要与相应的SoSM、其他产品负责人和干系人进行协调.. 元scrum由一个 首席产品负责人(CPO).

产品负责人以类似于scrum管理员周期的方式进行扩展, 这取决于组织的规模，最终形成一个 行政元Scrum (EMT)，负责制定全公司的优先事项.

实现Scrum@Scale

Scrum@Scale的实现首先要创建一个可伸缩的参考模型i.e. 一小部分团队小规模地使用scrum. 这样做是为了解决任何阻碍敏捷的组织策略和开发实践. Scrum@Scale建议尽早解决这些问题，因为所有团队都可能面临这些组织范围内的问题，随之而来的挫折可能会阻碍敏捷的采用. 然后将参考模型用作将scrum扩展到其他团队和部门的模式.

最初必须创建执行行动团队(Executive action team, EAT)来实现参考模型. EAT由在组织内部拥有政治和经济权力的个人组成, 因为他们将能够实施组织的政策变更.

结论

在这第二部分的项目管理蓝图, 我们已经介绍了一些大型项目或程序中使用的最流行的框架. 瀑布法在许多组织中仍然被广泛使用, 虽然它有很多缺点，由于其不灵活的过程, 当项目很小，范围定义良好且不太可能更改时，使用此框架有时是有意义的.

当公司遇到更大的, 需求或目标不断变化的更复杂的项目, 他们寻求更敏捷的方法. 因为敏捷最初适用于5-9人的小团队, 各种敏捷实践者都有多种方法来从单个团队扩展敏捷, 针对多个团队, 对整个企业. 在本文中, 我们讨论了有纪律的敏捷交付(爸爸), 规模化敏捷框架(安全)，大规模Scrum (少)，以及Scrum@Scale.

最后部分为项目管理蓝图, 我们将介绍一些特定的项目管理框架，如PMP (PMBOK)和PRINCE2. 我们还将讨论一些创新过程和框架，如“要完成的工作”(JTBD)和“设计思维”.”