敏捷架构:规模化敏捷开发的策略敏捷架构:规模化敏捷开发的策略
1.迈向敏捷架构
体系结构提供了构建系统的基础,体系结构模型定义了体系结构所基于的愿景。架构的范围可以是单个应用程序,应用程序系
列,组织,或许多组织共享的Internet等基础架构。无论范围如何,我的经验是您可以采用敏捷的架构建模,开发和发展方
法。
以下是一些让您思考的想法:
架构没什么特别的。异端你说!绝对不。敏捷建模的谦逊价值表明每个人对项目都有同等的价值,因此任何担任架构师和他们
努力的人都同样重要,但不会比其他人的努力更重要。是的,优秀的架构师拥有适合手头任务的专业技能,应具备有效应用这
些技能的经验。然而,完全相同的事情可以说是优秀的开发人员,优秀的教练,优秀的高级管理人员等等。谦虚是您架构工作
的重要成功因素,因为您需要避免象牙塔式架构的发展并避免您的队友的敌意。架构师的角色对大多数项目都是有效的,它不
应该是由基座上的某个人完成的角色。
你应该提防象牙塔式架构。象牙塔式架构通常由架构师或架构团队开发,与项目团队的日常开发活动相对隔离。强大的架构专
家会开发并开发一个或多个模型描述了团队中的仆从为架构师建立的最佳体系结构。象牙塔架构通常是美丽的东西,通常有很
多花哨的图表和精彩的视觉陈述,宣称它们是你的救赎。理论上,这通常是您的架构师的工作基础,象牙塔式架构完美地运
作。然而,经验表明象牙塔架构存在重大问题。首先,“minion开发者”不太可能接受这种架构,因为他们在开发过程中没有发
言权。其次,象牙塔式架构通常是未经证实的,象牙塔式架构师很少会弄脏他们编写代码的手,因此在您知道他们实际通过技
术原型提供的具体反馈之前,您的项目将面临重大风险。第三,如果架构师除了模型之外什么也不做,因为你无法思考系统所
需的一切,象牙塔架构将是不完整的。第四,象牙塔式架构促进了软件的过度建设,因为它们通常反映了任何系统所需的每个
功能。架构师曾经参与其中,而不仅仅是您的系统实际需要的功能。
每个系统都有一个架构。但是,它可能不一定具有描述该架构的架构模型。例如,一个小团队采用XP方法在同一个房间里一
起工作可能没有必要对他们的系统架构进行建模,因为团队中的每个人都非常了解模型并不能为他们提供足够的价值。或者,
如果存在架构模型,则通常会有一些简单的旧白板(POW)草图可能由定义的项目隐喻支持。这是因为XP的通信方面,包括
结对编程和集体所有权,否定了需要在整个项目中开发和维护的架构模型的需要。其他团队 - 不遵循XP的团队,更大的团
队,人员不在同一地点的团队 - 将发现他们的环境中固有的更大的沟通挑战要求他们超越口碑架构。这些团队将选择创建架构
模型,以便为开发人员提供有关如何构建软件的指导。从根本上说,您执行体系结构建模的原因是为了解决开发团队成员无法
实现共同愿景的风险。
架构规模敏捷。传统技术也是如此。为项目制定可行且可接受的架构策略对于您的成功至关重要,尤其是在敏捷团队大规模发
现的复杂情况下。扩展问题包括团队规模,法规遵从性,分布式团队,技术复杂性等(有关详细信息,请参阅软件开发上下文
框架(SDCF))。一种有效的体系结构方法使您能够解决这些扩展问题。
2.整个生命周期的架构
图1描绘了敏捷模型驱动开发(AMDD)的生命周期。在“迭代0”(Disciplined Agile Delivery(DAD)中的初始阶段),您需
要使项目井井有条并朝着正确的方向前进。这项工作的一部分是初步要求设想和架构设想,以便您能够回答有关项目的范围,
成本,进度和技术策略的关键问题。从架构的角度来看,在迭代0期间,目标是确定您的团队的潜在技术方向以及您可能面临
的任何技术风险(应通过代码证明风险来解决)。此时您不需要详细的架构规范,事实上在软件开发项目开始时创建这样的规
范是一个非常大的风险。相反,在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划,在实时
(JIT)基础上识别细节。最终的结果是,体系结构随着时间的推移逐渐出现,最初由于更需要设置项目的基础而更快,但是
随着时间的推移仍在不断发展,以反映对开发团队的更多理解和了解。这遵循小增量中的实践模型并降低项目的技术风险 - 您
始终拥有一个坚实且经过验证的基础,可以从中工作。换句话说,你想要考虑未来,但等待采取行动。
图1.软件项目的敏捷模型驱动开发(AMDD)生命周期。