加入收藏 | 设为首页 |

老歌经典-「灵敏架构」规模化灵敏开发的战略

海外新闻 时间: 浏览:305 次

与盛行的观念相反,架构是灵敏软件开发作业的一个重要方面,就像传统的作业相同,而且是扩展灵敏办法以满意现代安排的实践需求的要害部分。可是,灵敏专家的架构办法与传统主义者的办法略有不同。本文谈论以下问题:

  1. 迈向灵敏架构
  2. 整个生命周期中的架构
  3. 谁担任架构?
  4. 具有“架构一切者”的人物
  5. 大规划的灵敏架构
  6. 依据需求树立您的架构
  7. 为您的架构建模
  8. 考虑几种挑选
  9. 记住企业束缚
  10. 游览灯
  11. 用作业代码证明你的架构
  12. 交流您的架构
  13. 想想未来,等候举动(推延许诺)
  14. 采纳多视图办法
  15. 这是怎样运作的?
  16. 处理灵敏和架构周围的神话

1.迈向灵敏架构

体系结构供给了构建体系的根底,体系结构模型界说了体系结构所依据的愿景。架构的规划可所以单个运用程序,运用程序系列,安排,或许多安排同享的Internet等根底架构。不论规划怎样,我的经历是您能够选用灵敏的架构建模,开发和开展办法。

以下是一些让您考虑的主意:

  • 架构没什么特别的。异端你说!肯定不。灵敏建模的谦逊价值标明每个人对项目都有平等的价值,因而任何担任架构师和他们尽力的人都相同重要,但不会比其别人的尽力更重要。是的,优异的架构师具有适宜手头使命的专业技能,应具有有用运用这些技能的经历。可是,彻底相同的作业能够说是优异的开发人员,优异的教练,优异的高档办理人员等等。谦善是您架构作业的重要成功要素,由于您需求防止象牙塔式架构的开展并防止您的队友的歹意。架构师的人物对大多数项目都是有用的,它不该该是由基座上的某个人完结的人物。
  • 你应该防范象牙塔式架构。象牙塔式架构一般由架构师或架构团队开发,与项目团队的日常开发活动相对阻隔。强壮的架构专家会开发并开发一个或多个模型描绘了团队中的奴隶为架构师树立的最佳体系结构。象牙塔架构一般是美丽的东西,一般有许多花哨的图表和精彩的视觉陈说,宣称它们是你的救赎。理论上,这一般是您的架构师的作业根底,象牙塔式架构完美地运作。可是,经历标明象牙塔架构存在严重问题。首要,“minion开发者”不太或许承受这种架构,由于他们在开发进程中没有发言权。其次,象牙塔式架构一般是未经证明的,象牙塔式架构师很少会弄脏他们编写代码的手,因而在您知道他们实践经过技能原型供给的具体反应之前,您的项目将面对严重危险。第三,假如架构师除了模型之外什么也不做,由于你无法考虑体系所需的悉数,象牙塔架构将是不完整的。第四,象牙塔式架构促进了软件的过度制作,由于它们一般反映了任何体系所需的每个功用。架构师从前参加其间,而不仅仅是您的体系实践需求的功用。
  • 每个别系都有一个架构。可是,它或许不必定具有描绘该架构的架构模型。例如,一个小团队选用XP办法在同一个房间里一同作业或许没有必要对他们的体系架构进行建模,由于团队中的每个人都十分了解模型并不能为他们供给满意的价值。或许,假如存在架构模型,则一般会有一些简略的旧白板(POW)草图或许由界说的项目隐喻支撑。这是由于XP的通讯方面,包含结对编程和团体一切权,否定了需求在整个项目中开发和保护的架构模型的需求。其他团队 - 不遵照XP的团队,更大的团队,人员不在同一地址的团队 - 将发现他们的环境中固有的更大的交流应战要求他们逾越口碑架构。这些团队将挑选创立架构模型,以便为开发人员供给有关怎样构建软件的辅导。从底子上说,您履行体系结构建模的原因是为了处理开发团队成员无法完结一同愿景的危险。
  • 架构规划灵敏。传统技能也是如此。为项目拟定可行且可承受的架构战略关于您的成功至关重要,尤其是在灵敏团队大规划发现的杂乱状况下。扩展问题包含团队规划,法规遵照性,分布式团队,技能杂乱性等(有关具体信息,请参阅软件开发上下文结构(SDCF))。一种有用的体系结构办法使您能够处理这些扩展问题。

2.整个生命周期的架构

图1描绘了灵敏模型驱动开发(AMDD)的生命周期。在“迭代0”(Disciplined Agile Delivery(DAD)中的初始阶段),您需求使项目有条不紊并朝着正确的方向行进。这项作业的一部分是开端要求幻想和架构幻想,以便您能够答复有关项意图规划,本钱,开展和技能战略的要害问题。从架构的角度来看,在迭代0期间,方针是确认您的团队的潜在技能方向以及您或许面对的任何技能危险(应经过代码证明危险来处理)。此刻您不需求具体的架构规范,现实上在软件开发项目开端时创立这样的规范是一个十分大的危险。相反,在迭代期间经过在每次迭代开端时的初始迭代建模或经过在整个迭代中进行模仿计划,在实时(JIT)根底上辨认细节。终究的成果是,体系结构跟着时刻的推移逐渐呈现,开端由于更需求设置项意图根底而更快,可是跟着时刻的推移仍在不断开展,以反映对开发团队的更多了解和了解。这遵照小增量中的实践模型并下降项意图技能危险 - 您一直具有一个坚实且经过验证的根底,能够从中作业。换句话说,你想要考虑未来,但等候采纳举动。

