软件工程中的敏捷开发模型
对于某些类型的软件和特定类型的软件项目,敏捷软件工程是传统软件工程和敏捷软件工程之间可以接受的折衷方案。敏捷流程可以在短时间内提供高质量的系统。它强调开发人员和客户之间持续沟通和合作的必要性。
为了有效执行具有更短上市时间和不断变化的公司需求等特性的离岸软件开发项目,我们使用敏捷软件开发流程模型。具有频繁客户交付的迭代软件开发是敏捷软件开发中的一项基本策略,它立即解决了离岸开发的主要问题之一:缺乏对项目进度的洞察力。
客户满意度、增量软件交付、小型项目团队(由软件工程师和利益相关者组成)、非正式方法和最少的软件工程工作产品都是敏捷软件工程概念的一部分。敏捷软件工程原则优先考虑及时交付功能软件增量,而不是分析和设计。
在项目开发过程中,敏捷团队可以适应变化。
敏捷开发承认项目计划需要适应性。
敏捷培养团队结构和思维方式,促进开发人员和客户之间的沟通。
敏捷使客户和开发人员不再分离。
敏捷强调快速交付可操作软件的价值,同时淡化中间工作项的相关性。
如果项目团队能够自由地简化活动并以消除非必要工作项的方式进行准备,那么任何软件流程都可以从敏捷中获益。
敏捷流程
敏捷流程基于三个基本假设 -
很难预测哪些客户优先级或需求会发生变化,哪些不会。
许多类型的软件开发和设计任务是交织在一起的(构造用于证明设计)
从计划的角度来看,分析、设计和测试不像人们希望的那样可预测。
为了应对不确定性,敏捷流程必须逐步调整。增量适应需要基于在短时间内提供的软件增量(可执行原型)的评估的客户输入。
敏捷原则
最高目标是通过及时且持续地交付有用的软件来满足客户。
应欢迎法规的变化。即使在开发过程的后期,容忍变化也被视为为客户赢得竞争优势。
频繁交付功能软件,偏向于更短的交付时间(例如,每 2 或 3 周)
在项目期间,业务人员和开发人员必须每天进行协作。
围绕积极进取的人员构建项目,为他们提供所需的氛围和支持,并相信他们能够完成任务。
在开发团队内部,面对面的交流是传递知识最有效的方式。
工作的软件是衡量进展的最重要指标。
敏捷方法鼓励长期开发,因此开发人员和客户应该能够永远继续开展项目。
持续关注技术卓越和智能设计可以提高敏捷性。
简单性(定义为最大限度地减少未完成的工作量)至关重要。
自组织团队提供最佳的体系结构、需求和设计。
团队定期思考如何变得更成功,并相应地改变其行为。
影响人类的因素
敏捷开发团队成员必须具备以下特征 -
胜任力
共同的目标
协作
决策能力
解决模糊问题的能力
相互尊重和信任
自我组织
敏捷流程模型
极限编程 (XP)
自适应软件开发 (ASD)
动态系统开发方法 (DSDM)
Scrum
Crystal
面向特征的开发 (FDD)
敏捷建模 (AM)
极限编程
使用面向对象的方法。
最重要的行为
组织(用户故事由客户价值创建和排序)
概念化(首选简单设计,CRC 卡和设计原型是唯一的工作产品,鼓励使用重构)
编码过程(专注于单元测试以练习故事,强调使用结对编程来创建故事代码,持续集成,并使用冒烟测试)
检查(在编码之前创建的单元测试使用自动测试框架实现,以鼓励使用回归测试,每天进行集成和验证测试,验收测试侧重于客户可见的系统特性和功能)
自适应软件开发
当一群自主代理协同工作以解决超出任何单个参与者能力的问题时,就会发生自组织。
强调自组织团队、人际合作以及个人和团队学习。
自适应循环的特征
阶段 -
使命驱动型
组件化
迭代
时间盒
构思(项目启动并进行自适应循环计划)
协作很重要(需要来自凝胶团队的团队合作,首选联合应用程序开发作为需求收集方法,创建迷你规范)
学习(实现和测试组件,焦点小组提供反馈,正式的技术审查,事后分析)
动态系统开发方法
通过在安全的环境中使用增量原型,为开发和管理满足严格期限的系统提供框架。
使用帕累托原则(80% 的项目可以在交付整个项目所需的 20% 的时间内交付)
每个增量仅具有足以允许您进入下一个增量的功能。
时间盒用于通过固定时间和资源来确定每个增量中将提供多少功能。
遵循的原则
积极用户的参与
拥有决策权的团队
交付成果的验收基于其对业务目的的适用性。
需要迭代和增量开发才能得出精确的业务解决方案。
在整个开发过程中进行的所有修改都可以撤消。
在高级别上,需求是基线化的。
测试集成到整个生命周期中。
利益相关者以协作和合作的方式共同工作
在整个生命周期中发生的活动
可能性研究(确定需求和约束条件)
业务研究(确定提供业务价值所需的功能和信息需求)
功能模型迭代(生成一系列增量原型以向客户演示功能)
设计和构建迭代(重新访问原型以确保它们为最终用户提供业务价值,可能与功能模型迭代同时发生)
实施(最新迭代置于操作环境中)
Scrum
Scrum 原则 -
使用小型工作组来增强沟通、减少开销并最大化非正式知识交流。
为了确保创建最佳结果,该过程必须能够适应技术和商业难题。
该过程生成可以检查、修改、测试、记录和扩展的定期增量。
开发中的工作以及执行工作的人员被划分为简洁的、低耦合的部门。
在构建产品时,会进行测试和记录。
允许您在任何时候选择声明产品已完成。
开发活动由过程模式定义。
产品待办列表(按优先级排序的需求或功能列表,为客户提供业务价值,随时可以添加条目)
冲刺(完成待办列表中一项所需的工作单元,必须符合预定义的时间盒,受影响的待办列表条目冻结)
每日站会(每天15分钟的会议),涵盖以下主题:自上次会议以来完成了什么?您遇到了哪些挑战?在下一次会议召开之前将完成什么?
演示(向客户交付软件增量以供评估)
Crystal
在提供功能性软件这一主要目标和为下一阶段做好准备这一次要目标的驱动下,制定了一种开发策略,该策略在资源受限的创新和沟通游戏中优先考虑敏捷性。
水晶方法的基本原则 -
面对面沟通总是更经济、更快捷。
随着流程变得越来越严格,团队变得不堪重负,难以应对项目工作的变化。
随着项目规模的扩大,团队规模扩大,流程变得更繁重。
随着项目变得越来越重要,流程的某些方面将需要变得更加正规化。
随着反馈和沟通效率的提高,中间工作项的需求减少。
流程、形式和文书工作都受到纪律、能力和理解的制约。
不在核心项目路径上的团队成员可以利用空闲时间开发产品或协助核心项目成员。
采用增量开发方法,项目时间线为1到3个月。
在项目开始之前、增量开发过程中以及增量交付之后,都会举行反思研讨会。
水晶方法
透明水晶(小型、低关键性项目)
橙色水晶(大型、中等关键性项目)
橙色网络水晶(典型的电子商务应用程序)
面向特征的设计
面向对象软件工程过程模型在实践中
客户重视的功能,可在两周或更短时间内部署。
FDD的理念
强调团队成员之间的协作。
使用基于特征的分解和软件增量集成来控制问题和项目复杂性。
利用口头、图形和文本方式传达技术信息。
增量开发、设计和代码审查、SQA 审计、度量收集和模式使用都有助于提高软件质量(分析、设计、构建)
构成框架的操作
创建综合模型(包含一组描述要构建的应用程序业务模型的类)
列出功能(从领域模型中提取的功能,功能被分类和优先级排序,工作被分解成两周的块)
制定基于功能的计划(根据优先级、工作量、技术问题和时间安排依赖关系评估功能)
基于功能的设计(选择与功能相关的类,编写类和方法序言,开发初步设计细节,为每个类分配所有者,所有者负责维护其工作包的设计文档)
基于功能的构建(类所有者将设计转换为源代码并执行单元测试,集成由首席程序员执行)
敏捷环境中的建模
一种轻量级、基于实践的范例,用于成功建模和记录软件系统。
建模原则 -
目标明确的模型
使用多种模型
只取所需(只保留具有长期价值的模型)
内容的重要性超过表示形式的重要性。
您应该熟悉您用来开发模型的模型和工具。
本地化您的适配。
收集需求并对分析进行建模
协作确定客户想要做什么。
在创建需求模型之后,与客户的协作分析建模继续进行。
架构建模
初步架构源自分析模型。
架构模型必须在环境方面准确且对开发人员友好。