领域驱动设计 敏捷_大规模敏捷–结果驱动（或失败）

领域驱动设计 敏捷

敏捷，这一过程原本是为小型，跨职能的协作团队而优化的，并且使其能够大规模运行，这着实令人着迷。 在重新定义上下文时，您必须更改某些元素并保留其他元素。 以结果为导向，是您必须保留的要素之一，甚至是重要性的提升，或者您从根本上破坏了交付系统

更快地构建错误的事物

我在2000/2001年“变得敏捷” –当时我在一家企业软件公司中编写软件和领导团队，我们在内部和外部将其称为“快速周期时间”（XP）并采用了XP和其他敏捷实践的要素（ FCT）。 它不仅仅是增量交付，我们确实确实结合了诸如配对和演示之类的敏捷原则以及诸如自动构建和测试过程，代码读取，测试设计之类的工程实践。 当时对我来说，这是一个勇敢的新世界，我被永远迷住了。 在接下来的几年中，我的职业生涯从人员管理，售前和计划管理职位发展到产品管理。

十年前，我在早期的敏捷产品经理中花了很多时间-测试，学习，应用和理解如何不仅成为与敏捷团队一起工作的产品经理 ，还如何成为产品经理 。 两者都很罕见，而且仍然很重要。

我会经常说-我仍然相信这是真的-当一个团队或一个较小的组织（例如100个开发人员或更少）变得敏捷时，如果他们不同时专注于产品管理，他们所做的一切将会变得越来越快。建立错误的东西。 引用我很幸运现在打电话给同事的乔恩·哈默尔（ @jharmer ）的话来说：“您只是将汽车撞到墙上的速度更快。”

在旅程的最后半年，我已经了解了大规模敏捷产品管理如何工作。 在实践中看到事物。 帮助中型组织实现从瀑布式（大规模）到敏捷（大规模）的转变。 想像一下数十个团队（数百人）致力于为一个数十亿美元的组织提供数百个系统的交付。 泰纳·布莱恩（Tyner Blain）的长期读者将知道，我在这里的写作很大程度上是通过对体验的吸收，采用，外推和归纳（通过模式，概念和适用的思想）来驱动的。

对于小型团队而言，不注重正确结果的敏捷开发会更快地构建错误的事物。 结果，您只会构建更多错误的东西。 缺乏对结果的关注并不比对错误结果的关注更好。 以产出为中心不是以结果为中心。

对于大规模的敏捷，我不相信这是真的。 从规模上讲，如果您不是通过关注结果来推动执行，那么我认为您实际上并没有更快-只是与众不同。 大规模地利用Jon的聪明才智，“您仍然会撞车撞墙，但不一定更快。”

此处的主要区别在于封装和协调的相反系统动态。 较小的组织几乎不需要协调-团队内部发生“一切”。 为什么如此重要值得探讨。

规模是必要的编排和计划

您可能会相信计划会变得敏捷。 理性主义与经验主义之间的经典战争，使我想重新阅读布鲁克斯的《设计学》 。 我还怀疑我很高兴与之合作的另一件灯具 ，戴夫·尼科莱特（ @davenicolette ）甚至暗示，“规模化敏捷”原则上可能是矛盾的。 他可能也已经写过有关它的信息-但我听到他在谈论它:)。 归根结底，这取决于您如何定义敏捷性，或更确切地说，取决于您如何定义“自我指导”。 始终存在适用自决的环境 。 由于这是一个沉重的名字删除帖子，我将再次感谢Andy Polaine （ @apolaine ）提供的视觉效果，该视觉效果现在永久地嫁接到了嵌套上下文的概念上。

同意团队在团队合作的背景下具有行动自由和决策自主权是敏捷的宗旨。 这样做以达到共同的期望结果是将敏捷性作为实现业务目标的强大力量的关键。

