敏捷学习－ Scrum与功能团队 2016-7-13

敏捷学习－ 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，需要带多个团队，该怎么办？

 

（顺便回答，上篇文章，提到的画漫画的事情，我们每次社区活动，都会赠给授课老师一张漫画，因此活动组织者，在课程进行中，就边听边画了。。。）