文摘

SCRUM方法和面向服务的体系结构(SOA)框架至关重要的因素在评估影响业务流程的效率和确保业务目标的实现,并有望实现这些目标的过程。灵活性和改变采用SCRUM和SOA方法的关键特性。尽管双方鼓励敏捷,集成的两个独立的概念(SOA体系结构框架而SCRUM开发过程),在使用之前应该考虑在软件管理和开发项目。本研究评估和分析SCRUM和SOA的不同和不同的软件体系结构框架、开发方法以及它们的环境,这是结合软件项目管理和开发的上下文中设置软件开发行业。此外,本研究还探讨了SCRUM流程模型之间的相似性和SOA体系结构框架,看看他们是兼容的,如果是这样,他们如何可以提高基于SOA的项目相结合。这项研究还关注如何构建和使用SCRUM方法大规模的SOA项目。因此,SCRUM被选为软件开发方法的研究和基于SOA的开发项目。在项目开发和实施方面,完整的项目结构由八个主要部分。

1。介绍

至关重要的是任何组织的成功在今天的现代的、动态的世界对他们来说能够欢迎,和适应,改变顺利和有效。SOA是一种设计方法建设、开发、管理和部署软件应用程序和基础设施的所有应用程序排列成网络和可执行的业务服务(1]。SOA和敏捷软件开发方法需要灵活性和接受改变。建议彻底调查(之前实现体系结构在软件开发项目框架和开发过程)的集成这两个概念(2][迪亚斯,2022 # 232]。因此,使用一个有效的基于soa的应用程序开发,敏捷方法是至关重要的一个系统,允许大量的需求发生变化,即使是在应用程序开发,同时保留软件优势和质量(3]。客户的需求提高和可预测性是提高优先级迭代和用户故事按照敏捷原则(4]。ASD(敏捷软件开发)涉及产品通过频繁的快速、高效发展和完整的版本,允许其成员和赞助商来评估他们发布之前5,6]。敏捷回顾会议是用来检查和测试应用程序和过程。通过这种方式,一个模型转化为一个迭代和增量的方法,一个运转良好的进步和创新系统涉众提供反馈基于频繁的软件版本。

反复强调的交付工作软件的高质量和价值客户和项目。除了创建有用的构件,它还生成其他有益于用户和项目。敏捷流程设计交付高质量功能及时交付。敏捷流程的主要目的并不是专注于设计模型和文档,而是提供产品和交付他们尽可能快速有效地7,8]。SCRUM是一种敏捷方法,由于它的灵活性和坦率,已经成为一个常见的方式引入敏捷的9]。在商业领域,它是一个著名的敏捷管理技术。由于小组成员的不同性质和周围环境,敏捷应用程序开发在企业设置可以很复杂10]。通过促进两个人和团体,SCRUM过程有助于发现更好的方法来开发软件(11]。SCRUM,开发过程分为短跑为了专注于提供有用的产品和项目,利益每个人(12]。

SCRUM是最常用的敏捷方法,强调群体自我管理,经验反馈,迅速改善的目标完全优质的产品(13]。关键股东在SCRUM中,产品负责人,经常被称为客户端,SCRUM团队,SCRUM master。项目经理的任务共享这三个SCRUM角色14]。SCRUM管理者的工作是确保软件开发团队的过程顺利通过促进SCRUM会议,确保所有SCRUM规则和思想是坚持。SCRUM团队是一个跨职能小组与特定的专业知识。Sprint计划会议举行每个Sprint周期的开始。产品所有者和SCRUM团队决定冲刺目标,以及和sprint将努力完成,在这次会议上。“疾跑”审查会议期间,sprint的成功来衡量它的目标。每个sprint结尾sprint回顾会议,在此期间团队显示他们已经完成了的一切。团队成员讨论如何合作,互动,应对行为挑战,提高他们的技术能力。因此,除其他事项外,以下sprint快sprint回顾会议(15]。

SCRUM是一种黑箱方法用于构建和找到一个项目的团队和流程工作。白盒流程模型像瀑布模型是不灵活的方法从管理的角度14]。冲刺的目标和结果在规划和后期阶段定义。精心准备必须克服任何增长障碍或过程每一步。回顾会议,也被称为在敏捷公之于众,是必要的检查操作和建立知识库的最佳实践。图1说明了过程模型的属性在白盒和黑盒的基础上。