我建议以结果为导向的敏捷团队是我们可以用来放松并可能解开戈尔迪安敏捷性和规模逻辑上一致的结的撬棒。 因此，只要我们愿意接受对敏捷的定义，即“自我指导”意味着在该团队角色范围内的自主权，我们只需要在其余上下文中明确表述即可。

• 大规模敏捷性需要多个小型团队
• 每个团队在团队角色范围内都有自主权
• 每个团队都在与其他团队协作以交付
• 每个团队专注于业务目标

专注于业务目标-投资以构建事物的“为什么”-是以结果为导向的定义。

这种协调需要以持续的方式进行计划。 从无协调到纯粹的同步动作，存在着理论上的连续性。 高度耦合的系统越少，共享资源的瓶颈越少，所需的协调就越少。 作为一名技术专家，我可以想象所有系统都解耦，而没有团队被超额认购的情况。 通过将架构，培训和人员配备决策结合在一起。 作为顾问，我感到永远不会有可以避免协调和计划的大规模组织。

因为事情变了。

每个人都有一个计划，直到…

这个概念有很多引用版本，这是几年前抓住我的那个版本。 其他战士会为与泰森先生的战斗做准备，拟定一个在他周围跳舞的计划，使他疲劳数轮，然后利用他们更大的耐力和技巧赢得这场战斗。 泰森先生通常会通过在第一轮上半场进行击昏对手的动作等使这些计划变得毫无价值。 正如泰森先生所说 ：“每个人都有一个计划，直到他们受到打击。”

对于我来说，这是记住计划有很多原因的试金石。 我的另一个同事Jeff Howey（ @AgileAlchemy ）很喜欢问房间-“这个计划是骗人的，对吧？” 所有人都同意。 这不是敏捷所特有的-瀑布计划也是一个谎言。

大约5年前，我探讨了产品失败的几种原因。 原因之一是各种变化，这些变化都反映出需要更改计划。 您意识到（通过在开发过程之外获取新信息）您的团队将要失败，因此您需要进行更改。 正式的机制是事前验尸。

1. 您选择了要为其解决问题的错误客户 。
2. 对于您选择的客户，您选择了错误的问题来解决
3. 您在未完全解决问题的情况下犯了宣告成功的错误
4. 您发现的解决方法无法解决问题
5. 您的执行/实施无法满足您的设计需求，因此无法解决问题（即使设计可行）

最后两种情况（4）和（5）实际上不是选择错误问题的示例，而是无法解决所选问题的示例。 通常，这些不是计划的问题（要解决的问题的选择），尽管可以。 在您关于解决哪些问题的战略选择既有价值又可取的情况下，对于您的团队来说，解决方案可能不可行。 您的策略可能超出了团队的能力，在这种情况下，您需要选择其他问题来解决。 为了全面起见，我列出了它们-尽管我仅一次看到这是导致失败的原因。 通常，其他事情也是错误的。

您可以进行一项强大的练习，称为“事前验尸”，以帮助提前发现计划中的问题。 由心理学家加里·克莱因（Gary Klein）提出，它是丹尼尔·卡尼曼（Daniel Kahneman）的最爱之一。 这是3分钟的说明

成果，合作与敏捷

当一个小的（例如，“按设计要求”的）敏捷团队发现他们在解决错误的问题时，由于所列的任何原因，他们都可以轻松地进行更改。 他们可以更改，因为他们直接与其业务利益相关者合作。 他们直接与客户接触，获取触发计划需要更改的发现的信号。 从组织的角度来看，您可以将这个团队描述为精简的团队-更改计划的能力在他们的协作影响力范围内。

他们可以更改计划。 他们可以更改计划，因为他们可以一起工作-业务方面（赞助商/客户/利益相关者/用户）和技术方面（创建产品或解决方案的团队）。 他们对解决问题的价值/机会/可取性和成本/复杂性/时间有共同的了解。 他们对设计可能解决问题的适用性有共同的了解。 他们对执行设计的能力有共同的了解。 他们可以集体管理技术和市场不确定性的原因，原因以及工作方式。

