敏捷工程方法

我们总结了“协作建模”（以下简称“ CoMo”）背后的想法和概念。在“敏捷”和“领域驱动”之后，我们将“ CoMo”视为商业软件开发的下一个重大步骤。 什么是协作建模？几年前，我们的三个同事被要求更换客户的

TOGAF数十年来的方向出错了：数据架构竟然是信息系统架构的一部分，其实信息系统架构应该是和数据架构没有依赖的，数据应该与技术无关。 众说纷纭：流程的二重性在哪里？光有数据是没有用的，只它在为业务目标而处理时它才能获得价值。（数据架构应该放

许多软件开发人员会很快告诉您： “我们很敏捷” “我们认为工作软件胜于全面的文档” “价值在于对话” “代码就是文档” “测试是文档” 代码是事实，而不是全部事实正如

两个概念之间的耦合与某些属性有关。不论哪个属性更改都会影响一起更改的内容。我们的有界上下文边界划分是一种押注，押注那些会一起改变的事情。

作为产品人员，我们可以非常喜欢我们管理的产品。尽管在乎它们是件好事，但我们一定不能忘记它们是达到目的的一种手段：产品的存在仅仅是为了为其用户和业务创造价值。因此，正如我在本文中讨论的那样，您的产品必须帮助您的公司前进并支持整体业务战略，这一点很重要。

在许多敏捷项目中，需求通常不是以正式需求文档的形式编写的。取而代之的是，通常使用一组简洁而有效的方法来描述必须构建的内容，即用户故事。用户故事从客户的角度描述了系统的行为，性能或界面。一个典型的用户故事可能看起来像这样：作为潜在的客户，我希望能够根据输入的搜索条件查看书籍。</

EventStorming是一种基于研讨会的方法，可以快速找出软件程序领域中正在发生的事情。与其他方法相比，它非常轻巧，不需要计算机的特别支持。在宽阔的墙上的粘便笺表示。业务流程被“冲出”为一系列领域事件，这些事件被表示为橙色便签（维基百科定义）我与EventStorming的第一次

很长时间以来，我对公司组织软件开发团队的方式感到失望。我记得我还是一个年轻的，天真的软件开发人员，我曾假定会存在类似于设计软件架构的结构化过程和模式。我渴望结构和分析思维模式来设计最佳解决方案。令我感到震惊的是，经理们基本上根据他们的直觉来任意划分团队边界。这不是孤立的一家公

拥有非常小的团队规模能使达成共识变得容易。让多个人一起从事某项工作的协调性的补偿性流程会让人感到惊讶。小团队的失败模式是总线因素。

敏捷团队使用迭代的、需求驱动的、务实的方法来实现IT实施、变更和运行。这些团队的业务范围如果是有限的，效果则很好。这有助于团队以灵活和富有成效的方式执行任务。但是带来副作用是：增加了生产率和灵活性的同时也增加了相互配合的节拍越来越大。没有软件架构上的指导机制，传统的长期业务目标最终将

在您的项目中执行设计冲刺(design sprint)的好处是：在非常短的时间内创建用户验证的原型。由杰克·纳普（Jake Knapp）先生在Google期间开发的这种“快速学习，快速失败”方法已被Google以及许多行业的其他顶尖公司使用或使用（是的，设计冲刺不仅仅属于我们在硅谷的家伙！）

如今，奥迪和汇丰银行等公司在其所有领域中都使用了IT系统。这是否使他们成为IT公司而不是银行？大多数人可能会认为汇丰是一家银行，就像奥迪是一家汽车制造商一样。但是，Chime等数字银行或提供数字产品的公司呢？在数字公司中，大多数员工都在开发软件。因此，它们也不是IT公司吗？不，他们是IT公司

敏捷方法为团队提供了在收集业务需求时同时开始创建软件的能力。因此，通常被称为“分析建模瘫痪”的现象不太可能阻碍团队前进。事实上，敏捷方法论以其使项目能够创建“正确”产品的能力而广受赞誉。它使团队具有竞争力，并通过不断的重新计划，有助于保持产品与市场的相关性，并确保团队的努力得到认可并及时发布

应用程序开发中最困难的部分是如何确定客户的实际需求。一种方式是开发团队可以精心设计软件需求，直至细节；还有一种观点：认为解决需求问题的最佳方法是完全放弃需求，而选择快速的软件原型。加利福尼亚州针对政府的立法数据中心的IT经理说：“不再有书面要求。” “相反，我们与客户组成一个小组，找

我们的一些团队成员是Allen Holub的追随者。他是noEstimates方法的

事件建模对信息系统而言比对敏捷性所希望的更为真实。 以我的经验，“敏捷”意味着没有雇用足够的人员，而没有进行充分的测试，完善的用户界面或编写文档，产品会失败。也许它应该意味着其他事情，但这是我的经验。 在