理解敏捷开发和 EA

敏捷和企业架构完美地融合在一起。两者都解决了问题的不同部分。

敏捷软件开发擅长构建我们从未有过的,不知道如何做的东西。当您不知道该怎么做时,企业架构会在做出决定之前表现出众。

敏捷性,企业架构和软件开发在三个领域融合在一起

  1. 架构敏捷企业
  2. 敏捷的工作实践,以开发最佳实践的企业体系结构
  3. 敏捷软件开发与企业架构

大多数建筑师跳到最后。他们试图将两个大相径庭的世界融合在一起,通常不停地了解其中一个。

我与新聘的系统可靠性工程师进行了有趣的交谈。 SRE专家感到非常兴奋。我们终于开始了现代实践CI / CD实践。她问我EA团队正在做什么?

当她问时,我不得不微笑, EA团队正在做些什么来帮助'她真正的意思是,你今天要怎么支持我'今天,面对她眼前的挑战,可能是-什么都没有。她跳到EA团队如何支持她的日常工作。

她从来没有见过引入容器,测试数据管理以及坦率地说不足以提供自动化测试套件的产品组合路线图。她没有意识到相同的旧路线图确定了为她的工作提供资金的过渡点。

成功的EA团队可以实现他们的目标。他们没有兑现其他任何东西。即使他们可以。

六个用例涵盖了敏捷和企业架构的所有方面

思考企业体系结构的一个简单框架是询问其支持什么?

  1. 支持策略
  2. 支持投资组合
  3. 支持项目
  4. 支持解决方案交付

https://conexiam.com/togaf-9-2-body-of-knowledge/

敏捷开发与企业架构

当链接到敏捷软件开发时,会询问相同的问题,团队应协助他们回答什么。某些一致性是由企业体系结构团队设计要支持的驱动的。

  1. 定义敏捷方法
  2. 指导sprint中的积压
  3. 限制冲刺
  4. 解决跨产品依赖性
敏捷和企业架构工作产品

敏捷与企业架构:定义敏捷方法

通常,为策略和产品组合服务的EA团队会 定义敏捷方法。

产品

产品在路线图上显示为空白或工作包。 EA团队可能会谈论能力或业务服务。当他们这样做时,期望看到新的或返工的产品。

平台类

EA支持敏捷开发工作产品什么将支持或操作该产品?了解产品是基于新平台的独立产品,使用现有平台的产品,还是利用第三方平台的产品,通常会在零冲刺之前确定敏捷方法的关键要素。

较弱的从业者将专注于定义“平台”之类的术语。清晰,过于精确的定义是一个陷阱。花几秒钟的时间,对于某人来说谈论SAP,0365,Facebook,Pega甚至Angular和Containers作为平台是完全合理的。该术语需要一个狭义定义的上下文。您需要的是消费者和运营商的同意。我屈从于指定一种产品被其他人使用的平台的诱惑。学徒们试图确定它是产品还是平台。

服务提供策略

顶级路线图最好清楚地说明如何实施转换。例子包括。

  • 建立强大的内部能力还是使用第三方?
  • 确保使用寿命长的可持续系统或将部分或全部产品视为一次性Kleenex?

主要价值休息点

我们通常将“价值休息点”用作体系结构转换的代名词。始终为利益相关者提供准入门槛。我们使用坡道有两个原因:

  1. 当达到下一个静止点的努力超过了增量值时。
    这是一个投资回报率对话。 ROI对话通常会导致优先级发生变化。
  2. 当努力达到一个休息点时,可能会达到一种更加令人兴奋或有益的休息。

权衡的对话提供了战略或投资组合路线图练习中最有价值的结果之一。资源是有限的。高级领导者总是在寻找最佳路径,而不是最高的潜在回报。最好的道路。考虑因素包括静止时的比较值和作为其他活动的跳板的潜在值。

实施者很少了解这些对话。他们在情感上归属于一条道路或休息点。尤其是在考虑产品的存在或下一个发行版时。

敏捷和企业架构:Sprint中的积压指南

支持项目组合和项目的EA从业人员通常会通过指导Sprint的积压工作来与敏捷团队合作。

我已经观察到,太多的敏捷传播者感到惊讶,因为那些坚定致力于敏捷软件开发的利益的组织仍然坚定地致力于计划和长期预算。通常,谈话会使神话般的文化偏爱瀑布。

而是考虑问题。由于生态系统的复杂性,存在长期的计划和预算编制。每个组织都有多条前进的道路和不同的约束条件。成功的组织执行优先级和权衡。如果在时间和资源上都无法达到首选的未来,则不应开始任何工作。

敏捷和企业架构工作产品

企业架构归结为约束。每个约束都限制了敏捷软件开发团队的创造力。在没有约束的压倒性需求的情况下,不必这样做。只是不要。

指导产品的路线图

对于一支才华横溢的EA团队而言,指导产品的路线图是最困难的交付成果之一。知道您要去哪里而不知道如何到达那里的根本压力是一个热点。

