敏捷工程方法

敏捷的软件公司组织结构最好能映射到业务领的结构，公司组织结构不要映射到技术。DDD创建了一个从领域映射到软件技术的架构。如果有界上下文是商店、仓库和财务，那么架构中最大的可模块化部门就是商店、仓库和财务，而不是“前端”和“后端”之类技术的东西。康韦定律（Conway'

将我们的软件分解为模块时，我们常常忘记重要的社会方面。设计如何影响团队，可能使他们相互竞争。一个具有韧性和可持续性的系统需要和谐。谚语“好围墙造就好邻居”描述了为什么我们的软件设计需要边界：不仅是解决问题并使其易于理解和管理的一种方法，而且还可以使您公司中的团队更好地相处并相互发挥最

现在有3种流行的软件工程方法：简单的：不能真正解决问题的简单方法 -Scrum复杂的：可任意选择解决方案 -SAFe1＆2的混合：LeSS现在我们正在踏步于SAFe第二阶段，未来可能更需要第三步，第2步的SAFe到底是什

Open Group发布了一个新标准，为企业架构师向敏捷方法论过渡以进行数字转换提供指导和最佳实践。新的开放式敏捷架构（O-AA）标准为寻求在数字环境下过渡到敏捷的企业架构师提供了指导和最佳实践，特别关注正在进行数字化转型的组织的需求。Open Group是一个全球性的财团，

为什么每10个产品创意中就有9个失败，我们如何避免呢？许多公司以新产品的想法开始，并相信客户会想要并会购买它。公司花费数月（有时是数年）来定义，实施产品并使之“完美”。但是，他们永远不会与客户一起验证该想法，也不会在市场上对其进行早期测试。这就是为什么公司通常会因新产品而失败

这是2016年7月19日发布的原始版本

我不断听到有关“ DevOps团队”的消息。哪有这回事！DevOps思维的重点是集成Dev和Ops。只有一支队伍（banq注：没有专门的负责运营的DevOps团队）。 众说纷纭：我认为“ DevOps”一词很像“敏捷”，已经被卖狗皮膏药公司所采用，试图向您推销真正需要

我想明确指出我不是反微服务者，我将服务合并回到整体(单体/Monolith)中并不是为了摆脱微服务，目的是实现“大小正好”的整体。我正在做的事情是解决我团队的痛点。如果不能减少摩擦，我将不会花费太多时间（和机会成本）来提升，转移和重构旧代码。每次这样做，我都会冒引入新错误并破坏用户体

MLOps是ML的DevOps。数据科学家构建的机器学习（ML）模型需要与其他多个团队紧密合作，例如业务、工程和运营。这意味着了在沟通、协作和协调方面的存在挑战。MLOps的目标是通过完善的实践来简化此类挑战。此外，MLOps带来了敏捷性和速度，这是当今数字世界的基石。ML模型操作化

在这篇博客文章中，我将讨论为什么数据科学家和团队不能依靠软件工程团队在过去20年中一直使用的工具和流程？ 对软件工程工具和过程的依赖是有道理的：数据科学和软件工程都是以代码为主要工具的学科。然而，数据科学团队和软件工程团队正在做完全不同的事情。检查这两个学科之间的核心差异对阐明我们应

精益创业(LeanStartup)方法由埃里克·里斯（Eric Ries）于2011年提出的理论，埃里克·里斯（Eric Ries）成为Lean的发明者。如果很难知道是谁真正发明了这种方法，可以说埃里克·里斯（Eric Ries）能够抓住它的本质并给它起个名字。像IT领域中的许多流行

发布新产品并非易事，因为这会带来很多风险。但是，如果您知道一种可以简单有效地将您带入正确道路的技术。精益创造（Lean inception）是设计思维和精益创业（ Lean StartUp ）的有效结合，可以决定最低可行产品（MVP）。它是一个协作式研讨会，将帮助一群人（通常是敏捷团

、数字化是推动工业4.0（也称为工业物联网（IIoT））的重要领域。在制造领域，过去主要通过各种MES解决方案来解决这一领域。然而，事情已经改变，大型的整体/单体系统已经过时了。随着IIoT平台和

“计划只是未来很多可能发生事情中的一种情况，计划不是对将会发生的事情进行预测。” -肯特·贝克 一直成功的计划就是根本就没有计划 计划是我们为了完成目标而预期采取的行动。 计划不是关于我们准备做什么？而是关于可能会发生什么！ 在

互联网软件行业已经从漫长的开发周期和专门的质量保证（QA）阶段转移到了快节奏的连续集成/连续交付（CI / CD）管道，在该管道中可以快速编写，提交和推送新代码。这样做极大地提高了迭代速度，在LinkedIn上，提交新代码

我不敢相信我花了两个小时来绘制软件设计图，这是完全错误的，我其实只需两个月就对所有这些代码进行编码，就可以节省这两个小时！