敏捷性和软件架构如何结合在一起?
在这一期的Scrum.org社区播客中，Kurt Bittner客亚博一百送一百座主持了专业Scrum培训师彼得Goetz而且托马斯Schissler接下来讨论软件架构和敏捷团队之间的关系。他们讨论了敏捷团队对软件架构的常见误解，产品负责人在软件架构中的角色等等!
成绩单
库尔特·比特纳0点
大家好，我是库尔特·比特纳，今天由我代替戴夫·韦斯特主持Scrum.org社区播客。亚博一百送一百我们通常这是我的播客同事彼得和托马斯几周前的一次谈话的结果。我们想，嘿，这真的很有趣。让我们让我们把这个展示给更多的观众，并讨论一些有趣的话题。我们的话题。今天，我们将讨论敏捷性和软件架构，并尝试找出敏捷性和软件架构是如何结合在一起的。它们互补吗?他们有竞争力吗?他们完全被诅咒了吗?在我们开始之前，我是Kurt Bittner，我在scrum.org工作了，我不知道，可能从2016年开始。但是在这个行业工作了很长很长一段时间之后，我对scrum.org的兴趣主要与扩展、企业敏捷性、领导力和各种主题有关。 And so I think architecture fits really well into that. And we'll talk about why I think that and why Peter and Thomas think that But Peter, Thomas, why don't you introduce yourselves?
彼得·戈茨1:24
是的,太棒了。我可以开始了。我叫彼得。我是软件开发人员。我在这个行业已经呆了20年了。我大部分时间在使用Scrum的敏捷团队中工作。我是一名专业的scrum培训师。从2012年开始，我在过去的10年里一直是一名专业的scrum培训师。
托马斯·希斯勒1:51
是的，我是托马斯。自2010年以来，我也是Scrum.org的scrum培训师。我最喜欢的培训是APS - SD课程，它是关于如何在Scrum环境中真正应用软件开发实践的。作为彼得，我对软件开发或技术方面的东西非常有热情，你可以真正实现什么，以及你如何将这些东西与人力资源环境结合起来，真正创造出伟大的东西。是的，软件架构在这个领域绝对是一个非常重要的主题。这是我非常喜欢谈论的事情，因为关于这个问题有很多误解。我希望我们能在这期播客中更清楚地阐述这个话题。
库尔特·比特纳2:53
彼得，托马斯，在我们继续之前，也许你们可以扩展缩写APS- SD。
彼得·戈茨3点
哦，是的。它甚至是一个很长的缩写词。它代表将专业Scrum应用于软件开发。这意味着这是一种培训，Scrum.org提供了一个非常独特的软件开发视角，以及如何在这种情况下应用scrum。
Kurt Bittner 3:24
从我们的谈话开始，这是我们几周前在电话中开始的地方，在我看来，架构总是被许多人视为敏捷团队的禁忌话题。我想知道你的观点是什么，你知道，软件架构是如何不被团队所欣赏的，他们错过了什么吗?因为我知道我们都认为这很重要。但是很多人不同意这个观点。我很好奇你是怎么想的，我们是怎么走到这一步的?你知道，人们错过了什么?
我认为这是我们自己造成的问题。我们指的是scrum实践者、敏捷团队以及在敏捷团队中工作的人。因为我们经常听到或读到一个概念，但我们并没有真正阅读文章，我们只是阅读标题。我认为，当人们读到紧急架构，读到迭代增量构建软件，并不断改进时，他们错误地假设软件会，软件架构会从无到有。所以，我认为这是一个很大的误解，在我看来，这更像是对20多年前非常严格的软件架构实践的反运动，在那里，我们有，像这些大的阶段，我们做分析和设计。我们制作了所有这些图表，以及如何切断我们软件的构建模块。我们假设，或者很多人假设软件架构会自行发展，这是真的，一些架构会出现。但它很可能不是你想要的软件架构。
Thomas Schissler 5:27
这是真正的前进。
彼得·戈茨5:32
再补充一下彼得刚才说的，我认为，在过去，正是我们试图设计一种软件架构，它完美地适合我们正在为我们正在解决的问题而构建的软件。这对于旧的瀑布式方法来说是一个很好的方法，因为这要求我们在开始实现一个伟大的软件架构之前，预先了解软件的所有需求。因此，一旦我们以一种敏捷的方式进行规划工作，我们同意我们不能预先知道所有的需求。我认为这可能是一个巨大的挑战，可以说，好吧，我们如何为软件产品创建完美的软件架构，如果我们甚至不知道所有的需求，我认为这可能是一个很大的变化。至少，这是一个很大的变化，对我来说，真正意识到我们必须考虑一种不同类型的软件架构，当我们以敏捷的方式工作时，可能不太需要找到完美的软件架构来解决特定的问题。它更多的是构建软件架构，它是可进化的，随着时间的推移，允许我们适应不断变化的需求。我认为这一步可能也是问题的一部分。
库尔特·比特纳7:12
是的。另一件事，我认为也是我同意你们俩说的另一个误解，我认为是，甚至是软件架构的旧概念，因为相信你可以以某种方式获得一组需求，并提出一个完美的解决方案，而不实际构建和测试一些东西是一个谬论。所以，你知道，当我们过去构建系统的时候，我必须声明，我从来没有真正做过瀑布项目，即使回到20世纪80年代早期，我总是增量地和迭代地构建东西。部分原因是我在做一些事情，你知道，在刚刚推出的硬件上，我在做一些问题领域的事情，这些问题领域还没有真正定义好。所以唯一的方法，唯一成功的方法就是建造它，不断地测试它，不断地完善它。但是在做的过程中，我发现了一些我自己的紧急架构的问题，因为对我来说，架构的本质不是我们过去认为的图表和，你知道，建筑评论会议和其他类似的东西。它实际上是你所做的决定，关于你要建立什么以及你将如何去做。所以我总是发现，如果没有通过构建一点，然后进行测试而获得的信息，你是无法做出这些决定的。然后评估你的假设。因此，建筑是关于决策的概念是我最近一直在写的。 But I think it's it's an interesting thing to build on a couple of things that you both said, you know, Peter, your comment about, you know, you'll always have an architecture, the question of whether it's good or not, is sort of the thing that you're trying to achieve. And I think out of out of building something, you can figure out whether it's good or not. And so I tend to think of traditional architecture as being a lot of unproven assumptions about how things are going to work. And the only way to test those assumptions is to build a little, a little bit of it, not all of it, but build a little little bit of it. And so, for me, I find that there's a perfect fit between Agile processes and Scrum and architecture because well you know how I mean scrum basically says you need to produce something valuable and working every Every single sprint, well, you know, here's your opportunity to build a little bit of the solution and test some of your ideas. So I think that that's it. For me, it's not so much that actually, it's the opposite of architecture and agile don't fit together. It's like they fit together perfectly. But it's because of a mis misconception about what architecture is and how you do it. So I don't know what of your experience has been with that?
Peter Goetz 10:30
我想，我想，在此基础上，因为你说的关于决策的一件事，在我的理解中，这也是建筑的核心。但问题是，我的意思是，当我们，当我们创造软件时，我们一直在做决定。问题是，什么是建筑?像什么?架构是如何不同于我们所做的这些正常的决定。当我想到这一点时，我总是使用一个非常松散的定义。这就是，建筑是关于重要的事情。我想Martin Fowler说过类似的话，我很喜欢，因为它是关于那些有高风险或高成本的改变，如果我们需要重新评估它们如果我们需要重新做它们。而且，我认为这些类型的决定限定了建筑决策。然后问题是，我的意思是，我们什么时候我们什么时候我们决定这些重要的事情，无论重要的是什么，在我看来，有一些事情在大多数Scrum团队中被低估了，从我的经验来看，当涉及到软件架构时，产品负责人是一个非常非常重要的部分，因为它总是从产品的愿景开始。 What is the most important or what are the most important 123 Maybe five quality criteria or quality goals that we want to achieve? And then we optimize our important decisions on reaching these goals. And in my opinion, this is something that many product owners do not appreciate enough, many Scrum teams do not appreciate it enough. And I would like to, to have and work with product owners who are more interested in what is the vision? What are the quality goals? And then what what type of architecture do I get, because architecture is not something that is hype driven, or that is where we use the technologies that are currently on voc architecture and software architecture in particular, is something that is dedicated to solving a concrete problem to reach a specific quality goal or quality criteria.
Thomas Schissler 13:01
我非常喜欢你谈到验证的部分，因为我非常同意我们所做的所有决定都是基于各种假设，这些假设可能是对的，也可能是错的。验证部分是非常重要的，我一直在做传统的瀑布式项目，我可以，我可以，如果我回想那些日子，那是在项目非常非常晚的时候，当我们真正能够验证那些假设的时候。我认为，在瀑布式设计的传统中，你会尝试着在做决定时进行大量的分析思考。你的期望是,你有考虑过所有的东西,事实上是不可能的在我看来,这可能是传统的瀑布后面的大误导的想法,我们可以如果我们细心计划我们可以想出所有细节我们必须考虑如果我们后来发现我们错误的决策,那么可能我们的规划是不够好,下次你应该做得更好混合然后它会工作。这可能是过去瀑布时代最大的误解。我认为这正是你所说的，我们必须验证这些假设，并在开发周期中尽早纠正方向。这只有在我们实际构建软件时才成立如果我们正在构建工作软件，这就是敏捷和Scrum的本质，例如，我们在小增量中有一些东西，我们可以验证假设，这不仅是关于需求或业务价值的假设，也是关于软件架构的技术假设。
Kurt Bittner 15:11
现在，有很多有趣的事情。正如你们所说，我认为人们对架构的误解之一是，在某种意义上，如果你考虑敏捷的适用性，我们经常谈论我们正在处理复杂领域的问题。而架构，尤其是在当今世界，尤其复杂，因为在用户工作负载、响应时间、内存、网络吞吐量、网络延迟之间有非常复杂的交互，你知道，计算能力，使用所有这些来自不同供应商的不同组件和服务。这是完全不可预测的。和所有
托马斯·希斯勒16:00
你提到的那些部分一直在变化。所以这不是一个稳定的系统。在里面，我们正在计划和建造东西。它一直在变化。我想这甚至增加了复杂性。
Kurt Bittner 16:17
有趣的事情捆绑到彼得提到的东西,这是质量目标的概念,或在一些著作和另一个同事,我一直在做皮埃尔纯净,我们一直谈论质量属性需求,但这基本上意味着什么,你知道的,我们的目标是什么,你知道,响应时间和用户数量和吞吐量,以及,你知道的,甚至一些,像,你知道,系统的可维护性,以及支持性系统和弹性。通常，这些架构品质，你知道，你谈论led，英语，还有，有质量目标的概念，架构专注于质量目标，而功能需求专注于系统的行为目标，我认为这对人们来说是一个有趣的补充。我发现很多Scrum团队甚至没有必要考虑质量目标，但是，你知道，就你的观点而言，这应该是产品所有者非常关心的事情，甚至可能会把这些事情放在产品待办事项列表中。除此之外，我还想补充一件事，还有一个有趣的概念，叫做最后责任时刻。因为你知道，这种说法，我们必须满足所有这些质量目标可能会导致一些人说，哦，我们会花我们的第一个，你知道，五个Sprint处理质量目标，然后我们会处理产品，但你知道，更多的功能需求，那也不是，那是不对的，因为我们需要做的是我们想要尽可能地推迟决定，但以一种负责任的方式。所以，你知道，每个sprint的问题就像，好吧，这是质量目标，我们在这个sprint中所做的任何事情都可能会锁定我们的特定解决方案，或者可能会阻止我们实现这个质量目标?如果答案是否定的，在这次冲刺中没有什么会把我们锁定，我们仍然有完全的自由。很好，那我们现在就不用管这个了。但是如果你说不，你知道，为了实现这个特定的产品backlog项目，或者这组东西，或者冲刺目标，我们将不得不处理延迟问题来举个例子，那么，那么，好吧，那将不得不，你将不得不在冲刺中做一些架构工作来做到这一点，因为推迟这个决定的成本太高了。 You might you might have to rewrite everything, you know, if you find out a different answer, you know, five, Sprint's on, you might have to rewrite everything you've done up to that point that would be very responsible. So I think that notion of quality goals, and then thinking about what's the last responsible moment, or, you know, do we absolutely have to handle this issue in the sprint in order to have a sustainable solution. And using that as a filter on on the sprint planning is, I think a really interesting way to think about doing the architecture work instead of loading it all upfront. Because sometimes, you know, you, there's an interesting interaction between between functional requirements and those non functional or architectural quality goals is that is that sometimes in order to achieve a particular, you know, sort of user oriented outcome, you've got to solve some particular architectural problem. And so that the two of them interact, it's not like you can deal with all the quality goals first and then and that was sort of that I think the problem with with the waterfall approach architecture is that they they tried to solve all the quality gold problems first in some big design, and then build the funnel nothing's on top of it. And what usually found out this time, as you mentioned is that some of your assumptions turned out to be false. And that content causes you to completely rethink. And the later you find that out, usually, the worse it is.
Thomas Schissler 20:15
我认为这个质量目标也起着非常重要的作用。在评估部分，它们允许你关闭反馈循环。因为如果您想验证您在软件架构方面所做的决定，您必须提出具体的问题。无论您的质量目标是什么，这个决定是否使我们的系统变得更有弹性、更安全、更可维护?这些质量目标为您提供了正确的问题来验证您的体系结构决策。我认为这可能是一个机会，你不能只让产品所有者参与这种对话，我们甚至可以更进一步，让我们的利益相关者参与其中，说，好吧，我们现在已经改变了可能在几个星期的过程中，这个架构的事情，你觉得这个产品更接近质量目标吗?你感觉好点了吗?下一个我们应该关注的目标是什么?我们应该在哪里尝试在两个方面做出最大的改进，例如，这可能是在sprint评审期间的一次令人惊叹的对话。要提出这种讨论，如果你只是与利益相关者分享你选择的平台，一个Overbey。由于这个和那个技术原因，我们不会和他们进行对话。 But as soon as we bring in those quality goals, we find a connection between the technical world and the business world. And that is what the quality goals really do for me.
彼得·戈茨22:06
关于这个想法，我真正喜欢的是把它带回给产品所有者和利益相关者，我们也可以讨论我们必须做出的权衡。因为如果我问我的客户，你们想要安全吗?是的。你想让它易于维护吗?当然?你想让它可靠吗?当然，您希望它的性能高效吗?是的，我想要那个。但你想让它在功能上正确?是的，我也想要那个。 So if I give them a catalog with all these abilities, they want all of that. But the question is, if we if we make it a bit more performant, if we if we improve our resource utilization, but that in that impedes our maintainability, is that alright? So that we want to take that trade off. And this is something that I really liked discussing this, because this is often it's a business decision. It's not a technical decision. It's a decision that we have to make with the stakeholders with the product owner most probably. And I really like this type of conversation, because it makes it more graspable shell has introduced scenario based modeling in the 80s. They have, they have used it for many different things to for example, to model the, the the climate change, or to model political development in different countries. And the interesting thing about the scenario is that it makes something abstract concrete. If I talk about maintainability, I can I can wholeheartedly say, Yes, I want to have it maintainable. But if I have to make it concrete, and make it clear, what is this maintainability that you're talking about, then I need to find the concrete scenario, and this is something that really helps in in talking about this. So if I say we would like to be able to, to add a new language to our website, in within that most five working days and this should be should be mostly done by one person. So this is a concrete scenario. And then I can look at the decisions that I have made in my important decisions. I can look at them, and I can figure out or I can think about if if I think it plausible and probable that we will be able to make that quality goal or scenario. And if not, then we have to maybe we have to adapt something, we have to change something.
库尔特·比特纳24:41
我真的很喜欢。我认为质量目标中很重要的一点是它们不是二元的不是性能或非性能的问题。你必须非常明确你所说的表现是什么。响应性是什么意思可维护性是什么意思这个场景帮助你更具体地描述了这一点。然后回到托马斯关于验证的观点，你可以，你可以验证，好吧，在冲刺阶段，我们测试了那个场景，你知道，我们运行了一遍，我们做了一种，假设你想让系统对某些类型的变化非常可维护，比如，改变语言，或者添加一种语言，然后你实际上可以说，在冲刺阶段，我们实际上做了，我们添加了一种新语言。这是成本，这是结果。然后你可以把这些信息呈现给利益相关者，然后说，好吧，这是否满足了你的产品质量目标，然后你可以评估并说，嗯，你知道，也许它基本满足了，但你需要在下一个冲刺中做一些改变，或者在未来的冲刺中可能不是下一个冲刺可能不是这样做的正确时间。但是要明确质量目标，使其可测量，并实际使用您在sprint期间所做的工作来收集关于您是否满足质量目标的信息，而不是让它成为一个主观的，您知道，通常情况下，那些架构质量目标是主观的，它们不应该是，它们应该是非常精确的。如果它们不是，那么还有更多的工作可能是完善的好机会，例如，完善目标。所以我们可能只剩下五分钟左右的时间了，我们我知道，我们三个人可以说上几个小时。 And it would be really fun, although we probably would need to do it over a beer and you know, somewhere in Germany. But the, I think an interesting thing to maybe wrap up with is, you know, if most Scrum teams today are not really embracing this architectural work, and we've talked about some some ways that they might be able to do that, but you have any advice for those teams about how to get started, how to start incorporating the architecture work into the work that they do in the sprint, because, you know, most teams that I've run into, they have too much work to do in the sprint anyway, they have trouble, you know, really scoping the work enough so that they get it done and produce the working increment. And now we're asking them to add a bit more. But is there a way for them to basically do the architectural work in a way that doesn't put all the other things they need to do completed to the side?
托马斯·希斯勒27:44
我可能想从一个稍微不同的角度开始，因为我认为你是完全正确的。我经常遇到的一个误解是，为什么在Scrum中没有定义架构角色?所以如果我们不为它定义一个角色，那么它可能就不重要了。这可能就是为什么人们会想，好吧，那我们不做建筑就会神奇地出现，或者其他什么。所以，我认为，这又回到了我们谈到的质量规范。在我的理解中，我会说scrum团队中的开发人员，他们是软件架构师，他们应该做出所有的架构决策。但他们并不是孤立地这样做的。但是质量目标主要来自涉众和产品所有者，它们给开发人员提供了方向，让他们知道他们正在优化哪些目标。他们知道如何比较他们拥有的不同选项，因为他们可能会选择最有助于实现质量目标的选项。因此，这给出了方向，这就是如何，至少我看到了我们如何在scrum团队中划分架构工作，做出架构决策。 And probably more to the technical side. I'll leave it to Peter to go into this in more detail.
彼得·戈茨29:27
我不想讲得太详细因为它应该很容易开始。所以我总是把事物和其他事物进行比较。所以如果我问一个非常擅长跑马拉松的人，如果我问他们给我一些关于如何跑第一次马拉松的建议，他们会拿出一个20多页的训练计划，我很可能不会开始。我认为可以从非常简单的对话开始。我认为在那次谈话中，我们应该谈谈质量目标。所以我喜欢这个架构质量属性，我认为我们有时在架构讨论中听到的质量要求，并且可能明确地从开发团队的角度，问，好吧，关于这个需求，从功能方面而是从定性方面来说，什么是重要的，然后花5分钟思考一下我们是否必须做出重要的决定，一个很难改变的决定，改变成本相当高。然后给他们一些时间，也许10分钟的讨论就足够了。或者使用，明确地使用日常scrum来讨论当前高风险的事情，高成本的变化。也可能是你目前描述的，或者你在今天会议开始时提出的，将架构工作放在产品待办事项列表上。在我看来，如果是必须要做的事情，那就应该放在产品待办事项列表上。 But it's also a misconception that many teams have, that everything on the product backlog always has to be from a from a functional from a user's perspective, I disagree. The product backlog contains all the work that needs to be done for the for the product. And if architectural work is the work that needs to be done, we should put it on the product backlog. And, and I think with these small things, and with these small, let's say reminders of where to focus on architectural decisions, I think it becomes a habit. And then architecture becomes more natural to everyone on the team. And what I've realized in the teams that I work with, and currently I'm working with a development team that is quite Junior, but they are making all the decisions on architecture, I guide them a bit, I give them advice, I mentor them, you can say, but I do not decide because I'm not the architect, they are the developers of this team. And they grow very, very fast. And this is something that I really like that there does not have to be the architect, we can we can build that up like any other skill in the team as well, we can build that.
库尔特·比特纳32:27
我认为这也是正确的建议。其中有几点我想我们可以总结一下我们的演讲。一是架构关注于决策，它从根本上是关于产品的技术决策。我认为我们之前谈到的另一件重要的事情是，将这些决策暴露给产品所有者和利益相关者，最终会促进一些真正有趣的对话。所以要明确我们做了这个决定，这就是我们做这个决定的原因，这些是它的含义。你能接受吗?你觉得这样对吗?另一个你们谈到的有趣的部分是架构设计不是一个角色。这是团队，主要是团队中的开发人员所做的一项活动，但团队共同做的是为了解决或满足这些质量目标。所以对我来说，这种观点，从简单开始，是非常实际的。 It doesn't require you know, do lots of studying, in order to do it, it you know, you will learn by doing it. And, you know, there's no reason to put it off. You know, when you know, I would say that my advice to a scrum team out there is that, think about these things, talk about it when you're doing sprint planning. And the next time, talk about when you're doing refinement, and think about how you can start addressing the quality goals that you have for the product. And maybe the starting point might be just having, you know, being explicit about the quality goals, and then fostering those discussions. So I think this has been I know we're running short on time. And maybe we can have a follow up discussion sometime. But I want to thank both of you for taking the time today. It's always interesting to talk to both of you. And this is a topic I know that the three of us are really passionate about and hopefully the listeners are now passionate about it too. Or at least we've given you some things to take home and try and do on your own teams. So I want to thank everybody. Tune in next time for the next scrum.org Community podcast for another interesting topic. But anyway, thank you for this one.