进度，该死的进度！

早在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的看板拖拽操作，有可能真正将开发过程中的实际工作情况，记录下来，而这是一切改进的前提
• 进度估算，是一个伴随开发过程同时进行的行为，而不仅仅是开发工作的前置阶段。但是，不能因为估算困难，就放弃估算
• 也许，我们能够找到一个更加直观与科学的办法，既让开发者感到舒适，又让老板感到满意

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