敏捷工程方法

将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的潜在摩擦接触点。

任何规划过程都必须允许变化，但太多的变化最终是不可改变和无法计划的。关键不在于数据的捕获或分析，而是如何让正在做决策的人尽早关注异常情况以做出更好的决策上下文就是一切，但我们也需要自动化（这是算法帮助的地方）来触发警报并触发足够的视角多样性以使任何决策具有弹

这是Nicolas Carlo个人针对发布“Clean代码”和“单一职责原则”的罗伯特·马丁的权威质疑：自从我

工程团队需要比以往任何时候都更快地为客户提供价值。云、SaaS 和永远在线服务的兴起意味着客户期望新功能、更少的错误和 99.99%（或更高）的正常运行时间。 为了跟上这些需求，组织采用了敏捷实践和最近的 DevOps 实践，这有望加快上市时间/交付周期、改进部署频率、更好的团队文化

这篇文章的灵感来自于 HackerNews 上的一条评论，我再也找不到了。它的要点是“虽然架构经常被过度设计，但代码本身却经常被设计不足”。如果有人认出作者，我会很乐意归于他们。作为免责声明，本文描述了我在过去 10 年担任顾问的经历。可能有一些框架和方法可以解决我将要描述的问题，但它们要么

新型产品技术团队模型简述： 没有孤岛，团队专注于了解客户的问题和市场挑战（环境），并由此发现和塑造他们应该如何构建和发展他们的产品（技术系统）。（他们显然在业务/公司使命和目标之间取得了平衡）。 这并不意味着团队中的每个人都一直在处理团队需要处理的所有任务。产品（和设

富士通全球交付架构团队 Chris Frost 着眼于企业架构和企业敏捷性的基本挑战。企业架构——通过以下方式应对大规模业务变更和系统设计： 将 IT 变革与业​​务战略联系起来 问题分解 解决方案过程的逻辑组织 敏捷——通过以下方式减少软件

在与 Facebook、Whatsapp、Google、Netflix 和类似组织的工程师交谈时，他们中的大多数人从未使用过 Scrum。为什么？这是因为以下几点： 有能力、自主的人需要较少的结构来产生可靠、高质量的输出。大型科技公司能够吸引、负担和雇用这些人。 通过

一位作者分享了他第一次担任工程经理的经历。它会成为你的下一个职业吗？最近，我加入 Nextail Labs 担任工程经理。这是我第一次在软件初创公司工作并担任工程经理。

向技术领导地位的转变是一个巨大的挑战。技术领导是不同的。领导技术团队不仅需要管理技能，还需要技术实力和驾驭科技世界的能力。在数字产品上工作，您需要了解如何领导您的技术团队，为用户提供高价值，同时保持敏捷并准备好改变方向。我们收集了一些最好的技术领导力书籍，因此您可以深入了解成功的最佳

事件风暴将正式包含在下一版本敏捷框架 SAFe 中

Matthew Skelton与 Manuel Pais 合著了《团队拓扑：组织业务和技术团队以实现快速流程》一书，这是一篇开创性的文本，讲述了如何围绕软件对您的特定组织的角色构建最佳团队结构。Matthew 在 2018 年、2019 年和 2020 年被 TechBeacon 评

Nick Horney 是《VUCA Masters》的作者和 Agility Consulting 的创始人。在这一集中，Nick 分享了他在领导敏捷性方面的创新，包括 AGILE Model 和 Leadership Agility Fitness，这是成为当前 VUCA 世界（即 V

Amplitude 的核心是为跨职能的产品团队（以及影响产品体验的增长和营销团队）而设计。我们将我们的产品视为加速学习、透明度、结果、一致性和自主性的良性循环。成为“真正的产品团队”（

当我们考虑如何以最好的方式做事时，首要考虑的是不要以最糟糕的方式做事并阻止以错误的方式做事，Poka-Yoke（“防错”）——这不仅仅是一个听起来很棒的词，而且是丰田防止用户错误操作的方法的一部分。例如，要启动汽车，你的脚必须踩在刹车上，然后才能启动汽车，这样来防止你做错事。

我们中的许多人都去过健身房，最初取得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助你保持，但你不会看到任何进一步的进步，你甚至可能开始倒退。我觉得 Scrum 作为交付软件项目的方法也遇到了同样的问题。Scrum 循环，或实践 Scrum 的方式，要么过于字面化，要么过于严格