图1
类比的白盒和黑盒的软件开发流程。

不灵活创建软件开发方法是一个耗时的过程。这些方法都是基于一系列的迭代,包括确定需求,构建解决方案,测试和部署。传统的过程涉及到很多的文档在项目的一开始就和提供一组预设的要求。传统方法有很多,如瀑布、螺旋模型,双赢,统一过程。精确的前期策略、丰富的文档和大规模的预先设计都是重量级过程所需。不灵活创建软件开发方法是一个耗时的过程。这些方法是通过一系列的迭代,包括建立需求,构建解决方案,测试和部署。传统的过程涉及到很多的文档在项目的一开始就和提供一组预设的要求。螺旋模型、瀑布、双赢的螺旋模型,统一过程是传统方法的例子。精确的前期策略、丰富的文档和大规模的预先设计都是重量级过程所需。 Large-scale projects with a well-defined and relatively consistent set of needs benefit from traditional methodologies. However, some practitioners have begun to employ agile approaches for specific projects [16]。

SOA是一种设计、开发、管理和部署软件应用程序框架和策略。这是一个软件架构在应用程序分为服务,每个network-executable和访问业务规则。SOA也定义为一个组合应用程序,客户,和现有系统能够立即响应的变化这些系统(13]。SOA通常被认为是最有效的候选方法开发分布式应用程序。而不是从零开始,SOA允许重用现有系统的功能。在基于soa的系统中,这个属性的可重用性增强组织经济效益(14]。每个SOA服务是自包含的,但不是从系统的其余部分分离。在问题域,每个服务封装了特定的逻辑。除了松散耦合、服务合同、自主性、抽象,可发现性和无国籍,SOA有许多其他属性,使得一个强大的结构(17]。

尽管SOA和敏捷方法通常与类似的担忧,仍然没有明确的描述如何组织和建立这两种方法在一个物联网的平台。很少有这个集成实现的信息会影响至关重要的标准,如质量、生产力、敏捷性和创新性。

根据下面的语句和实际市场需求,以下研究检查SCRUM过程的相似性和SOA体系结构框架来确定SCRUM和SOA是兼容的。这项研究还关注如何构建和使用SCRUM方法大规模的SOA项目。因此,SCRUM被选为软件开发方法的研究和基于SOA的开发项目。整个项目结构由八个基本模块在项目开发和部署的视角。

本研究分为七个不同的部分。目前的部分介绍了许多重要的概念用于这项研究。第二阶段讨论了现有的SCRUM和SOA技术的研究,以及他们根据分析解释。研究设计和设置,以及分析SOA、SCRUM、SCRUM和SOA的联合使用,都是第三步。在第四步中,提供的集成分析的讨论SOA和SCRUM集成提出了在第五部分,6日和7日的步骤,分别呈现整个研究的结论和建议。

2。文学研究

敏捷技术的目的是确保软件产品是快速高效地开发的。在迭代工作(9使之成为可能。作为一个迭代过程的一部分,工作软件交付项目和客户。在迭代期间,软件和其他构件创建有利于客户和项目以同样的方式他们受益客户端(9]。敏捷过程主要是关心动态交付成果和工作产品,而不是专注于设计模型和文档(7]。

构造复杂和庞大的软件时,传统的开发专家认为,跳过文件和评估过程会导致公司失去记忆。敏捷专家,另一方面,认为应用敏捷软件建设和全球软件发布导致更好的结果在达到所需的结果18,19]。很难的组织协调和集成灵活性与全球服务条款,但它也将让他们提供商业软件,是快速和无错20.]。

创建敏捷软件构建策略,以应对需要从业务部门更轻、更快,更多灵活的软件构建方法(21]。因此,敏捷构建方法都集中在敏捷,速度,和愿意开发22]。敏捷流程,根据牛津字典,强调敏捷的重要性,以及愿意行动,灵活,活动,和技巧在运动12]。可以获得客户满意度的轻盈的关注过程,根据几个敏捷方法,例如极限编程和SCRUM (12]。

SCRUM是一种流行的敏捷管理方法。三个SCRUM的调查揭示了一个专注于实际审核,集团意识,努力开发和验证合适的产品增量在一个小周期(23,24]。SCRUM是一种广泛使用的敏捷方法,这是最常见的方法,将敏捷性由于其灵活性和简单性。通过鼓励个人和团队精神,敏捷软件开发方法支持更好的软件开发(11]。敏捷流程是为了确保软件产品是快速高效地开发的。

