商业软件开发的下一个重大步骤:协作建模(CoMo)的本质 - WPS


我们总结了“协作建模”(以下简称“ CoMo”)背后的想法和概念。在“敏捷”和“领域驱动”之后,我们将“ CoMo”视为商业软件开发的下一个重大步骤。

什么是协作建模?
几年前,我们的三个同事被要求更换客户的旧系统。客户聘请了一名需求工程师来帮助他们了解新系统的期望。需求工程师做得很好,但是,我们的同事在围绕这个新领域寻找方法时遇到了问题。因此,他们要求与需求工程师和一组关键用户举行研讨会。通过使用一些视觉叙事技术,他们成功地激发了用户讲述其工作的故事:他们如何使用旧版系统来完成其任务(从而提供了一个解释需求的需求和优先级的背景)以及他们打算如何使用该系统。新系统(为需求提供上下文)。他们甚至在故事中发现了“漏洞”,从而产生了新的要求。
CoMo是许多成功方法的基础,传统上将这些方法归类为“需求工程”。IT专家需要了解领域,即用户的任务和工作流程。软件只能反映开发人员对领域的了解,否则无法创建好的软件。相反,领域专家和用户需要了解可以打开哪些潜在软件以及数字化将如何影响他们的日常工作。
开发人员和领域专家需要一种通用语言,以便能够讨论领域和软件要求。CoMo旨在将领域知识从用户头传递到开发人员,测试人员,产品所有者,产品经理,业务分析人员的头部,并传播给参与软件开发的每个人。这里的关键因素是所有相关人员之间的直接反馈。例如,这将CoMo方法与经典的需求技术区分开来,在经典的需求技术中进行访谈和从中得出方案。
CoMo在域驱动设计(DDD)中是必不可少的-域驱动设计(DDD)–这可能是当前可用的最成功的方法,它将域知识置于软件开发的核心。领域的语言,事件,动作,资源和领域的结构形成了所谓的领域模型,开发人员可以在软件中进行映射。有效的领域模型只能由开发人员和领域专家共同创建。现在,Paul Rayner等DDD专家将协作建模视为DDD的支柱(参见图1)。

CoMo的本质
随着DDD的成功,CoMo技术获得了普及和接受。我们经常使用其中的几种,并且正在自行开发一种技术(域讲故事)。在本文中,我们将研究四种CoMo方法,并将其实质提炼为一些基本概念。我们对方法的选择不完整,是基于我们的个人经验。由于我们假设许多读者熟悉这些方法,因此我们仅简要介绍它们:

  • 在EventStorming [Brandolini] 期间,各个部门的开发人员和专家使用贴纸和笔来绘制复杂的业务流程。图片是根据域事件“自下而上”创建的。在故意混乱的开始(因此称为“风暴”)之后,一个故事出现了,并被记录为领域事件的流。
    图2:“大图”事件存储事件和热点
  • 域叙事 [Hofer]是一种视觉叙事技术,着重强调人员(和软件系统)如何协同工作。领域专家讲述有关业务流程具体示例的故事时,主持人使用象形文字来记录故事。该图片是域专家和开发人员之间讨论的基础。
    图3
  • 用户故事映射 [Patton]从用户的角度将需求(大致描述为用户故事)构建为一个连贯的故事。参与者在便签或卡片上简要描述了他们将如何与软件交互。用户故事地图的水平维度描述了业务流程或用户旅程。垂直维度可用于详细说明需求和优先级(请参见图4)。
    图4
  • 在示例映射 [Wynne]中,用户案例是更详细地了解问题域的起点。使用示例,业务部门,开发人员和测试人员的代表尤其应该确定业务规则或用户故事的边界条件,以便得出验收测试。用户故事,带有示例的规则和未解决的问题均在不同颜色的卡片上注明(请参见图5)。
    图5

CoMo的基本概念
我们看到了各种CoMo技术背后的以下常见概念:

  • 所涉及小组的团队合作:来自业务部门(领域专家,用户,产品所有者等)和来自IT部门(软件开发人员,架构师,UX专家等)的人员一起建模。他们使用建模来转移领域知识并阐明范围,工作流或需求。CoMo研讨会可能需要一大批参与者或一些角色的几个代表。跨角色的协作与进行访谈,分析文档并产生文本输出的个人专家形成了鲜明的对比,这些文本输出被他人使用。
  • 讲故事:在CoMo讲习班中,参与者讲关于过去发生的场景或他们想在将来发生的场景的故事。场景是关于业务流程的一个实例(而不是所有可能实例的抽象描述)。每个方案都描述了与该领域相关的事件,活动或示例的时间表。一旦了解了场景,讨论就可以继续进行软件开发所必需的抽象,规则和大小写区别。
  • 旨在通过一种通用语言在所有参与者之间达成相互理解:人们经常抱怨业务部门和IT部门生活在各自的世界中,并且彼此交谈。但是,所有CoMo方法都着眼于用户的语言。应该采用各种研讨会技巧来帮助参与者更好地了解彼此。
  • 创建应用程序域的通用模型:讲故事时生成的模型不仅仅是副产品。即使它们是非正式的,并且通常是由图纸,索引卡或便签纸制成的,但它们还是可以在以后的工作中使用的明显结果。建模的另一个甚至可能更重要的目的是推动故事的发展。模型将所有参与者的讨论状态可视化。协作建模的符号必须为所有人所理解,即不需要专业知识即可理解该符号。

达成对CoMo的共识
通过这篇文章,我们想开始讨论CoMo不同方法的本质。我们认为,从严格意义上讲,这超出了DDD方法的范围,而超出了一般敏捷社区和TDD / BDD方法的范围。讨论可能会揭示每种方法在哪些情况下以及针对哪些问题特别合适,而在哪里不合适。此外,我们想找出如何在实际项目中结合这些方法,以便在不中断概念的情况下获得持续的支持。这也是Visual Collaboration Tools [Baas]的目标之一,这是一本为从业者社区编写的书。
最后,我们希望不同的CoMo方法的拥护者能够在共同的概念基础上达成共识,以使许多好的想法可以彼此补充,从而得到更广泛的应用。