敏捷原则:适应性项目管理的12个关键

敏捷原则:适应性项目管理的12个关键

适应性项目管理——也被称为敏捷……如果你想要理解它,就回到最开始。首先是敏捷宣言:一份意图声明和四种信念。然后是12条敏捷原则。

正是这些敏捷原则告诉我们敏捷到底是什么,以及如何进行适应性项目管理。

因此,在本文中,让我们看看12条敏捷原则,看看它们是如何指导我们的。我们也会用适应性项目的原则来测试良好项目管理的更广泛的原则。

敏捷原则:适应性项目管理的12个关键

我们将在本文中回答的问题

人们很容易直接进入敏捷项目管理的12条原则。但我们需要先设置一些背景。如果您了解上下文,可以使用下面的链接跳到前面。下面是我要回答的五个问题:

什么是敏捷项目管理?

敏捷是一种交付新产品的思考方式。因此,有许多我们可以描述为“敏捷”的项目管理方法。但是,更好的描述可能是“适应性”。

敏捷方法适应业务和客户的需求,特别是适应它们如何随着时间的推移而发展。嵌入在敏捷方法中的是增量开发和迭代细化。因此,敏捷项目管理避免了死板的计划,并强烈强调成本和进度管理。

敏捷联盟有一个很好的定义:

创造和应对变化的能力,以便在不确定和动荡的环境中取得成功。

敏捷联盟:什么是敏捷?

因此,敏捷最适合那些存在高度不确定性的项目。因为敏捷方法似乎促进了更大程度的创造力和创新。

更多的传统。计划项目管理方法在我们看到更高水平的熟悉度和确定性的地方蓬勃发展。因此,定义、计划、主动成本和进度管理是实现控制和可预测性的最佳方法。

关于适应性(敏捷)和预测性(传统或“瀑布式”)项目管理的区别和适用性,请参阅我们的文章,“敏捷vs瀑布:哪个适合你的项目?””

为什么敏捷项目管理变得如此重要?

正如我上面所说的,敏捷最适合高不确定性的情况。当今世界的不确定性、模糊性和复杂性要高得多。

这一切都需要更大的灵活性和适应性。敏捷方法提供了这一点。事实上,随着基于软件的互联网初创企业的兴起,我们已经看到敏捷开发成为大量新业务诞生和增长的核心,而这些新业务的创始人从来没有指望准确预测客户的需求和需求。

因此,敏捷使我们能够适应对客户需求的不断理解——以及他们不断变化的需求。而且它不需要太多的返工。

但关键是,敏捷主义者声称它比传统方法更强调最终用户或客户。我要反驳这一点,并建议传统的项目经理,当我们做好我们的工作时,对客户的需求和愿望给予同等的重视。对我来说,不同之处在于,当它们发生变化时,我能够快速而廉价地做出反应,变得敏捷。

敏捷项目项目管理是如何开始的?

这个问题很重要。因为敏捷的12条原则很早就出现了,是敏捷项目管理起源故事的一部分。

在20世纪90年代早期,软件开发经历了一些评论家所说的“应用程序开发危机”。事实上,这是对新应用程序交付滞后的认识。投入使用的时间太长了。一些专家估计,从组织认识到需求到拥有应用程序的工作生产版本之间的时间大约为3年。