SOA承认的集成项目,客户,和当前系统到一个通用的框架能够迅速适应系统变化时是必需的(14]。SOA是公认的最有效的方法之一,开发分布式应用程序(25]。而不是从零开始,SOA允许重用现有系统的功能(26]。在基于soa的系统中,可重用性的属性提升组织的经济效益。SOA服务是自包含的,但他们不与系统的其余部分分离。在问题域,每个服务封装了特定的逻辑。SOA的主要特征是可重用性,松散耦合、服务合同、独立、透明、搜索能力,和无状态性27]。

研究人员和专家们混合两种方法是否和兼容是相似的。批评家指出SOA和敏捷方法之间的差异,声称SOA和敏捷正朝着相反的方向:SOA是一个框架,和敏捷技术(24,25]。一般来说,soa是自上而下的方法,而敏捷是一种自底向上的方法(28,29日]。过程范式等敏捷实践层面的工作,而SOA功能在架构层(30.]。为了集成SOA和敏捷服务创建策略,SOA和敏捷集成的倡导者认为,SOA架构和敏捷方法的指导原则是互补的31日,32]。一些专家认为,基于soa的系统不是像传统的创建21]。有许多障碍需要克服,其中包括利益相关者的参与,IT和业务部门之间的对齐,资产重用。面向服务的灵活性和更好的相关应对这样的挑战(33,34]。SOA和SCRUM分享许多特征等问题时的业务理解,新的工作方式,改变反应(35]。

当评估并指定SOA和SCRUM,技术挑战,以及他们与it相关商业组织(36)和消费者的个人信息,必须考虑。其他需求,如可用性和灵活性,表示为可测量的和可被识别的系统特性(37,38]。

3所示。SOA和SCRUM方法的建立过程

SCRUM作为发展方法,SOA平台架构解决类似问题,灵活性和快速响应性等变化,同时保持一个强大的业务重点。尽管这固有的操作相似之处是明确的,没有做足够的研究来确定最佳策略整合这两个方法结合获得收益(39,40]。还有一个需要考虑的结果采用SOA提高生产率和更好的利用时间和资源在使用SCRUM方法。

分析这个场景中,一个案例研究使用SCRUM模型已被选为构建基于soa的软件应用程序。m4是一个软件应用程序(采矿、映射、建模和管理系统)对矿业资源。整个项目结构由八个主要部分相关项目开发和实现。系统通过一系列的构建迭代,这将在下面的章节中讨论。

研究的有效性是衡量识别、确定,并实现最有效的软件工程组合之一:基于soa架构,高效的开源架构和解决方案,敏捷开发流程和客户端和云应用程序部署。

结构化的SCRUM敏捷方法称为应用开发和完善功能原型迭代的需求改变了(41,42]。案例研究系统组件构建SOA,以确保他们可以作为独立的模块通过服务网关。这个系统的架构包含方面的人际关系,可持续性,在自然资源和服务可靠性,映射,仿真和系统管理(m4)阶段,以及交付阶段。

云基础设施部署和分布式计算是用来满足这些需求。开发应用程序的模块开发等功能服务,是相互联系的,可以单独使用和重新创建一个连贯的系统额外的模块。矿产和资源数据银行,以及应用程序来管理数据库,建立明确的m4系统。他们为开源作为数据库,开发库和程序。

SCRUM方法是用来保证透明m4评估和发展的过程,以及利益相关者的参与项目的各个组件之间的动态交互。由于采用开源工程和项目治理方法,学者、政府和企业已经形成了一个多边接口来解决一系列的合作伙伴。