该团队以结果为导向。 并且当他们隐喻地打在脸上时，他们可以转向解决问题的新方法，解决的新定义或要解决的新问题。 由于团队被封装，这种变化的复杂性可能不会引起注意。 涟漪效应和新的编排要求在团队内部得以解决。

如果团队不是以结果为驱动力，那么他们进行根本改变的能力将仍然具有可比性–可以给团队分配一组新的任务，并且他们将放弃之前的工作，解决依赖性并进行新的工作。 在这个封装团队的外部，变更过程似乎同样容易。

这种误解（无论关注结果如何，对于敏捷团队来说都很容易改变）是组织难以在大型生态系统/组织中采用敏捷实践的困难的根本原因。

没有结果的敏捷

当这个团队试图不以结果为导向时，会发生什么？ 好。 插入刺耳的轮胎声音（或在表面上拖动留声机针）。 我反复
向其他作者提出以下挑战 ：

1. 描述一件坏事。
2. 将好事（如路线图）的名称分配给坏事。
3. 雄辩地争论为什么坏事真正是坏事
4. 宣布（2）的好消息为不好，因为（1）的坏消息实际上为坏。

我将尽力避免相同的错误。 如果团队不是以结果为驱动力，那么他们的过程就不会敏捷 （这只是根据项目规范的增量交付）。 正如我过去所说，该团队可以做的是产生更多的输出。 这是一个更有效的过程，但是只会更有效-不会更有效。 它可以帮助您更快地撞到墙上。 这使其成为一件坏事。

解决错误的问题时，有效的协调和执行是无关紧要的。

成果和逐步完善

对于产品经理而言，敏捷的一个有趣特征是如何管理“需求”。 这些天，我真的在谈论意向性，因为我所谈论的是组织实现成果的意向。 意图一词会引起我的听众共鸣，并帮助我专注。

一个敏捷原则（我相信我早在2000年就从​​肯特·贝克（Kent Beck）那里听说过）是在最后一个负责任的时刻做事。 这也是精益制造的特征。 在软件开发中，“做某事”正在创建在制品清单。 来自思想的洞察力，来自设计的设计，来自编码的代码，测试和来自测试的结果都是库存。 库存。 除非必须创建，否则不要创建它。 YAGNI是记住这一点的一种方法–“您将不需要它（所以不要构建它）。”

正如滚动计划鼓励我们勾勒出大致的时间表和未来的方向正确的计划，并为近期保留了详细的计划一样，意图性也随时间和范围而逐渐阐明。 我们避免投资创造可能会被丢弃的东西-有关遥远未来的具体细节。

您正在努力实现长期目标或结果。 为了支持该长期目标，您可以定义一些战略计划。 为了推进这些计划，您还可以确定一组可交付的，有价值的产品或产品功能。 这些是实现长期目标的步骤。 这些功能中的第一个功能可能会逐步完善为功能和故事-这是团队在发布和sprint中努力提供的功能，并在整个过程中获得反馈。 您不会建立涉及为实现目标而设计的所有计划的全部故事。 您可以根据需要逐步进行详细说明。 在最后负责任的时刻。

逐步阐明意图的一种方式的可扫描列表：

• 战略–长期目标，多年规模和组织范围
• 机会–支持该策略的计划，轻松一年或更长时间，范围可能有所不同
• 史诗般的–机会的关键组成部分或能力，可定位市场，产品或服务范围
• 功能–从用户角度收集的结果，可以为客户自动交付或测试
• 故事–在至少一种情况下为至少一位客户提供价值的一种方案

在一个小的团队中，所有这些逐步完善的过程都有两件事。 首先，它建立了环境–全局。 其次，它驱动焦点-团队目前正在努力实现的目标。 但是，这是以无法消除的需求和多层次设计元素为代价的。