图1.软件项意图灵敏模型驱动开发(AMDD)生命周期。

图2描绘了Disciplined Agile Delivery(DAD)东西包描绘的灵敏/底子生命周期。 DAD东西包具有本文中描绘的一切体系结构战略.DAD是一种混合体,它选用来自各种来历的战略,包含灵敏建模,Scrum,XP,灵敏数据等等。 实践上,DAD在处理方面做了“深重的作业”,由于它捕获了来自这些不同办法的主意怎样组合在一同。 由于DAD不是规定性的,所以它支撑几个生命周期。 图2的生命周期是DAD依据Scrum或“底子”的灵敏交给生命周期,但它也支撑精益/看板类型的生命周期和持续交给生命周期。 咱们的主意是,您的团队应该选用对您所面对的状况最有意义的生命周期。

图2. DAD Agile生命周期(单击以打开)。

这种轻量级初始体系结构建模办法的代替办法是测验在完结开端之前彻底界说您的体系结构。这种极点一般被称为预先规划(BDUF)。这种办法背面的动机一般是项目办理不期望任何人行进,直到就办法或“一个数据本相”达到一起。不幸的是,这种办法一般导致没有人向前推动很长一段时刻,象牙塔式架构往往在实践中证明是软弱的,这种架构关于你实践需求的东西来说是过度的,和/或开发子团队在他们的具有,由于他们不能等候架构师完结他们的作业。这种办法一般是所涉人员的一种思想办法的成果,是瀑布式软件开发年代(20世纪70年代和80年代,当今许多办理人员都是软件开发人员)的留传思想进程。实践状况是,架构的开展十分困难,这是您成功的要害,也是您从一开端就无法做到的。进化(迭代和增量)办法经过一次开发一次,而且只在您需求它时,处理了架构不充分或不恰当的危险。


3.谁对架构担任?

这个问题比你幻想的要杂乱得多。答案很简略,适用于小型灵敏团队(绝大多数),团队中的每个人都担任架构。实践模型与其别人告知你,你真的不想独自作业,坦率地说,架构是十分重要的,不论他们多么聪明,都不能留在一个人的手中,因而架构应该是一个团队的尽力。在一个小型项目团队中,比方十五人或更少,我更乐意包含一切开发人员,由于它答应一切参加者在体系结构中发表意见。这增加了每个人对体系结构的了解和承受,由于他们一同作业一个团队。当架构证明缺少时,它也增加了开发人员乐意改动架构方面的时机,或许它不像你开端幻想的那样扩展,由于它是集团的架构而不仅仅是他们的架构。当一个人开发某些东西时,它就变成了“他们的宝物”而且没有人喜爱听到他们的宝宝是丑恶的 - 当你发现他们的架构有问题时,他们或许会抵抗任何批判。当整个团队开发一个架构时,人们一般更乐意从头考虑他们的办法,由于这是团队问题,而不是个人问题。

可是,“每个人都具有架构”战略存在两个底子问题:

  • 有时人们不同意。当团队未达到一起时,此战略或许会大幅溃散,因而您需求具有架构一切者人物的人员来促进协议。
  • 它不会扩展。当您的团队规划较大或地理方位涣散时,在软件开发上下文结构(SDCF)中调出的八个缩放因子中的两个,您将安排您的团队成为一个子团队。在这种状况下,大规划的架构需求和谐安排。

4.具有“架构一切者”

关于任何恰当杂乱的体系,您需求花一些时刻来构建它。您将做一些前期架构幻想,让您开端朝着正确的方向行进,然后架构将需求从那里开展。许多灵敏团队发现他们需求扮演“架构一切者”人物的人,有时称为灵敏处理计划架构师。这个人一般是团队中技能最有经历的人,担任促进架构建模和演化作业。就像Scrum的产品一切者人物担任团队的要求相同,架构一切者担任团队的架构。架构一切者是Disciplined Agile(DA)东西包中的首要人物之一。

架构一切者不同于架构师的传统人物。在曩昔,架构师一般会成为架构的首要创造者,而且是少量参加其间的人之一。他们常常开发架构,然后“开发”它,或许更精确地强制它开发团队。架构一切者与团队协作以开发和开展架构。尽管在架构方面他们是终究抉择计划权的人,但这些抉择计划应该与团队以协作的办法进行。有用的架构一切者是在安排正在运用的技能方面经历丰厚的开发人员,而且能够运用架构峰值来探究新战略。他们还应该对事务范畴有很好的了解,并具有将架构传达给开发人员和其他项目利益相关者的必要技能。

5.规划灵敏架构

在大型灵敏团队,地理方位涣散的灵敏团队或企业规划的架构作业中,您将需求架构一切者团队或企业架构团队(在灵敏建模中,我开端将其称为中心架构团队,这是我从未实在喜爱过的术语)。 大型灵敏团队一般被安排成较小的子团队,如图3所示。每个子团队的架构一切者都是架构一切者团队的成员,这有助于增加每个子团队了解并遵照全体架构的时机。 以及增加全体架构战略满意全体处理计划的悉数需求的或许性。 将有一个全体的首席架构一切者,这或许是一个轮番人物,担任促进团队。

