好的，我觉得这个问题发错地方了，我会转到https://softwareengineering.stackexchange.com/阅读/询问它。感谢大家到目前为止的回答。 :)
抱歉 ;) 如果这个问题有点主观，我很抱歉，但我想不出更好的标题。如果您有更好的了解，我会更正它。
在我的组织中，关于整个自动化测试和持续集成的事情有很多议论，但我经常听到的一个论点是:
How should I develop good, clean, easy to maintain code and write unit tests, if the deadline is already set and it is only half of my estimate?
我自己是开发人员，所以我能理解这一点。但我总是试图回应，不仅开发人员需要范式转变，管理层也需要。
如果您是一名开发人员，并且您的估算值被削减了一半，那么无论您的估算值是多少，您都无济于事，无论您的问题多么复杂或微不足道。您需要管理人员的支持，即提供资金的One Guy。
结论？
你能给我一些帮助吗，它可能是一个很好的 URL 来阅读这个开发/管理冲突，一本书或者个人见解？您是否在一家正在进行精益开发的 Waterfall 公司中经历过像这样的大型流程转变？或者你知道这个论点并且有一个聪明的答案吗？
请帮我重命名或移动这个问题。 :-)
更新
谢谢大家的回答! :) 我认为我必须明确表示，我的观点不是来自管理层的“快两倍”声明。这是关于来自开发人员的声明的负面观点。
我能做些什么来帮助人们理解这不是软件开发中的默认设置吗？ PM 没有积极阻止编写好的代码，也许双方都需要更多关于干净代码库、良好覆盖率和大量自动化测试的优点/缺点的教育？
最佳答案
一个很好的例子是 Technical Debt .这是经理友好。想象一下您的信用卡。如果您在几周内累积债务，这可能会有所帮助。您不需要随身携带现金进行日常采购，您可以在月底还清。
这就像发布前的紧缩。你承担了一些债务，然后很快就还清了。如果你继续收费，却从不还清债务，它就会开始变得复杂。您想要的新功能更加困难，因为您构建的基础不稳固。您积累的债务使您无法迅速采取行动。如果您超出限额，即使是典型的小额购买也不会通过。
您可能还想看看 Facts and Fallacies of Software Engineering .它讨论了估算以及它们在项目发展过程中不进行审查时可能造成的麻烦。
关于testing - 你如何回应论点 "No time to test/develop clean code, because of the deadline"？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3933510/