敏捷工程方法

在构建业务关键型软件时，像领域驱动设计这样的实践是把一个重要的焦点放在IT和领域专家协作上。此外许多公司还看到了与客户更亲密的关系，更好地了解他们的愿望和需求，从而建立更忠诚的客户群的必要性。这就是服务设计、用户体验研究和敏捷概念（如用户故事）的亮点所在。用户故事图能帮助我们设计出既可行又有

Cynefin框架是一个概念性框架用于辅助决策，由戴夫·斯诺登在IBM全球服务部工作时于1999年创建。它是马克斯·博伊索特的I-Space知识模型一种实现，其他实现还

真正价值是开发客户想要的功能，而不是基础CRUD功能：各种敏捷专家提供了一些有关用户故事切片/拆分的重要信息。但是，经常遗漏的一个关键方面是能力划分和功能划分之间的区别。通常认为，用户故事的关键要求是其实现应为您的产品或服务的用户带来价值。我的解释方式是，它应该讲一个故事，使

宁可相信 10 倍的上下文和环境......在哲学上，比赛的获胜者是跑得最慢的人。或者：最后到达那里的人（维特根斯坦，文化和价值）如果10倍开发人员位于一个开发团队中，这个团队与需求以及技术架构之间组成一个复杂系统，而缓慢对于复杂系统是重要的。

系统级别的架构为避免过于细节，需要简化架构方法：“做得足够”（即：不多也不少）。架构师（和/或任何决定架构的人）应该专注于解决系统级别的这个最高优先级，以便从事系统那些特定元素的团队可以最大化其对整个系统的有效性（而不是“局部优化”）。这种方法还努力为在系统“较窄范围”要素上工作的团队留出最

诸如Scrum等管理风格是以较短的开发周期为中心，也就是冲刺，许多组织误解了这一点，并采取“无前期设计”和“从第一天开始编码”的方法。对他们来说，理论上我们不需要设计软件解决方案。我们开始编码，但增量很小。在每个冲刺结束时，向产品所有者和利益相关者展示工作软件的演示。利益相关者提供反

自从Scaled Agile Framework（简称SAFe）在4.5版中采用

由中央高智能部门协调和控制软件的大批量发布经常会失败，其原因是由于数学NP问题以及人类之间的弱相互影响。大多数公司以某种命令和控制方法开始软件版本发布，这是一种中央智能组织推动和控制工作流程，批量大小为N的发布策略是问题所在。 首先是数学上行不通，像很多问题一样，我们

如果未来发布”敏捷宣言“新版本，则应强调这样的重要性：如何理解和应对不同上下文！（纯敏捷反而不敏捷！上下文为王，需要根据自己的情况引入敏捷和决定敏捷方法）在《福特兰迪亚：亨利·福特被遗忘的丛林之城的兴衰》一书中：福特兰迪亚（Fordlandia）是嵌入亚马逊河心脏地带的“幽灵区”，恰

产品管理顾问兼教育家 Melissa Perri 就设计领导力和产品管理发表一些访谈观点：产品经理给流程带来的真正价值，以及设计师如何可以在产品管理方面更有效地与同行合作。我们听过很多人的意见，我们也有过产品和用户体验之间挑战的经历。我很好奇你在产品和用户体验或产品和设计的关系中看到

高弹性组织可以解决诸如构建软件等新问题，它是靠发展解决现有问题，是生成性的，总是创造自己的下一个版本来解决明天将出现的问题。一个有弹性的组织会产生积极的结果，即使某处总是出现问题。就像弹性软件一样。旧的、官僚的组织结构图有很多层次；信息向上流动，决策向下流动。一个弹性的、生成的组织结

SRE代表站点可靠性工程（或有时称为站点可靠性工程师），它是一种IT操作方法，优先考虑软件开发常用的工具和方法。换句话说，您不会使用传统的IT策略（例如手动部署）来处理IT任务（例如应用程序部署和监视），而是使用基于代码的自动化工具（例如“基础结构即代码”解决方案）。同时，可

在当今瞬息万变的市场中开发现代SaaS产品，需要克服各种极端不确定性，需要比Scrum还要敏捷得多的东西！让我们面对现实吧！ Scrum真的不是那么敏捷：我已经拥有20多年的Scrum，足够长了！当时转向使用Scrum无疑是在敏捷阶梯上的进步，但是因为在我整个职业生涯中都一直再使用S

“不好了！我们估计该冲刺有23个故事点，但我们只交了20个故事点。我

认知神经科学的渐进模板： 这是一个系统 这是两个系统 两个系统实际上是一个系统 有两个但它们广泛地且动态地交互作用 我们不知道运作方式 DDD建模认知的渐进模板： 这是一个领域 这是两个领域 两个系统实

在当今的敏捷/ DevOps项目中：对当前问题的分析我们会考虑的各种可能性和替代方法，这本身可能会导致僵局；有时，我们可能会推迟做出决定，直到“所有”数据可用为止；有时，某个决定会被延迟，以便稍后做出最佳决定；有时我们可能会付出不必要的努力进行研究。所有这些都会导致生产阶段的缓慢移动