图3.大规划的灵敏团队被安排成子团队的调集。

大规划安排灵敏团队有四种底子战略:

  • 架构驱动的办法。运用此战略,您能够环绕架构中调出的子体系/组件安排子团队。当您的架构具有高质量(松懈耦合且高度内聚)而且在子团队实在开端之前现已辨认出子体系的接口时,这种战略很有用(接口会跟着时刻的推移而开展,但您期望取得杰出的开端)在他们开端)。该战略面对的应战是,它需求以反映架构的办法捕获您的需求。例如,假如您的体系结构依据大型事务域组件,那么一个需求应尽或许专心于单个事务域。假如您的体系结构依据技能层 - 例如具有用户界面(UI),事务和数据层的3层体系结构 - 那么假如或许,需求应该会集在单个层上。
  • 特征驱动的办法。经过这种战略,每个子团队一次完结一个功用,这个功用关于利益相关者来说是一个有意义的功用块。我会将这种战略运用于架构展现了许多耦合的状况,而且您能够运用杂乱的开发实践。这种办法的应战在于子团队一般需求拜访各种源代码来完结该功用,然后冒着与其他子团队发作冲突的危险。因而,这些团队进行了杂乱的改动办理,持续集成,乃至或许是并行的独立测验战略(仅举几例)。
  • 开源办法。运用此战略,一个或多个子体系/组件以开源办法开发,即便它是针对单个安排(这称为内部开源)。此战略一般用于许多团队广泛重用的子体系/组件,例如安全结构,而且有必要快速开展以满意拜访/运用它们的其他体系的不断改动的需求。此战略要求您选用支撑开源办法的东西和流程。
  • 其组合。大多数灵敏团队将恰当地结合前三种战略。

图4描绘了大规划灵敏项意图体系结构活动进程。您一般会看到在大型项目(一般称为程序),地理方位涣散的项目,杂乱(域或技能)项目或企业级(一般支撑灵敏企业架构)上选用这种办法。这种办法有四个重要方面:

  • 幻想初始架构。最小的架构一切者团队担任初始架构幻想,然后将其带到子团队以取得反应和后续演化。关于大型项目/项目,一般还有其他灵敏团队成员参加此初始建模作业,包含产品一切者乃至是要害项目利益相关者。估量作业的架构能够持续数天,关于十分大或杂乱的项目,能够持续数周。关于企业架构作业,企业架构团队一般会在项目初始建模作业中包含项目级运用程序/处理计划架构师,而且一般包含履行利益相
  • 与开发团队协作。在大型项目/程序中,如图3所示,架构一切者团队的成员将在项意图各个子团队中扮演活泼的人物,将架构传递给子团队并与他们协作以经过具体的办法证明部分架构试验。关于企业架构作业,企业架构师将最低极限地充任参谋,他们的专业常识是企业架构,但更好的是他们将成为要害项目团队的活泼成员,承当架构一切者在这些团队中的人物。由于灵敏开发的协作性质,架构一切者只需简略地进行初始架构幻想,或许经过偶尔检查他们的作业来“支撑”项目团队,但他们有必要“卷起袖子”并成为活泼成员项目团队。这将有助于他们防止创立“象牙塔式架构”,这在纸上听起来不错但在实践国际中证明是不切实践的。它还有助于增加项目团队实践运用架构的时机。
  • 将架构传达给架构利益相关者。关于项目团队,架构利益相关者包含与灵敏交给团队,要害项目利益相关者以及开发团队其他成员协作的产品一切者。这些人需求了解架构愿景,现已取得的权衡以及施行架构的当时状况。
  • 更新架构著作。架构一切者团队将发现他们需求偶尔调集在一同,跟着项意图开展改善架构,洽谈架构的更改并依据需求更新架构模型(假如有的话)。这些会议将在项目开端时常常举办,跟着架构的稳固,需求越来越少。关于或许不是中心架构团队成员的开发子团队成员来说,参加一些会议以供给信息,或许他们参加了一些技能原型规划并与调查成果同享,这将是常见的。最好的会议很短,一般不超越一个小时,并常常站在白板周围 - 每个人都应该为会议做好预备,乐意到会和谈论他们的问题,以及作为一个团队一同作业。很快得出抉择。

图4.大规划的灵敏架构流程

6.需求驱动的架构

您的架构有必要依据要求,不然您便是黑客进犯,就这么简略。在辨认架构需求时,自动利益相关者参加的实践对您的成功至关重要 - 请记住,需求来自项目利益相关者,而不是开发人员。技能架构要求的杰出来历将包含您的用户及其直接办理,由于他们一般会对技能要求和束缚有所了解。操作人员必定会对您的布置体系结构有所要求。面向事务的需求的最佳来历正是您期望的 - 您的用户,他们的司理。您安排内的高档办理人员将取得或许导致体系潜在改动事例的见地。

正如您所期望的那样,实践运用正确的工件和并行创立多个模型适用于您的架构需求作业。当您处理架构的技能方面时,您将期望依据技能要求,束缚和或许的更改事例。相同,当您处理体系结构的事务方面,或许辨认软件子体系或事务组件时,您或许需求重视描绘要害运用要求的底子用例或用户故事,以及或许适用于您的体系的要害事务规矩。

