什么是敏捷方法论？What is Agile Methodologies?
我们经常被问到这个问题：什么是敏捷方法论 (Methodologies)？很简单，敏捷是IT行业用来描述项目管理的替代方法的炒作词。
敏捷是一个过程，可以帮助团队快速，不可预测地响应他们在项目中收到的反馈。它为在开发周期中评估项目方向创造了机会。团队在常规会议中评估项目，称为冲刺或迭代。
敏捷是一个非常强大的过程，可以帮助公司设计和构建正确的产品。管理过程对软件公司非常有利，因为它有助于他们在整个开发过程中分析和改进产品。这使公司能够生产出高价值的产品，从而保持市场竞争力。
敏捷开发本身并不是一种方法论。它是一个总称，描述了几种敏捷方法。在2001年签署敏捷宣言时，这些方法包括Scrum，XP，Crystal，FDD / DSDM。从那时起，精益实践也成为一种有价值的敏捷方法，因此在后面的插图中包含在敏捷开发保护伞下。
敏捷从哪里来？
2001年，一小群人厌倦了管理软件开发项目的传统方法，设计了敏捷宣言。它是一种更加改进的方法，用于管理软件项目的进度。
敏捷宣言有四个重要的价值观：
- 重点应放在个人和互动上，而不是过程和工具上
- 工作软件比综合文档更重要
- 客户协作比合同谈判更重要
- 该过程应该响应变化而不是遵循计划
敏捷软件开发有12条原则：
- 通过持续提供有价值的软件提供客户满意度
- 始终接受需求的变更，无论项目的早期或晚期如何
- 提供在更短时间内工作的软件
- 开发人员和业务专业人员必须在整个项目期间每天密切合作
- 信息最好通过面对面交谈在各方之间转移
- 激励人们通过创造欣赏，信任和赋权的环境来建立项目
- 工作软件是衡量进展的关键指标
- 敏捷过程促进可持续发展
- 持续关注技术开发和设计的卓越性和质量可提高灵活性
- 简单性是有效敏捷管理的重要组成部分
- 自组织团队提供最佳架构，要求和设计
- 团队应通过检查和调整来反映更有效
有不同的敏捷方法可以促进宣言的价值观和原则。Scrum和XP是两个众所周知的例子。
敏捷软件开发的好处
许多开发人员经历了项目的噩梦，没有任何实践来指导它。缺乏有效的做法会导致不可预测性，重复错误和浪费精力。客户对计划下滑，预算不断增加以及质量低劣感到失望。开发人员因为工作时间越来越长而生产越来越差的软件而感到沮丧
顶级软件开发人员开发了敏捷会议。在反复体验现实生活项目中传统瀑布式开发的挑战和局限之后，他们希望创建一个更有效的分析项目开发的过程。他们使用的方法直接解决了传统方法的哲学和过程问题。
敏捷软件开发有很多好处。他们包括：
利益相关者参与和满意度
敏捷过程在每次sprint会议中创造了许多机会，以实现团队与利益相关者之间的真正互动。由于客户积极参与整个项目，因此各方之间的合作水平不断提高。这使团队有机会充分了解客户的愿景。通过频繁提供高质量的工作软件，利益相关者可以迅速与团队建立信任和真实的关系。这也进一步促进了客户与团队之间的互动。
透明度
敏捷方法在整个项目中积极地涉及客户，包括迭代计划，审核会话和软件中的新功能构建。但是，客户必须明白，在项目透明度期间，他们看到的是正在进行的工作，而不是最终产品。
早期和可预测的交付
短跑的持续时间为1至4周。通过使用这种时间框方法，可预测性很高，因为可以快速，频繁地向利益相关者提供新功能。如果软件具有足够的业务价值，它还允许团队更快地对软件进行beta测试或发布。
可预测的成本和时间表
由于Sprint是按照固定的时间表进行的，因此成本是有限且可预测的，并且基于完成的工作量。通过在每个Sprint之前组合估算的成本，客户将更好地了解每个功能的大致成本。在确定功能优先级或添加迭代时，这可以提供更多改进的决策机会。
灵活的优先级
通过优先考虑客户驱动的功能，Scrum方法可以提供更大的灵活性。该团队可以更好地控制每个sprint边界的可交付工作单元; 在最终产品里程碑方面不断取得进展。为了从工程中获得提示RIO，需要尽早将工作交付给客户，以便他们从功能中实现价值。
允许更改
虽然重点应该是提供商定的产品功能子集，但敏捷流程创造了一个不断重新确定优先级并优化产品待办事项的机会。这些更改可以添加到下一次迭代中，以便在几周内引入新的更改。
专注于商业价值
团队可以更好地了解对客户业务最重要的内容，并提供能够为业务带来最大价值的功能。
重点关注用户
用户的故事通常用于定义与以业务为中心的验收标准相关的产品功能。通过关注用户的需求，每个功能都可以提供真正的价值，而不仅仅是IT组件。通过在每个Sprint之后对软件进行beta测试，它提供了更好的机会来获得有价值的反馈。这在项目早期提供了重要的反馈，以便根据需要进行更改。
提高质量
这些项目被分解为可管理的单元，使团队更容易或专注于高质量的开发，测试和协作。通过在整个迭代过程中创建构建并进行测试或评审，可以及早找到并修复缺陷和不匹配，从而提高整体质量。
它为您的团队提供了目的
大多数敏捷流程都专注于为所有团队成员创建共享的所有权和目标感。这是为了给你的团队目的而不是产生一种错误的紧迫感。有目标的团队提高工作效率，挑战自我，提高速度和效率。
敏捷的商业利益
敏捷管理可降低与项目交付，范围和预算相关的常见风险。
它鼓励客户和团队之间的协作 ; 在缓解软件开发过程中的高风险方面提供互惠互利。
2009年，David F Rico博士将Agile与传统的软件项目管理方法进行了比较。在他的研究和综合过程中，他分析了23个敏捷过程，并将它们与7,500个传统项目进行了比较。
他发现敏捷项目有20项好处：
- 41％的整体业务价值更好
- 83％的人表现出更快的上市时间
- 50％的质量更高
- 50％的成本更低
- 83％的人更有效率
敏捷方法论
有几种敏捷方法; 所有人都有相似的哲学，特征和实践。但是，从实现的角度来看，每个敏捷都有自己的实践，术语和策略。一些主要的敏捷软件开发方法组件包括：
Scrum
Scrum是一个管理框架，具有远程控制和管理所有项目类型中的迭代和增量的能力。它们是轻量级的，可以与其他敏捷方法一起用于各种工程实践。Scrum在敏捷软件开发社区中越来越受欢迎，因为它们很简单并且具有可靠的生产率。
精益和看板
1.Lean软件开发
精益软件开发是一种最初由Mary和Tom Poppendieck开发的迭代方法。精益软件开发中的许多原则和实践来自精益企业运动，并且首先被丰田等大公司使用。这种基于价值的方法侧重于为客户提供有效的“价值流”机制，为项目提供价值。
该方法的主要原则是：
- 消除浪费
- 扩大学习
- 尽可能晚地做出决定
- 尽快交付结果
- 赋予团队权力
- 建立诚信
- 设想整个项目
通过仅选择对系统具有实际价值的功能，小批量优先排序和交付可消除浪费。相反，精益方法强调速度和效率; 依靠客户和程序员之间快速，可靠的反馈。它侧重于客户要求“拉动”产品的想法。重点更多的是个人或小团队更快，更有效的决策能力，而不是层次控制方法。该方法集中于其团队资源的效率，确保每个人始终尽可能高效。
看板方法 (Kanban)
组织使用看板方法来管理项目的创建，同时强调持续交付而不会使开发团队负担过重。与Scrum一样，看板流程旨在帮助团队更有效地协同工作。
有三个原则：
- 可视化您的工作：查看彼此上下文中的所有项目 - 提供更多信息
- 限制正在进行的工作量（WIP）：平衡基于流的方法，以便团队不会立即做太多工作
- 增强流程：一旦完成一项任务，就从积压工作开始下一个最高优先级工作
看板方法促进了客户和团队的持续协作。它鼓励持续学习和改进，为团队提供最佳的工作流程。
极限编程（XP）
极限编程（XP）最初由Kent Beck描述。它是最流行和最有争议的敏捷方法之一。XP是一种高度自律的方法，可以更快地持续提供高质量的软件。客户积极参与紧密团队，不断进行规划，测试和快速反馈，以便经常提供工作软件。该软件应每隔三到几周发送一次。
最初的XP方法基于四个简单的值：
- 简单
- 通讯
- 反馈
- 勇气
它有12个支持实践：
- 规划游戏
- 小版本
- 客户验收测试
- 设计简单
- 结对编程
- 测试驱动的开发
- 重构
- 持续集成
- 集体代码所有权
- 编码标准
- 隐喻
- 可持续发展
水晶 (Crystal)
Crystal方法是开发软件中最轻量级和适应性最强的方法之一。它由几个敏捷过程组成，包括透明，水晶黄，水晶橙和其他独特的特征方法。推动这些流程的因素包括：团队规模，系统的重要性以及项目的优先级。
Crystal系列专注于实现每个项目都具有独特的特征，因此，必须定制策略和实践以适应这些功能。
Crystal方法有几个基本原则，包括：
- 团队合作
- 通讯
- 简单
- 反射
- 经常调整
- 改善流程
与其他方法一样，这种敏捷过程可以促进早期和频繁的工作软件交付。它鼓励高度的用户参与，适应性和消除干扰和官僚作风。
动态系统开发方法（DSDM）
动态系统开发方法（DSDM）起源于1994年，为当时称为快速应用程序开发（RAD）的项目交付提供行业标准框架。虽然它在20世纪90年代非常流行，但RAD方法以非结构化的方式发展。
自成立以来，DSDM已经发展成熟; 它为敏捷流程和迭代项目的规划，管理，执行和扩展提供了全面的基础。
DSDM有六个围绕业务需求的关键原则：
- 值
- 积极的用户参与
- 授权团队
- 经常发货
- 综合测试
- 利益相关者合作
DSDM使用“适合商业目的”的方法来实现交付和验收标准。它侧重于公式：80％的系统部署在20％的时间内。
功能驱动开发（FDD）
Jeff De Luca，以及贡献者Am Rajashima，Lim Bak Wee，Paul Szego，Jon Kern和Stehen Palmer开发了功能驱动开发（FDD）。它是一个模型驱动的短迭代过程，首先建立敏捷模型的形状。“按功能设计，按功能构建”的迭代每两周举行一次。这些功能对客户很有吸引力，因为它们很小且很有用。
使用以下八种做法提供FDD设计和开发：
- 域对象建模
- 开发功能
- 组件和类所有权
- 特色团队
- 检查
- 配置管理
- 定期构建
- 进展和结果的可见性
敏捷中的角色
在敏捷开发过程中，Scrum最清楚地定义了敏捷在项目管理中的作用。
Scrum项目中有三个角色： 产品负责人，Scrum Master和团队成员。
产品负责人监督项目的所有业务条件，以确保以正确的顺序构建正确的产品。一个好的产品负责人可以平衡竞争优先级，为团队提供，并对项目做出决策。
Scrum Master 是团队的教练; 他们帮助团队有效地合作。Scrum Masters通过消除影响进度的障碍，促进会议和讨论组，跟踪进度，解决问题以及执行其他项目管理职责来为团队服务。
团队共同努力确定实现产品所有者概述的产品目标的最佳方法。该团队决定哪些成员将管理特定任务，并概述实现预期目标所需的技术实践。
Scrum Master角色在哪里适合敏捷软件开发？
在敏捷项目管理实践中，Scrum Master的是21世纪的项目经理 (Project Manager) 的版本。但是，与传统的项目经理不同，Scrum Master不会对项目的成功或失败负责。
他们的权力只延伸到这个过程。Scrum Master在此过程中的专业知识激励并指导团队在最高级别上执行。其他传统管理角色，如项目范围，成本，人员和风险管理仍然是项目经理的责任。
惊喜：敏捷组织是分层的！
关于敏捷组织的一个常见误解是它们是非等级的或扁平的。没有东西会离事实很远。高层管理人员仍然为组织的其他成员设定方向和基调，人们仍然因没有完成工作而被解雇。与传统的官僚组织相比，推动更高绩效的努力更加无情。在官僚机构中，表现不佳的员工仍然可以隐藏在系统的角落和缝隙中。但在一个敏捷的组织中，存在一种激进的透明度，使所有同行对其行为负责。
敏捷组织中的层次结构与官僚机构中的层次结构非常不同。该灵活的层次结构是基于能力的，不权威。表现并非基于取悦老板，而是为客户增加价值。该组织使用动态水平和垂直通信方法，非常具有互动性。想法可以来自任何位置的任何人，包括客户。这是一个不断发展，学习和适应不断变化的网络; 它通过利用所呈现的机会为客户增加新的价值。如果做得好，通过减少工作继续为客户提供更多价值，可以为组织带来更丰厚的回报。
敏捷清楚地区分了剥削和探索之间的差异。在敏捷组织中，所有成员都在不断探索为客户增加更多价值的方法。
在敏捷管理的早期阶段，批评者认为小型团队永远无法处理大型复杂问题。但他们错了。所有团队都是交织在一起的网络的一部分，这种网络由所有关注共同目标的各方之间的持续对话驱动。各方的共同和一致的节奏，提供了一个坚实的平台，使小型团队能够管理更复杂的问题。到目前为止，这是一个比官僚方法更好的系统。
敏捷过程
敏捷过程将更大的软件项目分解为几个较小的部分，可以按增量和迭代开发。研究证明，项目规模与成功之间存在负相关关系（即：项目越短，成功率越高）。
敏捷方法通过创建几个较小的项目来减少项目的大小。这种迭代方法将敏捷管理与其他管理方法区分开来。
与其他方法不同，敏捷管理在规划和开发阶段使用迭代。每次迭代通常为一周。在这些会话期间，项目团队和客户团队协作确定需要添加到迭代的优先级。最终结果是在类似生产环境中快速交付给客户的工作软件程序。然后，客户可以测试他们的程序并根据需要进行更改。随着程序的更改，在整个过程中会发布许多版本。重复此迭代过程，直到项目完成。
一般管理和敏捷
软件编程是当今几乎所有业务的关键组件。这意味着敏捷是每种组织和工作形式的必要过程。
融合新价值观，实践，原则和利益的敏捷方法是传统的命令和控制方式的项目管理的更好的替代方案。敏捷过程甚至遍布不同的行业和功能，包括C套件。
然而，虽然许多公司正在采用一些敏捷流程，但它们仍采用官僚自上而下的方法运营。在当今的数字化主导经济体中，公司开发敏捷管理实践至关重要。但许多公司仍然在努力应对这种转变，并在命令式文化中运作。这体现在高级管理层的思维方式和技能上，是公司今天面临的最大障碍。
敏捷实践
有许多不同的敏捷实践 ; 敏捷从业者不会使用许多人。那些想要转换为使用敏捷过程的人应该了解不同的实践，以帮助他们将实践应用到他们的环境中。以下示例有助于说明如何应用敏捷实践。
每日站立（站立会议）
每日站立会议也称为每日Scrum会议。Scrum会议每天由团队举行，以便他们可以相互分享相关信息。这些会议旨在让所有团队成员了解项目状态并获得最新信息。每次会议的关键是简洁。
在每日Scrum会议期间，每位成员应回答以下三个问题：
- 我昨天做了什么？
- 我今天要做什么？
- 什么问题阻碍了我的进步？
用户故事 (User Stories)
用户故事是最终用户所需功能的简要描述。用户故事有三个要素。他们是：
- 书面描述，策划故事（通常写在卡片上）
- 关于故事的对话以获得更好的理解
- 一系列测试证实了这个故事。
这些故事是从最终用户的角度编写的，并使用他们理解的语言。故事充当开发者和客户之间的货币; 双方都清楚地了解它们。
自动化测试 (Automated Testing)
实施正式和彻底的自动化测试是敏捷过程的重要组成部分。测试从源头查找并消除缺陷，以确保将可用的软件包交付给客户。开发人员可以使用各种可用框架在安全网下创建测试代码，同时开发软件代码。此方法在更改软件时保护其他功能。它也是一种更快，更有效的方法来查找程序中的错误。
自动构建 (Automated Builds)
敏捷方法的一个关键原则是始终运行软件。实际上，实现此目的的唯一方法是确保定期自动编译，构建，部署和测试所有软件开发。这通常每天进行多次，每次开发人员“检入”代码作为开发分支的主要部分时至少进行一次。
敏捷规划 (Agile Planning)：发布 (Release)，迭代 (Iteration) 和任务 (Task)
敏捷开发计划有三个级别：发布，迭代和任务。在开始阶段，项目开发人员和客户会面讨论该软件所需的主要用户故事。会议最初的重点是必须具备的功能，以估计和优先处理需要完成的工作。
发布计划是一个以客户为导向的计划会话。客户和开发人员都会选择第一个产品发布系列的日期。他们协作决定在每个版本中加入哪些故事。开发人员专注于故事的估计工作，而客户则专注于故事选择。有多种形式的估算工作由客户和开发团队的需求和需求决定。
迭代计划需要客户和开发人员之间的协作，以启动部分发布计划。在迭代期间，客户定义用户故事并确定其优先级，同时开发人员估计开发每个用户故事需要多少工作量。迭代的时间线要短得多，只需几周而不是几个月。
任务计划在迭代计划之后进行。故事分解为开发团队的一系列可行步骤。任务列表在项目室中开发和发布，因此所有党员都可以清楚地看到它们。在此计划会话期间使用的常用工具包括便利贴和白板。每个开发人员都自愿执行任务并为其分配估算。
配对编程 (Pair Programming)
在结对编程中，两个开发人员在一个编程任务上作为一个团队工作。一个人是司机，即输入代码的人，而第二个人是导航员，即在将代码拟合到整个画面中时计划下一步的人。
结对编程的一个常见抱怨是浪费人力资源来完成任务。不应该让两个人做一个可以由一个人完成的工作。然而，虽然编程使用更多的人力，但最终的输出证明了费用。最近的一项研究发现，结对编程使用了15％的工作量，但缺陷减少了15％。虽然结果可能因具体情况而异，但开发人员经常发现错误的减少值得使用额外的资源。
另一个好处是不需要全时配对。在决定是否更好配对时，团队可以建立自己的规则和时间表。
持续集成 (Continous Integration)
在持续集成期间，开发团队在一天中多次将其代码输入系统。在添加代码之前运行一系列测试，以确保它不会损坏系统中其他预先存在的测试或功能。开发人员必须首先运行系统的所有测试，并在集成其他代码之前解决所有问题。代码集成到软件中的次数越多，合并和发现错误的速度就越快，越容易。
回顾 (Retrospective)
回顾是在项目结束时或接近结束时举行的会议。它们使所有相关方都有机会回顾并反思在此过程中所做的工作。整个团队看什么进展顺利，什么都没有，哪里的改进可以进行，而且最重要的是，他们如何利用他们学到的经验教训，并把它们转化为可操作的变化。
结论
敏捷管理是一种令人兴奋且引人入胜的软件开发方法。通过将产品开发人员和客户集成到规划和实施流程中，结果是为每个参与者提供更有价值的体验。
当敏捷编程正确使用时，组织可以不断寻找增加客户价值的方法。它为那些积极参与项目的人提供了更多的意义，为客户创造了更积极的体验，为公司带来了更加慷慨的最终结果。
scrum 文章集合