[ICT研发项目叫做m4:https://www.openm4s.org],在[ICT研发程序名为m4:https://www.openm4s.org].org]图2描述了m4基础设施,包括开源库,服务,免费主机,程序,数据库管理系统,软件业务资源管理。互操作性和开放标准的基础是客户机-服务器体系结构和基于浏览器的客户端。计划内的m4,图形也说明了组件和信息流。


图2
m4 (https://www.openm4s.org)建议的体系结构。

模块的开发管理和组织使用SCRUM-driven敏捷软件开发过程(15]。以下部分解释了SCRUM的实施在这个案例研究中,以及分配的责任和团队结构:SCRUM敏捷规范建立的过程。SCRUM过程中存在的角色和工作简要总结如下。(一)SCRUM Master负责领导SCRUM会议,维护团队过程,并确保符合所有SCRUM原则(43,44]。(b)SCRUM教练促进会议,协助团队达成共识,确保高质量的开发环境和团队。(c)SCRUM团队组成的开发人员、测试人员、架构师和分析师,这是一个跨职能的团队。这个群体是整个项目的控制输出,并积极参与建设。集团负责开发特点,达到卓越和功能标准(45]。(d)产品负责人是一个个人服务终端客户和投资者的目标。产品所有者负责所有方面的质量与客户的需求。图3演示了一个典型的sprint周期。


图3
一个sprint周期的一个例子。
3.1。m4过程团队组织

项目开发团队中描述表1m4的过程。产品的所有者提供战略、经济学、交付计划和设计指南。SCRUM master熟悉m4的体系结构框架,以及上下文的需求和特性。他们负责业务分析和质量保证,以及sprint周期管理。

表1
SCRUM团队m4。

以下是每个项目参与者的主要职责和任务:

项目总监(PD)的职责是制定、监督和管理的项目。

Co-PD (co-project总监)负责协调和控制项目的操作,以及维护与公众和行业合作伙伴交互。

软件和计算机系统专家负责监督系统设计和性能评估。

工程管理专家监督项目管理和质量保证的责任。

团队领导负责安排并进行设计、实现和交付活动。

单位实施、调试、验证和报告是开发团队的工作。

Co-project主管的职责是处理交互和与公共和商业合作伙伴。

兼职采矿和软件专家值班的验证和确认m4及其模块。

顾问(学生监控)的监测和通知义务UG / PG m4项目的学生学习。

兼职程序员的职责模块构建,调试和验证。

实习生从事不同组件的m4项目作为研究和实施和记录他们的任务分配。

图4说明了m4项目的工作分解结构(WBS),以及为每个块相关的个人活动。


图4
m4项目的工作分解框架和资源的人。

下面是SCRUM的描述方法和它的许多方面适用于该项目。

3.1.1。用户故事

客户故事封装了用户使用该系统的目标。从客户的角度来看,这一目标转换为用户故事(46]。产品负责人(项目总监和导演)设计一个批准测试卡基于用户故事,和工程师构建这些故事。批准测试卡由一系列的测试实例,用于评估完成客户的故事。只有当批准测试通过一个用户故事将宣布成功。然后转换成用户故事的系统特征(17]。特点是一个单元的功能,必须纳入系统或“任务一个角色是一个单位的功能,必须纳入系统”或“执行任务,需要”。

个人特性是m4项目分成更小的单位。然后,为每个特定的任务,构造故事卡片。每天平均工作时间是8小时,任务的完成时间是5 - 15天。每个故事卡片通常由一个或两个工作团队的成员。作业优先级根据它们的重要性。每个成员的团队决定先完成的故事。

图5说明了两个故事,直到下一个叙述是选择执行。


图5
故事卡片使用的项目。
3.1.2。冲刺

根据SCRUM过程,编程是分裂/ 2或四周的冲刺。短跑是周期性迭代的开发由特定任务完成(36]。在每个sprint的开始,在一个sprint讨论会议,任务被分配到冲刺基于积压状态。创建m4项目也应该之前一周sprint(名叫sprint 0)。这使得程序员更多的自由学习的工作平台,科学的解决方案,并可重复使用的材料。

在七个冲刺,m4最初的模块已经完成。sprint 1日由九个故事,七个冲刺的时间框架内完成的,最后的两个故事被添加到2日冲刺完成后。每个sprint是记录在一个MS Excel文件,包括所有的每个故事的细节,包括团队成员的工作,它需要完成的时间,等等。最初的sprint是可视化的表2作为一个例子。

表2
最初的sprint m4项目,开发在Microsoft Excel。

SCRUM过程的一部分,产品负责人,团队,第三方,SCRUM master定期会面解决过程中出现的问题。集会发生,保证项目顺利进行,生产系统的整体质量阶段保存和维护。每天SCRUM会议,sprint回顾会议,为冲刺评估会议,会议计划冲刺,冲刺释放会议都是SCRUM过程的一部分范式。这样5进行会议和监控整个m4部署过程在不同的场景。下面的内容将超过这些一个接一个的会议:

(1)会议计划Sprint。将会有7 sprint会议做一个工作计划,将在一个sprint完成。每两周一个会话通常进行的。SCRUM项目所有者和组(m4项目总监和导演)识别冲刺目标在这个会议。在sprint评估会议,sprint的成功是评估。产品负责人重视故事卡片,这意味着他或她描述最重要的SCRUM团队。最后,SCRUM团队必须创建一个“疾跑”计划和sprint backlog,指定需要多长时间来完成分配的工作(47]。

(2)每天SCRUM。有一个定期的SCRUM会议的主要目标是确保应用程序的功能是实现他们计划的顺序。这次会议通常发生在每一次冲刺的开始和持续20到35分钟。这些会议将在规定的小时。在这次会议期间,每个团队成员将回答以下三个问题,如:(我)多少和什么样的工作你直到昨天?(2)你关于今天的工作目标是什么?(3)什么是限制你实现目标的障碍?

如果一个问题来了,这是团队经理的角色(正式名称是SCRUM团队)简化并解决问题。悬而未决的问题是在稍后的会议上再次强调。这个会议将在同一块场地,与此同时,和前一个男人的时间是一样长的。

(3)Sprint回顾会议。每次冲刺后,有一个会议安排。参与者的团队现在他们取得了什么,完成sprint在这个会议期间完成。通常,这个会议需要演示的新发明的形状特征。大多数的“疾跑”目标得到满足m4 SCRUM团队,和95%的sprint待办事项列表中的待办项被获取,以及大多数的产品待办事项列表中的待办项。因此,98%的项目的元素像m4满足“执行”标准,批准和有一个“做”的标签。剩下的2%的元素没有实现在sprint计划在即将到来的冲刺。元素被关闭时,项目经理(产品所有者)感到满意98%交付记录,修改下积压突出特性,需要额外的实现。(一)m4项目总监和co-project董事批准所有完成每一个sprint的故事。(b)会议期间,项目总监接受完整的功能。(c)对于每一个故事在一个sprint,所有的验收测试运行。(d)整个代码代码进行评估。(e)在缺陷积压不包含bug和问题。(f)所有故事点完成批准出版。(g)产品被彻底检查,未发现严重的错误。(h)一个成功的创建了备份。(我)大多数的安装文档更新。

(4)在Sprint回顾。m4团队的成员去了团队的程序的方法,相互关连,行为特征,提炼方法技巧等在此会议。组长(SCRUM Master)和团队成员在SCRUM会议期间讨论了三件事:顺利,什么并不顺利,什么可以改进下一个sprint。团队的所有性能(指标)的形式评估,增长和方法(kpi)的形状是强调,正如前面已经解释的研究论文。也建议团队成员交换技术技能和知识,他们与产品所有者保持不断的交流,等等。这次会议发生在每个sprint和持续大约2和3小时。

(5)规划。在发行版计划安排中,发布策略会议是一种定义方法,排列优先级,和分离软件功能在一个正在进行的和不受干扰的方法。这需要识别和承诺如下:(一)发布目标(b)优先的一组用户故事(功能开发)(c)用户故事的粗略估计(d)一个发布日期

以下是m4的主要输入步骤期间举行这个会议的项目:(一)用户故事是评估团队的成员,即。,使智能猜测故事的大小。(b)找到你的冲刺速度,故事点的数量你完成冲刺;你可以找到更多的信息在我们的前一篇文章。(c)使用预测来计算故事点,完成了基于日期的版本(的速度x短跑的数量)。(总故事点 速度)冲刺预计将完成绩效所需要的版本。

故事点(上图)计算用于选择最重要的故事。选择功能版本如果所有的故事将完成预期竣工日期(上图)计算。

4所示。集成SOA和SCRUM

在本节中,我们将探索SCRUM,如何开发软件的过程,和SOA架构风格,相互作用。SOA体系结构提供了一个有组织的和良好定义的技术架构,包含了敏捷性的概念和设计模式,使质量、效率和生产力。构建灵活和自适应系统,服务的可重用性和抽象16)工作。通过构建新的服务和修改现有的底层架构,SOA支持敏捷性在设计层面上,而不是修改架构。SCRUM支持增量式开发和更快的客户反馈。SCRUM促进增量开发,允许客户和开发团队更快地提供反馈。SCRUM和SOA帮助企业建立业务和发展战略是一致的。

m4项目开发环境使用的概念类似于SCRUM和SOA过程发展中必要的软件达到共同的目标。SOA操作时仍然可以利用SCRUM敏捷管理良好的环境没有不良的重叠。一个清晰的策略让温和措施的变化,另一方面,应该设计。

SCRUM还可用于传统的软件或设计通过指定需求积压和为客户提供增量的结果。然而,额外的开发支出和总体项目成本预计48]。