架构团队(或架构一切者的小型项目)将犯的一个常见过错是疏忽现有的和相关的工件,例如描绘安排现有技能根底架构的网络或布置图,企业级事务模型(用例模型,流程)图表,作业流程图,公司事务规矩等),或您的体系应契合的公司布置规范(适用于作业站,分支安排等)。是的,现有工件或许已过时或底子不适用于您的作业,但您至少应该尽力检查它们并尽或许运用现有作业。与适宜的人进行一些阅览或谈论或许会为您节约许多精力。换句话说,不要忘掉尽或许重用现有的工件。

了解架构建模的一个重要概念是,尽管它一般在项意图前期发作,但它永久不会首要呈现。从底子上说,您总是会花时刻确认一些要求。其他任何东西都是黑客进犯,黑客必定不灵敏。

7.建模你的架构

架构建模的首要方针应该是就您计划怎样构建体系达到一起或了解。换句话说,你将建模以了解。我的经历是,99.999%的软件项目团队需求花一些时刻来建模他们体系的架构,即便是依靠于隐喻来辅导他们的开发作业的Scrum / XP团队也是如此。尽管你的XP团队正在辨认你的体系的比方,你和你的队友在开发你的初始版别时会想到好几周,但你常常会画出你以为你的体系怎样作业的草图。在AM的操练抛弃暂时模型之后,您或许不会保存这些草图,这一般是由于它们是无法处理的主意,或许仅仅是由于您正在建模以了解问题,所以一旦您这样做,图表就不再对您有价值了。话虽如此,XP团队开发架构模型并没有错。这些模型或许就像你在大众可见的白板上留下的草图相同简略,由于尽管隐喻可所以十分有用的东西,但架构模型一般会供给团队所需的更多细节。正如您所期望的,Disciplined Agile Delivery(DAD)团队也将进行一些架构建模。

您怎样以灵敏的办法为您的架构建模?我一般会尽力创立一个或多个导航图,图表显现体系“景象”的概述。就像路线图概述了乡镇的安排相同,您的导航图概述了体系的安排结构。导航图是体系架构视图的实例。当您阅览有关架构建模的书本和论文时,作者提出的一个一同主题是需求各种架构观念,每位作者都会展现他或她自己的要害视图调集,您需求考虑这些观念。我的经历是,没有一套架构视图适宜每个项目,而项意图性质将有助于界说您应该考虑创立的视图类型。这意味着您创立的导航图类型取决于您正在构建的体系的性质。这在概念上与AM的实践一起运用正确的工件,它告知您应该运用正确的建模技能来完结手头的使命。例如,运用依据J2EE的技能构建杂乱事务运用程序的团队或许会发现UML组件图和作业流图适宜用作体系结构导航图。可是,构建企业数据仓库的团队或许倾向于运用依据其体系结构的数据模型和UML布置图。不同的项目,不同的架构视图,因而不同类型的导航图。风趣的是,两个项目都需求两个导航图,契合多模型准则。您需求灵敏处理您的办法,由于一种尺度并不适宜一切状况。

安排将犯的一个常见过错是将其架构作业树立在其安排结构上。例如,具有强壮数据组的安排或许期望将数据模型作为其体系结构的首要工件,而不论体系的实践性质怎样。当你有锤子专家时,每个问题看起来都像钉子相同。当您运用新技能或测验开发安排简直没有经历的新体系时,这个问题十分老歌经典-「灵敏架构」规模化灵敏开发的战略遍及 - 曩昔运转杰出的安排结构在您的新环境中或许不再适宜您。有关架构和安排结构的意义的更多信息,请参阅Conway规律的安排形式。

要创立导航图,建模作业的首要驱动力应该是假定简略。创立简略内容的做法标明您应该尽力辨认或许的最简略的体系结构办法 - 您的体系结构越杂乱,个别开发人员不会了解它的或许性就越大,过错和溃散的时机就越大。此外,您的架构模型应包含正确等级的信息,显现体系的各个方面怎样协同作业,而不是细节(这便是规划的悉数内容)遵照实践描绘模型简略。您还应该运用最简略的东西来完结这项作业,许多时分,您需求运用白板草图来模仿架构的要害方面。绘图东西能够运用CASE东西。一般旧白板(POW)能够使​​用绘图东西。当纸张和便当贴能够运用时,请勿运用POW。

重要的一点是,当您的一切通讯都是面对面的时,导航图一般足以描绘您的架构。假如不是这种状况,当您的架构一切者无法与开发人员密切协作时(或许某些开发人员坐落长途方位),那么您需求运用文档弥补图表。

当您进行架构建模时,您应该考虑运用可用的丰厚架构形式,但您应该以有用的办法进行。 “形式体系:面向形式的软件体系结构”这本书是开端学习常见体系结构形式的好地方,例如图层,管道和过滤器,署理,模型 - 视图 - 控制器和Blackboard。与剖析和规划形式相同,应该依照常规轻轻地运用形式 - 只需在清晰需求时才将它们引进您的架构中。在此之前,假如您置疑架构形式或许是适宜的,那么您或许以为您将具有需求署理的多个要害服务来历,然后对您的架构进行建模,以便在实践状况呈现时运用此形式。请记住,您正在逐渐开发体系,遵照小增量中的操练模型,而且您不需求在第一天就树立正确的体系结构(即便您乐意,也无法完结此方针)。

