敏捷学习- Scrum与功能团队 2016-7-13
现在流行一个词“撕B”。这个词,足可以形容,互联网行业,人员和组织间的各种“摩擦”。
一个普通的程序员可能这么度过一天的。拎着早餐,打开机器,邮件列表里,已经有一堆的Bug列表了,随便浏览了一下,心里已经在暗暗的说,某某某,这个傻X,这么明显,环境变量少了一个,测试环境咋配的啊,不是早改了么。
好不容易,吃完了早饭,还没抬头呢,项目经理正大声的说,某某某,都三天了,你那个功能,写完了么?你这边,马上就说,代码早写完了,在联调,框架那边,跟他们说了好几回了,缺个返回,他们一直都拖着不改。
程序员的“心情指数”已经下降到快冰点了。
这个场景,描述的,是一个项目组织的片断。
如果用一个词来概括,那就是依赖。
我们可以用下面的图大致描述这样的组织(组件团队),一个PM(project manager)代理一个组织。
这种情况下,依赖关系,大部分出现在PO(Product Owner)和PM之间。(图中,没有体现PM和PM之间可能的依赖)。
目前的项目管理,主要针对针对这种依赖,相应的工具,有计划,Deadline,成本,审计等等。
Scrum建议的组织的模型(功能团队),与之不同,直观上来看,是将依赖关系“下移”了一层。
下面的图中的PB(Product Backlog)的属主是 PO。
从左侧来看,PO只看到他的待办列表。他不再关心,这些Item怎么实现的。
在社区活动中,老师用道家的阴阳双鱼图来描述列表中的一个Item,他的一侧是how,另一侧是what。
我简化如下:
PO : “What|How” : Developer
同一个 Item,在PO的视角下,看到是它是什么,它能完成什么功能,它有哪些特性。在Developer的视角下,它怎么工作,怎么实现它。
PO 和 Dev.,都做自己最擅长的工作。
现在,还有一个最重要的问题,依赖怎么办?
让我们回到一个实际的问题中来。功能1需要调用功能2中的一个API。假设就是查询当前在线用户信息。这该怎么办?
我们很难等到功能2完成后,给出一个“稳定”的版本,再定这个API,原因很简单,复杂的依赖关系。而且是动态的。从调用者的角度来看,可能刚开始的时候,觉得直接返回在线的人数,就够用了。随着功能的增强,希望返回的是一个列表。
如果这些功能是一个人来完成的,我想,大部分人采用的策略是两边调整的策略,不够使了,根据具体的情况,再细化。
上升一个层次来看,为什么一旦涉及到多人之间协调的时候,就开始撕了呢?
在这张图中,如果椭圆形代表是单个的人,那显然,我们可以把这个组织看做一个PO带若干开发共同组成一个团队。
如果椭圆形又是一个小组织呢?
这就是多个团队对应一个PO的情形。
这个问题,是这次活动的老师,一开场,提出的一个问题:如果1个PO,需要带多个团队,该怎么办?
(顺便回答,上篇文章,提到的画漫画的事情,我们每次社区活动,都会赠给授课老师一张漫画,因此活动组织者,在课程进行中,就边听边画了。。。)