什么是敏捷方法论? 初学者指南

什么是敏捷方法论?

敏捷是一种管理项目的迭代方法,涉及将工作分解为小的、动态的阶段,通常(但不总是)被称为“冲刺”。

敏捷方法论的重点是连续的提高,自组织团队之间的协作,客户与利益相关者的沟通,并尽快交付团队所能提供的最大价值。

迭代方法开发软件和其他数字产品的历史可以追溯到 20 世纪 50 年代末和 1960 年代,当时关于如何管理项目的传统、固定的想法第一次开始受到挑战。

然而,直到 20 世纪 90 年代,我们今天认识的许多敏捷框架(例如Scrum) 出生。敏捷宣言最终于 2001 年出版,将一系列不同的想法和方法论纳入一个有原则的框架之下。 敏捷有四个核心价值观或“支柱”:

  • 个体和互动超越流程和工具
  • 工作软件过于全面的文档
  • 客户协作合同谈判
  • 回应按照计划改变

这四大支柱是我们的基础12 条敏捷原则用于软件开发(现在所有敏捷工作),我们将在下一节中讨论。

敏捷的关键原则

随着敏捷价值观上文提到的,敏捷宣言由组成12 项关键原则最初旨在指导软件开发团队完成工作,但现在经常应用于各种其他行业、角色和项目,特别是在科技领域。

“我们的首要任务是通过早期和持续的方式满足客户交付有价值的软件” 宣言写道——这是第一个也是最重要的敏捷原则。 其他十一条原则是:

  • 张开双臂迎接不断变化的需求
  • 快速、频繁地交付工作软件
  • 业务人员和开发人员之间的协作
  • 围绕有积极性的个人构建项目并信任他们
  • 面对面的会议是最好的沟通方式
  • 衡量成功的标准应该始终是可用的软件
  • 发展应该是可持续的并保持稳定的步伐
  • 关注“技术卓越”提高敏捷性
  • 简单性——消除浪费并最大化“未完成的工作”
  • 自组织团队打造最好的产品和工作结构
  • 反思工作和采取行动反馈至关重要

敏捷的关键原则试图让团队能够自主工作,批判性地思考以改进自己的流程,并相信高绩效的个人能够做出正确的决策。

敏捷方法论的好处

敏捷工作方法具有许多关键优势,这就是为什么如此多的团队将其用作管理项目的基础。 由于这些好处,在敏捷环境中工作将有助于您的团队发展基本的项目管理技能,例如改进时间管理。 实施敏捷框架的主要优点是:

灵活性和对变化的响应能力

敏捷框架旨在快速交付大量价值。 然而,团队如何快速增加价值将根据以下因素而发生变化:利益相关者反馈外部变化宏观经济环境,所以框架不能僵化,必须适应性强

这种程度的灵活性意味着敏捷团队特别擅长响应变化,尤其是在项目需求方面。 冲刺是短爆发工作量,因此如果在完成一次冲刺时发生变化,您可以纠正或者代替它在下一篇中。

客户与利益相关者参与的优先顺序

在非敏捷项目中,项目涉众可能会通知团队“我希望在此日期之前交付 X 产品”,然后在截止日期之前不再与他们进行进一步的交互。

问题在于,如果利益相关者没有提供足够的细节从一开始,或者项目团队误解了为他们提出的要求,最终的产品就不会令利益相关者满意——他们可能在项目上花费了大量资金。 他们的担忧、想要和欲望是孤立从启动阶段之后的过程。

敏捷团队通过要求利益相关者参与任何给定项目的各个阶段来挑战这一点,优先考虑并回应他们的担忧以非敏捷团队所不具备的方式。

确保利益相关者在每个阶段都满意意味着可以更好地管理和项目预期局限性和成功所有相关人员(而不仅仅是参与日常工作的人员)都能更好地理解。 当最终产品生产出来时,没有人感到惊讶

更好的团队士气

在漫长而复杂的项目中,这些项目的截止日期非常遥远,团队很容易变得没有动力并忽视了他们正在努力实现的目标。

在冲刺和持续创造价值– 通常以数字或物理产品的形式 – 往往具有激励作用。 不断创造新事物是一些长期项目无法提供的切实进展衡量标准。

此外,增加的重视反馈快速采取行动的能力更有可能让人感觉他们正在被倾听而不是那些只在最终交付成果准备好后才进行审查的项目。

降低风险

在完成大型项目时,有时很难发现正在形成的风险或危险,如果不及早发现,它们就会像滚雪球一样越滚越大。甚至更大的问题

迭代方法往往可以确保更早地发现问题,就像持续合作敏捷项目中发生的利益相关者和开发人员/团队成员之间的关系。 更重要的是,反馈回路在敏捷工作环境中创建的以及它优先考虑反思的方式意味着可以快速解决所识别的问题。

