敏捷 架构
Throughout the world, pre-Agile software development was commonly done using a waterfall-based delivery model made up of a sequence of distinct activities performed by specialists. Hand-offs between stages are usually weighty documents — the keys required to unlock the next stage. All these models were variants on a common theme:
在世界范围内，敏捷前的软件开发通常使用基于瀑布的交付模型来完成，该模型由专家执行的一系列不同活动组成。 阶段之间的交接通常是较重的文件-解锁下一阶段所需的密钥。 所有这些模型都是相同主题的变体：
Requirements 要求 Analysis 分析 High-level design 高级设计 Low-level design 低层设计 Development 发展历程 Testing 测试中 Deployment 部署方式 Release 释放Getting from start to finish would be a matter of months or maybe even years.
从头到尾要花费数月甚至数年的时间。
The key responsibility of the Solution Architect in this world is to produce the High-level design — an artefact that ostensibly tells the dev team enough about the structure of the solution that they can take forward, but also reassures multiple external stakeholders that the solution is fit for purpose. Those external stakeholders are the Corporate Guardians — people with accountability for distinct concerns of the Enterprise which also includes the Enterprise Architects who own the Technology Strategy.
解决方案架构师在这个世界上的主要职责是制作高级设计，这种伪造表面上告诉开发团队有关他们可以采用的解决方案的结构的足够信息，而且还向多个外部利益相关者保证解决方案是适合目的。 这些外部利益相关者是公司监护人 ，他们是负责企业独特问题的人员，其中还包括拥有技术战略的企业架构师 。
The distinction of responsibilities in the lifecycle meant that Architects didn’t need to be physically located with the dev teams — an arrangement that has often led to Architects being too abstract or academic to consider developer concerns resulting in accusations of Architects handing out proclamations from their “Ivory Towers”.
生命周期中职责的区别意味着，建筑师不必在开发团队中处于实际位置–这种安排经常导致建筑师过于抽象或学术性强，无法考虑开发人员的关注，从而导致建筑师指责建筑师从他们的工作中发放保证金。 “象牙塔”。
Then along comes Agile with its fancy ideas! Rather than taking several months to deliver something we thought was the right solution at the beginning, let’s go for smaller batches of change. With smaller batches of change, we can iterate towards the goal and realise value earlier than with Waterfall. We embrace that the goal we eventually hit may not be the goal with which we started the journey. We have the power to change our minds and plot a new course. I’m sold, and there’s no going back for me.
然后出现了敏捷的想法！ 与其花几个月的时间来交付我们认为一开始就正确的解决方案，不如让我们进行小批量的更改 。 通过进行少量更改，我们可以朝着目标进行迭代，并比Waterfall早实现价值。 我们接受最终实现的目标可能不是我们开始旅程的目标。 我们有权改变主意并制定新的路线。 我被卖了，没有回头路了。
The key to making smaller batch size work is to minimise the hand-offs necessary to deliver the batch. How can Architecture, with its role of keeping the Corporate Guardians pacified, support this without becoming a bottleneck? The answers are guide, trust and support.
使小批量生产工作的关键是最大程度地减少交付批生产所需的交接。 在保持公司监护人安抚的作用下，架构又如何在不成为瓶颈的情况下提供支持呢？ 答案是指导 ， 信任和支持 。
Guide — to clearly communicate solution options, along with risks and strategic alignment. This needs to be done with the right level of detail — not so high that it’s meaningless, and not so low that it’s over-detailed
指南 -明确传达解决方案的选择以及风险和战略调整。 这需要以适当的详细程度来完成-不能太高以至于没有意义，而不能太低以至于过于详细
Trust — Empower delivery teams to make appropriate decisions
信任 -授权交付团队做出适当的决定
Support — to be there for the delivery teams, to provide additional guidance where required, to reassure or review where conflict emerges, and to hear and evaluate ideas and challenges from the teams
支持 -交付团队可以在那里使用，在需要时提供其他指导，以确保或审查发生冲突的地方，以及听取和评估团队的想法和挑战
Intentional Architecture is the declared, desired target state. Note I say “target”, not “end” because there rarely is an end for software — a point at which no further development is required. The target state can and will evolve, but it’s always a projection of where we now believe we want to be at some point in the future.
意图架构是已声明的所需目标状态。 请注意，我说的是“目标”，而不是“终点”，因为软件的终点很少-不需要进一步开发的时候。 目标状态可以并且将不断发展，但这始终是对我们现在认为将来希望达到的状态的预测。
With Agile and its small batches, delivery teams may make decisions that diverge from the Intentional Architecture. And that’s fine when done openly, with honest debate. Architects need to be aware of Emergent Design as it has potential impacts:
对于敏捷及其少量产品，交付团队可能会做出与意图架构不同的决策。 公开讨论并坦诚讨论后就可以了。 建筑师需要意识到紧急设计，因为它有潜在的影响：
Embrace — the Emergent Design is a valid transition state of the Intentional Architecture
拥抱 -紧急设计是意图架构的有效过渡状态
Eliminate — the Emergent Design meets the needs of today but introduces new technical debt that needs to be paid back to reach the Intentional Architecture (rework required at some point)
消除 -紧急设计满足了当今的需求，但引入了新的技术债务，需要偿还这些债务才能达到意向性架构(有时需要进行返工)
Rethink — the Emergent Design introduces an opportunity to do things better. The Intentional Architecture needs to be updated.
反思 -紧急设计为您提供了做得更好的机会。 意图体系结构需要更新。
A way I like to look at it is that Emergent Design represents a fast-feedback loop for Architecture, and thus the Architecture itself becomes Emergent.
我喜欢看的一种方式是，紧急设计代表了体系结构的快速反馈循环，因此体系结构本身就变成了紧急状态。
The Agile Architect is one who accepts Emergent Design as a necessary and beneficial part of the process. Trust is a two-way street — teams need to be able to trust their Architects and Architects need to be able to trust their teams. That trust comes from familiarity, from being in the game, not outside it. The Agile Architect must join the devs in the trenches, providing valuable support and absorbing feedback.
敏捷架构师是接受紧急设计作为流程必要和有益的一部分的人。 信任是一条两条路-团队需要能够信任自己的建筑师，而建筑师需要能够信任自己的团队。 这种信任来自于熟悉度，来自于参与游戏，而不是出于游戏之外。 敏捷架构师必须加入开发者的行列，提供宝贵的支持并吸收反馈。
Finding the right level of guidance again comes from familiarity. Embracing Agile fast feedback loops. If a design doesn’t land right the Agile Architect has to adapt their approach and try again.
再次找到正确级别的指导来自熟悉度。 拥抱敏捷的快速反馈循环。 如果设计不正确，则敏捷架构师必须调整其方法，然后重试。
This means a successful Agile Architect has to be an effective communicator, able to adapt to the audience, to be understood and just as important to be able to understand.
这意味着成功的敏捷架构师必须是一个有效的沟通者，能够适应听众，被理解并且对理解同样重要。
The days of Architects commanding from their Ivory Towers are long gone…
建筑师从象牙塔指挥的日子早已一去不复返了……
翻译自: https://medium.com/the-innovation/emergent-architecture-architecture-in-the-age-of-agile-9f21ba654845
敏捷 架构
相关资源：微信小程序源码-合集6.rar