Originally conceived for software development teams, 敏捷现在是世界各地的行业和公司的首要项目管理方法. 它的吸引力在于它的简单性和灵活性:敏捷缺乏规定性的实践，这使得它具有很高的可采用率. 然而,, when guiding 敏捷 转换 in several companies, 我发现这种灵活性也会导致对敏捷的误解. Many companies prioritize adhering to 敏捷-derived框架 over underst和ing the philosophy itself.

相反, 项目经理 组建和指导敏捷团队的教练应该从训练他们采用敏捷思维开始, 本质上内化哲学的核心价值和原则. Only then should they combine, 定制, 或者根据最能满足项目需求的方式从敏捷框架中省略实践.

通过追溯敏捷的历史发展，并将其创始原则与公司和团队的特定需求联系起来, 本文可以帮助项目经理为敏捷转换创造一个最佳的未来. As the following cases demonstrate, 敏捷不应该被严格地认为是一种项目管理方法, 而是一种在实践中不断发展的产品开发理念.

敏捷的先例

First compiled in 2001, the “Manifesto for 敏捷 Software Development,，简洁地概括了4项核心价值和12项原则, was a radical response to linear, 流程繁重的方法充斥着规则和大量文档. 但是敏捷的历史起源于几十年前的一种简化工业制造的方法.

An antecedent of the philosophy for its focus on iterative improvement, the Plan-Do-Study-Act model was developed 20世纪30年代 by Bell Labs physicist 和 statistician Walter Shewhart. After World War II, his protege, W. Edwards Deming, applied it to train managers at Toyota. 这种方法是丰田生产系统发展的组成部分，而丰田生产系统是生产的主要来源 精益 thinking with its efficient build-measure-learn loop.

在20世纪70年代，当Barry Boehm提出 宽带德尔福 技术, 使用迭代过程来准确客观地估计开发软件所需的劳动和时间.

随着20世纪80年代中期个人电脑的普及，它 很明显 软件作为一种产品和服务将成为人们做生意的基石. 当专业人士开始 认真关注 对增量, iterative approaches to software engineering, 敏捷方法超越了瀑布过程，成为更好的开发和管理方法.

研究人员 发现 那些比竞争对手创新更快的制造商正在采用多学科技术, 以团队为导向的方法，推动产品通过其生命周期. 这是 被广泛认为 正如Jeff Sutherl和在1993年发明Scrum框架的灵感一样 允许 他需要在预算内按时完成看似不可能完成的项目，尽量减少bug.

敏捷的理论价值——从这些前因后果中浮现出来——已经在我对敏捷的实践中得到了证实, with an emphasis on iterative development, 合作的团队精神, 以及准确的估计.

什么是理论上的敏捷?

As companies continue to adopt 敏捷 ways of working, 他们冒着让它变得比哲学的制定者预想的更规范的风险. 根据我的经验, 希望采用敏捷的领导者过于关注框架——或者一组特定的实践及其相关的术语——而对价值和原则关注不够.

正如在传授敏捷原则方面很有经验的实践者所知道的那样, 每个寻求进行敏捷转型的组织都必须找到并适应适合他们的方法. 通过向团队展示如何遵循宣言的价值观和原则，然后从框架中汲取灵感，我促进了这个学习过程, 如 Scrum, 看板, 极限编程(XP), to implement them in practice.

宣言的原则现在已经成为敏捷项目经理的第二天性:

1. Individuals 和 interactions over processes 和 tools
2. Working products over comprehensive 文档
3. Customer 协作 over contract negotiation
4. Responding to change over following a plan

The caveat that follows these tenets in the manifesto, 然而, often gets overlooked: “That is, while there is value in the items on the right, we value the items on the left more.“许多敏捷实践者最终忽视了右边的价值，而只关注左边的价值. 结果? 盲目地遵循重流程框架的反面:根本没有流程, which is equally problematic.

在左边和右边的项目之间取得适当的平衡已经成为我指导敏捷转换的关键. 苹果的管理方法也体现了这一点, 谷歌, 亚马逊, 脸谱网, 和Netflix, none of which have subscribed to a singular 敏捷 framework. 他们已经 体现原则 of the manifesto first 和 foremost, while following or changing parts of different frameworks based on what has worked best for them; as a result, 他们已经适应了市场的变化，能够快速推出新产品.