我记得我的软件工程同事在20世纪90年代中期谈论RAD:快速应用程序开发。这只是工程师们创建的许多软件开发方法中的一种,以加快新软件的创建。以下是部分列表:

  • 快速应用程序开发(RAD)
  • Rational统一过程(RUP)
  • 水晶
  • 极限编程(XP)
  • 动态系统开发方法(DSDM
  • Scrum
  • 特性驱动开发(FDD)

17人……

2001年,十七个软件开发人员开会讨论这些轻量级软件开发方法:

  1. Kent Beck
  2. 迈克比
  3. Arie van Bennekum
  4. Alistair Cockburn
  5. Ward Cunningham
  6. 马丁
  7. 詹姆斯Grenning
  8. Jim Highsmith
  9. 安德鲁•亨特
  10. Ron Jeffries
  11. 乔恩·克恩
  12. Brian Marick
  13. 罗伯特·c·马丁
  14. 史蒂夫Mellor
  15. Ken Schwaber
  16. Jeff Sutherland
  17. 戴夫·托马斯。

会议的结果是,他们发表了敏捷软件开发宣言

敏捷宣言

这是他们发表的宣言:

敏捷软件开发宣言

我们正在通过自己做和帮助别人做来发现更好的软件开发方法。通过这项工作,我们得到了以下价值:

  • 个人和互动超越过程和工具
  • 工作软件文档过于全面
  • 客户协作关于合同谈判
  • 响应变化按照计划行事

也就是说,虽然右边的项目有价值,但我们更看重左边的项目。

©2001,上面列出的作者AgileManifesto.org
本声明可以任何形式自由复制,
但只有通过这份通知才能完整体现。

我已经在我们的文章中讨论了每个要点的解释,“敏捷vs瀑布:哪个适合你的项目?””

几年后,在2005年,其中两个人召集了另一个小组,阐述了敏捷宣言背后的12条原则。

敏捷的12条原则是什么?

下面是12条敏捷原则,它们是敏捷宣言的基础AgileManifesto.org

  1. 我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。
  2. 欢迎需求的变化,即使是在开发的后期。敏捷过程利用变化来获得客户的竞争优势。
  3. 频繁地交付可工作的软件,从几周到几个月不等,优先考虑较短的时间尺度。
  4. 业务人员和开发人员必须在整个项目中每天一起工作。
  5. 围绕积极的个人建立项目。给他们所需的环境和支持,相信他们能完成工作。
  6. 向开发团队传递信息的最有效的方法是面对面的对话。
  7. 工作软件是进度的主要度量。
  8. 敏捷过程促进可持续开发。发起人、开发人员和用户应该能够无限期地保持恒定的步调。
  9. 持续关注卓越的技术和良好的设计可以增强敏捷性。
  10. 简单——最大化未完成工作量的艺术——是必不可少的。
  11. 最好的体系结构、需求和设计来自自组织的团队。
  12. 每隔一段时间,团队就会思考如何变得更有效,然后相应地调整自己的行为。

我们将依次研究这些敏捷原则,以理解它的含义,以及它如何适应更广泛的项目管理概念。

敏捷的12条原则

顾客满意第一

我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。

敏捷宣言背后的原则

客户和用户现在就想要他们的软件。或者,现实地说,越快越好。因此,敏捷方法需要实现针对交付速度进行优化的过程。如果那是顾客想要的,那就是他们应该得到的。

但我不同意这样的说法,即客户总是希望尽早和持续交货。对我来说,我更喜欢关注前8个词:“我们的首要任务是让客户满意”.太多的敏捷者关注交付的速度。

这里有两个原则似乎是近乎普遍的:

  1. 专注于交付价值
  2. 把客户/利益相关者放在第一位

欢迎变更需求

欢迎需求的变化,即使是在开发的后期。敏捷过程利用变化来获得客户的竞争优势。

敏捷宣言背后的原则

敏捷原则有两个重要方面。首先是认识到,在一个不稳定的、不确定的、复杂的和模糊的(VUCA)世界中,驱动竞争优势所需要的东西可能会在开发周期中发生变化——也许经常发生变化。这表明在过去的30到40年里,变化的速度在数量上有所增长。

但这只是一个f度的问题。更重要的方面是敏捷方法将不断变化的需求构建到其过程的核心。这与大多数传统项目过程所采用的方法不同变更控制作为一个“螺栓连接”过程。

适应和响应变化的能力一直是项目管理的基本原则。但我确实认为它现在更重要了,敏捷原则正确地把它带到了前台。我希望它能在新项目管理知识体系指南第七版

频繁交付

频繁地交付可工作的软件,从几周到几个月不等,优先考虑较短的时间尺度。

敏捷宣言背后的原则

频繁的增量意味着快速的反馈,这意味着快速的补救和最小的返工。这是一条合理的生活原则。工业界似乎已经把这一点放在了心上。迭代或“冲刺”周期正在减少,每周发布的情况也不再罕见。

PRINCE2是预测性项目管理的堡垒,它的第二条原则是“从经验中学习”。快速周转为更多和更快的学习提供了机会。

然而,很容易将这一原则讽刺为与传统项目管理思维的对立面。它不是。早在20世纪90年代中期,我交付的项目经常出现可交付成果的丢失。我在培训新的项目经理做同样的事情。

商业与发展合作

业务人员和开发人员必须在整个项目中每天一起工作。

敏捷宣言背后的原则

这一点不是很明显吗?嗯,的确如此。但是在传统的高范围和计划的软件项目中,软件工程师和业务人员很少彼此交谈。他们说的语言不同。因此,企业、咨询公司和开发人员雇佣了被称为业务分析师的翻译人员,他们会说足够多的“业务语言”来准确地收集需求,也会说足够多的“系统语言”来将它们翻译成技术语言。

敏捷开发的第二个原则强调良好的沟通和涉众参与。许多项目经理早在敏捷宣言之前就应用了这一原则。

激励的个人是项目的核心

围绕积极的个人建立项目。给他们所需的环境和支持,相信他们能完成工作。

敏捷宣言背后的原则

在我看来,这个原则可能是由一些糟糕的经历驱动的。你觉得你没必要这么说。但是,作为一个基本原则,它必须是健全的。怎么可能不是呢?

但是,除了提倡管理士气和提供资源,它还告诉我,我们需要招募想要在那里工作的人。这让我想起了一个熟悉的建议:

招聘要看态度,培训要看技能。

很容易让人失去动力的一件事就是不确定别人对我们的期望是什么。PRINCE2的七大原则之一是,“明确的角色和责任”.我们应该激励和支持我们的团队成员的原则适用于所有环境。

面对面是最主要的沟通方式

向开发团队传递信息的最有效的方法是面对面的对话。

敏捷宣言背后的原则

如果电子邮件是人类已知的最糟糕的沟通方式(我相信在未来的创新中它是),那么用共享语言进行面对面的交谈就是黄金标准。这是另一个专注于沟通的原则。很多人,比如我自己,都同意这一点“项目管理80%是沟通”

许多开发和项目团队所面临的挑战是他们不再是同一地点的。视频通话等技术解决方案和Slack等即时通讯应用程序可以填补这些漏洞。但它们永远不会胜过开发团队或工作流团队在一个大房间里一起工作。

与其说这是一个项目管理的一般原则,不如说这是一个关于人类社会互动的一般陈述!

工作软件是进度的主要度量

工作软件是进度的主要度量。

敏捷宣言背后的原则

每个项目经理都需要衡量进度。有一些简单的度量(比如里程碑和产品交付)。还有更微妙和复杂的方法,比如挣值分析.但是,对于敏捷实践者来说,敏捷原则的主要衡量标准是交付工作软件。

所以,这是项目管理中一般原则的一个特例。总的原则是衡量进度,并找到一个合适的衡量方法(如果必要的话可以使用代理方法)。在这里,我们看到一种特殊的措施出现了。PRINCE2也有类似的原则:“专注产品”

我还认为,关注价值交付的一般原则与此相关。在软件项目中,它是团队交付给客户的具有价值的工作软件。

事实上,我们可以更进一步。直到交付工作软件,开发工作才算完成。未发布的软件不是资产,所以它一定是负债。你可以把它想象成库存。库存是企业的一项成本;不是一个正的资产。

以可持续发展为目标

敏捷过程促进可持续开发。发起人、开发人员和用户应该能够无限期地保持恒定的步调。

敏捷宣言背后的原则

敏捷哲学和传统计划项目之间有一个真正的区别。计划的项目有截止日期和里程碑。他们有交接和上线日期。你是大事件,造成一定的压力,匆忙,密集的工作,甚至压力。

敏捷原则结合了频繁交付原则来解决这个问题。或者,至少,试着去做。相反,敏捷的目标是创造一个短周期的工作压力。我不怀疑在一个周期或冲刺的最后冲刺的现实。但其目标是使不断改进和更多功能的增量开发成为现实。这样做不会让团队处于高压时期,也不会有压力和疲劳的风险。

这是一个不可思议的原则,在一般项目管理中找不到相应的原则。但这是应该的。应该要求项目经理建立流程,允许他们的团队从开始到结束在一个合理的水平上持续努力。当然,我们当中最优秀的人会努力实现这一点。

持续关注重要的事情

持续关注卓越的技术和良好的设计可以增强敏捷性。

敏捷宣言背后的原则

是不是只有我这么认为,或者这似乎与这12条敏捷原则中的第一条有些冲突?如果你还记得,那就是说我们的首要任务是通过尽早、持续地交付有价值的软件来满足客户。

如果你按照我的建议去做,只要记住原则的前八个字,就没有冲突。因此,本着同样的精神,我把我对这一原则的解释作为“持续关注重要的事情”.你无法优化时间而且质量,没有空白支票的预算。

但是,你知道吗?我认为卓越的技术和优秀的设计总是很重要的。它们还增强了敏捷性,因为它们允许对解决方案进行必要的修改或添加,而不需要覆盖不合理的数量。

这里的一般原则是关于

  1. 的重要性质量管理,并将其构建到您的核心项目过程中
  2. 平衡时间、成本和质量。

保持简单

简单——最大化未完成工作量的艺术——是必不可少的。

敏捷宣言背后的原则

如果“保持简单”不是项目管理(和生活)的普遍原则,那么什么是?

这一点不需要解释,但我想到了我们的两个视频,这将帮助你理解这一点:

创建自组织团队

最好的体系结构、需求和设计来自自组织的团队。

敏捷宣言背后的原则

在敏捷项目中,项目经理的角色是什么?当然,答案取决于您选择的敏捷方法。但是有些没有明确的项目经理角色。敏捷原则解释了其中的原因。

敏捷更喜欢自组织的团队。在这里,一个积极的团队可以安排自己的工作。任何一个明确的领导者的角色都是一个辅助角色仆人领袖

这在许多一般项目管理原则的陈述中找不到现成的对等物。虽然创造一个支持性的文化,让团队成员可以为自己的工作负责,显然总是存在的。

花时间反思

每隔一段时间,团队就会思考如何变得更有效,然后相应地调整自己的行为。

敏捷宣言背后的原则

我喜欢这个。作为专业人士,反思是我们成长智慧的主要机制。它让我们远离从聪明到聪明.敏捷方法通常有明确的方法来促进在其过程中嵌入反射。

所有的项目管理方法都强调学习和经验教训会议

敏捷原则是如何与它的工具和技术联系在一起的?

我非常相信学习和做事的“工具方法”。也就是说,我们了解的工具越多,我们的灵活性、适应性和敏捷性就越强。当我们有更多的工具可以使用时,我们可以成为更有效的专业人员。在这方面,我们与木工、水管工和外科医生没有什么不同。

因此,对我来说,敏捷对我们这个行业(以及我们的crad=ft)最大的贡献在于它的实践者创造了许多新工具。通常,这些都是为12条敏捷原则中的一个或多个服务的。

以下是我最喜欢的,按字母顺序排列。

  • 验收测试驱动开发(ATDD)
    这强调了验收测试—业务客户、用户、开发人员和测试人员之间的协作—其中满足用户和客户预先定义的标准是成功的衡量标准。
  • 积压(产品和Sprint)
    一个过程,它收集所有尚未筛选和计划的内容,为优先级排序做好准备。
  • 行为驱动开发(BDD)
    这个开发过程关注的是用户做了什么,而不是他们说他们会做什么,或者他们认为他们想要什么。
  • 跨职能团队
    这并不是敏捷过程所独有的。但他们确实强调了这一点,而且这是一种将多样性嵌入工作流程的有价值的方式,从而增强解决问题的能力,并使决策变得更加稳健。
  • 每日站立/每日Scrum
    定期召开简短会议,加强沟通、问责和协作。
  • 迭代和增量开发
    敏捷适应性的核心是一步一步(渐进式)改进工作产品(迭代)的方法。
  • 规划扑克
    估计是项目管理中最难的学科之一。我们已经完成了一篇关于它的完整文章.“规划扑克”(Planning Poker)是另一种方法,通过汇集团队的经验和评估,可以对任务的规模进行广泛衡量。在这个短视频中了解更多,回答“什么是策划扑克?””
  • 回顾
    回顾是回顾经验、反思它们并从过程中学习的一种特殊方法。
  • 举例说明
    这提供了一种通过参考交互示例来指定用户需求的方法。
  • 限定
    这是一个在个人时间管理方面很有效的方法,它可以有效地应用于更广泛的项目管理,而不仅仅是敏捷项目。给定的任务可以给一个严格的完成点和适应它的范围和质量。
  • 用户故事
    这是另一个项目定义方法。它采用叙述的方法来定义用户的功能需求

我最近在Hubstaff Teams网站上找到了一个很有价值的资源。要查看完整的敏捷术语表,请查看:

了解更多关于敏捷项目管理的原则和实践…

我们在这个网站上有很多资源可以帮助您了解更多关于敏捷项目管理的知识。我们还为您提供一系列详细的课程。要想对所有这些方法进行结构化的介绍,请看我们的敏捷路线图:

manbetx3.0app

您在敏捷项目管理和敏捷12原则方面有什么经验?

我总是对你的经历、意见和问题感兴趣。请在下方留言,我一定会回复的。

关于作者迈克·克莱顿

Mike Clayton博士是英国最成功和最受欢迎的项目管理培训师之一。他是14本畅销书的作者,其中包括4本关于项目管理的书。他还是一个多产的博主,为ProjectManager.com和Project(项目管理协会杂志)撰稿。从1990年到2002年,Mike是一名成功的项目经理,领导大型项目团队并交付复杂的项目。2016年,Mike推出了在线视频课程。

跟我来吧:
>
Baidu
map