最近看到一本书
Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software
以前在DDD活动上, 听到这协作方法.

其中书本第一章有讲到Telling stories的好处
我将前两章节的内容, 做成投影片简单的跟部门分享
Slide - Storytelling & Domain Stroytelling
这几天来以文字的形式跟各位分享

前言

常见的会议情况

情境1

在专案还是产品Kickoff时,
以会议报告的形式进行讨论, 真正具有价值的时间很少, 几乎都浪费掉了
然後就会以没结论的方式, 说下次再召开会议继续.

情境2

会议中有人报告时, 其实很多人不清楚, 这报告的内容主要是在解决什麽问题?
甚至很多某些领域下的专有名词

情境3

会议上, 直接对着画面跟操作动线进行争论
直接针对细节做深入讨论
有的则是直接在会议上讨论, 资料库或表格设计什麽的.

分析

以下是我的见解

• 情境1
  会议几乎都是听PM或企划在从画面草稿跟行销手段在介绍
  也许对於创新产品没问题,
  但若是针对既有问题或需求, 从画面草稿跟行销企划, 很难让所有与会人员都能理解完整的问题域与相关的业务流程

• 情境2
  其实也是跟上面一样, 所有与会人员都能理解完整的问题域与相关的业务流程.
  因为大家的背景或专长可能就都不同

常见状况: 有些人讲一讲会讲到API或Table... 与会人员一半都是管理跟企划行销, 根本不知道在讲什麽

• 情境3
  一开始就针对细节展开, 很容易产生争执
  这是因为每个人对问题的认知或理解程度, 都不同
  自然而然想像出来的也是不同

萧煌奇- 你是我的眼
眼前的黑不是黑 你说的白是什麽白
人们说的天空蓝 是我记忆中那团白云背後的蓝天

书上第一篇讲到一些观点

conversations cannot be adeqquately replaced by written, formal specifications.
attempts to do so have even widened the gap between business and software development.

交谈沟通并不能完全取代书写与正式规范,
如果只靠交谈沟通其实只会更加地让业务与软件开发人员之间的gap更深.

consider software development approaches like agile, Domain-Drivent Design or BDD.
these philosophies foucs on feedback and stackeholder involvement.
nevertheless, making great bussiness software is hard, but rarely is this because of technical problems.
because software developers need to understand how the day-to-day busniess operates.
they need to become domain experts themselves - not for the whole domain but at least for the part they build software for.

像是Agile、DDD或是BDD, 更鼓励的是回馈还有stackholder的参与.
构建出复杂的商业服务颇难, 但难的部份几乎不是技术上的问题.
更多的是业务问题, 开发人员需要了解日常业务的运作方式.
试图让自己也成为自己负责部份的领域专家.

书上也引述一段Alberto Brandolini的话

it's developers (mis)understanding, not expert knowledge, that gets released in production.

发布出去的软件其认知是开发人员的理解(or误解), 而不是领域的专业知识.
讲白话点, 是开发人员对规格书的理解而已.

根据上面我自己的分析, 加上书上这段论点.
如果要在沟通协作上, 更有效率的讨论, 对领域与问题的共同认知是必要的.
怎快速建立共同认知呢?
这时候说书人说故事就是个很简单又有成效的方法了

说故事前, 又得召集会议?
其实以前或是现在日常还蛮多活动, 不是以会议形式展开的,
而是以类似小团体, 彼此围成圈, 一起讨论的形式
像是Campfires, 营火够大就能圈多人, 小营火就圈少点人
中间的营火则是大家目光聚集的对象
常常这类活动也会有主持人或是说书人, 在旁边讲述事情
这样的形式, 大家都能很快地融入其中

上图大家都跟着主持人做起一样的动作, 因为都聚焦在主持人身上
事情有需要准备一堆说明或练习, 才能带动大家一起做出一致的动作嘛?
我想不必吧!?

上图这张我想表示的是, 小的营火聚会
能聚集一些来自不同背景、肤色、性别的人在一起, 也能愉悦的沟通讨论

但! 凡事总有But!
开会就不是这样阿? 老板就想要听到结论阿!!
But上面的开会形式就能有效率地在一次会议中得到结论嘛?
我想给的台词大多还是长官, 我们会後再招开小会议讨论,下次给结论
但这另开的小会议, 比较多都是要开发团队给个人天时程...
开发团队跟业务之间的gap依然存在, 需要时间跟经验来消弭.
且搞不好下次长官们想法又稍微变化了, 这顺序又要重复Loop
就回到情境1了

结论出来後...
开发团队: X的, 上面就只会要我们给时程, 怎麽做我们都不清楚
业务单位: x的, 开发团队是不是能力不够阿, 怎我们给了厚厚的文件, 他们每次都还是做错

Campfires只是个示意, 描述的是必要的开发团队与Stakeholder或是业务单位
聚在一起, 请Stakeholder或是业务单位用说故事的方式.
开发团队无法直接接触真实客户也无访. 反正有业务单位或窗口

Story Telling

说故事 总不会有人这样说书吧?

小明进到市场, 如果看到低於1斤20$的橘子则买一斤. 看到吐司有特价则买一条.
三英打吕布, 如果关羽挡住吕布刺击, 则张飞与刘备则从左右进行砍击.

描述的都是过去的事实;
且描述的事实顺序, 正好就是业务行为的顺序与时间线上的对应关系

小明进到市场, 今天是冬季且快关门了,买了1斤18$的橘子, 买了一条特价的吐司.
在虎牢关, 三英正在打吕布, 关羽挡住了吕布的刺击, 同时张飞与刘备发现吕步, 侧门大开, 则立刻从左右进行砍击.

敏捷开发宣言

前面扯一堆干话, 还是没讲到怎样的有效讨论
但这里是举另一个论点来讲 (又继续干话了)
敏捷开发宣言里说到

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan

Individuals and interactions over processes and tools
成员跟互动 比起 工具还有做抽象流程, 来的重要
这的重要指的是效率, 呼应我们主题有效的讨论

Customer collaboration over contract negotiation
与客户协作讨论 比起 文件合约的协商, 来的重要.
但我想转个角度想成, 传统的SA或PM文件, 公司都是希望能一次到位.
但等到这文件确定写的是符合客户所需的, 大概也是来来回回数次修改跟协商确认後的版本了.
但也没说这不重要, 但与其这样来来回回, 不如找客户一起当场确认修改.
这後面会说明.

简易有效的讨论

根据宣言可以发现要是成员们一起互动, 与客户一起协作讨论,
想必会比较能省去初期就投入一堆时间写文件

如果可以, 主要是邀请Domain expert来对着开发人员们讲解故事

这张图我想表达的是
用说故事的方式传达业务与领域知识, 比起用一堆流程图来传达,
更为简单好懂又不费太多功夫

当然文件还是得补上的, 只是可以在事後追加进去.
先让开发人员的理解, 足以理解/贴合业务流程所需.

下一篇来写Domain Storytelling这方法与对应适当的工具