杭州回忆:糟糕的项目管理之扭曲的scrum

2008-12-22 21:32:29
王春生
转贴 5048

在杭州这一年也许是我迄今为止经历过的 项目管理最差的一年。

阿里妈妈所采用的开发模式为 scrum。scrum一个比较明显的特征为一个月为一个sprint,在sprint开始的时候,需求方和开发商定这个月要实现的功能,并设定发布的主要内容( milestone)以及上线的日期( deadline)。在这个为期一个月的开发周期里面,是不允许有新的项目插进来的。待到这个sprint结束之后,会有一个总结,讨论这个月的得与失,同时开始下面个月的 plan meeting

scrum是一种解决IT行业变化频繁这个问题的有效方案。 但在阿里妈妈,却仅仅执行了一个皮毛

scrum中的开发team在一个sprint周期里面精力基本上是集中在一个项目上面的。在这一个月里面,大家就是集中完成一个项目。所以开发的效率会比较高,产品质量也比较好。但在我们这边,现状确实几个人的开发team要应对不同的产品线的需求,导致在一个周期里面要同时做好多事情。而且每一件事情都还不是仅仅自己team就能解决得了,还要频繁的和其他team的同事进行沟通、协商。(导致的一个结果是互相扯后腿,经常给别人 擦屁股,经常扯皮,互相埋怨)不仅仅如此,主要的开发力量还要担负线上环境的运维。所以开发会经常delay。当延期的时候,就会来压缩测试的时间。这样开发出来的产品,其质量可想而知。

scrum非常重要的一个环节就是每一个sprint结束之后,会召开一个总结会议。需求方、开发,以及测试的人员都应该参加,大家一起来讨论一下。但这一个在我们这里基本上没有得到执行。或者每次开会的时候,基本上都是开发的人员在参加,其实最应该参加的是需求方。而需求方却往往不来。这样正常的反馈机制基本上就无法形成,也就谈不上产品的改进了。

scrum其实可以理解为小步快跑。每一个月都做一些核心的功能,然后快速的发布,以此来赢得市场和用户。所以一个项目往往会有很多个sprint。每一个sprint都会都产品做相应的改进。但在我们这边,一个产品上线之后,很难有后续的改进计划。上线之后就完了。具体的效果如何,基本上没有人关心的。(除非老板们过问)

敏捷开发其实还有其他很多的实践在保障产品的质量的。比如开发的单元测试、比如开发的代码 review等。在国外的敏捷开发过程中,测试的概念是很弱的,或者说单独的测试人员这个角色是比较弱的。敏捷开发强调一系列的实践来保证代码的质量。而不是仅仅靠测试。而在我们这边,很好玩的事情就是,我们口口声声说是在敏捷开发,却还需要大量的测试来保障产品的质量。

还有非常奇怪的事情就是没有文档。 没有需求文档,没有设计文档,没有接口文档。对于后面两者,还可以理解。因为开发的压力确实非常大。但对于第一个来讲,就非常不应该了。一个好的产品经理,最起码应该把自己的意图表达清楚。我想这应该是最起码的素质吧。虽然敏捷开发里面强调可以工作的代码胜过长篇累牍的文档。但问题我们现在的代码工作起来并不正常。经常出现开发到了一半的时候,甚至已经提交测试的时候,才发现需求方面有问题。这一点很多产品经理强调说,自己没有时间写需求文档。我觉得这是非常不应该的。按照我们流行的说法,应该吊起来打,或者拖出去喂鸟。

要想追究原因,我想可以找出很多。我觉得主要的原因还是我们 做事不够专注,产品线过长。大家都在疲于应付,谁也不管过程如何了。( 其实没有过程,也就没有结果。)后来参加了一次PMP的培训,觉得我们现在做事情特别像那些面子工程。

公司也在改进、调整、最近花了很大的力气在组织项目管理方面的培训。希望能有好的起色。我祈祷!

评论列表
lee 2008-12-22 23:56:09
拥抱专注
xlight 2008-12-22 22:35:07
比如一个team里各个人员轮流专注。或2个team轮流专注。
xlight 2008-12-22 22:33:45
在绝大多数公司,人总是缺乏的。
但还是要想办法让开发人员专注。
我的想法是能让开发人员在一个星期内专注,各种打扰因素都有其他人员处理,虽然也许会慢一点,但是起码可以保证有一段时间可以专注。至少可以把核心代码理清楚了。
xlight 2008-12-22 22:27:32
恩,开发人员不能专注绝,对会出问题
1/1
发表评论
评论通过审核后显示。