最初是为软件开发团队构思的, 敏捷现在是世界各地的行业和公司的首要项目管理方法. 它的吸引力在于它的简单性和灵活性:敏捷缺乏规定性的实践，这使得它具有很高的可采用率. 然而,, 在指导几家公司的敏捷转型时, 我发现这种灵活性也会导致对敏捷的误解. 许多公司优先考虑遵守 敏捷-derived框架 过度理解哲学本身.

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

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

敏捷的先例

二零零一年首次编制的“敏捷软件开发宣言,，简洁地概括了4项核心价值和12项原则, 激进的反应是线性的吗, 流程繁重的方法充斥着规则和大量文档. 但是敏捷的历史起源于几十年前的一种简化工业制造的方法.

哲学为其前身 专注于迭代改进，“计划-执行-研究-行动”模式应运而生 20世纪30年代 由贝尔实验室物理学家和统计学家沃尔特·休哈特提出. 二战结束后，他的门徒W. 爱德华兹·戴明，将其应用于丰田公司的经理培训. 这种方法是丰田生产系统发展的组成部分，而丰田生产系统是生产的主要来源 精益 思考与它有效的构建-测量-学习循环.

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

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

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

敏捷的理论价值——从这些前因后果中浮现出来——已经在我对敏捷的实践中得到了证实, 强调迭代开发, 合作的团队精神, 以及准确的估计.

什么是理论上的敏捷?

随着公司继续采用敏捷的工作方式, 他们冒着让它变得比哲学的制定者预想的更规范的风险. 根据我的经验, 希望采用敏捷的领导者过于关注框架——或者一组特定的实践及其相关的术语——而对价值和原则关注不够.

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

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

1. 个人和交互优先于过程和工具
2. 工作产品胜过全面的文档
3. 客户协作优先于合同谈判
4. 对变化做出反应，而不是遵循计划

宣言中这些原则之后的警告, 然而, 经常被忽视:“那是, 而右边的物品也有价值, 我们更看重左边的东西.“许多敏捷实践者最终忽视了右边的价值，而只关注左边的价值. 结果? 盲目地遵循重流程框架的反面:根本没有流程, 这同样是个问题.

在左边和右边的项目之间取得适当的平衡已经成为我指导敏捷转换的关键. 苹果的管理方法也体现了这一点, 谷歌, 亚马逊, 脸谱网, 和Netflix, 它们都没有订阅单一的敏捷框架. 他们已经 体现原则 首先是宣言, while following or changing parts of different frameworks based on what has worked best for them; as a result, 他们已经适应了市场的变化，能够快速推出新产品.

实践中的敏捷是什么?

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

在第一个值中, 我用“人”来代替“个人”，因为敏捷意味着以团队为导向. 至于第二点, 很明显，软件必须是“工作的”,“所以现在的重点是成功和及时的”交付.第三个价值就是“协作”,，因为它同样适用于一起工作的同事和与客户合作的团队. 最后, “框架”取代了“遵循计划”,，因为这预示着应该完全放弃计划的误解.

人重于流程

敏捷 转换 是否困难，主要是因为大多数企业都习惯于严格遵循流程. 使用特定的工具完成特定数量的步骤, 而不是开发创新产品, 成为最终目标.

看到这种心态催生了一个有利可图的“敏捷产业”，我感到很沮丧.正如敏捷的创始人Ward Cunningham和Jon Kern所说 解释在美国，许多企业出售他们声称将帮助公司“走向敏捷”的软件.“但是采用敏捷意味着采用一种哲学, 不使用软件，只按照软件规定的程序操作.