纠正问题的机制是内置于敏捷框架中在某种程度上,它们不属于某些传统的项目管理框架。

赋予个人权力并激励个人

敏捷项目管理方法区别于传统方法的关键因素之一是,它们在多大程度上赋予团队自组织能力和个人自主性,从而充分利用他们的技能。

在一些传统项目,一些团队成员的角色只是为了执行命令从上面开始,或者完成严格概要定义的工作——这有时会导致才华横溢的团队成员的技能被浪费。 尽管有些项目需要这样做——特别是如果有大量的行政工作需要完成——但这可能意味着您没有充分利用团队的潜力和创造力。

敏捷框架要求更多比这个来自团队成员– 你必须做好准备测试你的想法,进行自我批评,并进行行动反馈,并想出更有效的做事方法。 并非所有项目框架都允许这样做,这也是软件开发领域之外的公司采用敏捷的关键原因之一。

敏捷方法论的缺点

虽然许多团队发现实施敏捷方法很有用,但它并非没有缺点。 以下是需要考虑的三个因素:

缺乏文档

敏捷工作的本质意味着完成许多任务“恰逢其时”,目标是交付工作软件和客户满意度。 这有时可能意味着文档和报告是不太彻底比使用其他项目管理方法或方法的团队所产生的结果要好。

敏捷团队经常会产生只是最低限度满足公司或监管标准并维护所需的文件项目稳定性。 然而,敏捷绝不是反文档的,但记录和跟踪非敏捷团队所经历的事情的压力并不相同。

范围蔓延

范围蔓延是常见的项目杀手– 这个术语指的是项目范围不断且常常无法控制的扩大,这会导致预算膨胀并导致工人精疲力竭。

敏捷团队 – 拥有没有固定的初始要求并不断应对不断变化的利益相关者的要求——特别容易受到范围蔓延,特别是如果没有健全的变更程序或者团队对敏捷工作方式缺乏经验。

利益相关者可能随时请求新功能或产品,并且这些可能需要不同的时间和需求不同的(和未指定的)资源去完成。

敏捷并不适用于所有项目

近年来,敏捷已在越来越广泛的行业、部门和项目中得到应用,软件开发领域之外的团队意识到他们也可以将其应用到自己的工作环境中。 然而,敏捷并不能应用于每个项目,在某些情况下,甚至会是有害的。

例如,从事项目的团队明确规定要求和单一交付成果可能会表现得更好瀑布方法,这是更固定、线性的项目管理方法的总称。

一个很好的例子是音乐节——制作组的工作都是为了单一的年度活动,只持续几天。 一切都必须在这一最后期限之前做好准备,而特定任务(例如预订表演者)将无法像移动应用程序的更新那样在冲刺中完成。

最流行的敏捷框架

正如我们所提到的,尽管本节中讨论的许多敏捷框架现在都被置于项目管理的“敏捷”方法的保护之下,但其中许多框架早于敏捷宣言2001年。

Scrum

Scrum 是一个敏捷框架,最著名的是它的方式将工作分解为冲刺。 这个名字起源于橄榄球争球——一小群统一的紧密排列的球员——他们都扮演着不同的角色——共同努力以获得球权。

Scrum 团队通常有一个敏捷大师,他们实际上是项目协调员——他们的任务是组织团队(或 scrum)并确保每个人都知道他们应该做什么以及何时工作。产品负责人另一方面,确保正​​在进行的工作与产品的目标保持一致。

scrum 的关键原则包括经验过程控制、自组织、时间限制(对于冲刺)、基于价值的优先级、迭代开发和协作。

看板

看板方法是一种调度装置由工业工程师开发20世纪的丰田公司,旨在提高效率。 此后,它在科技和软件行业广泛流行。

看板——这是大多数人的必备品项目管理软件程序——通常有四或五栏。 一个包含尚未分配的积压工作,一个包含“正在进行的工作”,另一个包含“已完成”的工作。

由于看板是应用最广泛的敏捷框架之一,因此它通常与其他敏捷工作实践相结合来创建新的混合方法。 最近的一个例子是“摇摇欲坠”,结合了两者的元素看板和 Scrum

精益开发

“精益”开发(现在被认为是敏捷框架)基于两个关键原则:消除浪费, 和精制 业务流程

与其他敏捷框架一样,精益开发(在制造业或其他行业)侧重于持续改进、减少延迟和最大化价值交付。 精益开发还利用准时制 (JIT) 方法– 在需要时准确交付货物 – 从而降低库存并消除浪费。

