作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
In 项目管理蓝图的第一部分 我们涵盖了项目管理方法, 比如精益软件开发, 敏捷, Scrum, 和看板, 和 how they all trace their roots back to Lean Manufacturing. 的se methodologies are usually deployed on a single team level. 然而, 随着项目和项目团队变得更大,复杂性也在增长,需要新的方法来实现大规模的敏捷.
在第2部分中,我们将首先深入了解如何 项目经理 使用瀑布方法, 传统公司最常用的软件开发框架是什么. 和那个并列, 我们将介绍最流行的框架,这些框架试图大规模地整合敏捷原则——有纪律的敏捷交付(爸爸), 规模化敏捷框架(安全),大规模Scrum (少),以及Scrum@Scale.
瀑布方法(也称为软件开发生命周期模型(SDLC))是一种更传统的方法,其中软件开发像瀑布一样从一个阶段级联到下一个阶段. 这些阶段不重叠,并且从一个阶段移动到下一个阶段有特定的入口和出口标准.
的 six life 周期 stages of the original waterfall model are:
瀑布有一些优点,它适用于某些类型的项目, 但也有一些严重的缺点. 瀑布法最适合于需求较短的项目, 技术很好理解,不太可能发生任何重大变化.
如果应用到正确的项目类型,瀑布模型的一些优点:
瀑布法不适用于需求不被很好地理解和/或可能发生变化和/或存在重大技术风险的较长项目. 在当今这个市场条件不断变化的时代,市场时间至关重要, 这适用于大多数软件项目.
瀑布模型的缺点, which mostly center around its inability to adapt to change, 包括:
有纪律的敏捷交付(爸爸) 被正式定义为 Scott Ambler 并扩展了敏捷和scrum框架, 认识到组织的非敏捷部分通常参与交付软件项目的某些能力. 这个框架明确地包括来自IT操作的活动, 企业架构, 项目组合管理, 金融, 和 procurement into the full delivery life周期. 爸爸旨在以实用的方式提高整体业务敏捷性.
爸爸比scrum有更多的角色,并被分为两类团队角色. 主要角色由经常与项目一起工作的人担任. 次要角色通常是临时引入的,以帮助团队解决扩展或其他问题. 爸爸具有这些额外的角色,因为它处理整个解决方案交付生命周期,并且它识别现实世界中所需的各种类型的临时和支持角色
主要角色:
次要角色:
爸爸促进了完整的交付生命周期, 不仅仅是敏捷/scrum所涵盖的编程和发布部分, 还有定义和批准项目愿景的初始阶段,以及发布后的支持和退出阶段. 目前,爸爸支持 6个不同的生命周期:
的se life周期s account for different work styles, 公司敏捷性水平, 和 other situations that the teams might find themselves in. 的 main point is that these life周期s act as suggestions. 爸爸提倡实用主义而不是纯粹主义,因为每种情况都是独特的,有纪律的敏捷实践者应该根据自己的需要采用敏捷过程.
爸爸使用目标驱动的方法来创建和适应敏捷过程. 该方法的作者概述了大多数团队在其生命周期中将面临的21个最重要和最常见的过程.
所有这些过程都有文档化的决策点,这些决策点将要求团队决定他们将如何构建该过程. 每个决策点提供可用于实现决策的建议技术或实践. You can see an example of this in the image below. 一个“发展共同愿景”的过程有6个应该做出的决定. Each of those decisions has 2 to 5 suggested 实践. 箭头表示爸爸作者对列表进行了排序,列表中最上面的项目是最佳实践,最下面的项目是最糟糕的实践. 的_粗体斜体_ 文本对于刚开始使用爸爸的新团队来说意味着良好的起点.
有纪律的敏捷交付从两个不同的角度进行扩展:
大规模战术敏捷性
大规模战略敏捷性
战术敏捷性试图解决单个团队的规模因素,比如规模, 地理分布, 项目的复杂性, 等, 通过过程目标的情景应用及其建议的实践.
战略敏捷试图通过在整个组织中广泛应用敏捷和精益战略,扩展框架以解决组织的不同领域,从而解决可扩展性问题:
训练有素的DevOps:涵盖了使用DevOps为组织提供更有效的结果.
有纪律的敏捷IT (DAIT):涵盖如何将敏捷和精益策略应用于IT的各个方面.
有纪律的敏捷企业:. covers how to apply lean 和 agile throughout an enterprise.
规模化敏捷框架(安全) 是最流行的,也是最复杂和全面的规模 敏捷框架 现在. 29%的受访者 年度敏捷状态报告 claim that they use this framework in their organizations. 反过来,也有很多 安全项目经理 在市场上.
安全敏捷框架的开始是Dean Leffingwell的书“Scaling Software Agility: Best Practices for Large 企业s,出版于2007年. Leffingwell is now the chief methodologist of 安全, but many other people also contribute to this framework. 目前,在版本4.6, this framework resembles a software product with versioning, 向后兼容性, 以及各种成分.
安全项目管理的主要目标是促进精益企业的创建和发展,因为它认识到许多不同类型的公司都是精益企业, 在某种程度上, 需要在最短时间内持续交付价值的软件公司, 可持续时间段.
精益企业安全试图通过提供经过验证的原则的知识库来创建精益企业, 能力, 最佳实践.
安全4.6 defines Five Core Competencies of the Lean 企业. 每项能力都是一组相关的知识, 技能, 和行为, 它们共同使组织脱颖而出:
Lean-敏捷领导描述领导者如何通过学习来推动和维持组织变革, 教学, 实施外管局的精益-敏捷思维.
团队和技术敏捷性:描述技能, 原则, 以及创建高绩效敏捷团队所需的实践.
DevOps和按需发布描述实现DevOps和持续交付管道如何为组织提供在任何必要时间发布产品增量以满足需求的能力.
Business solutions 和 lean systems engineering描述如何将精益敏捷原则和实践应用于规范, 发展, 部署, 大的进化, 复杂的软件应用
精益投资组合管理通过将精益和系统思维方法应用于战略和投资融资,使战略和执行保持一致, 敏捷投资组合运营, 和治理.
每个核心竞争力都直接映射到安全过程图中各自的级别,除了包含整个过程的精益敏捷领导.
的主要目标 精益敏捷领导能力 是帮助组织转变为精益敏捷企业. This is done by 学习ing, practicing, 和 教学 安全的精益敏捷思维模式价值观、原则和实践.
外管局的核心价值 guide the transformation to the lean enterprise. 在每一次机会中,领导者的行为都在提升他们的能力方面发挥着关键作用. 核心价值是:
对齐:沟通任务、投资组合策略和解决方案远景. 进行相关简报, 参与项目增量(PI)计划和待办事项维护.
透明度设想所有相关的工作.
内置的质量:参与实践以在整个生命周期中交付质量. 拒绝接受低质量的工作. Support investments in maintenance 和 reducing technical debt.
程序执行作为业务所有者参与PI执行并建立业务价值. Ensure that the scope is aligned with dem和 和 capacity. Aggressively remove impediments 和 demotivators.
敏捷安全方法的核心价值是通过采用 Lean-敏捷心态 和应用 安全的原则:
从经济角度看问题
运用系统思维
Assume variability; preserve options
Build incrementally with fast, integrated 学习ing 周期s
Base milestones on an objective evaluation of working systems
可视化和限制在制品,减少批大小,并管理队列长度
Apply cadence, synchronize with cross-domain planning
Unlock the intrinsic motivation of knowledge workers
分散决策
的se 原则 are similar to Lean 和 敏捷 原则. 最后,通过以下方法完成组织的转换 安全实施路线图.
的 团队和技术敏捷性能力 描述技能, 原则, 并且需要实践来创建能够创建高质量解决方案的高绩效敏捷团队. 两个关键特征至关重要:
团队的敏捷性:团队采用敏捷实践和原则, 是什么使他们能够工作, 学习, 并适应一个可靠的节奏
技术灵活性团队应用确保代码和组件质量的敏捷技术实践, 以及它们生成的代码的可维护性 质量是团队和技术敏捷性能力的重点. 为了实现这个目标, 敏捷工程技术,如行为驱动开发(BDD)和测试驱动开发(TDD)被用于提高质量和流程. 快速流程依赖于整个系统的构建质量,因为错误会严重影响流程并延迟发布.
安全的团队级别描述了单个敏捷团队如何运作. 所有团队都是敏捷发布训练的一部分,致力于交付产品增量. Most of the traditional agile/scrum flow applies, where teams work in iterations 交付 working systems. scrum管理员的角色, 产品负责人, 和团队成员在安全中使用,大多数scrum活动和工件也是如此. 团队还由项目级别的角色(如产品管理)提供支持, 系统架构师, 以及其他共享服务. 看板 是否用于帮助可视化通过交付生命周期的特性流,以及团队之间的交互和移交.
的 开发运维和按需发布能力 描述了“实现DevOps和持续交付管道如何为企业提供释放价值的能力”, 全部地或部分地, at any time necessary to meet market 和 customer dem和.”
DevOps致力于协调开发, 操作, 业务, 和 other areas to work together 交付 business results. 虽然不是每个组织都需要像DevOps运动的一些行业领导者那样经常发布(Amazon每隔几秒钟发布一次)。, all organizations need to be able to release on dem和.
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都有一个系统演示和回顾.
的 Business 解决方案 和 Lean Systems 工程 Competency 描述了“如何将精益敏捷原则和实践应用于规范”, 发展, 部署, 大的进化, 复杂的软件应用 和 cyber-physical systems”.
除了外管局的原则, 在处理大型解决方案时应用以下8条原则是这种能力的关键:
的 大解决方案级别 包含构建大型复杂解决方案所需的角色、工件和过程. 多个art正在合作 解决方案培训 交付 解决方案. 主要目标是:
管理频繁的集成
持续地处理合规性问题
为规模、模块化、可发布性和可服务性构建架构
解决方案管理 控件的内容 解决方案和解决方案培训工程师(STE) 指导工作. 解决方案架构师 负责维护解决方案中所有art的良好架构. 项目前期和后期计划 用于计划通过多个项目增量交付的解决方案. A 解决方案待定 包含 功能 和 解决方案的史诗 并通过a进行跟踪 解决方案看板 董事会
的 精益投资组合管理能力 “通过将精益和系统思维方法应用于战略和投资融资,使战略和执行保持一致, 敏捷投资组合运营, 和治理.”
Lean Portfolio Management focuses on the following areas:
战略和投资资金:将投资组合与企业战略联系起来, 基金价值流, 建立投资组合流程
敏捷 portfolio 操作: coordinates the value streams, 支持项目执行, 以及卓越的运营
精益治理:预测预算、度量组合绩效并强制执行
的 投资组合水平 包含原则, 实践, 以及启动和管理一组开发价值流所需的角色. A 投资组合积压 包含 业务史诗 和 推动者史诗 并通过a进行跟踪 组合看板. **精益投资组合管理(LPM) 决定投资组合中的价值流是什么,并包括企业中最高的决策者. An 企业架构师 指导工作 和 coordinates across Value Streams.
大规模scrum (少) framework was created by Craig Larman 和 Bas Vodde, 是谁根据他们在金融和电信行业的经验制定的. 顾名思义, 少提倡尽可能少的流程和程序,以便让多个Scrum团队一起工作. 扩展很难,因为人们让它变得复杂,所以这里的目标是让它尽可能简单.
少是Scrum,应用于许多团队,一起工作,开发一个产品.少项目管理基于10条原则,对于熟悉精益敏捷原则的人来说,这些原则似乎很熟悉:
大规模Scrum就是Scrum
经验过程控制
透明度
少花钱多办事
产品的关注
以客户为中心的
不断改进,追求完美
系统思考
精益思想
排队论
少只有两个主要角色,这两个角色都是从Scrum中借来的:
所有的团队都是一样的 产品待办事项列表 1-4周的冲刺. 团队并行工作,这意味着他们同时开始和结束sprint. At the end of the sprint, the teams collectively deliver a 产品增加. 一个产品负责人与8个团队一起工作似乎几乎是不可能的. 少促进将产品待办事项列表项澄清的责任转移给团队. 反过来, the teams must be cross-functional 和 contain not only coding, 设计, 和 测试 能力 but also business domain knowledge. 更重要的是,团队必须被授权能够接触到客户.
规划分为两个部分:
产品待办事项列表细化(PBR)是在冲刺期间完成的,目的是为冲刺计划准备产品待办事项列表项. 少没有提供如何进行PBR的规则,而是让公司自己找出最有效的流程. PBR涉及三个关键活动:
每次冲刺结束时,会发生三件事:
大规模的Scrum和 Scrum@Scale 是否可以互换使用. 这种方法是由 Jeff Sutherl和 2014年,他创建了Scrum方法,并且是敏捷宣言的签署人之一.
Scrum@Scale以Scrum为出发点,提供了一个简单的, 轻量级框架,用“最小可行官僚”来扩展Scrum. 它不像其他可伸缩敏捷方法那样具有规定性,可以看作是一个元框架. 它强调了可扩展性问题和领域,并提供了如何解决这些问题的心理框架.
Scrum@Scale是一个框架,通过使用Scrum来扩展Scrum,从根本上简化了扩展. 在Scrum中,“做什么”(产品所有者)和“怎么做”(Scrum管理员)是明显分开的。. Scrum@Scale也采用了同样的策略,以便很好地理解管辖权和问责制, 消除浪费和冲突.
Scrum@Scale包含两个循环,以明确区分管辖范围: Scrum Master 周期 和 产品负责人周期 有两个接触点:团队层面的过程和产品发布反馈.
的 Scrum管理周期 负责产品所有者周期确定的东西将如何构建. 在Scrum@Scale, 每个Scrum团队都有相同的角色, 工件, 活动, 和传统Scrum的仪式.
Scrum团队被分为 Scrum of Scrum (SoS) 谁共同负责生产共同的产品增量. 的y participate in joint backlog grooming 和 prioritization, 举行回顾, 维护障碍积压, 他们有一个 规模化的每日Scrum (SDS) (类似于每日scrum的形式)来协调团队并消除障碍. SDS由每个参与团队的至少一名代表(通常是团队的scrum主管)参加,并由团队经理领导 Scrum of Scrum大师(SoSM) 谁负责协调scrum团队和产品负责人.
如果需要进一步缩放,有一个 scrum of scrum (SoSoS) 由多个组织组成,这些组织也会每天见面,以此类推. 整体的领导者是 行政行动小组(EAT) which is responsible for promoting 敏捷 in the organization, 根据需要协调Scrum团队, 和 for being the final stop for removing impediments.
的 产品负责人周期 负责将要创建的产品或服务以及支持该产品或服务所需的所有活动. 产品负责人被分配到Scrum团队,执行Scrum中定义的他们角色的所有活动. 产品负责人分为 产品负责人团队 哪个地图指向SoS小组. 产品负责人团队每天开会一次 元Scrum 讨论团队的高级策略, 并根据需要与相应的SoSM、其他产品负责人和干系人进行协调.. 元scrum由一个 首席产品负责人(CPO).
产品 Owners scale in a similar way to the Scrum管理周期, depending on the size of the organization 和 culminates in an 行政元Scrum (EMT), which is responsible for company-wide priority setting.
Scrum@Scale的实现首先要创建一个可伸缩的参考模型i.e. a small set of teams using scrum at a small scale. 这样做是为了解决任何阻碍敏捷的组织策略和开发实践. Scrum@Scale建议尽早解决这些问题,因为所有团队都可能面临这些组织范围内的问题,随之而来的挫折可能会阻碍敏捷的采用. 然后将参考模型用作将scrum扩展到其他团队和部门的模式.
最初必须创建执行行动团队(Executive action team, EAT)来实现参考模型. EAT由在组织内部拥有政治和经济权力的个人组成, 因为他们将能够实施组织的政策变更.
In this second part of the project management blueprint, 我们已经介绍了一些大型项目或程序中使用的最流行的框架. 瀑布 is still widely used in many organizations, 虽然它有很多缺点,由于其不灵活的过程, 当项目很小,范围定义良好且不太可能更改时,使用此框架有时是有意义的.
当公司遇到更大的, 需求或目标不断变化的更复杂的项目, 他们寻求更敏捷的方法. As 敏捷 was originally meant for small teams of 5-9 people, 各种敏捷实践者都有多种方法来从单个团队扩展敏捷, 针对多个团队, 对整个企业. 在本文中, 我们讨论了有纪律的敏捷交付(爸爸), 规模化敏捷框架(安全),大规模Scrum (少),以及Scrum@Scale.
In the final part of the project management blueprint, 我们将介绍一些特定的项目管理框架,如PMP (PMBOK)和PRINCE2. 我们还将讨论一些创新过程和框架,如“要完成的工作”(JTBD)和“设计思维”.”
瀑布方法包含了大量的前期计划,并且在项目结束时交付结果. 敏捷方法提倡轻量级的计划和多次迭代,以小的增量交付结果.
是的. 将瀑布项目分成几个部分, 在sprint中迭代完成的一些工作将是两种方法一起使用的一个例子. 混合方法还有助于将两种方法结合起来,以获得最大的好处.
混合方法意味着瀑布式开发和敏捷开发的一些组成部分被用于同一个项目或同一个公司. 这是公司从瀑布式过渡到敏捷的常用方法.
世界级的文章,每周发一次.
世界级的文章,每周发一次.