实现适当的平衡并不是要消除程序, 而是找到最能支持每个团队开发目标的方法. 为我的一个客户，一个大型企业技术组织，我实现了 训练有素的敏捷这是IBM开发的一种方法. 它结合了来自多个框架的许多实践，包括Scrum和看板. 它利用迭代开发，但比传统的敏捷更侧重于过程, 尤其是在开始阶段, 因为它的目的是填补Scrum留下的空白. 有纪律的敏捷对这个客户很有效，因为这个组织是非常面向过程的. 它使我能够与团队达成妥协，获得他们的支持，并说服他们采用一种新的方法 Scrum流程.

我加入了待办事项细化会议, 审查会议, 每天召开会议，促进团队内部和团队之间的协作. 待办事项的细化是 Scrum指南，但改进会议不是. 我添加这些内容是为了让大家能够健康地讨论为什么我们计划在即将到来的sprint中实现特定的功能, 哪些对敏捷新手有帮助. 我还选择了命名法里程碑——瀑布式项目管理中使用的术语——因为客户更熟悉这个术语. 评审和日常scrum交互是scrum指南中的常规元素, 但我让他们在日程安排上更有条理, 持续时间, 和流.

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

软件交付胜于文档

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

我目前正在与一家美国初创公司合作，并采用这种方法为 非功能性测试. 我们专注于创建MVP，所以我们现在只编写了所需的最小文档. 虽然这种方法对很多产品都有效, 它对加密货币和nft特别有用, 哪一个是新的, 实验范畴正在迅速变化. 而不是起草完整的规格和功能, 而且在发布之前还得反复修改, 我们可以将这些时间用于整合用户反馈，以加强我们的市场开发.

合作胜于合同

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

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

让管理层参与进来, 我请求他们让我带领一个小团队与一个小客户一起进行概念验证, 谁曾对开发时间过长表示担忧, 甚至在任何必要的改变使问题复杂化之前. 通过让这个客户直接与我们的产品负责人合作, 我们能够在开发过程中进行更改，并显著缩短交付时间.

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

框架的适应性

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

我向CEO和CTO提议实施Scrum, 他解释说，冲刺将迫使工程师们遵守纪律，并以两周为单位进行计划, 而不是决定每天做什么. 也, 我建议他们雇佣一个产品负责人, 怎样才能解决团队缺乏产品责任的问题. 我要求高管们给我三到四个月的时间和他们的团队一起工作，然后他们才能看到结果.

得到他们的认可, 我首先介绍了敏捷的价值和原则, 然后对团队进行产品待办事项列表的培训，以及安排待办事项列表的不同技术, 包括制作 史诗 和 用户故事，以及创建子任务. 我们在工作流程中包含的技术和会议是对传统Scrum的偏离，因为它们没有出现在Scrum指南中. 我把它们整合到计划中，因为史诗, 故事, 在培训期间，子任务与团队产生共鸣，会议促进了富有成效的讨论.

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

为 估计，我从 t恤分级, 一种将项目和任务衡量为小的技术, 媒介, large; as the team progressed, 我换成了 故事点一种更传统的评估技术. 故事点经常被不熟悉敏捷的团队误用, 谁试图把它们转换成工作时间或天数, 过分关注时间框架，并根据人们在最后期限前完成任务的能力来判断他们.

t恤的大小更抽象，使团队更容易避免这个陷阱. 然而，它也不那么精确. 因此，一旦团队了解了如何用相对术语进行估算, 我把它们转换成更复杂的技术.

到那时，团队已经完成了两次冲刺, 高级管理人员能够看到他们的员工工作更有效率，沟通更有效. 开发人员第一次与涉众和执行管理人员接触. 他们会见了客户支持团队，并了解了他们实现的功能如何改善了用户的生活.

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

敏捷的未来是什么?

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

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

敏捷教练, Scrum master, 项目经理应该回到哲学的根源，并像宣言的制定者所做的那样呈现它:一套灵活和动态的开发和交付指导方针. 他们应该教会高管和团队领导这一点, 他们可以从项目管理中获得灵感, 在敏捷中，他们并没有真正管理任何事情——他们只是在指导团队，让他们把工作做到最好.