导读：了解如何将敏捷开发原则置入传统的软件开发生命周期中。

将敏捷软件开发原则注入软件开发生命周期（ SDLC ）有助于为所有利益相关者（客户、组织和投资者）释放更大的适应性、敏捷性、性能和产品价值。 

根据报告指出，72% 的人对采用敏捷开发实践非常满意或部分满意。

但剩下的人对结果不满意。42% 的人认为领导层参与不足是成功敏捷交付的障碍。与现有组织文化的冲突、变革的阻力、异构的 SDLC 实践以及培训和经验不足是那些渴望敏捷的人所面临的其它挑战。 

为了缓解这一问题的出现，agilemanifesto组织制定了敏捷宣言(https://agilemanifesto.org/)。这是一套价值观和12 条敏捷原则，帮助软件团队成功采用敏捷开发实践，以获得更好的投资回报率与更快的上线时间。

12 条敏捷原则：提高投资回报率的秘诀

敏捷原则 1：持续价值交付

“我们的首要任务是通过尽早、持续地交付有价值的软件来满足客户的需求。”

销售给现有客户的概率在60% - 70%之间。但只有 18% 的公司优先考虑保留客户。在软件行业，客户满意的一个简单方法是不断满足他们对更多特性、功能和改善客户体验的渴望。所有这一切都可以通过第一个敏捷原则来实现，该原则建议将持续交付融入到软件开发生命周期中。 

• DevOps等现代 IT 实践将此作为其核心灵魂。 

• 持续交付使人们能够快速适应不断变化的市场条件和客户需求，并将持续反馈注入你的开发生命周期。

• 这样会带来更高质量的软件、提高客户满意度、建立信任和忠诚度、提高参与度并影响回头客的相关业务。

敏捷原则 2：拥抱不断变化的需求

“欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来为客户带来竞争优势。”

提高客户满意度的另一个渠道是接受不断变化的需求。传统的软件开发实践（例如常见的瀑布模型）对于变更请求时并不友好。他们很僵化。这样的团队没有能力适应需求的变化。因此，他们错过了一些增长机会。此外，当他们发布的软件进入市场时，已经成为过去式了。更不用说，软件使用感觉也很陈旧。 

第二个敏捷原则鼓励欢迎不断变化的需求，这对你来说可能是一个很好的竞争优势：

• 及时利用新出现的机会，提高敏捷性，使你能够更好地满足客户的需求和期望。

• 为了顺利应对不断变化的需求，你需要从一开始就采用高度灵活的敏捷架构——不仅在文化和思维方面，而且在你的技术堆栈和软件架构方面。 

• 微服务和无服务器云/边缘架构在敏捷 IT 专业人士中非常流行。

• 作为预防措施，你必须制定适当的策略和框架来接受或拒绝传入的变更请求。否则，本来可以成为竞争优势的东西可能会变成一种负担（范围蔓延），并导致预算泄漏、不确定性、混乱和项目时间表不准确。

敏捷原则 3：较短的冲刺长度

“频繁地交付工作软件，从几周到几个月不等，优先考虑较短时间范围。”

现在，我们不应将第三个敏捷原则与强调持续价值交付的第一个原则混淆。敏捷确实提倡增量软件交付。是的，SDLC 团队应该关注软件质量，但这不应延迟您的周期时间或部署频率。第三个敏捷原则通过推荐较短的时间尺度（也称为时间盒子或冲刺长度）解决了同样的问题。

• 市场研究是 SDLC 的第一阶段，在软件开发的设计思维中具有非常重要的作用。尽管如此，42%的初创公司还是因为产品与市场不匹配而失败。

• 要将用户反馈和响应循环到软件开发中，您可以发布产品的 MVP 并开始分析用户分析和应用程序使用信号来塑造您的产品。

• 较短的时间尺度使您能够快速验证产品与市场的契合度，并引入可能需要的任何路线修正。

敏捷原则 4：协作

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

在传统的软件开发方法中，团队通常在孤岛中工作，即彼此独立并按部门划分。这会导致沟通障碍、缺乏主人翁意识和责任感，并在团队之间滋生目标不一致和误解。然而，第四条敏捷原则侧重于工作节奏——有效的沟通、协作和进步。

• 开发人员必须让业务利益相关者参与 SDLC 生命周期阶段，以提供有关特性和功能的输入，以确保产品进展与需求积压以及业务目标保持一致。

• 忽视这一敏捷原则可能意味着开发人员交付的产品质量低下，在产品市场契合度方面得分不佳，并导致采用率低、评价差，最终导致产品失败。

• 业务利益相关者也需要定期咨询开发人员，以更好地了解技术上可行的内容、开发团队面临的障碍以及实际的预算和时间估算。这有助于他们更好地确定功能的优先级并规划上线策略。

敏捷原则 5：积极主动的参与者

“围绕积极主动的个人构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。”

71%的员工表示微观管理干扰了他们的生产力。85% 的人表示会士气低落。一般来说，过分关注细节、试图控制每一项任务、迫使管理层做出每项决定都是工作场所有毒的迹象。

这些违背了敏捷宣言的本质。第五条敏捷原则宣扬了地方决策优于中央决策的理念。

• 有毒的管理者经常会在出现任何危险信号时收回个人和团队的工作。 

• 相比之下，当个人深入投入项目、发挥自己的潜力并对积压项目表现出更大的责任感和主人翁精神时，敏捷工作场合就会蓬勃发展。 

• 敏捷原则表明你的团队应该非常精简，并且由积极主动的个人组成。 

• 领导的重点应该是识别障碍，并提供必要的资源/支持来克服障碍，而不是试图管理它们。

敏捷原则 6：团队协作

“向开发团队以及在开发团队内部传达信息的最高效、最有效的方法是面对面的对话。”

远程工作时，团队成员很容易感到疏远。不幸的是，在某些工作场所，项目中的个人或团队是孤立工作的。这不是最好的工作方式。如果项目中的角色和责任不明确，人们往往会偷懒发散。 

相反，角色明确可以使员工绩效提高25%。在敏捷环境中，责任由个人共同承担，沟通不畅和误解可能会极大地加剧问题。 

第六条敏捷原则建议建立一个开发环境，促进敏捷项目伙伴之间面对面的高强度沟通和协作，以防止任何误解。

一些敏捷方法将这一原则内置到其框架中：

• Scrum 敏捷框架每天召开 Scrum 会议，讨论当天的进度、障碍和计划，并协作解决问题。这确保每个人都在同一个页面上。

• 这些会议通常设计得很短，最好是 15 分钟。Sprint 评审/回顾和 Sprint 计划的持续时间较长。

• 另一个敏捷框架是XP（极限编程）。在 XP 中，你可以进行结对编程等实践，其中两个成员一起工作共享相同的资源。 

• 有时，XP 会让客户现场参与 SDLC 流程，以便获得快速的客户反馈和协作，从而生产出质量更高、更有价值的软件。

敏捷原则 7：可用的软件是最终信号

“可用的软件是衡量进展的主要标准。”

人们很容易迷失在流程、会议、冲刺和无休止的文档中。但经验统计数据并不能代表真正的进步，只有可用的软件才能代表真正的进步。 

有几个项目 KPI 和工程 KPI 可以衡量团队的绩效。第七条敏捷原则强调仅将工作软件视为进度信号，而不是依赖于工作时间、编写的代码行数、部署频率、开发吞吐量、解决的错误或拉取请求数量等指标。其他一切都是噪音。 

• 仅仅提供功能是不够的。 

• 该软件在质量指标上也应该表现良好。

• 导致产品崩溃/挂起的新功能将弊大于利。

敏捷原则 8：可持续性

“敏捷流程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持恒定的步伐。”

健康和高效的工作环境并不以毒性或倦怠为特征，而是以开发人员的福祉、持续的工作节奏、及时性、现实的工作量、持续改进和简化的流程为特征。第八条敏捷原则强调了其重要性。 

• 为了提高团队工作的可持续性并确保开发人员的福祉，请使用 Hatica 等工程分析工具和敏捷项目管理软件、时间跟踪工具（不推荐）、容量规划、燃尽图等。 

• 在 Scrum 和看板等敏捷方法中，积压工作列表应该被很好地分成等长的冲刺。利用 Scrum 或看板来分配工作，可视化项目移动到“正在进行的工作”(WIP) 和“已完成”列的频率，并对其进行优化。

敏捷原则 9：以设计和技术为主导

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

软件开发中没有什么必杀技，只有上述说的这样。而错误是唯一的现实。但如果你想增强韧性、占据良好的市场份额并持续击败竞争对手，那就要投资可扩展、安全、高性能的技术。第九条敏捷原则是良好的技术堆栈、架构和设计的热心支持者。 

• 良好的技术堆栈并坚持最佳的软件设计实践可以让您免受致命的技术债务的影响，从而提高你的敏捷性。

• 此外，低技术债务意味着您将拥有更好的资源可用性和可用性。因此，我们可以挖掘更多机会并提高投资回报率。

• 定期的多级代码审查、架构分析、代码重构、广泛的测试和结对编程实践可以带来更高质量的技术基础设施。

敏捷原则 10：精益和简单

“简单性——最大限度地减少未完成工作量的艺术——至关重要。”

精益软件开发实践之所以受欢迎，原因显而易见——它使你保持灵活、敏捷，并准备好适应不断变化的市场条件或用户需求。

无论你是在准备需求积压、计划冲刺、编写代码、测试功能还是交付产品，始终致力于最大限度地减少你所做的工作，并最大化所提供的价值。 

• 一般来说，第十条敏捷管理原则表明，一个简单的 HTML JAVASCRIPT 网站不必要的情况下不要使用 JS 框架来实现。 

• 此外，技术主管或工程经理通常需要做出艰难的决定并进行一些权衡——选择一种技术堆栈而不是另一种技术堆栈，并批准一种软件架构设计而不是其他设计。你不需要太简单，但需要确保没有任何选择会损害敏捷性。

• 产品所有者也应该避免在没有任何实际用户需求的情况下在产品中引入花哨的功能。 

• 根据这一敏捷原则，只有当新项目能够增强产品的可用性或为用户提供更多价值时，才在待办事项中添加新项目。 

敏捷原则 11：自组织

“最好的架构、需求和设计都来自于自组织团队。”

为了使敏捷团队实现最佳绩效，设计出色的架构和产品设计，第十一条敏捷原则促进培养一种工作文化，使自组织团队能够独立于设计/架构审批的红丝带流程，进行创新更快地培养队友的责任感与责任感。

• 与金字塔结构的组织相比，扁平化管理/层级组织倾向于从敏捷项目中获取更大的价值。

• 团队中的个人不仅限于自己的角色，还可以发挥不同的作用，来创造更大的价值。

敏捷原则 12：迭代改进

“团队会定期反思如何提高效率，然后相应地调整其行为。”

实践中的敏捷不仅仅是几个框架、原则和价值观，这些是一种持续改进的心态和文化。迭代开发和增量交付是敏捷软件开发流程的基本方面。第十二条敏捷原则是关于广泛跟踪、跟踪、跟踪和弥合任何已发现的差距。

• 敏捷流程和方法的特点是总是有改进的空间。 

• 因此，无论是组织的文化、敏捷人才、技术系统和流程——质疑、分析和优化一切。 

• 越早重新进行优化，你花在技术债上的费用就越少。 

• 冲刺回顾、自动化测试和同行反馈文化可以在让敏捷为团队服务方面发挥神奇作用。

结论

敏捷原则帮助组织吸收敏捷宣言价值观，指导软件开发团队快速高效地交付高质量的软件。

这些原则强调拥抱协作、灵活性和持续改进，以满足不断变化的市场需求。使用工程分析工具可以帮助团队衡量进度、确定需要改进的领域并且优化开发流程。通过利用数据指标，团队可以不断提高为客户提供价值的能力，同时坚持敏捷性原则。

让我们继续打造令人惊叹的产品！

作者：万能的大雄