您应该认识到,您的架构模型将提醒您的体系对其他体系的依靠性或它们对您的依靠性。例如,您的体系能够经过Internet与信用卡处理服务交互,从留传联系数据库拜访数据,或为另一个内部运用程序生成XML数据结构。网络图和UML布置图关于辨认这些依靠性十分有用,面向进程的模型(如作业流程图,UML活动图老歌经典-「灵敏架构」规模化灵敏开发的战略和数据流图)也十分有用。这意味着这些依靠联系标明或许需求遵照这样的做法:在您的团队与您同享依靠联系的体系的一切者之间正式化合同模型。抱负状况下,许多这些模型现已到位,信用卡处理器或许具有您有必要遵照的严厉界说的协议,而且留传数据库或许具有为其界说的物理数据模型,尽管比如XML数据结构之类的新功用将需求满意的界说。有时,假如没有精确的文档,您需求对旧体系的现有接口进行剖析,有时需求规划新的接口。在这两种状况下,都需求由您的团队,其他团队或适宜的联合开发相应的合同模型。

您应该怎样安排架构建模作业?在项目开端时,我将典型地将架构团队调集在一个独自的房间中进行开端想象。抱负状况下,这个会议将持续不超越几个小时,但在一些较大的项目上,它或许持续几天乃至几周(我会仔细地质疑任何超越两周的尽力)。与平常相同,建模会话越长,由于缺少反应而违背航线的或许性就越大。这个建模会议的方针是就咱们正在树立的体系的格式达到开端协议,或许不是达到一起,而是满意的协议,因而咱们能够开端作为一个团队向前跨进。

8.考虑几种代替计划

正如精益软件开发告知咱们的那样,咱们不该该尽早采纳架构战略,而应该考虑几种代替计划,而且只需它们依然可行,就让这些代替计划对咱们“敞开”。这意味着,当您在项现在期想象架构时,您应该实在幻想出几种或许的架构。公平地说,这种战略并不是新的,现实上,这种战略现已在IT架构社区中推行了几十年,尽管并不总是如此。


9.记住企业束缚

除最新安排外,一切安排都具老歌经典-「灵敏架构」规模化灵敏开发的战略有现有的技能根底设施。更老练的安排或许有:

  • 他们正在尽力完结的技能根底设施的“远景”愿景
  • 企业级规范和攻略 - 用于开发,数据,用户界面,安全性等 - 项目团队应遵照的规范和攻略
  • 用于下降整体开发和运营本钱的战略性重用战略
  • 企业架构,战略重用和/或相似的团队,担任开展和推行这些事物
  • 运营和支撑安排,有时也称为体系办理安排,担任在出产中运转安排的体系

要害是这些企业级考虑要素为开发团队供给了应战和时机。尽管每次构建一个新体系时从一个洁净的架构板开端会很棒,但实践状况是在绝大多数状况下战略都是不适宜的。多年来我见过几个灵敏项目团队由于他们挑选从头开端,宣称他们的架构跟着时刻的推移而呈现,他们有勇气忧虑明日明日的问题,他们制造了潜在的可交给软件。定时,并底子上嘲弄任何其他灵敏的言辞,他们以为这些言辞证明了他们的捉弄。训练有素的团队构建体系,其架构呈现在他们作业的安排环境中。他们谦善地认识到他们无法做出他们想要的一切技能抉择计划,而是遭到现有根底设施和愿景的约束。此外,他们还出产可在安排生态体系中运用的可耗费处理计划。

走运的是,企业重视的焦点或许多。经过运用现有的根底架构团队,能够更快地供给,由于他们的构建更少。经过运用现有技能,或许至少经过运用企业愿景中说到的新技能(对您的安排来说是新的),他们经过协助最小化运营本钱来下降体系的整体具有本钱(TCO)。经过遵照公司开展准则,它们有助于行进作业的一起性和质量,增加其可保护性,以便将来担任开展和保护作业。趁便说一句,软件开发上下文结构(SDCF)的企业规程扩展因子是八个中仅有的扩展因子,这使得开发团队或许更简略完结,由于这个要素远离项目等级的要点( “简略”的状况)到企业层面的焦点(“硬”状况)。

那你怎样做的?最低极限,企业架构师,运营团队等企业集团是重要的利益相关者,应由您的产品一切者代表。关于您的企业体系结构组,其间一个或多个或许成为您的开发团队的活泼成员,具有架构一切者的人物。关于其他组,产品一切者能够依据需求和恰当的即兴根底挑选让他们作为域或技能专家参加您的团队。


10.轻装上阵

您的架构作业的一个方针应该是轻装上阵,尽或许灵敏。当一个五页的文档能够做时,不要创立一个五十页的文档。当图表履行时,不要创立一个五页的文档。当隐喻能够做时,不要创立图表。记住“他们不会读它(TAGRI)”的准则。