当涉及到成本效益和响应性,组织设计中扮演着关键角色在帮助敏捷实现宣称的好处。否则,敏捷方法可能只提供一个小对组织的价值。

SOA和SCRUM,正如前面说的,是两个技术,追求不同的路径。SCRUM是一种自底向上的方法过程开发(始于基本设计和以原型交付)。服务开发了基于SOA的系统(自顶向下方法)。问题的出现,这些不同的方法是如何彼此兼容使用时在开发过程?另一个争论是如果SOA遵循敏捷方法在SCRUM一样吗?如果答案是肯定的,您应该如何进行呢?最后,这两种方法如何结合最大化每个单独提供的好处?这一节将介绍这些担忧,以及SOA和SCRUM的相似性度量。图6说明了标准SOA和SCRUM开发范例。


图6
一个基本的SOA和SCRUM开发过程。

表2显示最基本的SOA和SCRUM指标,可以帮助企业和消费者希望使用SOA和SCRUM组合在一个软件工程项目(表中3)。

表3
典型的SOA SCRUM和指标。

一些SCRUM和SOA指标结合使用SCRUM和SOA环境。这些度量SOA集成SCRUM和指标,也有类似的目标,但不同的术语。开发过程中可以适当加快当这些kpi测量,导致增强的业务敏捷性,适应性,SOA的兼容性和SCRUM设置。

