软件项目管理在快速交付时面临着很多压力。时间就是本质。你如何快速完成呢？
想像你的开发团队TEAM有两个程序员，分别叫小刘与小李。他们拥有背景相同的业务知识，有相同的编程语言技能。在开发时，你发现小李总是完成他的功能模块所花费的时间比小刘快。当小李关注在快速编写代码的时候，小刘花费时间对已写过代码重构。他使那此变量与方法的命名变得更加易于理解。他总是把代码分成小块小块的，接着他又写在单元测试UnitTest保证这些小块儿代码是期望的那样。他为他所完成的功能模块所自豪。
但是假设你不知道这些细节。如果你只看功能模快完成的时间你认为小李表现是不错的。
一个星期过去了，你演示这个功能给客户看。通常，客户喜欢完整的功能，所以现在要求你修改并完善你的软件。你让你的开发人员去实现剩下的功能模块，当你需要加新功能到现有的模块时，小刘这边更加容易的实现它。不幸的是，他们发现一些小李完成功能模块有些奇怪。当小李去增加新功能到原来的代码，把原有的一个功能点儿破坏了。客户认为这是个缺陷,你让小李修复它。 客户后面又去测试这些功能，或新人刚来就直接上手操作软件。
如果你有个小孩，你知道什么发生了。小李创建是个打地鼠玩具类应用程序。就是那些给小孩玩的，小孩用几块木头就可以搭建的，那很好玩。但是，修复软件中随机出现的缺陷并不好玩。如果失败，不可预料，同时使你整个开发进程变得慢了。小李的精神可嘉，但是他的方向错了。
外面看到小刘明显较慢，他实际上编写的了优雅的代码。他前进的速度是持续的。更好质量的代码使它们更加容易快速修改。同时，那些UnitTest保证了整个程序每个部分可以正常工作。同时有的代码块可以重用。当用时间来衡量软件功能实现，不到考虑一次性完成就没事儿。花点儿时间去完善，提高代码质量。写高质量的代码与测试代码需要花费时间。短期有损失，但是有长期回报。
问问你自己是想要速度，或是你想要可持续的进度？
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
— Bill Gates
你可能感兴趣的文章：
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
