PDF敏捷与 SEMAT—完美伙伴
将敏捷与 SEMAT 相结合比单独使用任何一方都更有优势
Ivar Jacobson、Ian Spence 和 Pan-Wei Ng
时至今日，与往常一样，许多不同的倡议正在进行中，以改进软件开发的方式。其中最受欢迎和最普遍的是敏捷运动。SEMAT（软件工程方法和理论）倡议是后起之秀之一。与任何新的倡议一样，人们都在努力了解它如何融入世界，以及如何与所有其他正在进行的事情联系起来。例如，它是改进还是取代他们目前的工作方式？它像精益一样，支持和促进敏捷运动的目标，还是更像瀑布式计划，与敏捷方法背道而驰？
好消息是，这两项倡议都提倡非规定性的、基于价值的理念，鼓励软件开发团队选择和使用最适合其环境的任何实践，更重要的是，不断检查、适应和改进其工作方式。这两项倡议相辅相成，为希望掌握软件开发艺术的团队提供了完美的基础。
敏捷运动为审视软件开发的日常活动提供了一种新的方式——团队如何组建以及工作如何组织。这促成了开发团队的赋能，以及敏捷实践（如 Scrum 和测试驱动开发）作为现代开发人员首选实践的突出地位。
SEMAT 是一种审视软件工程领域（此处该术语与软件开发互换使用）的新方式，它提供了对开发工作的进展和健康状况的理解，以及如何将实践结合成有效的工作方式。SEMAT 通过提供所有团队都可以在不断改进其工作方式时使用的通用参考模型，增强了敏捷的力量。
当结合使用时，这两项倡议真正地赋能团队进行创新、实验、调整其工作方式并改进他们交付的成果。
本文重点介绍 SEMAT 如何帮助现有和未来的敏捷团队。它是为那些已经熟悉敏捷性的人设计的。
SEMAT 为敏捷性增加了什么
敏捷性提供了一系列价值观，这些价值观影响和塑造了软件开发人员进行日常工作以及与彼此、他们的客户和他们的干系人互动的方式。
它也为我们提供了许多方法，这些方法共享共同的原则，但在实践中有所不同。这些方法是开发人员必须能够检查和适应的，因为情况会发生变化。敏捷方法为团队的敏捷之旅提供了一个很好的起点，但它们需要不断发展以满足团队不断变化的需求，并反映他们所吸取的教训。这反映在越来越多的敏捷团队从可用的一组实践中组装定制的方法，而不是从货架上拿现成的方法。
面向敏捷团队的 SEMAT
使用 SEMAT 可以帮助敏捷团队做到以下几点
尽早发现系统性问题并采取适当的行动。 敏捷团队持续使用快速反馈和密切协作进行检查和适应，以避免问题并为团队提供方向。为了支持和鼓励这种工作方式，SEMAT 提供了一些简单的清单，以帮助团队了解其进展和健康状况，并帮助他们尽早发现其工作方式的问题。SEMAT 提供的清单类似于其他专业中使用的清单。例如，英国医院的外科团队通过使用一个简单的 19 个问题的清单（其中问题如“你的名字是什么？”）将手术错误导致的死亡人数减少了 47%。同样，使用 SEMAT 清单降低了团队灾难性失败的风险，因为它帮助他们避免了许多导致失败的常见错误，例如不断增加的技术债务、干系人支持的丧失、低效的工作方式、不切实际的期望和功能失调的团队。
衡量团队的进展和健康状况，而无需考虑选择的方法或实践。 所有敏捷团队的关键进展衡量标准是他们生产的工作软件的数量以及他们生产软件的速度。SEMAT 通过提供团队及其工作的进展和健康状况的另一个视角来补充这些衡量标准——这种视角可以帮助团队在他们和他们生产的系统成熟时保持速度。通过使用 SEMAT 及其提供的简单清单来评估他们当前的状态，团队可以轻松了解他们身在何处、下一步应该去哪里，以及他们的努力如何适应他们需要支持的任何组织治理实践。
比较和对比实践，并为团队选择最佳实践。 敏捷团队一直在寻找新的实践来帮助他们改进工作方式并发展他们的方法。SEMAT 提供了理解实践的范围、目的和内容的机制，帮助团队理解其覆盖范围以及它们在哪里重叠、冲突或互补。它还允许团队即插即用实践，在他们最喜欢的敏捷框架（例如，Scrum 或 Kanban）的上下文中安全地混合和匹配它们。
评估所选实践集的完整性，并了解工作方式的优势和劣势。 在匆忙采用新实践的过程中，团队有时会在其工作方式中留下漏洞，其后果通常要到团队的速度开始下降并且始终未能实现其目标时才会变得明显。这并不意味着工作方式需要预先定义或完整；事实上，如果不是这样可能会更好。重要的是团队成员意识到他们已达成一致的内容、他们在哪里保持一致以及他们可能需要哪些帮助。SEMAT 的使用有助于团队推理工作方式，并就他们选择的一组实践的广度和深度做出基于事实的决策。拥有帮助理解其工作方式的优势、劣势和完整性的机制对于真正致力于持续改进的团队来说是宝贵的。
保持团队工作方式的最新记录，并与其他团队共享信息和经验。 敏捷社区在协作和互动中蓬勃发展。实践和经验的共享有助于个人、团队、组织和整个行业改进和发展。SEMAT 提供了帮助团队以轻量级、敏捷的方式准确记录其工作方式的机制，他们可以与同事和合作者实时共享这些方式。这提供了关于团队工作方式的透明度，并且它帮助每个人了解团队正在做什么，而不会被过时的关于团队应该做什么或者团队成员在获得实际经验之前认为他们会做什么的描述所困惑。
对方法保持敏捷，轻松安全地发展团队的实践集，因为它可以检查和适应其工作方式。 检查和适应工作方式对于任何真正希望持续改进的敏捷团队来说都是必不可少的。当团队：（1）变得过于执着于当前的实践集，有效地冻结了其工作方式；（2）选择不同但效果较差的实践，这些实践引入的问题多于它们解决的问题；或（3）不了解他们在软件系统演进中所处的位置，因此不了解他们应该更改哪些实践时，其有效性可能会降低。SEMAT 提供了框架和思维工具，以帮助团队更有效地检查和适应其工作方式，理解其决策的后果，并持续改进其工作方式。
面向敏捷组织的 SEMAT
SEMAT 提供了额外的支持，帮助整个组织变得敏捷，而不会损害构成它们的团队的敏捷性。特别是，它有助于
在组织内建立软件开发的 ground rules，并以独立于实践的方式捕获组织价值观和原则。 软件开发不是孤立发生的。开发团队必须始终意识到文化、价值观和原则对他们合作的组织的重要性。他们需要与其他团队和组织的互动领域建立一些共同点和共同理解。SEMAT 提供了所有软件开发团队共享的共同点的简单定义。这为希望将软件开发集成到其业务和价值流中的组织奠定了坚实的基础。组织可以扩展 SEMAT 定义，以捕获适用于他们开发的特定类型的软件或他们开发软件的特定环境的任何其他规则或建议。建立共同点是组织敏捷性的先决条件，但它还不够。它应该辅之以组织实践交流，团队可以在其中分享他们使用的实践。
定义独立于实践的治理程序和质量关口。 出于业务、法律和安全关键原因，许多组织感到需要对其软件开发工作应用治理。大多数大型组织在法律上被要求对其软件团队及其生产的软件执行财务和/或技术治理。不幸的是，许多组织将其治理定义为一系列顺序阶段，每个阶段都有一组预定义的必需工件，这些工件必须在下一个阶段开始之前完成并签署。
在这种僵化、规定性的环境中，敏捷团队不可能充分发挥其潜力。治理的存在是为了提供制衡并确保所产生结果的质量。治理程序和质量关口应与所生产软件系统的自然演进对齐，侧重于所需的关键结果而不是要生产的工件，并体现为简单的独立于实践的清单。然后，它们将提供一个框架来支持而不是抑制敏捷和精益的工作方式。这是 SEMAT 采取的方法，允许以轻量级和独立于实践的方式定义治理程序和质量关口。然后，敏捷团队可以混合和匹配他们想要的任何敏捷实践，并且他们可以持续检查和适应，而无需脱离治理。
跟踪和鼓励组织内实践的使用。 敏捷团队喜欢学习和分享新的实践；这是持续改进方法的基本组成部分。通过将所有软件开发工作都建立在共同点的基础上，团队可以更轻松地共享他们的实践。通过建立实践交流以促进实践的共享和分发，组织可以深入了解哪些实践正在何处使用，以及哪些实践集正在产生最佳结果。这有助于组织不断发展其推荐实践集，撤回那些已过保质期的实践，并在需要时推广新的实践。
更轻松地组建团队和动员团队的团队。 尽管敏捷团队旨在保持在一起，但现实情况是，即使他们不为坚持矩阵式管理方法和不断重组的组织工作，他们也会定期更换团队成员。以这种方式进行上下文切换通常会降低速度、增加摩擦并浪费时间。SEMAT 为团队提供了软件工程的通用语言，这将帮助他们相互理解、清晰地表达自己并分享他们知道的实践——所有这些都将帮助他们快速有效地协作，最大限度地减少浪费的时间、毫无意义的讨论和误解。它还提供了建模团队所需能力和个人获得能力的机制。这可以帮助组织找到合适的人加入合适的团队，然后观察他们作为软件专业人士的发展。
跨团队的团队和系统的系统扩展敏捷方法。 扩展敏捷性是当前希望变得更加敏捷的组织面临的最大挑战之一。SEMAT 方法通过多种方式帮助组织扩展敏捷性
• 它为所有相关团队建立了共同点。扩展的敏捷性要求许多团队协作，在同一系统上工作并改进相同的价值流。在这种情况下，所有团队都对他们正在做什么有共同的理解，并且有共同的语言来帮助他们沟通，这一点甚至更为重要。
• 它允许团队灵活地使用他们的实践。扩展的敏捷性需要团队可以使用的实践集具有更大的灵活性。在同一系统上协作的团队将需要彼此共享实践。在某些系统上工作的团队将需要使用最初用于开发该系统的一些实践。SEMAT 混合和匹配实践的能力，根据需要将它们换入和换出，为团队在扩展的敏捷环境中取得成功所需的工作方式提供了灵活性。
• 它帮助团队了解他们与其他团队的交互点、他们的职责范围以及他们的进展和健康状况如何影响他们合作的团队。如果每个人都使用共同点来表明他们的职责以及他们的进展情况，那么团队间的协作就很容易监控和改进。
选择企业级工具。 通过为软件开发提供共同点，SEMAT 也为企业级工具提供了共同点。将共享的共同点与使用的各种实践分离，有助于组织了解他们需要哪些独立于实践的工具，他们需要哪些特定于实践的工具，以及这些工具是如何相关的。SEMAT 还通过提供他们将共享的公共元素的定义，帮助团队了解如何集成他们使用的工具。
敏捷性为 SEMAT 增加了什么
SEMAT 是非规定性的，以至于它甚至不坚持采用敏捷方法。它不关心团队采用什么方法，只要它以有效和健康的方式生产“好的”软件即可。
采用敏捷价值观为团队和组织带来了许多好处——好处太多，无法在这篇简短的文章中详述。对于采用 SEMAT 的组织，敏捷性在软件工程方法领域增加了一些重要元素，包括
• 原则和价值观。将敏捷价值观添加到 SEMAT 框架为评估进展和健康状况提供了必要的定性维度。
• 许多实践。敏捷社区是新的和创新实践的温床，所有这些实践都可以被编纂并作为 SEMAT 实践提供，供团队安全地比较、对比以及混合和匹配。
• 改进的驱动力。敏捷性将检查和适应周期嵌入到团队工作的方方面面。
在采用 SEMAT 之前，团队应确定其新的工作方式希望体现的原则和价值观。否则，将很难选择正确的实践或摆脱最初看起来像是学术过程构建练习的东西。
本节的简洁性与前面“SEMAT 为敏捷性增加了什么”部分形成对比，反映了敏捷性比 SEMAT 更广泛的接受度和知识。它不代表这两项倡议的相对价值或影响。
SEMAT 如何做到这一切？
SEMAT 倡议的目标是为软件开发人员提供健全的实践和理论基础，以提高他们的绩效。（有关更多详细信息，请参阅我们之前的文章“软件工程的本质：SEMAT 内核”。3）
SEMAT 倡议的第一步是为软件专业人员（开发人员、测试人员等）建立一个共同点，以便他们在谈论他们所做的事情时可以立足于此。这个共同点体现在 Essence 中，Essence 是软件开发中通用元素的内核——在每个开发工作中普遍存在的元素。Essence 包括以下要素：需求、软件系统、工作、团队、工作方式、机会和干系人。
这些要素具有可用于衡量进展和健康状况的状态。例如，团队可以采用以下状态：萌芽、形成、协作、执行和休会。为了达到特定状态，必须满足许多检查点，代表真正的成就。例如，为了实现协作，已满足以下检查点：团队作为一个有凝聚力的整体工作；团队内部的沟通是开放和诚实的；团队专注于实现团队使命；团队成员彼此了解。
传统上，检查点用于衡量活动或文档的完成情况，但 SEMAT 检查点衡量结果。因此，通用要素代表成就而不是文档或工件。这使得它们与任何特定方法（敏捷与否）无关。这些要素被称为阿尔法。
软件开发是多维的，阿尔法识别了每个软件开发工作必须考虑的典型维度，以便以健康的方式取得进展。如图 1 所示的雷达图给出了沿每个维度当前进展情况的视图。 1 从中心发出的每条线代表一个阿尔法，该线上的径向代表该阿尔法的可能状态。
Essence 还提供了一种轻量级的方式来描述内核之上的实践，从而扩展内核。团队可以从实践库中选择合适的实践并组合它们以获得他们满意的工作方式。通过这种方式，他们可以通过用更新更好的实践替换现有实践来随着时间的推移发展他们的工作方式。实践可以是不同类型的——例如，业务、社交或技术。每个实践都可以为将阿尔法从一个状态移动到另一个状态添加指导，或者它可以添加内核中未包含的阿尔法。通过这种方式，工作将增加更多维度。它还可以为它接触的每个阿尔法添加工作产品。例如，用例驱动的开发实践可能会添加用例作为阿尔法，并将用例规范和实现作为工作产品。
卡片和清单
Essence 规范提供了内核阿尔法的详细描述，包括其检查点的定义。然而，在日常工作中，团队不会随身携带 Essence 规范。更简洁实用的表示形式是一副卡片。图 2 显示了团队阿尔法的状态卡。
每张卡片顶部都有阿尔法的名称，后跟状态名称和简洁的检查点列表。这些充当开发人员的有用提醒。
板和可视化
除了状态卡之外，还有使用阿尔法的替代方法——例如，如图 3 所示的阿尔法算盘。算盘是一种计算设备，在线（代表数字）上有珠子（计数器）。在阿尔法算盘中，每条线代表一个阿尔法，每个珠子代表一个阿尔法状态。
这个可视化板可以用于各种目的。一种可能的用途是供团队评估其当前状态（它在哪里）并讨论其下一个目标（它想去哪里）。这可以通过绘制虚线和如图 3 所示定位珠子来轻松可视化。
游戏
一旦卡片和可视化可用，拥有游戏就变得很自然了。例如，Progress Poker 是一款评估进展和健康状况的游戏，类似于敏捷方法中使用的 Planning Poker 游戏。在 Progress Poker 中，团队的每个成员为每个阿尔法选择一张状态卡，以表示开发的当前状态。如果他们都选择相同的状态卡，则意味着他们对自己的进展有共同的理解。如果他们选择不同的卡片，他们可能对他们的开发所处的位置有不同的理解，并且对需要完成的事情有不同的期望。这种误解通常表示存在风险。一旦发现，团队成员可以进一步讨论以达成共识。其他游戏——Objective Go、Chasing the State 等——可以在 http://www. ivarjacobson. com/alphastatecards 找到。
案例研究
本节中描述的案例研究是软件开发团队如何充分利用 SEMAT 和 Essence 的很好的例子。
为大型电信公司的教练配备工具
我们与一家大型中国电信产品公司合作，该公司拥有多名内部教练。这些教练的能力对于每个团队的改进能力至关重要。为教练配备尽早发现开发问题的工具非常重要。在我们与其中一位教练的第一次接触中，我们询问他的团队做得如何。他觉得进展良好。然后，我们要求他使用一副阿尔法状态卡评估进展情况。他将卡片放在桌子上并开始移动它们，并很快发现干系人阿尔法的进展缓慢。他认识到这是一个风险，并将其作为制定计划以应对风险的重点，该计划基本上是实现干系人阿尔法的前四个状态。与这位教练的初步讨论仅用了 15 分钟。进一步的讨论发现，这位教练来自开发背景，而不是业务分析背景，这可能是他忽略干系人维度的原因。
在这个特定的案例中，所讨论的教练在一个领域很薄弱。在其他情况下，教练忽略了软件系统阿尔法所代表的其他维度，例如设计和质量。在另一些情况下，团队成员在工作方式阿尔法上存在分歧。无论情况如何，Essence 阿尔法都是评估进展和健康状况的简单、直观和有效的工具。
在互联网媒体产品线中运行开发
下一个案例研究涉及北京的几个开发团队合作交付互联网媒体服务器。这是一个新的产品线，团队成员和领导者都比较年轻。他们有很多东西要学习，不仅是如何工作，还有关于他们的问题领域。此外，他们正在从传统的烟囱式组织（测试人员和开发人员分开工作）过渡到开发人员和测试人员作为跨职能团队协作的组织。
我们的方法涉及使用内核和用例驱动的开发实践2来设计如图 4 所示的团队可视化板。这个团队可视化板从三个不同的角度提供了可视化
• 过程。这使阿尔法对团队成员可见，以便他们了解其当前的迭代目标（即，他们需要达到的内核阿尔法状态）。这还包括一个部分，显示他们正在处理的用例切片的当前状态。用例切片是用例的一部分，代表一个工作单元。用例切片的状态使用类似于图 1 中的状态卡进行描述。这使得团队成员在日常工作中可以看到实现每个状态的标准。
• 产品。每个团队都被分配了一个用例。用例规范和实现（由 UML（统一建模语言）图表示）被粘贴在团队板上，并且始终代表当前的协议。更改被潦草地写在用例规范和实现上。如果它们变得合格（在进行一些重大更改后），团队中的某人必须创建一个干净的版本。
• 进展。代表用例切片的 Post-it 便签被粘贴在板上。在每日会议期间，处理用例切片的成员将通过参考其切片对照需求和设计，以及过程可视化中的“完成定义”来谈论他们正在进行的工作。
拥有随时可用的过程、产品和进展可视化不仅帮助初级成员快速了解他们需要做什么，而且还帮助团队快速发现任何误解。
改进团队之间的协作
这个案例研究发生在日本消费电子产品线的电子书阅读器中。该公司有三种型号，每种型号都具有不同的功能，例如 Wi-Fi 或 3G 接入、触摸屏等。它有三个产品团队（每个型号一个）和三个开发团队，以及一个验收测试团队、用户体验团队和硬件团队。每个团队大约有四名成员。由于每个团队单独工作，因此协调性很差，导致瓶颈。
我们通过使用阿尔法帮助团队使其开发工作可见。具体来说，他们确定了两个阿尔法：用例切片和用户体验元素。他们为这些阿尔法定义了状态以及实现这些状态的检查点。他们在类似于前一个案例研究的产品线可视化板上使当前状态可见，但有两个例外：它有一个用户体验元素部分，并且它涵盖了整个产品线而不是单个团队。这是可能的，因为每个团队都相对较小。
团队领导使用产品线可视化板来计划和讨论进展。借助可视化板，他们能够展望未来并做好必要的准备。通过这种方式，每个团队都可以努力完成每个集成事件的部分，从而消除瓶颈。
离岸协作的快速启动
最后一个案例研究涉及一家日本公司，该公司在中国离岸供应商的开发和测试帮助下启动了一条新产品线。该产品线从最初的八人团队（我们主要与他们合作）发展到 50 人（当地日本人）加上 200 人（离岸中国人）。这些数字不包括硬件开发和当地承包商（从事设备驱动程序工作），他们是整体开发不可或缺的一部分。所有这些都发生在约两年内。
这家日本公司没有描述的工作方式，而中国供应商的规范是遵循客户的方法，因此没有起点。使用 Essence，我们能够帮助这家日本公司描述一种工作方式，其中包括以下实践：迭代开发、用例驱动的开发、持续集成和测试驱动的开发。
下一个挑战是弄清楚如何将部分开发工作分配给中国供应商。这家日本公司希望这是循序渐进的，以便随着中国成员对理解的加深，他们可以承担更大的责任。职责的分配基于架构和流程。在架构方面，中国供应商可以从事用户界面和中间层领域的工作，而设备驱动程序和更接近硬件细节的处理仍由日本开发人员负责，因为这些领域需要高度专业的技能，并且硬件正在不断变化。
在开发过程方面，阿尔法状态为讨论职责和参与提供了便利的方式。开发过程涉及由阿尔法表示的几个工作流。通过需求阿尔法状态的进展代表了主要开发。添加了另外两个阿尔法来表示架构和验收方面的工作。
在开始时，客户对大多数阿尔法状态负有主要责任。随着供应商知识的增长，它承担了更大的责任。阿尔法状态为商定协作提供了一种简单的方法。重要的是要注意，当中国供应商承担阿尔法状态的责任时，这并不意味着日本人摆脱了所有参与。日本开发人员仍然参与其中，但作为中国开发人员的助手。
使用 Essence，日本产品线组织可以描述他们的流程、职责和参与。它帮助团队入门。它还帮助团队领导（日本和中国）快速了解他们的责任领域，因为开发人员从 8 人增加到 250 人。
可持续改进的坚实基础
SEMAT 和敏捷性是两个互补且完美对齐的倡议。它们都是非规定性的框架，可帮助您思考和改进您的软件开发能力。
如果您认真对待在您的团队内部或整个组织范围内实现软件工程能力的可持续改进，那么敏捷性与 SEMAT 的结合提供了许多超出单独从任何一项倡议中获得的益处。
参考文献
1. Graziotin, D. , Abrahamsson, P. 2013. 用于软件工程 SEMAT Essence 理论的基于 Web 的建模工具。《开放研究软件杂志》1(1):e4； http://dx.doi.org/10.5334/jors.ad。
2. Jacobson, I. , Spence, I. 2011. 用例 2. 0：为敏捷项目向上扩展、向外扩展、向内扩展。Ivar Jacobson International； http://www.ivarjacobson.com/resource.aspx?id=1225。
3. Jacobson, I. , Ng, P-W. , McMahon, P. , Spence, I. , Lidman, S. 2012. 软件工程的本质：SEMAT 内核。 (10月24日); https://queue.org.cn/detail.cfm?id=2389616。
喜欢还是讨厌？请告诉我们
Ivar Jacobson 博士，Ivar Jacobson International 的主席，是组件和组件架构、用例、统一建模语言以及 Rational 统一过程之父。他对现代业务建模和面向方面的软件开发做出了重大贡献。 近年来，Ivar 一直致力于研究如何在敏捷和精益的方式中处理方法和工具。目前，他是 SEMAT 的领导者之一，其目标是重建软件工程作为一门严谨的学科。2004 年，Ivar 荣获瑞典哥德堡查尔姆斯理工学院颁发的 Gustaf Dalen 奖章。他是北京大学的国际荣誉顾问，也是秘鲁圣马丁德波雷斯大学的荣誉博士。他是七本有影响力的畅销书的主要作者，包括与 Pan Wei 合着的《面向方面的软件开发》以及与本文合著者合着的《软件工程的本质》。他还与人合着了两本关于 UML 的书。
Ian Spence 是 Ivar Jacobson International 的首席科学家，他在那里帮助人们更好地进行软件开发，多年来参与了许多大规模的敏捷应用，影响了数千人。他曾在许多不同规模的公司工作过，目前热衷于扩展敏捷和通过可操作的措施推动可持续变革的实用机制。他还领导了 Essence 内核的工作，并与本文的合著者合着了三本软件开发书籍，包括《Essence》一书。
潘伟博士（Dr. Pan-Wei Ng）是 Ivar Jacobson International 的亚太区首席技术官。他是中小型和大型软件开发组织的顾问和教练，专门从事大规模敏捷应用、设计可变更系统和软件产品线。自 SEMAT 成立以来，他一直帮助团队和组织应用其背后的思想，并在日本担任教练期间发明了 alpha 状态卡。潘伟与 Ivar 合着了《Aspect》一书，并与本文的合著者合着了《Essence》一书。
© 2013 1542-7730/13/0900 $10. 00
最初发表于 Queue vol. 11, no. 9—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。 存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定的民间传统，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 从直觉上看，技术领导者普遍认为良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来提供关于该主题的新见解，以研究生产力方面的差异。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。 在其快速前进的过程中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。 用例于 1986 年首次引入，并在后来普及，是这些行之有效的解决方案之一。
© 保留所有权利。