比率测量在SCRUM和故事与计划完成比例测量的新服务和服务在SOA评估产品性能使用比率和总百分比。他们都是测量服务和工作,但是它们使用不同的术语。团队速度、开发时间和开发时间平均三个指标的团队用来跟踪其进展和完成服务所需的时间。这个指标可以结合团队速度测量,可以用作SOA集成测量和SCRUM。因为SOA SCRUM和使用不同的指标来评估质量,但他们的目的都是一样的,这两个指标可以作为质量保证指标来衡量服务质量的SCRUM模型。

团队成员准备当涉及到团队工作热情度规吗?free-planned架构团队的成员将愉快地工作,遵守所有的法律和规则,如果他们感到满意,在一个令人愉快的工作环境。他们将合作在一个团队中设置。当团队成员正在急切地因为他们是幸福的,他们之间的交流永远是愉快的。

5。SCRUM和SOA讨论的兼容性

SOA和SCRUM的主要目标是使整个组织敏捷利用服务,比如软件应用程序构建块(49]。也使用SCRUM流程范例开发软件涉及增加组织灵活性结合SCRUM原则可以提高协作、沟通和反馈(13,14]。虽然有一些相似之处和SCRUM和SOA之间的不兼容,如前所述,之间有一定的区别和不兼容两种技术来设计一个框架的集成,这两种开发方法的兼容性和通用性研究[50,51]。

5.1。SCRUM和SOA的兼容性

它可能不清楚为什么SCRUM和SOA之间的共性和兼容性是必需的。这两个概念(过程和建筑风格)是完全独立的。尽管大多数SOA团队是下意识地知道如何计划和发展服务,确定两个一起使用时的兼容性是明智的和有价值的。重点是完全服务设计和有关政策。SOA,像SCRUM,刺激特定的团队组成和沟通模式团队间基于政策(3]。SCRUM是类似于人类的手工作使用手套,而SOA是类似手套。大多数的SCRUM和SOA原则被认为是兼容的,因为他们都是适应性的方法(52]。尽管SOA,利用传统的方法,例如,瀑布设计、预测,预测技术主要取决于需求评估和细心安排每一个周期的开始。任何变化,必须将受到全面监控和修改优先级程序。敏捷方法采用一种自适应技术没有广泛的准备完成但只有特定的即将到来的与功能相关的工作必须被分配来实现。球队经常响应不断变化的产品需求。定期产品彻底评估,减少严重错误主要在未来的可能性。敏捷方法的强度是客户交互,以及敏捷制造环境的特征是开放的对话和最小的文书工作。基于团队紧密合作,经常在同一地理区域。因此,在SOA项目的创建,敏捷模型是最适合的快速实现适应性服务(53]。SCRUM应用程序实现将是无效的缺乏一个坚实的理解组织的目标。没有一个清晰的图片如何开发和创建利用SCRUM流程概念的指导方针,SOA是一种时间和钱的损失。因为它强调了能力与修改,反应采用SOA作为一个广泛的技术,设计软件的应用也在增长。因为SOA开发和敏捷开发都需要适应变化,利用敏捷方法似乎是一个逻辑适合构建SOA应用程序。

