进度,该死的进度!

早在2005年,我在ITEye连载了一个系列文章,当时的标题起得很大气《定论——软件开发的方法论探讨》,在写完1~7之后,我突然偃旗息鼓,写下了最后一篇(完)。

有兴趣的朋友,不妨一读:定论——软件开发的方法论探讨(1)(2)(3)(4)(5)(6)(7)(完)

当年的这篇文章,也是有感而发,最大的困扰,来自于软件开发的进度,难以估算。按照传统的软件工程的做法,大多数的开发进度,都会不断延期,不仅仅是一个给定范围的开发任务,会出现估算偏差,更加糟糕的是:在一个不断延期的开发过程中,还会有新的功能需求,不断加入。

后来,软件大师们,发明了一个新的办法:既然不能指哪打哪,那就打哪指哪。既然不能在给定的时间内完成任务,那么就反过来画个圈,这个阶段咱们完成的任务,就是咱们的阶段目标。

在给这种“掩耳盗铃”开发模式,起了一个漂亮的名字之后,这种敏捷开发的方式,在全世界流行起来了!

但是,真正“精明”的老板,是不会上当的!在敏捷开发模式下,开发人员永远是无可指责的!所有的开发进度,开发人员拥有无可争辩的主导权:“每一个Story的开发工作量都已经被估算出来了,产品经理能够选择的,仅仅是在下个阶段先实现哪几个Story而已。”

老板们通常会说:“三个月内,我要看到这个上线,不要告诉我不可能!公司的信条是:没有借口!”

进度,有时候是一个刚性需求,比如说:双11促销配套网站,决不能在11月12日才上线!

另外还有一些原因,导致了老板的无法信任不再估算进度的敏捷开发方法。

1. 听说,程序员之间的开发效率,高手和低手之间,甚至可以相差100倍。你如何才能让老板相信,你已经竭尽全力了呢?(他已经发现,你一到6点就下班了)

2. 软件开发的过程,总是难以一帆风顺,老板就会深度怀疑,明明你们的开发是可以提前完成的(如果不出这个、那个的bug的话)。

3. 当然,过度乐观的程序员,给自己挖了深坑,也是可能出现的情况之一。

4. 很多老板有一种行之有效的方法:先给程序员们,定一个无法完成的进度,然后,程序员会出于内心的愧疚,而努力熬夜加班,最终:进度虽然也会拖延,但是却常常能令老板偷笑。

根本的原因在于,即使是经验丰富的开发者,面对复杂的项目,也难以准确的估算进度,更不要说对于软件开发一无所知的老板了。一方面,老板不知道这活需要干多久,另一方面,手下的开发者,又不能做出靠谱的估算。一个不甘被愚弄的老板,只剩下一个选择:督促开发,尽力赶工。(只有这帮家伙,真正干到精疲力竭,我才能够相信,他们没法更快了。)

正好今天在微博上看到两个段子,虽然都是在说产品经理的,但其实是在说软件开发进度的。

一位艺术青年去拜访大师在:“为什么我专心画一幅画,只消一周功夫,可卖掉它却要整整一年?”“请你倒过来试试。你花一年功夫画一幅画,兴许一周就能卖掉。”大师说。青年照办,第二个月就因为进度太慢被产品经理捅死了……(via @顾扯淡 )「段子」

天黑请闭眼,rd睁眼,rd开发,rd闭眼,qa测试,qa找rd的bug,qa闭眼,天亮了,pm死了

因为开发进度,大多数的公司内部,都存在各种紧张的关系和激烈的争吵。这几乎算是永恒的矛盾了。

 

回到我写的那篇文章,当年的《定论》之所以没有写完,当年我是这么说的:“要能够检验软件开发方法的优劣,必须基于对于软件开发本质的正确认识,这样才能量化两个因素:软件需求的复杂程度以及软件开发的实际工作量。”

但是,在当时,我并没有找到这样的方法,而现在,我猜测Trello也许是解开这一难题的关键一环。由于我们目前还在各种尝试的阶段,还难以提出太多明确的观点,简单随意的先抛出一些:

  • 软件开发的本质,是经验复用+智力探索,经验丰富与脑子好用,同等重要
  • 软件开发管理的主要目的,是减少团队配合中的各种浪费与等待时间,以达到开发效率最大化
  • 基于Trello的看板拖拽操作,有可能真正将开发过程中的实际工作情况,记录下来,而这是一切改进的前提
  • 进度估算,是一个伴随开发过程同时进行的行为,而不仅仅是开发工作的前置阶段。但是,不能因为估算困难,就放弃估算
  • 也许,我们能够找到一个更加直观与科学的办法,既让开发者感到舒适,又让老板感到满意

先告一段落,等回头想得更加清楚一些时,再继续这个话题。