不确认怎样创立文档?过错的是由于你能够随时回到白板,可是你浪费了创立你不需求的工件或许为工件增加不必要的细节的时刻现已一去不复返了。您的方针应该是考虑项目团队(或安排乃至职业所面对的要害问题,具体取决于您的规划),不该该创立许多的文档。最大化股东出资回报率的准则告知您要专心于高价值的活动,例如作为一个团队处理困难问题并达到一同愿景。相同,它告知您要防止低价值的活动,例如编撰具体的文档或开发分数美丽的图表。这些活动往往令人感到欣喜,由于它们供给了行进的错觉,假如你企图防止处理扎手的问题,就会为你供给一个离题的来历,但实践上很少像你幻想的那样有用,由于其别人很少看到比作者。准则软件是您的首要方针意味着您应该对您的架构进行建模,直到您以为自己有可行的战略停止,此刻您应该持续开端开发软件而不是文档。

您何时想编撰架构文档?在我看来,有两个比如让它变得“灵敏”。首要,当您具有分布式开发团队而且无法找到更有用的交流办法(例如面对面攀谈)时,文档便是一种挑选。其次,在项目完毕时,您期望留下满意的文档,以便其别人能够在今后了解您的办法。实践状况是,关于恰当杂乱的体系来说,记载代码中的一切内容是十分困难的,假如不是不或许的,当然也不可取。有时,描绘您的体系结构的最佳方位是扼要的概述文档。本文档应侧重于解说您的架构的要害方面,或许由您的导航图捕获,它或许包含要害架构要求的摘要,以及对您所做的“可疑”方面背面的要害抉择计划的解说。与平常相同,假如您要创立一个架构文档,那么它应该增加正值,抱负状况下应该以最有用的办法履行。

许多人在发现架构没有“记载杰出”时会感到忧虑,不论这意味着什么。我并不是很忧虑这个问题,但我忧虑的是架构是否实在,以及开发人员是否了解并承受它。假如您要优先考虑您的体系结构文档,具有可行的体系结构,让开发人员了解该体系结构,并让一切开发人员都能运用它,那么我置疑文档将在该列表中排在最终。想一想。

11.证明你的架构

实践证明它与代码指出模型仅仅一个笼统,一个看似十分好的模型在实践中或许实践上并非如此,你能够必定知道的仅有办法是经过完结验证你的模型。这意味着你应该证明你的架构是有用的,XP称之为尖峰,RUP称为架构原型。当您的架构呼喊一些对您来说不熟悉的东西时,或许您是第一次运用两个或更多产品,您应该花时刻来探究这种办法是否能够怎样作业以及它是怎样作业的准则快速反应。记住要取得项目利益相关者的答应才干完结这项作业,由于这是他们花的钱。有时您会经过尽力发现原始办法不起作用,我期望尽早发现,有时您会发现您的办法实践上是怎样作业的(而不是您以为它的作业办法)。架构尖峰/原型的开发有助于下降项目危险,由于您能够快速发现您的办法是否可行,您还没有简略地制造象牙塔架构。

图5概述了优先需求“最佳实践”的灵敏办法。经过对交给生命周期的危险价值办法,Scrum价值驱动生命周期的扩展,您将确认处理项目首要技能危险的少量需求。例如,假如您的要求标明您的体系有必要能够在10小时内每秒处理4,000个事务,那么这将是一个清晰包含某些技能危险的要求。这是您期望在项现在期完结的一种要求,以确保您的体系结构实在起作用。我的一般规矩是,当你进入为期6个月的项目仅18天而不是在“6个月项目”的8个月点完毕时,最好发现你的架构战略需求从头考虑。这意味着,假如技能危险要求不在积压的首位,那么您需求与产品一切者密切协作,以压服他们从头确认优先级不高的要求。可是,假如您无法压服您的产品一切者这样做(我在实践中从未遇到过这个问题,但认识到或许会发作这种状况),那么您需求尊重他们的决议并承受今后证明您的架构的危险生命周期。

图5.作业积压。

12.传达您的架构

有两个首要受众,您的架构的交流很重要:您的开发团队和项目利益相关者。为了促进您的开发团队之间的交流,我深信您应该遵照揭露展现模型的一切架构图,由于一个紧密保密的架构不是一个架构,它仅仅一个徒劳无功的自我训练。我参加了几个项目,咱们成功地保护了一个专门用于架构图表的白板,让它们揭露显现给项目中的每个开发人员以及偶尔走过的任何其别人。咱们还答应任何想要在图表中增加谈论或主张的人,依照敞开和诚笃的交流准则以及团体一切权的实践,由于咱们期望他们对咱们的作业有所反应。咱们没有什么可隐秘和信赖的,其别人乐意协助咱们(他们的确)。

在项目开端时,在整个项目中不那么频频,您常常会发现需求使图表“看起来很美丽”,这样您就能够将它们呈现给您的项目利益相关者。您的利益相关者期望了解什么是什么您计划采纳的办法来确认您是否明智地投入资源,这意味着您需求树立模型来交流和定位您的某些模型,以便其别人能够了解它们。这或许意味着您需求花时刻来整理模型以使其可呈现以及为它们编写概述文档。为了坚持尽或许灵敏,有意图的模型准则告知您,您应该切当地知道您正在为谁开发模型以及他们将运用它们,以便您能够专心于所需的最小尽力。向重要的项目利益相关者进行演示,这些作业往往令开发人员烦恼和涣散注意力,这对项意图成功至关重要,由于它们为您供给了取得项目支撑和获取所需资源的时机。此外,您能够进步让您能够活泼参加项意图利益相关者的重要性(假如您没有可用的利益相关者,则无法遵照自动利益相关方参加的做法)。

