SoS: Story over Solution, Coaching Pattern Series

模式名称

• SoS, Story over Solution

意图

• 当改变相对复杂时, 通过一个故事或场景引导团队参与方案的推导过程, 而不是枯燥的说应该这么做, 以使团队对复杂的改变更加支持.

动机

当一种改变看起来与直觉不符, 通常会遇到一些抵制, 典型的反对意见比如”没必要”, “自找麻烦”, “现在这样已经足够了”. 而这些反对意见有时是源于对新改变背后的原理不够了解. 此时如果强制推行, 在实际操作中也会遭到阴奉阳违的抵制, 使效果不够理想. 我们需要一种使团队更加自愿的接受改变的技巧.

方案

温伯格在<<咨询的奥秘>>中提到一条规则, 当不是直接使用从超市中购买的配好的蛋糕料包而是除了料包还要再加入自己的鸡蛋时, 味道会更好, 因为这个过程有自己的参与. 我们可以借鉴一下. 如果最后的方案制定, 有团队的参与, 那团队是不会反对自己的意见的. 我们只需要创造一个机会, 让团队参与到改变的规划和方案的推导中. 拿这次改变所针对的问题讲一个故事, 一起来推导最后的方案是一种可行的方法.

比如, 当我们需要引入”提交构建”实践的时候, 由于要比不构建直接提交多做很多工作, 尤其是要做多遍代码合并和跑多遍测试, 初次接触这些实践的团队会认为带来了额外的负担而产生质疑. 此时我们可以和团队从头来梳理一遍面临的问题:

“我们的目的是让测试人员能随时拿到包含最新代码的可用的包, 如果大家都认同这一点的话, 要怎么做来保证代码库的每个版本都是可用的呢?”
“提交前跑一遍测试”
“跑测试的过程中别人又提交了, 怎么办?”
“合并后再跑一遍? k, 那这样没头了, 我觉得直接提风险不大”
“‘没头’的情况确实有可能发生, 但办法不只直接提交一种, 毕竟直接提交是有风险的. 有没有办法减少’没头’的几率?”
“测试运行时间越长, 别人再次提交的概率越大, 那就得想办法加快测试速度”
“好, 我们现在的测试运行时间是2分钟, 可以接受吗?”
“可以. 也可以有某种排队机制”
“毕竟现在我们还没出现大规模的提交抢先, 等出现了再想办法不迟.”
“OK”

到最后团队甚至都想出了新的实践.

已知应用

上面的对话在很多客户的团队中发生过.

相关模式

• CoC, Context over Code, 该模式也强调要讲清楚背后的考虑, 但针对的问题是新成员对代码不熟悉无法很快理解的问题.