java 电话薄
最近，我与两位同事进行了一次对话，试图解释经常提供垂直价值的薄切片相对于单独工作并最终整合的优势。
我已经很熟悉这个概念了很长时间，并且通常认为它是理所当然的，但是在解释它时，我发现自己茫然，只有等了好一会儿我才能提出自己的观点。 这次谈话促使我写这篇文章，以便我自己或其他任何人将来都可以将其用于此目的。
让我们想象一个典型的Web应用程序，它具有一个UI层，一个服务层和一个数据库层。 让我们考虑一种非常常见的情况，在这种情况下，我们的开发人员非常专业，可以执行UI或服务或数据库，不存在任何交叉技能。
通常有两种方法可以交付此应用程序：
- 创建组件团队，以定义组件之间的接口并隔离交付每个组件
- 创建一个包含所有3种技能的团队，并交付少量的价值增值，即包括3层且可发布的小型交付物。
不管您是否相信，第一个选择是大多数开发人员和传统软件开发经理通常首选的选择。 它给第一个提供了使用其主要技能的能力，第二个赋予了他们对效率的幻想，因为他们认为自己为正确的目的使用了正确的技能。
组件团队模型
通常，组成团队的梦想在整合时就被打破了。 让我们想象一下他们每月发送一次冲刺。 在冲刺结束时，每个团队都会相信自己已经完成了冲刺，因为一切都在他们的上下文中进行。 现实情况是，在集成时，似乎在接口中完美定义的东西通常被证明是不正确的。 事情不起作用，团队捍卫其组件设计和实现，将集成失败归咎于其他团队，并且没人对其中最重要的事情承担责任： 客户无法利用价值 。
在第二次冲刺之前，团队通常会决定他们需要一个“集成测试冲刺”（原文如此），以解决团队无法使用预定义的界面来阻止的问题。
通常，这标志着公司交付客户价值的能力开始缓慢下降的迹象。
随着时间的流逝，团队变得更加坚定地捍卫自己的组成部分，并责怪其他任何组件失败。 集成测试变得冗长而痛苦，与维护我们的组件团队的地位相比，客户变得越来越不重要。
你到过那里吗？ 我有，我敢打赌你也有。
组件集成爆炸
有一个解决方案。
秘诀是从交付组件转变为识别贯穿所有组件且客户可以使用的价值薄层。
似乎很容易，一旦习惯了，它实际上就是如此。 问题是思维方式从系统转向价值。 人们习惯于交付系统，而不是解决问题，如果您想确定要交付的价值的细小片段，则需要专注于解决问题，以便客户从基础系统中尽可能多地抽象自己。
您需要做的第一件事是让团队拥有全部技术堆栈所需的全部技能，以便每个单独的团队都能独立提供客户价值。 像这样：
团队创造价值
每个用户故事都将传递价值的一小部分，开发人员将进行协作和配对，而不是通过界面进行交流，所有权将是传递的价值而不是软件组件。
像这样工作，一旦我们将各层与价值的第一部分联系起来，集成问题就会立即出现。 反过来，这将有助于我们避免基于错误的假设而构建过多的软件。 第一个薄片可能具有挑战性，并且需要花费一些时间，但是它将包含大量的学习知识，这些知识将用于减少构建后续薄片的时间。
我们可以将相同的概念扩展到产品开发。
假设我们的公司是一家国际在线批发商店，服装店老板可以在其中购买其库存。 现在，我们有机会通过向我们的产品介绍珠宝来扩展市场。 企业主感到非常兴奋，因为他们相信新产品可以使我们的收入增加30％，并且他们已经确定了供应商以获取便宜的库存。
珠宝项目开始了！ 每个人都很兴奋。
经过短暂的研究，我们发现居住在Regulationstan民主共和国的顾客对一段时间内单个商店可以购买的珠宝数量有一些限制。 数量视珠宝类型（金，银，铂金）而异。 另外，其他10个国家/地区不允许批量购买手表并使情况更糟，在我们居住的国家Paranoidland，存在珠宝销售商获取和存储长达10年的珠宝了解客户信息的法规包含钻石。
我们可以设计一个复杂的系统，使其能够遵守所有限制和规定，并实施并在6个月内将其交付给全世界。 或者，我们可以选择一类不需要遵守自己国家法规的商品，而将目标放在一个不施加法规的富裕市场中，并在一周内交付。
选择将取决于我可能无法想象的许多特定于上下文的因素，因此我不会这样做。
我可以确定的是，如果使用第二种方法，则输出会有很大的不同，不同之处在于一周之后，我们的产品将收到其客户的反馈。 有了可用的客户信息，我们就可以发现未知的事物，并且可以轻松地决定下一步要交付什么。
您可能会说，这与组件团队和垂直切片团队有什么关系。
一切。
通过在短时间内提供垂直的价值切片，我们能够进行有意义的评估，并使用反馈来决定在下一个切片中构建什么以及如何构建。 第一部分价值很可能会为我们提供足够的信息，这些信息使我们计划在未来构建的某些价值部分变得不那么重要，甚至完全不相关。
通过这样做，我们刻意发现未知因素，并以学习为指导。
在每一个细微的变化之后，我们收到的反馈就是我们的指南针，每次发布时，我们都会获得新的指导，并确保我们永远不会走过成功之路。
翻译自: https://www.javacodegeeks.com/2015/04/thin-vertical-slices-of-value.html
java 电话薄