• 考虑到选定的功能，故事很有意义。
• 该功能反映了一组设计决策（就交互和实现而言），以实现史诗的意图。
• 史诗表现出一些有关如何最佳实现机会的假设和假设。
• 机会代表了一种策略成功的一种方式的一方面。

这不仅是故意的，还在于设计和计划。 它们之间有着千丝万缕的联系。

当您跨越多个环境（逐步深入问题空间）时，您正在将规划元素和设计决策移植到团队的工作中。

随着时间的推移，您与市场互动–您会发现需要调整计划。 作为小型敏捷团队，您可以轻松地做到这一点。 您可以在细化阶梯上重新访问决策，然后进行调整。 大规模运营是关于协调和协调。 规划。 这就是为什么要注重结果才能使敏捷大规模开展工作的原因。 随着预期结果的变化，计划也会变化

成果和大规模规划

当您协调一个大型组织一起工作时，执行计划的某些部分时，必然会有分解和责任分配的元素。 对于瀑布式组织和敏捷组织而言，这是正确的。 他们俩都这样做，但是他们做的方式却不同，这使得从一个人转换到另一个人很困难。

在瀑布式世界中，将组织的各个区域，部门和团队分别作为“计划的一部分”执行。 有人协调团队之间的执行和职责分配。 这就是大型项目始终完成的方式。

当一个不敏捷的大型组织称自己为“敏捷”但跨团队协调计划时，而不是逐步阐述其故意性，该系统的行为与大型瀑布式组织相似。

当计划改变时，事情会变得有趣–也许我们生活在有趣的时代有点“有趣”。

其中一个团队将发现他们计划的特定部分将无法正常工作。 也许他们对原型或当前Sprint的交付品获得负面的客户反馈。 团队希望更改计划，以纳入此反馈。 问题在于团队只知道计划而不知道计划的意图。 他们缺乏有效地偏离（或修改）计划以解决非常实际的问题的环境。 他们必须官僚主义地将他们的发现“推向上游”，并就如何调整计划展开讨论。 同时，什么也没做。 这是“大规模”的，但不是“敏捷的”。 瀑布团队和非敏捷团队也是如此。

为了使团队能够适应计划，他们需要了解其意图。 有了对意图的洞察力，他们就可以在如何实现意图的一部分的背景下进行自我组织。 他们可以评估所学到的知识是否也使意图性框架在一级上无效。 该团队可以确定他们将如何适应，而无需逐步进行逐步升级-除非需要这样做。

以下区别是关键。 当每个团队都在计划的一部分中工作时，他们对跨团队的依存关系不了解，因此必须始终在升级之前进行升级。 在适应不断变化的环境方面没有自主权。 当每个团队都在努力表达自己的意图时，他们具有自主权和灵活性，可以改变自己要交付的内容。 他们只会在学习到的东西使意图无效时升级–然后升级只会达到所需的程度。

独特之处在于，在专注于意向性的过程中，每个团队在逐步完善的每个阶段都可以根据自己的情境进行调整，而不会破坏或破坏更大的意向性。 这是大规模敏捷性的秘诀。 没有它，您将只有规模化的瀑布，只有敏捷

变化的速度需要故意

在本文开始时，我断言，没有意向，大规模的“敏捷”组织不会更快。 如果计划没有更改，那么它们将比瀑布式组织更快- 避免死亡游行 ，并且通常更高效是由于交付频率频繁而产生的结果。 但是，每个团队都会被打败，每个计划都必须改变。

变更计划以及所有跨团队依赖关系的需要，减缓了规模团队的不敏捷性，使他们不比瀑布团队快。 与逐渐详细阐述的意图相反，可以使作为大型组织一部分的小团队的敏捷性和适应性得以提高。 没有延迟。

翻译自: https://www.javacodegeeks.com/2017/05/agile-scale-outcome-driven-broken.html

领域驱动设计 敏捷