什么是敏捷方法论？现代软件开发的解释
每个人都在谈论敏捷开发，但它到底是如何运作的？了解团队如何使用scrum、kanban和其他流行的敏捷方法论进行协作。
目录
很难相信，敏捷方法论在去年正式成立了20年。曾经是初创公司在办公场所用便签和白板进行协作的外围实践，现在已经成为一套成熟的、可扩展的、广泛使用的敏捷软件开发流程和工具。
敏捷开发背后有着丰富的历史，以及为什么企业要使用敏捷方法，如scrum和kanban来实现应用程序的现代化，改善客户体验，并实施数字化转型。围绕着这些方法以及它们与设计思维、产品管理和Devops的交集，也有大量的知识。如今，越来越少的人问 "什么是敏捷"？更多的人在寻求指导，如何将他们的团队置于敏捷的最佳实践中。
本文从人员、团队、流程和工具入手，对敏捷方法论进行了介绍。你还会了解到敏捷与devops的联系，以及帮助组织培养敏捷文化和交付更好的软件的最佳实践。
敏捷方法论中的角色
敏捷软件开发过程总是从定义特定产品的用户开始，并为需要解决的问题、机会和价值的范围记录一个愿景声明。产品拥有者抓住这个愿景，并与一个多学科的团队（或多个团队）一起工作来实现它。敏捷开发过程中，有几个角色参与其中。
用户
敏捷过程总是以用户或客户为出发点。今天，我们经常定义用户角色来说明不同的工作流程角色或客户需求和行为的类型。
产品所有者
产品所有者的任务是成为客户的代言人，包括任何内部利益相关者。这个人提炼出洞察力、想法和反馈来创造一个产品愿景。产品愿景通常是简短而直接的，但它们还是描绘出了谁是客户或用户，正在解决什么价值，以及解决这些价值的策略。我想象谷歌最初的愿景是这样的："让我们通过一个简单的、以关键词为导向的界面和一种在搜索结果中排名靠前的算法，使任何能上网的人都能轻松找到相关的网站和网页。"
无论愿景是什么，产品所有者负责定义它，然后与开发团队合作，使其成为现实。
为了与开发团队合作，产品负责人将产品愿景分解为一系列的用户故事。每个用户故事都应该确定目标用户，他们的挑战，为什么需要这个解决方案，以及什么约束和验收标准来定义这个解决方案。产品负责人对这些用户故事进行优先排序，并与团队一起审查，以确保他们对要求他们做的事情有共同的理解。
软件开发团队
团队应该是多学科的，包括具有完成工作所需技能和背景的不同群体。除了开发人员，敏捷开发团队还应该包括质量保证自动化工程师、数据工程师、用户体验（UX）设计师，以及其他角色，具体取决于软件项目的类型。
敏捷将团队的重点放在交付可运行的软件上，因此他们必须完成端到端的功能应用、集成和其他影响用户的交付物，而不仅仅是技术组件。团队成员必须对他们正在建立的东西，谁在做什么，以及如何开发软件保持一致。
敏捷团队通常有其他的角色分配，包括以下。
- 技术或团队领导与产品所有者在架构、非功能验收标准、顺序、依赖性以及其他技术和安全考虑方面合作。技术带头人有广泛的责任，可能包括估计故事和与团队一起规划实施细节。
- Scrum主管经常指导新团队的敏捷过程、责任和工具。Scrum主管的职责包括解决阻碍进展的问题，审查提高敏捷团队速度的方法，以及梳理积压的工作。
- 业务分析员与产品负责人合作。分析师的职责通常包括创建线框，记录用户故事，并审查测试结果。当软件开发团队正在开发微服务和其他技术产品时，以及当业务分析师比产品负责人拥有更多的软件开发知识时，业务分析师尤其有帮助。
如何配备敏捷团队，以及将其扩大到多大，都由组织领导者决定。许多人遵循Jeff Bezos的最佳实践，构建两个比萨饼大小的敏捷团队，以最大限度地提高队友之间的合作。
Scrum和Kanban
一旦产品愿景和团队（或多个团队）采用了敏捷原则，从敏捷宣言中确定的原则开始，组织必须选择一种流程方法。Scrum和kanban是主要的敏捷流程。
有些组织从看板开始，因为它相对容易解释和实施。看板是一个扇进扇出的过程，团队从接收板上拉出用户故事，并通过工作流将其输送到目的地，直到它们被标记为完成。
但许多组织实施Scrum，它将工作组织在称为冲刺的节奏中，通常持续一到两周。产品拥有者把需求写成用户故事，然后根据它们的商业价值把它们放在一个backlog里，确定优先次序。团队审查积压的需求，并承诺他们在冲刺期间可以完成的最重要的用户故事。
Scrum包括几个标准会议（有时被称为Scrum仪式或Scrum仪式），以帮助团队承诺冲刺优先级，在冲刺期间完成工作，并成功结束每个冲刺。这些会议通常包括一些共同的内容。
- 冲刺计划是产品所有者分享优先事项的地方，团队决定在冲刺期间能完成多少工作。
- 每日例会帮助团队讨论用户故事的状态；团队成员分享他们的每日目标，任何人都可以升级阻碍团队进展的障碍。
- 冲刺回顾是冲刺结束时的演示会议，向产品所有者展示功能，以获得对已完成工作的认可。
- 回顾性会议是团队讨论在敏捷和软件开发过程中哪些地方做得好，哪些地方需要改进。
应该注意的是，这些实践可以适应敏捷的混合工作模式。
Scrum通过授权团队承诺可实现的工作量，而不是由产品、程序或项目经理指定预期的时间表和范围来提高团队的绩效。用户故事形成了一个微合同，将业务需求、验收标准（或敏捷团队有时称之为完成的定义）分开，然后使团队能够自我组织如何实施。冲刺回顾是反馈回路的一种类型，鼓励产品所有者在每个冲刺前重新调整优先级并重新定义需求。冲刺回顾帮助团队改善协作并启动流程改进。
敏捷组织的技术最佳实践
Scrum形成了团队协作、计划和交付的基本流程，但它并不涉及技术最佳实践、组织标准或定义和推动敏捷文化。
今天，许多技术最佳实践包括定义软件开发生命周期（SDLC）和实施devops流程。SDLC提供了编写代码、管理软件资产和制定技术标准的指导方针。像CI/CD、基础设施即代码（IaC）和持续测试这样的Devops自动化，能够为生产提供更可靠的路径。其他实践，包括左移的安全实践、可观察的微服务、功能标记、金丝雀发布和AIOps，提供了一个更加灵活和可靠的交付模式。
授权自组织团队、敏捷方法论、devops自动化和现代化云架构的结合有助于技术组织发展其文化。较长的开发周期被持续交付模式所取代，从而能够更快地发布功能和改进。自动化解决了寻求自主权和速度的开发人员与围绕性能、可靠性和安全性的运营责任之间的许多差距。结合这些实践，可以帮助敏捷团队做出更明智的架构决策，推动实验，变得更加数据驱动，并迅速纠正错误。
其他的实践，如将设计思维与scrum相结合，实施价值流，发展产品管理实践，以及实施持续计划，都有助于敏捷团队与客户、终端用户和商业利益相关者合作。
敏捷团队通常部署Jira软件、Azure DevOps和Digital.ai等工具，在敏捷积木和看板上进行协作。这些工具帮助敏捷团队确定工作的优先次序，捕捉需求，完成用户故事，审查埋头报告，并使用版本控制、CI/CD和其他工具实现工作流程自动化。
概念框架和指南，如SAFe、企业Scrum、LeSS（大规模Scrum）、Spotify模型和StarCIO Agile，可以帮助推动许多合作团队的敏捷原则、标准和实践。
大多数教练建议，在开始进行敏捷实践时，应明确商业目标，选择几个团队，并选择有限的、最合适的工具。组织领导者面临的挑战是如何在不同的团队、自组织原则、标准、工具和集成之间找到适当的平衡，使他们的组织能够建立、扩展、扩大和维护技术能力。
相关的：
