在软件开发的世界里，经常听到“完成”这个词，但很多时候，所说的“完成”并不意味着真正的“完成”。在不同的工作环境中，这个概念有着不同的含义。一位经理曾经向介绍了一个非常有用的术语——“真正完成”。这是一个行业中非常需要的概念。他从来不会简单地问：“完成了吗？”，而是会加上：“意思是，真正完成了吗？”
在编程领域，如果认为自己完成了任务，但实际上并没有，这是一个一再看到的问题。也曾犯过这样的错误。曾经带领一个团队将几个新功能集成到产品中。经过几个冲刺阶段后，注意到燃尽图总是呈现出相同的形状。
在最初的几天里，总是能够提前完成计划。在站立会议上，团队成员会高兴地宣布他们完成了任务，燃尽线会迅速下降。然而，随着截止日期的临近，会发现那些认为已经完成的任务实际上还需要更多的工作。没有充分测试它们，看到了一个结果，就决定继续前进。
结果，速度会减慢，燃尽线会逐渐超过理想的预测。这种情况在每个冲刺阶段都会发生。那么，什么时候才算是“真正完成”了呢？为什么程序员总是坚持说已经完成了，而实际上并没有呢？
“真正完成”的定义实际上取决于具体情况。如果正在编写一个一次性脚本，将一些数据从一个地方移动到另一个地方，可能不需要考虑代码质量和集成。这甚至可能是浪费时间。但是，如果正在将一个复杂的功能集成到生产环境中，不能仅仅因为它在机器上看起来工作正常就认为它完成了。
它是否经过了充分的测试？它是否已经集成到构建中？是否添加了单元测试？是否进行了审查和重构？是否需要进行同行评审？文档是否已经编写？程序员在日常工作中的一个反复权衡是乏味与专业性之间的权衡。通常知道应该做更多的事情，但这并不令人兴奋。认为可以稍后再担心这些事情（当别无选择的时候）。有趣的部分是朝着想象中的期望结果努力，然后当在屏幕上看到那个结果时感到满意。毕竟，最终用户并不关心重构、单元测试或代码质量。
但最终用户确实关心的是系统不断崩溃，修复错误和添加新功能需要很长时间。更重要的是，队友不会感谢，因为他们需要理解并清理混乱。程序员经常过早地说他们已经完成的另一个原因是压力。可能已经提出了正在工作的估计，如果任务比预期的要长，自然会急于告诉老板终于完成了。失败的恐惧是所有人都不时经历的事情。如果承认并没有真正及时完成，可能会得出结论，已经失败了。
不能陷入这个陷阱。如果事情比估计的要长，保持冷静。不要惊慌。估计就是估计，没有人确切知道某件事需要多长时间。随着在行业中的经验增加，估计技能会提高。给自己提供尽可能准确的估计的最佳机会是很重要的。当被某人要求提供一个“大概数字”时，问问是否能回复他们。问问他们是否可以给十分钟，写下认为的子任务，然后按照承诺回复他们。当在计算那个估计时，不要忘记那些乏味的事情。
实现“真正完成”的一个有用概念是每天做一点所有的事情。在《敏捷开发的艺术》中，James Shore提倡这种方法：XP在每天在工作的每个方面都取得一点进展时效果最好，而不是在迭代的最后几天为让故事“真正完成”而保留。通过这种方式，能更好地了解进展情况，并且会在过程中尽早发现令人不快的惊喜。TDD和持续集成是帮助做到这一点的两种明显方法。