您可能会看到精益被称为精益敏捷 - 有些人不认为它是真正的敏捷框架,尽管它以许多相同的原则为基础,并且也是丰田员工尝试制定制造流程的产物更高效

极限编程(XP)

极限编程 (XP) 是一种敏捷软件开发方法,它优先考虑适应性合作在技术编程的背景下。 该框架的基本原则包括设计简单,持续反馈,迭代开发。

XP 提倡诸如测试驱动开发(TDD)、结对编程、持续集成和定期发布,以确保高质量的软件交付,同时有效响应不断变化的客户需求。

如果正确实施,该框架可以促进尊重的文化,鼓励开发人员两人一组编写代码,并倡导可持续的工作节奏——就像其他敏捷框架一样。

然而,极限编程不仅仅涉及更高质量的软件交付成果——根据敏捷联盟,极限编程的一个核心部分是改进生活质量软件开发人员经验丰富,从长远来看,这应该会带来更好的工作。

动态系统开发方法(DSDM)

与大多数其他敏捷框架一样,动态系统开发方法 (DSDM) 的核心原则围绕交付功能软件在指定的时间范围和预算内增加,同时确保最终产品满足用户需求并与业务目标保持一致。

不过,有点多了严格的,结构化,并且有纪律的与其他敏捷方法相比——这也许可以通过与 Scrum 的简短比较来最好地看出。 有八个关键原则,其中许多与敏捷宣言类似。 然而,一个关键的区别是 DSDM 的原则是“展示控制力” – 涉及制定计划和进度跟踪超可见

事实上,与此框架不同,DSDM 通常部署于具有以下特性的项目:明确的范围以及预定义的开始和结束日期。 它是围绕项目,而不是产品。 DSDM 和 Scrum 之间的另一个大区别是“产品拥有者Scrum 团队中的角色分为多个不同的角色,例如业务发起人、分析师和业务远见者。

什么是敏捷生命周期?

敏捷生命周期有六个不同阶段,代表产品在创建过程中经历的每个不同阶段。

  • 概念:这包括定义您的企业或主要利益相关者希望您从事的项目,然后确定最重要项目的优先级。
  • 引发:一旦您选择了要开展的项目,您就可以启动它——同样,这将涉及与利益相关者的沟通来定义需求。 在大型企业中,项目负责人或 Scrum Master 将检查员工的能力并为手头的项目选择团队成员。
  • 迭代:这个阶段是大部分艰苦工作发生的阶段,团队创建产品、修改设计并不断改进他们正在制作的产品。
  • 发布:这是测试阶段,软件将经过质量保证检查并解决错误。
  • 生产:一旦您的软件发布到全世界,您就必须对其进行监控,解决出现的任何问题并确保其运行良好。
  • 退休:这个阶段是不言自明的——一旦软件达到了它的目的并且你更新或替换了它,你就可以让它休息了。

什么是敏捷中的冲刺?

冲刺是一个短暂的、有时间限制的工作阶段(通常在一到四个星期长),其中团队完成范围狭窄的任务和职责,这些任务和职责有助于实现可交付的目标,例如移动应用程序的更新。

正如我们在本文中已经介绍过的,冲刺通常由Scrum 团队,每个阶段的持续时间通常会根据他们正在完成的不同类型的工作而有所不同。 通常,会创建一个冲刺待办事项列表,其中包含为单个冲刺设定的所有工作。

短跑复古通常在冲刺结束时举行回顾和反思已完成的工作,这些会议的反馈可以用于改进下一个冲刺。

经常问的问题

敏捷与传统项目管理方法之间的主要区别是灵活性。 敏捷的设计是为了适应变化,使用这个框架的团队应该做出改变。 传统的项目规划更多的是固定的事情,更强调长期规划和可预测的项目阶段。

敏捷方法并不适合每个项目。 有些项目非常简单,并且从一开始就有明确定义的需求,因此使用像敏捷这样的方法会使事情变得过于复杂。 此外,如果您在一个受到高度监管的行业工作,并且您的项目有严格的法律和财务要求,那么敏捷在这里不会很有用。

如果您没有一个由积极主动且能够自主行动的个人组成的团队(如果您有一个非常新的员工团队,则可能会出现这种情况),他们可能会发现敏捷工作不断变化的结构令人困惑且缺乏方向。 需求不断变化的项目也会引起财务部门和项目团队之间的摩擦。

敏捷项目的主要成功指标首先是工作软件的交付(或在软件行业之外应用时的等效交付成果)、客户/利益相关者满意度和所生产产品的质量。

是的——敏捷-瀑布混合方法结合了更传统、高度结构化、线性项目管理框架的元素以及源自敏捷的迭代工作方式。 但是,如果您是项目管理的新手,我们建议保持简单并选择一个用于您的项目。

Related Posts