了解敏捷开发和企业架构
敏捷和企业架构完美地结合在一起。两者都解决了问题的不同部分。
敏捷软件开发擅长构建我们以前从未有过并且不知道如何构建的东西。当您不知道该做什么时，企业架构在决策之前表现出色。
- 构建敏捷企业
- 开发最佳实践企业架构的敏捷工作实践
- 敏捷软件开发和企业架构
大多数建筑师跳到最后。他们试图将两个截然不同的世界融合在一起，通常都不会停下来去理解。
我与新聘用的系统可靠性工程师进行了一次有趣的交谈。 SRE 专家很兴奋。我们终于开始了现代实践 CI/CD 实践。她问我 EA 团队正在做些什么来提供帮助？
当她问我时，我不得不微笑， 'EA 团队正在做些什么来提供帮助？她真正的意思是，'你今天在做什么来支持我？今天，面对她眼前的挑战，它可能是——什么都没有。她跳到 EA 团队如何支持她的日常工作。
她从未见过引入容器、测试数据管理以及坦率地说自动化测试套件不足的产品组合路线图。她没有意识到同样的旧路线图确定了为她的工作提供资金的过渡点。
敏捷开发和企业架构
在链接到敏捷软件开发时，会问同样的问题，即团队应该协助回答什么。某些一致性是由企业架构团队旨在支持的内容驱动的。
- 定义敏捷方法
- 指导 sprint 中的积压工作
- 限制冲刺
- 解决交叉产品依赖
敏捷和企业架构：定义敏捷方法
通常，服务于战略和投资组合的 EA 团队将 定义敏捷方法。
产品
产品在路线图上显示为差距或工作包。 EA 团队可能会谈论能力或业务服务。当他们这样做时，期望看到新的或重新设计的产品。
平台
较弱的从业者将专注于定义诸如“平台”之类的术语。一个清晰、过于精确的定义是一个陷阱。花几秒钟的时间考虑一下，有人谈论 SAP、0365、Facebook、Pega，甚至 Angular 和容器作为平台是完全合理的。该术语需要一个狭义定义的上下文。您所需要的只是消费者和运营商的同意。我已经屈服于将产品指定为其他人使用的平台的诱惑。学究们试图确定它是产品还是平台。
服务交付策略
顶级路线图最好清楚地说明如何实施转型。例子包括。
- 建立强大的内部能力还是使用第三方？
- 确保长期可持续的系统或将部分或所有产品视为一次性面巾纸？
主要价值休息点
我们经常使用价值休息点作为架构转换的同义词。始终为您的利益相关者提供一个出口。我们使用出口匝道有两个原因：
- 当达到下一个休息点的努力超过增量值时。
这是一次投资回报率对话。 ROI 对话通常会导致优先级发生变化。 - 当达到一个休息点的努力可以达到更令人兴奋或有益的休息时。
权衡对话提供了战略或投资组合路线图练习的最有价值的结果之一。资源是有限的。高层领导总是在寻找最佳的前进道路，而不是最高的潜在回报。最佳路径。考虑因素包括静止时的比较价值和作为其他活动跳板的潜在价值。
实施者很少理解这些对话。他们在情感上归属于一条道路或休息点。尤其是在考虑产品的存在或下一个版本时。
敏捷和企业架构：Sprint 中的积压工作指南
支持投资组合和项目的 EA 从业者通常会通过指导 Sprint 中的积压工作与敏捷团队互动。
我观察到，让太多敏捷布道者感到惊讶的是，深深致力于敏捷软件开发的好处的组织仍然坚定地致力于规划和长期预算。通常，对话会混淆对瀑布的神话文化偏好。
而是考虑问题。由于生态系统的复杂性，存在长期规划和预算。每个组织都有多条前进的道路和不同的约束。成功的组织执行优先级和权衡。如果没有在时间和资源限制下达到理想的未来，就不应开始任何工作。
企业架构归结为约束。每个约束都限制了敏捷软件开发团队的创造力。如果没有压倒一切的约束需求，就不要。只是不要。
指导产品的路线图
指导产品的路线图是优秀的 EA 团队最难交付的成果之一。知道你要去哪里而不知道如何到达那里的基本张力是一个热点。
太多的架构团队陷入了人工精确或想象无所不知的陷阱。两者都是说瀑布思维的奇特方式。
当团队拥有各种自由度时，敏捷开发会产生惊人的结果。想想未开发的独立产品的最佳位置。
好的架构通常归结为提供最小的约束，以确保决策不会通过对决策者来说并不明显的测试。如果决策者可以看到测试，您就不需要架构来约束它们。当因素超出建筑师的视野时，建筑的存在是为了指导或约束选择。
经典的 EA 路线图将说明过渡、差距和工作包。对于产品团队来说，这将是不可理解的。与产品所有者一起将路线图转换为正确的条款。产品负责人需要了解他们在其中操作的约束。
期待紧张
指导史诗的路线图
对于有才华的 EA 团队来说，指导史诗的路线图是最难交付的。我总是想在轰炸期间被困在雷区。无处可去。
时间线预期使瀑布思维的常见陷阱变得更糟。以人为的精确度和想象中的无所不知的方式领先于敏捷团队的发现之旅会破坏敏捷开发中的一切。只是不要这样做！
如果没有紧密集成或严格限制的产品，史诗的路线图注定会失败。如果有必要，示例包括在一个生态系统中共存的多个产品，以及共享参考数据。消耗彼此的数据消耗通常需要相关的史诗或复杂的惩罚性监管。
没有外部压力，请勿进行此活动。自称无所不知的从业者的过度规范和过度设计是我们发明敏捷以消除的一件事。如果您发现自己被迫制定史诗路线图，请确保您准确理解为什么有必要限制软件开发人员的创造力。每一个限制他们自由和创造力的约束都最好超越来自肆无忌惮的创造力的价值传递
期待失败。
当我们取得成功时，我们积极采用了像 SaFE 这样的方法语言，并在战略主题和架构跑道方面制定了路线图。
企业价值
卓越的架构将始终解决利益相关者的共同问题。它应该提供一套内部一致的原则，为价值定义提供约束。在这里，架构确保评估价值的草率不会产生下游成本。
价值评估草率是优秀架构解决的最常见问题。临时考虑规则。经典的二分法是战术上市时间与安全性、弹性或稳定性之间的区别。当您的组织有当务之急时，需要告知产品经理和 Scrum 团队。否则，他们无法根据真正重要的指标适当地评估积压。
约束“自下而上”的产品所有者
太多的产品所有者不了解他们的产品存在的原因，或者太多的产品所有者不了解他们的产品存在的原因，或者生态系统的角色是什么。通过禁止选择或强制评分和评估来限制自下而上的产品所有者的自由。
敏捷和企业架构：限制冲刺
开发架构以支持项目和解决方案交付的 EA 从业者应该期望限制 sprint。正在开发生态系统或平台的面向产品组合的从业者也应该期望与这里的敏捷团队合作。
对于曾经积极参与开发的新架构师来说，限制冲刺可能在情感上很困难。很难离开你的旧工作。通常，主题专业知识会导致过度规范和过度设计。每一个限制他们自由和创造力的约束都必须证明它超越了来自肆无忌惮的创造力的价值传递。
离开旧工作的困难是为什么我们将每个刚接触企业架构的人视为 新人.应届毕业生和拥有 30 年从事企业架构以外工作经验的人是新架构师。
我用多年的观察新建筑师 其他 亲身体验。他们有许多坏习惯，使他们无法成为高效能的建筑师。
验收标准
与 sprint 的一个非常简单的链接是外部定义的验收标准。如果架构需要某些东西，请将其作为验收标准。除非详细程度非常接近干扰敏捷创造力，否则约束将是一致的。业务架构、数据架构、应用架构或基础架构架构都会有需求。架构规范将是主体、模式或标准。提供约束作为验收标准。要么与 Sprint 对齐，要么发布。然后让开，看创意
价值（措施和休息点）
一个反复出现的冲突点是理解价值。
最佳实践敏捷软件开发注重价值。不幸的是，大多数从业者对价值的理解有限。快速的速记是用交付的东西来表达价值。价值在交付中不言而喻。
在一个复杂的世界中，交付的东西很容易降低价值。一个简单的例子是远离目标客户的功能，或工作单元之间的工作移动。当产品服务于一组时，这很常见。我们强烈建议学习有关本地优化和价值的基本精益和六西格码实践。同样，目标客户和价值主张的商业模型画布概念也很有帮助。
为了应对这些挑战，我们希望业务架构能够确定如何评估价值。架构需要为开发团队提供价值评估标准。
绿地、进化或革命
在 TOGAF的E期，有一个很酷的步骤。查看工作包并选择适当的策略。
这项工作将是绿地、进化还是革命性的？我们是想尽可能多地保留、彻底重构还是从头开始？这是重要的指导，也是对敏捷团队的强大约束。他们是否从头开始（Greenfield）？逐步改进现有系统（进化）？或者进行彻底的改变以消除我们一直生活的摩擦和麻烦（革命）？
方法选择可能不是他们的。当他们没有选择时，总是会受到高于他们工资等级的选择的驱动。
约束接口
当产品必须适应现有企业环境或支持不断发展的企业环境时，接口是关键。接口将由数据和方法驱动。即使产品正在出现，在一个复杂的世界中，也不会有允许数据结构或接口出现的自由。主数据、参考数据和现有系统都将限制敏捷开发。
现有系统不会改变。甚至 F-22 Raptor 也必须使用 1970 年代开发的接口与旧系统连接。即使是昂贵的飞机也无法改造遗留系统。 Raptor 适合现有的接口和数据结构。
快速移动的团队忽略的一个常见限制是多司法管辖区的立法或商业计划将如何影响产品。在这些情况下，EA 团队有责任深入研究并制定最低限度的必要约束，以防止产品在不方便的时刻需要彻底重构。就像对创造力的所有限制一样，优秀的 EA 从业者了解足够的重要性。
企业架构与敏捷：解决依赖关系
我们可以预期，在企业中工作的 eA 从业者需要介入并解决产品、解决方案和系统之间出现的依赖性和冲突。简单看一下 TOGAF 阶段 G，它强调了对指导和架构更改的需求。敏捷开发和现代集成使这种长期存在的需求服务比以往任何时候都更加重要。
解锁投资组合
即使您不受传统的限制，也会有多种产品向前发展。创造性的最佳实践敏捷开发团队将找到解决问题的不同方法。期望创造力不会产生冲突是愚蠢的。一个优秀的 EA 团队在所有敏捷软件开发发生的阶段 G 工作，可以预期消除整个企业投资组合的冲突。
识别真正的利益相关者
真正的利益相关者通常很难找到。许多战术决策都是授权的。当委派正式时，敏捷团队可以期望拥有合理的访问权限。如果代表团是非正式的，当地的主题专家和用户可能会推动一个不协调的议程。
企业架构团队没有获得参与的特殊能力。他们确实有能力通过卓越的架构来代表利益相关者的关注点。
交叉投资组合
产品所有者和开发团队的其他成员被驱使逐步交付一种产品。最小化可行产品和增量交付是敏捷价值主张的核心。
整个敏捷方法来自观察到的失败，即试图想象复杂投资组合中的每一次交互，这就是失败的路径。详细的自上而下的企业设计可以适用于孤立的系统。在不断变化的生态系统中，自上而下的设计总是失败。这条失败的道路是敏捷存在的原因以及敏捷是首选的原因。
几乎不可能想象一个复杂的未来，这样做的努力往往会演变成闹剧。然而，我们需要做的已经足够了。随着多种产品的出现，新的冲突和协同将出现。一个优秀的 EA 团队，对企业优先级的变化有深刻的理解，将有助于解决协同和冲突。
当 EA 团队发现交叉点时，他们需要利用他们的洞察力和参与度来获得最佳答案。这通常是一种风险管理的方法。第一步是快速评估冲突以确定解决方案是否可以推迟。利用协同作用和避免冲突是昂贵的。昂贵且耗时。它们直接影响产品上市时间。
当我们必须跨越投资组合时，我们会用市场力量和创造性破坏来说话。
发布影响
恰到好处的架构意味着在发布之前没有发现每一个意外事件、每一个约束、每一个冲突。
有一种情况是架构团队遇到紧急情况。这是发布后的危机。那些影响超出产品范围的罕见情况。产品在野外。我们组织内外的最终用户都在使用它。他们要么处理缺陷，要么更糟，给我们的组织带来意想不到的风险和责任。
敏捷和企业架构的结论
敏捷开发和 企业架构 遭受慢性误用。太频繁地同时发生。
六个用例涵盖敏捷和企业架构的所有方面.企业架构指导和约束敏捷软件开发。
在链接到敏捷软件开发时，企业架构师需要：
- 定义敏捷方法
- 指导 sprint 中的积压工作
- 限制冲刺
- 解决交叉产品依赖
企业架构归结为极限——做这个，不要做那个。每个限制都限制了敏捷软件开发团队的创造力。如果没有压倒一切的约束需求，就不要。只是不要。
这 TOGAF 知识体系 支持制定有效的治理方法。
加入企业架构 Kickstart
成为更好的企业架构师的 12 周免费计划