实践中的敏捷是什么?

在下面的概述中，我修改了宣言价值观的原始措辞. 语义的变化有助于澄清我在实践中如何应用敏捷价值观.

在第一个值中, 我用“人”来代替“个人”，因为敏捷意味着以团队为导向. 至于第二点, it’s obvious that software has to be “working,” so the focus is now on successful 和 timely “delivery.” The third value is simply “协作,，因为它同样适用于一起工作的同事和与客户合作的团队. 最后, “frameworks” replaces “following a plan,，因为这预示着应该完全放弃计划的误解.

人重于流程

敏捷 转换 是否困难，主要是因为大多数企业都习惯于严格遵循流程. 使用特定的工具完成特定数量的步骤, instead of developing an innovative product, 成为最终目标.

看到这种心态催生了一个有利可图的“敏捷产业”，我感到很沮丧.” As 敏捷 发现ers Ward Cunningham 和 Jon Kern 解释在美国，许多企业出售他们声称将帮助公司“走向敏捷”的软件.” But going 敏捷 means adopting a philosophy, not using software 和 following the program it prescribes.

实现适当的平衡并不是要消除程序, 而是找到最能支持每个团队开发目标的方法. 为我的一个客户，一个大型企业技术组织，我实现了 训练有素的敏捷, an approach developed at IBM. 它结合了来自多个框架的许多实践，包括Scrum和看板. 它利用迭代开发，但比传统的敏捷更侧重于过程, especially in the beginning phase, because it’s intended to fill gaps left by Scrum. 有纪律的敏捷对这个客户很有效，因为这个组织是非常面向过程的. 它使我能够与团队达成妥协，获得他们的支持，并说服他们采用一种新的方法 Scrum流程.

I incorporated backlog refinement meetings, 审查会议, 每天召开会议，促进团队内部和团队之间的协作. Backlog refinement is part of the Scrum指南, but refinement meetings are not. 我添加这些内容是为了让大家能够健康地讨论为什么我们计划在即将到来的sprint中实现特定的功能, which is helpful for 敏捷 novices. I also chose the nomenclature “里程碑——瀑布式项目管理中使用的术语——因为客户更熟悉这个术语. 评审和日常scrum交互是scrum指南中的常规元素, but I made them more structured in terms of the schedule, 持续时间, 和流.

另外, 然而，严格遵守Scrum会让每个人完全专注于Scrum指南中列出的一个角色, 在我客户的团队中，有些人的技能并不完全适合一个角色. 使用有纪律的敏捷方法允许我在多个团队成员之间划分这些职位的职责，并创建一个发挥相关人员优势的过程.

Software Delivery Over Documentation

我更喜欢定制的Scrum或看板工作流，而不是严格遵守任何一个框架的另一个原因是，它们让我有机会将最小可行产品(MVP)作为目标添加到计划中. 源自精益, 创建MVP的实践与迭代开发是一致的，并且已经成为敏捷实践者中流行的技术. 它允许团队有效地向用户交付高质量的软件和其他产品，然后根据反馈对其进行改进. 将它作为主要基于Scrum或看板的混合方法的一部分来应用，增强了我的团队创建满足客户需求的产品的能力.

我目前正在与一家美国初创公司合作，并采用这种方法为 非功能性测试. 我们专注于创建MVP，所以我们现在只编写了所需的最小文档. 虽然这种方法对很多产品都有效, it’s especially useful for cryptocurrency 和 非功能性测试, 哪一个是新的, experimental category that’s changing quickly. Instead of drafting complete specs 和 features, having to change them repeatedly before the release, 我们可以将这些时间用于整合用户反馈，以加强我们的市场开发.

合作胜于合同

前面提到的大型企业技术组织严重依赖于许多固定成本项目的合同. 合同概述了他们完成这项工作的方法, 以及负责每项任务的具体人员. 合同一旦签署，就必须经过漫长的请求过程才能更改.

在我领导的转变中，合作优先于这些僵化的协议. 我们实施的计划用一页纸的文件取代了合同. 每个人都表示，我们同意使用敏捷与我们的客户进行协作, 以及我们的队友和来自不同团队的同事——在指定的开始和结束日期之间. Whatever came out of the 协作 would be the result. 我没有详细说明成品可能是什么. 因为我们正在征求客户的反馈，并将其纳入我们的产品开发, 从我们的计划文档中删除规范使我们更容易接受他们的反应，并激励他们更积极地与我们合作.