预备好在演示文稿中传达您的架构,没有理由不能坚持演示文稿的灵敏性。


13.考虑未来,但不要过度制作(推延许诺)

我置疑关于灵敏架构建模的最具争议性的概念是你应该考虑未来的改动,但在你实在需求之前不要采纳举动。换句话说,不要过度构建你的体系,但一起要聪明一点。 XP社区关于过度构建软件的概念恰当直爽,他们信任“你不论怎样都不需求它”(YAGNI)。底子思想是你无法精确猜想未来[1],因而不该该为未来的或许性而尽力。相反,您今日应该专心于构建您现在需求的东西并洁净地构建它,以便您的软件在需求时易于更改。明日,当您发现需求更改软件以满意新要求时,请更改它。当您过度构建软件以愈加通用时,为了满意未来的潜在需求,您实践上正在做出十分严厉的权衡:

  • 很难估量你正在出产的实践价值。您并不专心于满意当今的需求,导致您不会为您的用户带来直接的价值。我参加了几个项目,前几个月,在少量状况下,前几个季度,咱们的作业要点是开发通用根底架构(持久性结构,音讯传递结构等)。技能上风趣的东西,咱们必定有许多趣味构建它们,但对咱们的用户没有任何价值。
  • 你在猜。你真的不知道你是否乃至需求你正在制作的任何东西 - 当一辆大众汽车满意时你或许正在制作一辆保时捷。
  • 你增加了保护担负。您今日过度制作的任何东西都需求在项意图整个生命周期中进行测验和保老歌经典-「灵敏架构」规模化灵敏开发的战略护,这违反了Travel Light的准则。
  • 现在尚不清楚它需求在多大程度上进行测验。当你过度制作某些东西时,仅有能够精确验证它的办法便是经过虚拟的反应 - 没有人要求你过度制作任何东西,所以没有人能够去验证你的作业。此外,大多数开发团队都会测验危险,但假如您猜想需求,那么您也会猜想危险等级。

所以你怎样能对这悉数都很聪明?尽管您不期望依据未来/神话要求过度构建体系,但考虑未来并没有任何问题。这是一个两阶段战略:

  • 初始建模。做一些开端的架构,幻想考虑问题,探究要害概念,然后让你朝着正确的方向行进。这并不意味着您需求创立许多的架构文档,尽管您或许会进行一些建模,是的,egads!,乃至能够创立满意的架构文档来满意您的需求。
  • 推延规划抉择计划。精益软件开发的准则之一是推延对您需求做出决议的最终或许时刻的许诺,然后行进您的灵敏性并行进您的成功时机。

一个风趣的战略是改动事例建模。改动事例用于描绘体系的新潜在要求或对现有要求的修正。改动事例是您未来或许需求或或许不需求支撑的要求,但您今日肯定不需求支撑。改动事例一般是与项目利益相关者进行脑筋风暴的成果,其间比如“事务怎样改动?”等问题。 “什么立法能够改动?” “你的竞争对手在做什么?”和“还有谁或许会运用该体系以及怎样运用?”在技​​术方面,开发人员常常会提出比如“什么技能能够改动?”等底子问题。和“咱们需求与哪些体系进行交互?”这将导致辨认改动事例。改动事例应该是实践的,例如“咱们为银行进入保险事务”或“咱们需求支撑咱们体系中的[INSERT FLASHY NEW TECHNOLOGY]”是合理的改动事例,但“咱们的出售人员被不明飞行物劫持” “T。此外,改动事例一般描绘的要求与您当时正在处理的要求恰当不同,这些要求或许会导致严重的返工。经过辨认改动事例,您现在能够智能地挑选看起来与架构或规划抉择计划相同的内容。当您的当时要求缺少以协助您在备选计划之间进行挑选时,您应该只将相关的改动事例归入抉择计划进程。另一个长处是你现在能够向你的项目利益相关者解说为什么你挑选一种办法而不是另一种办法,由于我想说你有一个故事要讲。可是,我不能着重改动事例不该该被用作为你的体系镀金的托言。坚持灵敏,不要过度构建体系。那么当你以为你有一个你实在信任现在需求施行的革新事例时,你会怎样做?简略 - 与项目利益相关者谈论。问询他们是否当即要求改动事例,假如是,则相应地采纳举动。假如这不是一个直接的要求,那么承受这个现实并持续行进。永久不要忘掉项目利益相关者有职责确认需求的优先级,而不是您的需求。

未来的建模是否会遭到危害?这是一个滑坡,由于我置疑假如你建模它然后你更有或许树立它。我信任,这需求严厉的高石鑫纪律,不要过度制作,由于一旦你把它作为一系列气泡和线条捕获,就很简略让自己信任过度制作一次就没有害处。现已说过,在谈论改动事例的时分制作一些丢掉的草图并没有什么不当,仅仅不要过度建模你计划保存的任何模型。

14.选用多视图办法

灵敏建模的多模型准则主张您认识到,由于现代体系很杂乱,您需求考虑架构中的一系列视图。尽管它们选用不同的办法,但多视图战略是现代架构结构中的底子概念,例如Zachman结构,TOGAF,4 + 1等。这些结构中的每一个都有很好的理由来挑选视图,它们在实践中好像都运转杰出,它们都能够灵敏地进行处理,所以我的主张是检查您的选项并挑选最能反映出来的架构结构。您安排的文明。我的方针不是提出另一个架构结构,而是让您了解它们及其底子概念。图6概述了软件/体系架构师需求重视的视图和重角度(一般称为服务质量要求)。

