最初是为软件开发团队构思的, 敏捷现在是世界各地的行业和公司的首要项目管理方法. The appeal lies in its simplicity 和 flexibility: 敏捷’s lack of prescriptive practices makes it highly adoptable. 然而,, 在指导几家公司的敏捷转型时, 我发现这种灵活性也会导致对敏捷的误解. 许多公司优先考虑遵守 敏捷-derived框架 过度理解哲学本身.

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

By tracing 敏捷’s historical development 和 tying its 发现ing principles to the specific needs of companies 和 teams, 本文可以帮助项目经理为敏捷转换创造一个最佳的未来. 如下面的案例所示, 敏捷不应该被严格地认为是一种项目管理方法, 而是一种在实践中不断发展的产品开发理念.

敏捷的先例

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

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

在20世纪70年代，当Barry Boehm提出 宽带德尔福 技术, using an iterative process to accurately 和 objectively estimate the labor 和 time required to develop software.

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

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

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

什么是理论上的敏捷?

随着公司继续采用敏捷的工作方式, 他们冒着让它变得比哲学的制定者预想的更规范的风险. 根据我的经验, leaders wishing to adopt 敏捷 focus too much on the frameworks—or sets of specific practices 和 their associated nomenclature—和 not enough on the values 和 principles.

正如在传授敏捷原则方面很有经验的实践者所知道的那样, 每个寻求进行敏捷转型的组织都必须找到并适应适合他们的方法. I facilitate this learning process by showing teams how to follow the values 和 principles of the manifesto 和 then drawing inspiration from the frameworks, 如 Scrum, 看板, 极限编程(XP)，以便在实践中加以实施.

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

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

宣言中这些原则之后的警告, 然而, 经常被忽视:“那是, 而右边的物品也有价值, 我们更看重左边的东西.” Many 敏捷 practitioners end up disregarding the values on the right 和 focusing only on what’s on the left. 结果? 盲目地遵循重流程框架的反面:根本没有流程, 这同样是个问题.

Striking the proper balance between the items on the right 和 left has become the key to how I guide 敏捷 转换. 苹果的管理方法也体现了这一点, 谷歌, 亚马逊, 脸谱网, 和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指南，但改进会议不是. I added these to enable healthy conversation about why we planned to implement specific features in upcoming sprints, 哪些对敏捷新手有帮助. 我还选择了命名法里程碑——瀑布式项目管理中使用的术语——因为客户更熟悉这个术语. 评审和日常scrum交互是scrum指南中的常规元素, 但我让他们在日程安排上更有条理, 持续时间, 和流.

另外, whereas a strict adherence to Scrum would have each person fully dedicated to one of the roles listed in the Scrum指南, 在我客户的团队中，有些人的技能并不完全适合一个角色. Using the 训练有素的敏捷 method 允许 me to divide the responsibilities of these positions among multiple team members 和 create a process that played to the strengths of the people involved.

软件交付胜于文档

Another reason I prefer 定制d Scrum or 看板 workflows over strict compliance with any one framework is that they give me the opportunity to add the minimum viable product (MVP) into the plan as an objective. 源自精益, the practice of creating an MVP is consistent with iterative development 和 has become a popular 技术 among 敏捷 practitioners. It allows a team to deliver high-quality software 和 other goods to users efficiently 和 then refine them based on feedback. Applying it as part of a hybrid approach largely based on Scrum or 看板 has enhanced my teams’ abilities to create products that meet customers’ needs.

I’m currently working with a US-based startup 和 employing this method in building a cryptocurrency marketplace for 非功能性测试. 我们专注于创建MVP，所以我们现在只编写了所需的最小文档. 虽然这种方法对很多产品都有效, 它对加密货币和nft特别有用, 哪一个是新的, 实验范畴正在迅速变化. 而不是起草完整的规格和功能, 而且在发布之前还得反复修改, 我们可以将这些时间用于整合用户反馈，以加强我们的市场开发.

合作胜于合同

The aforementioned large enterprise tech organization relied heavily on 合同 for a lot of fixed-cost projects. 合同概述了他们完成这项工作的方法, 以及负责每项任务的具体人员. 合同一旦签署，就必须经过漫长的请求过程才能更改.

在我领导的转变中，合作优先于这些僵化的协议. 我们实施的计划用一页纸的文件取代了合同. 每个人都表示，我们同意使用敏捷与我们的客户进行协作, 以及我们的队友和来自不同团队的同事——在指定的开始和结束日期之间. 合作的结果就是结果. 我没有详细说明成品可能是什么. 因为我们正在征求客户的反馈，并将其纳入我们的产品开发, removing specifications from our plan document made us more receptive to their responses 和 incentivized them to work with us more actively.

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

这些结果说服了管理层让我把这个计划推广到更多的团队. 整体, the streamlined contract 和 our 敏捷 workflow decreased the time required to develop 和 take product features to market.

框架的适应性

我的另一个客户, 一家健康科技公司, 也未能在认识到敏捷价值的两个方面的重要性方面取得平衡, 也就是对变化做出反应，而不是遵循计划. 在这种情况下, 然而, it had made the opposite of the mistake my enterprise tech client had: Instead of following a process too rigidly, 它过分强调灵活性，而在很大程度上忽视了过程. 工程师们很少知道他们应该做什么，因为没有优先级或时间表. They lost time 和 productivity trying to figure that out each day 和 completed less-important tasks before more crucial ones.

我向CEO和CTO提议实施Scrum, 他解释说，冲刺将迫使工程师们遵守纪律，并以两周为单位进行计划, 而不是决定每天做什么. 也, 我建议他们雇佣一个产品负责人, 怎样才能解决团队缺乏产品责任的问题. I asked the executives to give me three or four months to work with their teams before they could expect to see results.

得到他们的认可, 我首先介绍了敏捷的价值和原则, 然后对团队进行产品待办事项列表的培训，以及安排待办事项列表的不同技术, 包括制作 史诗 和 用户故事，以及创建子任务. The 技术s 和 meetings that we included in our workflow are deviations from traditional Scrum in that they do not appear in the Scrum指南. 我把它们整合到计划中，因为史诗, 故事, 在培训期间，子任务与团队产生共鸣，会议促进了富有成效的讨论.

我还加入了速度的概念, a late addition to XP that measures the total-of-effort estimates for all 用户故事 in each product iteration. 然而, 我用了“容量”这个词,” which I prefer because it emphasizes how much work team members can pick up rather than how fast they can complete tasks.

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

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

到那时，团队已经完成了两次冲刺, senior management was able to see their employees working more productively 和 communicating more effectively. 开发人员第一次与涉众和执行管理人员接触. They had met the customer support team 和 had gained an underst和ing of how the features they’d implemented were improving users’ lives.

This approach soon led to an increase in the quality of the company’s software 和 a reduction in delivery time for new features from months to weeks.

敏捷的未来是什么?

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

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

敏捷教练, Scrum master, 项目经理 should return to the philosophy’s roots 和 present it as the manifesto’s framers did: a flexible 和 dynamic set of development 和 delivery guidelines. 他们应该教会高管和团队领导这一点, 他们可以从项目管理中获得灵感, 在敏捷中，他们并没有真正管理任何事情——他们只是在指导团队，让他们把工作做到最好.