让管理层参与进来, 我请求他们让我带领一个小团队与一个小客户一起进行概念验证, 谁曾对开发时间过长表示担忧, even before any required changes compounded the issue. 通过让这个客户直接与我们的产品负责人合作, 我们能够在开发过程中进行更改，并显著缩短交付时间.

这些结果说服了管理层让我把这个计划推广到更多的团队. 整体, 精简的合同和我们的敏捷工作流程减少了开发和将产品特性推向市场所需的时间.

框架的适应性

我的另一个客户, 一家健康科技公司, 也未能在认识到敏捷价值的两个方面的重要性方面取得平衡, namely responding to change over following a plan. 在这种情况下, 然而, 它犯了与我的企业技术客户所犯的错误相反的错误:没有过于严格地遵循流程, 它过分强调灵活性，而在很大程度上忽视了过程. 工程师们很少知道他们应该做什么，因为没有优先级或时间表. 他们每天都在浪费时间和生产力，在更重要的任务之前完成不那么重要的任务.

I proposed the implementation of Scrum to the CEO 和 CTO, 他解释说，冲刺将迫使工程师们遵守纪律，并以两周为单位进行计划, as opposed to deciding what to work on every day. 也, I advised that they hire a product owner, which would fix the team’s lack of product accountability. 我要求高管们给我三到四个月的时间和他们的团队一起工作，然后他们才能看到结果.

Having gotten their approval, I first introduced 敏捷 values 和 principles, 然后对团队进行产品待办事项列表的培训，以及安排待办事项列表的不同技术, 包括制作 史诗 和 用户故事，以及创建子任务. 我们在工作流程中包含的技术和会议是对传统Scrum的偏离，因为它们没有出现在Scrum指南中. I integrated them into the plan because the 史诗, 故事, 在培训期间，子任务与团队产生共鸣，会议促进了富有成效的讨论.

I also included the concept of velocity, 这是XP的一个后期添加，它测量每个产品迭代中所有用户情景的总工作量估计. 然而, 我用了“容量”这个词,我更喜欢这个说法，因为它强调团队成员能完成多少工作，而不是他们完成任务的速度有多快.

为 估计，我从 t恤分级, a 技术 that measures projects 和 tasks as small, 媒介, large; as the team progressed, 我换成了 故事点, a more traditional 估计 技术. 故事点经常被不熟悉敏捷的团队误用, who try to convert them into work hours or days, 过分关注时间框架，并根据人们在最后期限前完成任务的能力来判断他们.

t恤的大小更抽象，使团队更容易避免这个陷阱. 然而, it’s also less precise. 因此，一旦团队了解了如何用相对术语进行估算, I transitioned them to the more sophisticated 技术.

By the time the team had completed two sprints, 高级管理人员能够看到他们的员工工作更有效率，沟通更有效. 开发人员第一次与涉众和执行管理人员接触. 他们会见了客户支持团队，并了解了他们实现的功能如何改善了用户的生活.

这种方法很快提高了公司软件的质量，并将新功能的交付时间从几个月缩短到几周.

敏捷的未来是什么?

2019冠状病毒病大流行造成了一个新的现实，即团队无法再共处一处, 在构思敏捷时，哪种方式是首选的工作方式. 然而, 认为它必须保持这种状态的想法是一个神话:随着远程工作变得司空见惯, 很明显，视频会议软件完全可以实现密切的交流. 我现在工作的团队是完全分散的，我远程提供培训. 有些团队甚至选择异步工作，使用诸如 概念 和 织机, as well as Slack plugins like 站立会议.

协作的分布式模型是新的工作世界，其核心是敏捷性. 为远程团队提供的工作与生活平衡对士气和心理健康有积极影响, which boosts productivity 和 quality; it puts people over processes 和 is flexible 和 adaptable, making it quintessentially 敏捷.

敏捷教练, Scrum master, 项目经理应该回到哲学的根源，并像宣言的制定者所做的那样呈现它:一套灵活和动态的开发和交付指导方针. They should teach executives 和 team leaders that, while they can take inspiration from project management, 在敏捷中，他们并没有真正管理任何事情——他们只是在指导团队，让他们把工作做到最好.