图6.架构视图和重角度。

视图/角度被捕获为图表和文本描绘(例如用例,技能规范或散文)的组合。潜在的问题,或许是您自己的观念,您的架构应该处理的观念包含:

  • 用法/事务流程
  • 用户界面
  • 体系界面
  • 网络
  • 布置
  • 硬件
  • 数据存储
  • 数据传输
  • 活动
  • 代码/组件分发
  • 功用/逻辑/服务

借用面向方面编程(AOP)的言语,您的架构也或许需求考虑“横切重角度”。这些问题/观念也应该经过您的架构视图来处理,在某些状况下或许是您自己的特定视图。这些忧虑包含:

  • 分层/分区
  • 重用
  • 质量和验证
  • 精确性和及时性
  • 可靠性,可用性,可保护性和功能
  • 环境(绿色核算问题)
  • 定制点
  • 可耗费性(包含(de)装置的简易性,支撑等级,可用性,......)
  • 并发
  • 安全
  • 国际化
  • 法令
  • 保护,操作和支撑问题

这意味着,任何担任架构师人物的人都需求具有广泛的技能才干发挥作用,他们需求脱节过度专业化的传统哲学,更多地是一个遍及化的专家。最低极限的是,他们应该从简略的数据架构师,安全架构师或网络架构师转变为架构师。仅仅是一名架构师也或许过于专业化,但这取决于具体状况。实在的专业人士力求具有广泛的技能以及一个或多个专业。

15.这是怎样作业的?

我所描绘的架构办法与许多安排现在正在做的作业显着不同。表1比较并对比了许多安排中常见的架构实践与灵敏对应的架构实践。明显,这有很大的不同。灵敏办法之所以有用,是由于它专心于团队协作的人员。灵敏建模认识到人们是过错的,他们不太或许从一开端就取得正确的架构,因而需求有时机依据施行作业的反应行事。当灵敏架构师是开发团队的高效成员,而且当开发团队参加开端的架构作业时,他们不需求全面的文档,导航图就满意了(颁发,当这不是案子文件,期望最小,或许是必需的)。不需求架构谈论,由于架构是经过架构原型规划/峰值的具体反应来证明的,由于人们能够看到架构开展,由于您的模型揭露展现供一切人检查。灵敏架构师有勇气专心于处理当今的问题并信任他们明日能够处理明日的问题(Beck,2000),以及认识到他们无法精确猜想未来并因而挑选不过度构建他们的架构的谦善。

表1.比较常见和灵敏架构实践。

一同的实践

灵敏实践

架构师遭到高度重视,常常被置于基座上,乃至更糟糕

灵敏的架构师谦善地供认他们不会走水

架构师太忙了,不能随意开发

灵敏架构师是开发团队的活泼成员,在恰当的状况下开发软件并充任团队的架构参谋

架构模型十分强壮,能够满意未来的需求

灵敏架构师谦善地供认他们无法猜想未来,而是有勇气信任他们明日能够处理明日的问题

方针是在项现在期开发全面的架构

您能够逐渐和迭代地改善您的体系结构,使其跟着时刻的推移而呈现

需求记载杰出的架构模型

轻装上阵,专心于概述您的修建的导航图,记载足以与您的方针受众进行交流

架构模型只需在“适宜大众消费”时才会传达

架构模型即便在进行中也会揭露展现,以促进其别人的反应

在投入运用之前,将进行架构评定以验证您的模型

经过具体试验证明了架构

16.处理灵敏和架构周围的神话

我想经过处理一些与国际各地的安排协作时依然遇到的常见神话来完毕这篇文章。

  • 灵敏者不做架构。我的期望是,这篇文章将把这个神话牢牢地放在一边。
  • 您需求进行具体的前期架构建模。您应该进行一些前期架构建模,以确认您的一般技能战略,辨认您或许遇到的潜在技能应战,并协助您在团队中环绕技能方向达到一起。要害是你不需求许多细节来完结这些方针。选用“大型模型猜想(BMUF)”办法是一种挑选,这种办法在理论上听起来很棒,特别是假如你是一名专业建模师,但在实践中一般被证明是一个恰当差的人。 BMUF战略导致糟糕的抉择计划和处理计划不太或许满意利益相关者的实践需求,下降您支撑不断改动的需求的才能,并导致士气失落。
  • 架构师担任架构。尽管许多安排挑选支撑首要担任架构活动的专业架构师,但现实证明这在实践中是一个恰当糟糕的挑选,由于开发人员或许会将架构师视为“象牙塔”而且常常会挑选疏忽它们。正如您在本文中看到的那样,有用的架构战略本质上是协作的,而不是独裁的。

17.称谢

我要感谢Birol Aygun,Jesper Rugard Jensen,Ashely McNeile和Paul Oldfield对更新本文的调查。

原文:http://agilemodeling.com/essays/agileArchitecture.htm

本文:https://pub.intelligentx.net/agile-architecture-strategies-scaling-agile-development

谈论:请参加常识星球或许小红圈【首席架构师圈】