太多的架构团队陷入了人工精度或想象中的无所不知的陷阱。两者都是表达瀑布思维的奇特方式。

当团队拥有各种自由度时,敏捷开发将带来惊人的结果。只是想想未开发的独立产品的最佳选择。

好的架构常常会归结为提供最小的约束,以确保决策不会通过对决策者而言不明显的测试。如果决策者可以看到测试,则不需要架构来约束测试。当因素不在建筑师的视野范围之内时,存在架构可以指导或限制选择。

经典的EA路线图将讲述过渡,差距和工作包。这对于产品团队来说是无法理解的。与产品负责人将路线图转换为正确的条款。产品负责人需要了解他们在其中操作的约束。

期待紧张

指导史诗的路线图

对于有才华的EA团队而言,指导史诗的路线图是最难交付的。我一直想着在轰炸中被困在雷场中。无处可去。

对时间轴的期望使瀑布式思维的常见陷阱变得更糟。敏捷团队以人为的精确度和想象中的无所不知的发现能力前进,破坏了敏捷开发中的一切。只是不要这样做!

没有紧密集成或严格限制的产品,史诗般的路线图注定要失败。必要时,示例包括在一个生态系统中共存并共享参考数据的多种产品。消耗彼此的数据会经常需要相关的史诗或复杂的惩罚性规定。

没有外部压力,请勿执行此活动。自我指定的无所不知的从业者过度规范和过度设计是我们发明的敏捷可以放弃的一件事。如果您发现自己不得不制定史诗般的路线图,请确保您确切地理解了为什么有必要限制软件开发人员的创造力。限制他们自由和创造力的每一个约束都最好克服来自无限制创造力的价值传递

期待失败。

当我们取得成功时,我们将积极采用SaFE等方法的语言,并根据战略主题和体系结构跑道制定路线图。

企业价值

优秀的架构将始终解决利益相关者的共同担忧。它应该提供一组内部一致的原则,这些原则对值的定义施加了约束。这里的架构确保了评估价值的草率不会造成下游成本。

松散的价值评估是好的架构要解决的最常见问题。暂时性注意事项规则。经典的二分法是战术上市时间与安全性,弹性或稳定性之间的区别。当您的组织有当务之急时,则需要告知产品经理和Scrum团队。否则,他们将无法根据真正重要的指标来适当评估积压。

约束“自下而上”的产品所有者

太多的产品所有者不了解其产品存在的原因,或者太多的产品所有者不了解其产品存在的原因或生态系统的作用。通过禁止选择或强制进行评分和评估来限制自下而上的产品所有者的自由。

敏捷与企业架构:约束冲刺

开发架构以支持项目和解决方案交付的EA从业人员应该期望限制冲刺。正在开发生态系统或平台的面向投资组合的从业人员也应该期望与此处的敏捷团队合作。

对于曾经积极从事开发工作的新建筑师而言,限制冲刺在情感上可能会很困难。很难丢掉旧工作。通常,主题专业知识会导致过度规范化和过度设计。任何限制他们自由和创造力的约束都必须证明,它超越了无限创造力带来的价值传递。

离开旧工作的困难是为什么我们将对待企业体系结构新手的每个人都视为 纽伯。新毕业生和拥有30年从事企业架构以外工作经验的人都是新架构师。

我看了多年的新建筑师 其他 亲密接触。他们有许多不良习惯,使他们无法成为高水平的建筑师。

敏捷和企业架构工作产品

内森(Nathan)和山姆(Sam)谈论 培养新的企业架构师。所有的东西都非常重要 企业架构师 了解决策权并为利益相关者服务。

验收标准

外部定义的接受标准是与冲刺之间非常简单的联系。如果体系结构需要某些内容,则将其作为接受标准。除非细节水平非常接近于干扰敏捷创造力,否则约束将是一致的。业务架构,数据架构应用程序架构或基础架构将有需求。体系结构规范将是主体,模式或标准。提供约束条件作为接受标准。对齐Sprint或释放。然后躲开并观察创造力

州长指南

他们是否合理地解释了目标体系结构的指导和约束?

  • 如果是,则应接受其解释为合规。这是关键。好的体系结构可以有多种实现选择。实施者不需要坚持意见。如果实施选择是合理的解释,则它是合规的。

价值(措施和休息点)

冲突的复发点是对价值的理解。

敏捷软件开发的最佳实践注重价值。不幸的是,大多数从业者对价值的理解有限。快速的速记就是用交付的东西来表达价值。该值在交货中是不言而喻的。

在复杂的世界中,交付的东西很容易降低价值。一个简单的例子是针对目标客户的功能或工作单元之间的工作移动。当产品提供一组服务时,这很常见。我们强烈建议您学习有关局部优化和价值的基本精益和六西格玛实践。同样,目标客户和价值主张的业务模型画布概念也很有帮助。

为了应对这些挑战,我们希望业务架构能够确定如何评估价值。该架构需要向开发团队提供价值评估标准。

