一家大型跨国企业收购了另一家大型企业的的关键业务软件系统,并决定用半年时间在上面进行定制开发,来适应新的需求。这个收购貌似让前者能快速开展新业务,但对于其开发团队来说,这不亚于是一场噩梦的开始:没有一位开发人员能够说清这个由多个团队合作开发的庞大系统从头到尾的业务全貌。在没有人能说得清业务需求的情况下,开发团队如何进行开发?
作为辅导这些企业进行敏捷和DevOps转型的咨询师,这几年来我一直在思考这个问题,期间做了一些努力来尝试回答,但成效总是有点差强人意。直到2017年12月8日我在“领域驱动设计中国峰会2017”大会参加了Event Storming 之父 Alberto Brandolini授课的一天“事件风暴工作坊”上午的“探索业务全景”(Big Picture Exploration)环节之后,才让我有信心解决这个难题。
“领域驱动设计中国峰会2017”大会“事件风暴工作坊”
工作坊上午的“探索业务全景”环节,能让说不清遗留系统需求的开发团队很快了解业务需求。适合新团队接手遗留系统、团队有大量新成员加入、业务发生很大变化等场景。以下是实施步骤:
投票评选业务瓶颈(Bottleneck, 画有箭头的蓝色竖条报事贴)
说不清遗留系统需求的开发团队,就好比说不清使命的军队一样,无法高效行动。要想在新团队接手遗留系统、团队有大量新成员加入、业务发生很大变化等场景下,让不熟悉业务的团队成员快速了解需求,可以召集包括领域专家、业务、开发、测试、运维在内的团队所有成员参加一个“探索业务全景”的工作坊,用每个人贴报事贴的形式来讨论和梳理现有的业务,最终让团队了解需求,达成共识,以便维护实现这些需求的遗留代码。另外还能识别当前系统的业务瓶颈,确定下一步开发工作的重点。
步骤如下:
事件风暴之父工作坊下午的“软件开发设计”环节,可以让开发团队了解系统应该具备的领域模型及其交互关系,为编写单元测试进而驱动重构提供指导。下一篇博客将会对此进行讨论。敬请关注。