从实际案例看 Scrum of Scrum 如何运作(二) :SoS 的挑战

前些年去法国自驾,发现法国道路上的红绿灯特别少,大部分的路口都被设计成环岛(见下左图)。而在国内,这样的设计非常少,大部分是十字路口(见下右图)。两种路口的目标都是为了更好的让车辆通行,那么哪种是更好的设计呢?答案是各有利弊!

环岛的优势是不需要红绿灯(环保),车辆进入路口时基本无需等待。而十字路口在大流量时通行效率更高(车辆无需在岛内绕行),而在乡村车辆很少时,可能会造成车辆空等。如果路口有大于4条路交汇(比方上海的五角场),十字路口的信号灯设计将会非常复杂,远不如环岛效率高。但环岛对于司机的要求很高,需要理解的规则比信号灯复杂。

交通设计

之所以提到这个例子,是想提醒大家,我们在讨论一种模式或者工具时,很多时候我们会强调它的优势,而选择性的忽视其的局限。只有从各个角度去了解事物时,才能获得更多的洞察和更深的理解。

上一期我们从一个实际的案例展示了如何用 SoS 的方式运作一个大型的项目。这期我们将继续深入讨论 SoS 可能的不足之处。问大家两个问题:

1.上期案例中这样运作 SoS 哪些地方可能出现问题?

2.我们该如何应对?

在我们展开进一步讨论前,大家可以先思考一下,看看有没有自己的答案?

现在让我们从以下2个主要方面对 SoS 展开更多讨论,看看可能出现的问题。

1.需求管理

2.团队协作

需求管理

上一期中,我们提到张这幅需求分层的图,这是一个洋葱式逻辑包含关系的图。

洋葱式逻辑包含关系

如果我们从时间维度或者说生命周期来看的话,那么需求分解的图应该是怎么样的呢?(这里假设需求只需要拆分成3层)

需求拆分与完成的“理想情况”

(需求拆分与完成的“理想情况”)

上图展示了非常理想的状况,需求可以“快速分析和拆分,快速启动开发,迭代交付”。然后事实通常是如下图所示,可能会遇到反复调整方案,没有资源启动等等问题。

需求拆分与完成的“真实情况”

(需求拆分与完成的“真实情况”)

问题1:

在“真实情况”中,solution 通常从提出到开发会经历很久,有些时候是因为需求的反复变更,有些时候是 solution 的反复修改,而有些时候时要等待合适的开发资源。在 SoS 的框架中,我们会发现 APO-OPO 的沟通模式会有很多的交接,这增加了快速启动前等待的时间,最糟糕是,完整的 solution 已经在文件夹中躺了1年以上。而且,通常在开发资源准备好时,solution 很可能要重新刷新。

解决:

● 简化 solution 的制订,从最初的一个几十页的文档简化到 one page solution(PPT),只列出这个 solution 最关键的一些要点,并做一些简单的拆分。这里遵循的原则是避免提前,过度的设计。这里通常由 APO 负责,有时也会指定由某个 OPO(Operational PO)负责。

● 在预测到开发资源可能准备好时,通常1名或多名 OPO 将会对 solution 以及拆分的 feature 做进一步详细设计,并将需求细化。

这样我们就可以在需求出现时不必做过度的设计,而且也避免了过时的重新设计。

团队协作

在大团队进行协作时,一个无法避免的问题就是高昂的沟通协调成本。在 SoS 的框架下,由于引入了 APO-OPO,SoS-Team 双层结构,不可避免会加剧这样的问题。

问题2:

某些 solution,甚至 feature 是跨 area 的,需要不同 area 的 PO 与 team 进行协同。

解决:

由于 area 是相对静态设置,因此不可避免的会有一些需求穿越 area。解决方案:

● 尽量由同一 area 的 APO,OPO,team 负责主导。实际开发过程中,由一名 OPO 负责澄清需求,并且设置需求优先级。同时 team 的 scrum master 之间会建立一个团队层面的沟通机制,来协调进度和开发依赖。

● 之前提到 team 一般会有1-2个 primary domain, 2-3 secondary domain 的开发能力。因此一个 team 原则上是可以跨 area 工作的。这个在一定程度上缓解了这个问题。

● 尽量在架构与技术上解藕(这个依赖良好的软件架构),使两个团队可以独立开发和发布。

工具支持:我们在 PO 群建立一个需求看板,在各个 SoS 建立 SoS 共享看板,每个 Scrum 团队也有各自的白板。同时各个团队(包括 PO,SWAT)建立各自的 wiki,将团队信息发布出去。可以借助的工具包括 Jira,Teambition 等等。(P.S. Teambition 的知识库是很好的共享团队知识的工具。)

总结:以上列举了两个在 SoS 框架下可能发生的问题。我们可以看到,在 SoS 框架中,普遍来说信息沟通与决策链条会拉长,因此克服这些短板就成了很大的挑战。一方面在拆分需求时能消除复杂性,尽量避免需要大量的沟通;另一面,要给予团队更多的赋权和赋能,让他们能灵活处理各种问题。文章的开头我们提到了十字路口适合大流量的通行,但必须高度依赖信号灯。同样地,在团队协作时,我们需要有一些协作工具,例如 Jira, Teambition 等等。正是这些工具的出现,才使得团队有能力完成复杂协作,包括信息共享,知识共享,创新等等。

另外,敏捷开发依然是高度依赖人的开发模式,如果产品开发过程中,团队没有成长,总会遇到某种模式所无法克服的问题。相反,团队如果能持续成长,那么就能灵活运用各种模式,实现真正的敏捷!

作者:周巍,ThoughtWorks 高级咨询师,16年的工作经验,具备 CSPO,CSM,CSP 等资格认证。擅长精益(LEAN)与敏捷等辅导,关注管理方式的变革,帮助组织与团队持续提升响应力与交付价值。曾经服务过的客户包括华为,中国银行,汇丰银行,招商银行,中国电信这样的大型企业,也包括像 AHA 社会创业学院这样的创业孵化器。