绿地,进化或革命

在TOGAF的E期中,有一个很酷的步骤。查看工作包,然后选择适当的策略。

作品是《绿野》,《进化》还是《革命》?我们是否要保留尽可能多的内容,从根本上重构还是从头开始?这是至关重要的指导,也是对敏捷团队的强大约束。他们是否从头开始(格林菲尔德)?逐步改进现有系统(演进)?还是执行预期的根本改变以消除我们一直生活的摩擦和麻烦(革命性的革命)?

方法的选择可能不是他们的。当他们没有选择权时,它将总是由高于薪资水平的选择所驱动。

约束接口

当产品必须适合现有企业环境或支持不断发展的企业环境时,接口是关键。接口将由数据和方法驱动。即使产品正在出现,在复杂的世界中,也没有自由允许数据结构或接口也出现。主数据,参考数据和现有系统都将限制敏捷开发。

现有系统将不会更改。甚至F-22 Raptor都必须使用1970年代开发的接口与旧系统连接。即使是一架昂贵的飞机也无法改造旧系统。 Raptor适合现有的接口和数据结构。

快速发展的团队忽略了一个共同的约束,那就是多辖区立法或业务计划将如何影响产品。在这种情况下,EA团队有责任挖掘并开发最小限度的约束,以防止产品在不方便的时候需要进行彻底的重构。像对创造力的所有限制一样,优秀的EA从业人员也了解足够的重要性。

企业架构与敏捷:解决依赖性

可以期望在企业中工作的EA从业人员需要介入并解决产品解决方案和系统之间出现的依赖性和冲突。简单地看一下TOGAF的G阶段,它突出了对指南和体系结构进行更改的需求。敏捷的开发和现代集成的范围使这种长期存在的需求服务比以往任何时候都更加重要。

敏捷和企业架构工作产品

解锁投资组合

即使您不受传统的束缚,也将有多种产品向前发展。具有创造力的最佳实践敏捷开发团队将找到解决问题的不同方法。期望创造力不会造成冲突是愚蠢的。可以预期,一个出色的EA团队将在G阶段(该阶段进行所有敏捷软件开发)中进行工作,以消除整个企业产品组合中的冲突。

确定真正的利益相关者

真正的利益相关者通常很难找到。委派了许多战术决策。当代表团正式访问时,敏捷团队可以期望获得合理的访问权限。在代表团是非正式的情况下,可以期望当地的主题专家和用户来推动不协调的议程。

企业体系结构团队没有特殊的参与能力。他们确实有能力通过高级架构来表达利益相关者的关注。

交叉投资组合

产品负责人和开发团队的其他成员被迫逐步交付一种产品。最小的可行产品和增量交付是敏捷价值主张的核心。

整个敏捷方法来自于观察到的失败,这些失败是试图想象复杂投资组合中的每个交互的失败,这就是失败的路径。自上而下的详细企业设计可以适用于隔离的系统。在不断变化的生态系统中,自上而下的设计始终会失败。该失败路径是为什么存在敏捷以及为什么首选敏捷的原因。

几乎不可能想象一个复杂的未来,为此而付出的努力常常沦为闹剧。然而,我们需要做的恰到好处。随着多种产品的出现,新的冲突和协同作用将出现。一个优秀的EA团队,对其企业优先级的变化有深刻的了解,将有助于解决协同作用和冲突。

当EA团队发现交叉路口时,他们需要利用自己的洞察力和参与度来获得最佳答案。通常,这将是一种风险管理的方法。快速评估冲突以确定是否可以推迟解决方案是第一步。利用协同作用并避免冲突是很昂贵的。昂贵且费时。它们直接干扰产品上市时间。

当我们必须跨越投资组合时,我们就市场力量和创造性破坏而言。

释放影响

足够多的体系结构意味着在发布之前未发现任何意外情况,每个约束,每个冲突。

在一种情况下,架构团队会遇到紧急情况。这是释放后的危机。那些影响超出产品范围的罕见情况。产品在野外。组织内部和外部的最终用户都在使用它。他们正在处理缺陷,或更糟的是,为我们的组织带来了意料之外的风险和责任。

敏捷与企业架构的总结

敏捷开发和企业体系结构都遭受长期错误应用的困扰。太多时候在同一时间。

六个用例涵盖了敏捷和企业架构的所有方面。企业体系结构指导并限制了敏捷软件的开发。

在链接到敏捷软件开发时,企业架构师需要:

  1. 定义敏捷方法
  2. 指导sprint中的积压
  3. 限制冲刺
  4. 解决跨产品依赖性

企业架构归结为极限-做到这一点,不要这样做。每个限制都限制了敏捷软件开发团队的创造力。在没有约束的压倒性需求的情况下,不必这样做。只是不要。

https://conexiam.com/togaf-9-2-body-of-knowledge/

TOGAF知识体系 支持开发有效的治理方法。

加入个人企业架构启动

免费12周计划,成为一名更好的企业架构师

滚动到顶部