【51CTO.com快译】本文介绍了人们需要了解的关于Scrum、极限编程、动态系统开发方法(DSDM) 和特征驱动开发(FDD)等内容。
敏捷软件开发使企业能够在短时间内将产品推向市场。为了让企业高管了解敏捷方法是否适合，文中分享了敏捷软件开发的基本原则、首选团队结构、常见方法等信息，例如Scrum、极限编程(XP)、动态系统开发方法(DSDM)和特征驱动开发(FDD)。
1.什么是软件开发的敏捷方法?
敏捷是一种独特的软件开发方法，它考虑了不同的组件，例如客户的需求、持续学习和测试、迭代开发、每两周后的有形增值等因素。
2.敏捷软件开发的基本原则
(1)沟通与反馈
不同软件开发团队成员之间的沟通可能是一个挑战，尤其是在冠状病毒疫情蔓延期间，因为大多数人都在家远程工作。在这种情况下，可以使用通信工具使软件开发团队成员的工作保持同步，同时密切合作以创建最小可行性产品(MVP)。
在使用敏捷方法时，团队成员在同一时间工作，他们可以几乎实时地协作、分享关注点、提供反馈，并高效地协同工作。
在敏捷软件开发过程中需要遵循“更少的计划变更”的概念。经过几个sprint周期之后，这些变更将生效，需要仔细分析客户反馈。根据分析，在当前或即将到来的sprint周期中选择的待办事项列表中添加更多的更改。
(2)适应性
创建敏捷软件开发过程时应该考虑的两个基本要求是：一是以恒定的速度推进项目;二是处理压力的能力，例如由于需求变化而导致的截止日期、预算增加等。为了有效管理和提高生产力，可以先开展快节奏的sprint工作，然后休息一段时间。在所有sprint周期中保持更高的生产力和快节奏的工作是可以强制的，但这种方法通常是不可持续的。
(3)信任
选择团队成员使用敏捷方法进行软件开发项目是重要的一个步骤。选择过程的另外重要部分是考虑技能组合和责任，此外还应该有工作环境的个性化匹配。团队成员应该是优秀的专业人士，能够自我管理并且能够相互信任。
自我管理的质量在敏捷方法中至关重要，因为工作节奏通常很快，并且需要独立解决问题。另一方面需要避免微观的管理或指导，因为这些做法通常需要花费更多时间。团队成员事先清楚了解软件开发要求很重要，这也意味着需要了解产品路线图。
(4)协作
在软件开发中，有两种常见的开发模型——瀑布模型和敏捷模型。在瀑布模型中只收集一次需求，这也意味着客户可以一次性参与。而在敏捷模型中，客户在开发过程中一直参与以收集需求。因此，客户在维护产品待办事项方面将发挥积极作用。在其他时候，客户可能会在修改需求方面发挥积极作用，例如在提供产品演示、在日常会议期间等等。
3.敏捷软件开发的首选团队结构
作为敏捷软件开发的核心，协作扮演着重要的角色。协作发生在具有特定角色的不同团队成员之间。考虑到Scrum框架，其名称和角色解释如下：
- 业务主管：业务主管在最小可行性软件产品(MVSP)的开发中发挥积极作用。业务主管主要与Scrum主管和产品主管进行协调。
- 产品主管：产品主管在创建最小可行性软件产品(MVSP)的同时确保从开发工作中获得最大的投资回报(ROI)。产品主管通过设置优先级来做到这一点。产品主管的三个主要职责是：管理Scrum待办事项、发布以及利益相关者管理。
- Scrum主管：Scrum主管负责将产品主管或业务主管共享的方向转化为有形价值。为此，Scrum主管协助管理待办事项，并协助开发团队自我组织、管理潜在障碍等工作。
- 设计、开发和测试团队：在理想情况下，设计、开发和软件测试团队成员紧密协作。一旦开发了Web应用程序的前端，开发团队成员就会添加功能。最后，测试团队成员将通过开发不同的案例来检查功能。
- 主题专家：潜在客户需要解决其行业难点的解决方案。端到端Web和移动应用程序开发服务提供商可能拥有协助开发团队以及Scrum主管的主题专家。
4.敏捷中的通用方法和框架
(1)Scrum
Scrum是一种广泛流行的用于开发软件产品的框架。其重点主要是产品的设计、开发、测试和部署。开发是在sprints中完成的，通常需要两到三周的时间。Scrum团队由产品主管、Scrum主管、开发团队、主题专家等成员组成。
敏捷软件开发项目的进度是通过每天在15分钟内完成的Scrum会议来衡量的。
(2)Scrum框架的工作流程
Scrum框架由不同的组件组成，例如sprint、sprint规划、每日Scrum、sprint审查、sprint回顾、待办事项细化以及取消sprint。以下是对上述每个术语的简要概述。
- sprint：sprint通常持续两周的时间。在sprint期间会生成一个待办事项，其中包含有关当前sprint的可交付成果的信息。
- sprint计划：sprint计划流程以邀请Scrum团队的会议开始。团队就目标达成一致，并确定有助于实现该目标的待办事项。
- 每日Scrum：每日Scrum会议是一个限时15分钟的活动。在进行日常Scrum时要遵循某些指导方针，例如开发人员发言、识别瓶颈和风险等等。
- sprint评审：在sprint周期结束之后，进行sprint评审。在理想情况下，产品主管应该在场，因为可交付成果向利益相关者展示。这提供了接收反馈的机会。
- Sprint回顾：由于Scrum框架补充了持续学习的理念，因此在sprint完成后的回顾会议中讨论学习情况。其总体思路是讨论哪些进展顺利，哪些不顺利。如果事情没有按计划进行，那么也将讨论其背后的原因。
- 待办事项细化：为了保持待办事项中的质量，添加了细化步骤。待办事项细化步骤使团队成员能够将较大的需求分解为较小的需求、识别依赖关系、修改优先级等等。
- 取消sprint：如果在sprint:中没有实现目标，产品负责人可以取消sprint。
(3)极限编程
极限编程主要侧重于广泛的测试，为此使用了“结对编程”的概念。考虑到将常规软件开发实践提升到极端水平的一般方法，该名称包括“极端”这个术语。
极限编程中的常见活动：
- 编码：极限编程中的编码实践包括来自其他程序员的大量反馈，因为该框架主要以“测试”为重点。
- 测试：在软件开发阶段之后，测试对于消除错误(bug)至关重要。根据测试阶段所用的时间，软件产品的质量可能会有所不同。在极限编程中，将测试的概念发挥到极致，以消除数量最大的错误。这是通过“结对编程”实现的。极限编程中有两种不同的测试方法——单元测试和验收测试。
- 倾听：在极限编程中，程序员通过倾听客户的需求发挥着重要作用。为此，程序员应该清楚哪些功能可以真正帮助客户，以及可能需要哪些业务逻辑更改。
- 设计：良好的软件设计易于维护。它还通过避免可能增加复杂性的依赖关系来增加价值，因为修改软件的一个模块可能需要更改多个其他模块。
(4)动态系统开发方法(DSDM)
在动态系统开发方法(DSDM)中，预先确定了成本、质量、时间这三个因素。此外，动态系统开发方法(DSDM)采用MoSCoW优先级方法来修改优先级。这样做可以及时交付软件。
DSDM的原则：
- 关注业务需求：在DSDM中，业务目标与软件的交付日期同等重要。关注业务需求的管理方式是通过某些实践完成的，例如MoSCoW优先级划分、通过时间盒将大任务分解为小任务、改进可交付成果等。
- 准时交付：强调使用MoSCoW优先级、截止日期管理和时间盒技术来交付可交付成果。
- 协作：协作的概念在DSDM中实施，而利益相关者参与项目。了解赞助商和用户的需求很重要，主管将向团队成员传达这一点。
- 永不妥协的质量：测试阶段在DSDM的早期引入，并在整个开发过程中发挥积极作用。
- 从坚实的基础上逐步构建：“充分的预先设计”方法使客户以及敏捷软件开发人员能够理解基本需求。在每次迭代中，团队成员可以重新考虑优先级，并考虑来自利益相关者的反馈。
- 迭代开发：迭代方法为项目增加了价值，因为它涉及不断的测试。迭代软件开发方法还补充了对相关利益反馈的接受。
- 持续而清晰的沟通：在DSDM中，通过非正式的日常站立会议加强沟通，这是一个讨论各种想法的好地方，研讨会以保持产品与利益相关者的期望保持一致。
- 展示控制：管理软件开发项目和使用DSDM需要主动管理技能。这包括让利益相关者和团队成员保持一致，有效使用报告和分析，并专注于交付的需求。
(5)特征驱动开发(FDD)
要理解特征驱动开发(FDD)，需要考虑其三个基本组成部分。创建FDD的第一个组件是对象建模，第二个组件是使用特征列表来管理需求，功能驱动开发的创建者Jeff De Luca利用自己的专业经验设计了第三个组件。
特征驱动开发(FDD)中的活动：
- 开发整体模型：在这项活动中，软件开发项目的范围通过高级演练最终确定。创建不同的模型并在同行评审会议中进行评审，选定的模型最终会合并到整体模型中。
- 构建特征列表：在第一项活动完成之后，需要将复杂的特征简化并转换为小特征。这些特征代表了客户需求和业务活动的混合。在理想情况下，每个特征预计在两周内在特征驱动开发(FDD)中开发。
- 按性质规划：一旦最终确定特征，它们将被进一步划分并分配给每个程序员，然后他们努力改进类。这是一个三步过程;首先确定开发顺序，将业务活动分配给首席程序员，再将类分配给其他开发人员。
- 按特征设计：考虑到时间盒方法，最终确定特征列表。在特征选择后不久，序列图就被创建。最后进行设计检查。
- 按特征构建：在这个迭代活动中进行实际编码。单元测试在代码检查之后很快执行。如果没有发现错误，则将代码添加到主构建中。
结论
敏捷软件开发方法在过去几年中发生了根本性的变化。敏捷的应用可以在其他领域找到，例如营销和销售等领域。有了切实的成果，企业高管和项目经理必须了解敏捷软件开发的重要性并实施相关实践，并创建以客户为中心的产品或提供更多以客户为中心的服务。
原文标题：Agile Software Development: Principles, Team Structure, and Frameworks，作者：Ramesh Lal
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
