@AiryLinus 的微博：DDD,Deadline Driven Development（上吊绳驱动的开发）。拿到需求之后在开发者脖子上加一根随时间收紧的吊绳。如果规定时间内没有完成开发任务，开发者会被吊死。
记得在大学的时候写报告，作业吗？其实，它也是上吊绳驱动开发。如下图：
还有古代那个头悬梁，锥刺股去考科举也可以算是上吊绳驱动开发的一种自我激励方式吧：）。
Deadline-driven development is basically a way of borrowing against the future speed of development to meet a certain date.
上吊绳驱动开发基本上是一种借用未来的开发速度去满足特定的日期。
笔者对于上吊绳驱动开发有很深的感触。现任职于一家外包公司，做的是华为的项目，而华为的项目开发模式基本上都是上吊绳驱动开发。我想做过外包，或者做过华为外包的兄弟都会有比较深的感触。（注：这里不是要批评华为的这种文化，就事论事）。
不可否认，上吊绳驱动开发也有他的好处：
1.某个时候，业务上依靠直觉就知道点击什么预期结果是什么。这使得开发过程似乎更可靠。
2.目标明确。程序员都清楚的知道自己的任务的完成时间，尽管其中有些需求会发生变动。
3.紧张的工作气氛。程序员得到一种紧迫感,因此变得更积极。
4.开发人员不需要去担心其他的事情，只需要努力工作，学习正确预估任务的完成时间，而不必为错误预估任务的完成时间承担责任（从某一个层面上说，业务规划的人定的截至时间本身就有问题）。
但是，更多的是坏处：
1.大部分程序员都不愿意加班，甚至熬夜，周末加班。从我个人的观察，长时间的工作通常会导致情绪问题，或工作需要重做。这样不仅工作效率低下，而且违背了程序员们的初衷，甚至在一些不是很开明的公司，员工索取加班费和打车费还是一个问题，最终导致大部分程序员离职。试想，又有谁愿意将自己的健康和生活抛弃呢。（加班从某个程度上说节省公司的成本——加班在业内基本上是无偿的，但是从另一个层面上说是在牺牲员工的利益去满足公司的利益，不厚道啊）
2.技术负债将会不断发生。这本身就是一个危险的做法，让你的开发过程随时间而变得缓慢直到你的团队不能再任何合理的时间内完成基本功能。
既然知道这些问题的严重性了，怎么去预防呢？
1.首先，大家必须要有一个共识：过早的，错误的规划项目的结束时间几乎都会引发技术负债，上吊绳驱动开发基本上是一种借用未来的开发速度去满足特定的日期。
2.开发人员需要对任务“完成”有正确的预估以及评估其可靠性，确保技术债务非偶然性发生。
3.开发人员需要去发现一种新的保持紧张的工作气氛的方法。（通常，完成他们自身预估任务的完成时间本身就是一种挑战）。
4.每一个人都必须达到一种共识（无论是业务规划的人）：项目计划的截至时间由开发人员来预估。（当然，需要有经验的管理层来评估预估的正确性）。
5.随时根据项目真实情况不断调整和更新项目计划。
6.对于大部分人来说，管理人员需要满足与监测项目进度，而不是试图支配或者描述它。
在这里我并不是想说这些很容易实现，但是如果你参考这个去做，那么你的团队进度将会越来越快。在某种程度上，相比更加注重质量驱动开发，我还是支持上吊绳驱动开发的，至少它不会让项目进度停止或者倒退：）。在我的经验里，缓慢滚动的轮子，对项目来说，项目进度会越来越快，更加可靠和团队更加容易去管理的。
参考文献：
Are you writing code for a deadline or are you writing code for future