因此SCRUM和SOA都是关于敏捷性,他们可能利用结合采用一系列的原则和想法,并不是相互排斥的。通过这种方式,他们彼此保持平衡(54]。

5.2。SCRUM和SOA共性

SOA是一个架构方法,突出了商业组织的必要性是聪明,能够应对快速商业变化,正如前面。重用软件的目标是模糊不清的;开发服务可以帮助达到这一目标。团队建设服务的SOA方法,可以组合成应用程序(48,55]。SCRUM过程强调改变反应在应用程序开发56]。团队可以帮助企业变得更加敏捷,通过融合技术和非技术的方法。SCRUM和SOA是互补的,也有类似的目标。变化是灵活的在这两种情况下,和公司必须能够处理成功。因此,SCRUM为开发基于soa的应用程序可能是一个可行的选择。

5.3。SOA和SCRUM逆境

而SCRUM和SOA似乎是兼容的,这两种方法之间有显著差异时应该承认和管理使用SOA和SCRUM在同一个项目57]。的一个主要原因是,两种技术源自不同的方向去相反的方向。SCRUM通常被用于小项目,但是随着流程改善和从业人员获得了知识和经验,SCRUM宣言的标准可以用于大规模的软件项目。SOA应用程序开发方法是自顶向下和分治法(4]。“分裂”的一部分的方法就不可避免地导致跨团队缺乏沟通。似乎有三个主要领域在SCRUM和SOA在彼此冲突。(1)SOA促进建筑前期;然而,SCRUM社区并不鼓励预先设计和考虑大设计前期(BDUF)是一种反模式。(2)SOA促进团队按照功能划分的,而敏捷支持跨职能团队的形成。(3)SOA在开发团队缺乏正式的反馈和沟通,而敏捷强调频繁的评估技术和个人水平。

很难改变采用SOA时在一个大型的设置(53]。其他的困难,比如缺乏团队的沟通和服务的可发现性,可能存在除了软件灵活性和成本。相反,我们应该争取健壮的协作和透明度。每个小组将提交一个轻松定制版本的服务可用于内部测试。测试数据将从服务由服务团队隔离,以便它可以继续函数即使代码是损坏的。客户服务团队将建议清晰和简单的指令添加额外的调用服务存根。

6。结论

而不是从零开始,面向服务的体系结构(SOA)允许重用现有系统的功能。这个可重用性属性在基于soa的系统提高企业的经济效益。相比之下,SCRUM流程模型关注周期和客户反馈增加功能,同时使进化需求的可预测性。本研究建立一个基线之间寻找共同点和兼容性SCRUM和SOA过程,以确保最有效使用结构化的SCRUM管理过程的基于SOA的应用程序开发。大多数的SCRUM和SOA规则并不是互不相容的,根据这项研究。SCRUM和SOA都不是相互排斥的。他们都利用规则和原则适用于灵活性。基于特定的SCRUM和SOA使用正式的kpi指标,可以确定组合的成功SCRUM和SOA开发环境。所有组织希望在一个集成的环境中应用SCRUM和SOA应该能够评估他们的敏捷性,复杂性,有效性,基于这样的kpi和价值。尽管研究的产出是准确的,研究人员强调了几个约束实施之前必须仔细评估结论的SCRUM和SOA集成项目企业[58 59]。

7所示。未来的工作

本研究工作已经完成根据研究范围和领域但剩下一些工作在一个领域,可能是未来的研究方向。为了更好的理解,可以使用SCRUM流程模型在分布式环境中。此外,为了确定SCRUM和SOA组合对项目性能的影响时采用在分布式开发环境中,一个系统评价和确定指标和kpi应该建立在所有集成SCRUM和SOA项目,是否分布。

数据可用性

没有数据可用。

的利益冲突

本文作者声称,不包括任何利益冲突。

确认

不能开始这项研究也取得Shaqra大学的鼓励,和它的继续支持。