Scrum敏捷项目管理

在Scrum项目中集成软件架构需求的最佳实践

Scrum等现代敏捷软件开发方法建议使用“just in time”应用程序开发的愿景,往往使人们仅关注对当前sprint直接有用的活动。您如何在Scrum的迭代过程中包含具有长期视角的活动(例如企业软件架构)?

作者:Adamantium软件工程公司的Markus van Aardt, http://www.adamantiumse.com/

在过去的十年中,敏捷方法使软件开发和交付实践得到了更新。然而,自1980年代以来,迭代式和增量式开发方法就出现了,而且并不是那么新。敏捷棍棒的根源是《敏捷宣言》对旧观念的重新改造而创建的社区。敏捷方法的不同之处在于,它们将软件开发的范围放在软件需求,产品交付和人员管理等较软的领域之外。与传统的Waterfall过程甚至Boehm的Spiral模型相比,它们提供了一种管理工具,可提高软件工程师以更少的时间和更低的成本提供更好的解决方案的能力。但这不是故事的结局。

我发现技术趋势如何超越传统智慧作为新真理,并立即否定过去的一切,常常使人感到很有趣。敏捷和Scrum就是这种情况。因此,当我最近遇到一位高级IT高管时,他认为他的项目由于敏捷开发模型而不受体系结构的影响,这让我感到惊讶-很糟糕。

为了提供有关此问题的上下文,从企业和一般软件工程的角度了解软件体系结构很重要。

企业软件体系结构根据技术结构,技术环境和业务环境定义和传达应用程序格局。企业软件工程需要在通过特定企业软件体系结构(也称为参考体系结构)的边界和指南提供的结构内进行。在设计和开发过程中对齐不良会导致操作对齐不良。架构对齐是有效的企业软件工程的不可协商的要求。无论是传统的瀑布式处理,Scrum还是极限编程(XP),每种开发方法都适用。

让我们考虑两种情况。尽管工程师很少会遇到新的未知环境,但我们应该考虑可以引用很少或根本没有环境的干净环境。新业务通常是这种情况。第二种更常规的方案是现有(或旧式)目标环境。当遇到这样的环境时,在产品开发的设计和构造阶段中将其包含和引用是至关​​重要的。

那么,如何从干净的板岩或人口稠密的环境中获得成熟的建筑呢?下图将为您提供实现成熟,生动的建筑环境的路线图。

 实现成熟生活环境的路线图

定义参考架构

没有现有参考体系结构的目标环境通常是新的,并且是软件开发的最简单起点。这些环境通常没有遗留体系结构,并为工程团队提供了明确的条件。现在,团队的一部分职责就是确定目标环境体系结构。尽管敏捷方法可以即时生成参考架构,但应将这些活动仔细地划分为不同的重点领域。您应该在进行任何其他开发工作之前创建体系结构,尽管过程必须知道未决的技术要求。

企业的参考架构是由企业架构团队和相关主题专家(SME)首先创建和维护的。基于体系结构策略,参考体系结构将反映当前的成熟度,并向预定的最终状态绘制地图。战略由许多因素决定,但主要由技术交付物,财务状况和更大的企业战略驱动。正在进行的设计和开发会在有限的时候根据需要进一步扩展参考体系结构。由于参考架构指导了这些活动,因此通常需要与企业架构,中小企业和技术领导者商讨重大变更。

这提供了一个开始的位置,随着环境的发展和进一步成熟,该位置将随着时间的推移而增长。

审查参考架构

通常,已经存在需要交付产品的参考体系结构(无论是否已记录)。该项目将从审查现有参考体系结构或详细记录未记录的体系结构作为该项目的输入中受益。对于未记录的体系结构,建议此周期先于其他交付周期,以确保项目团队对环境有正确而普遍的了解。

此审查应该是初始sprint的项目积压中的初始(也是最关键的项目)。可交付成果和常规sprint结果之间的唯一区别是,参考体系结构是项目中后续sprint的输入。

更新参考架构以支持项目

并非所有项目都可以简单地遵守现有的参考体系结构。许多软件产品将挑战参考体系结构(或技术环境),以创建更合适的环境以实现有效运营。这是项目架构师或设计师开始与企业架构团队/负责人互动的地方。尽管Scrum团队没有专门的架构师或设计角色,但必须通过整个团队或以个人技能将这种能力包括在团队结构中。有效的架构参与高度依赖于这种功能。

Scrum项目中的大多数sprint都会对架构有所依赖。这可以是来自先前冲刺的项目内部,也可以是体系结构环境中的项目外部或其他正在进行的项目。需求在项目中正式确定后,必须根据参考体系结构进行评估。如果所需的组件已经存在,则只需很少的替代开发或配置即可重复使用。这给项目和组织都带来了两个关键的好处。

通过此模型获得的收益与财务和绩效相关。如果存在关键的企业功能并可以重复使用,则该项目通常只需很少的额外资金即可增加组织的总投资回报率(或ROI)。其次,根据敏捷方法的本质,对现有工件的重用可以减少交付时间,并可以简化环境复杂性。

需求和后续开发需要作为修订反馈到体系结构模型中。项目架构师(请参阅上面有关此角色的注释)需要根据现有参考体系结构明确识别需求,评估体系结构的更改并协商所需的更新。开发团队要求的更改必须支持现有和将来的体系结构。该体系结构的最终决定和责任仍由企业体系结构团队负责。

项目后审查和架构确认

现代组织不断变化。当组织采用敏捷方法进行软件开发时,这清楚地表明该组织(至少是其软件工程师)理解这一点。因此,至关重要的是,在与sprint审查和回顾活动同时进行的同时,通过修订的参考体系结构指南中的审阅和确认最新的体系结构来封闭体系结构反馈环。这降低了通常与未来开发和支持活动相关的风险和成本。

更进一步,成熟的架构审查流程将为Scrum团队提供有关更大架构变更的积极反馈。这标志着架构协作对于确保在垂直和水平方向上进行这些事务的参与的重要性。垂直参与可确保单个项目与企业架构和治理之间的一致性,而水平对齐可改善项目间的参与。

闭幕致辞

毫无疑问,敏捷方法已在软件开发方法论中证明了它们的地位。但是,应该提一个警告:这里是巨龙。在软件开发方面,没有灵丹妙药。无论项目选择的是传统方法还是敏捷方法,反之亦然,每种解决方案都需要仔细考虑所选方法。敏捷方法的核心理念非常适合现代和动态环境。但是,它们不会降低经验,风险管理和常识。最终,开发的解决方案仍然是企业的公民,需要遵守土地法律:企业架构治理。

关于作者

Markus van Aardt是金融行业的软件工程师和应用程序架构师。在创立Adamantium Software Engineering(一家软件和技术咨询公司)之前,他在德意志银行担任软件开发人员,开始了他的职业生涯,他目前在担任银行和金融服务架构师的同时,还经营着该软件和技术咨询公司。找到更多关于 http://www.adamantiumse.com/.

1关于在Scrum项目中集成软件体系结构需求的最佳实践的评论

  1. 这是一个优秀的文章…我认为敏捷社区对将架构(和设计)整合到敏捷开发中没有足够的思考。

    以我的经验(主要是使用Scrum),在有参考体系结构的情况下,项目的运行速度更快且质量更高,Scrum团队在项目早期花了一些时间来开发,审查和更新参考体系结构。

1引用和引用

  1. 软件开发Linkopedia 2013年6月

评论被关闭。