您如何回应“由于截止日期而没有时间测试/开发干净的代码”这一论点？
好吧，我认为这个问题是在错误的地方，我将前往 https://softwareengineering.stackexchange.com/阅读/询问它。感谢大家到目前为止的回答。 :)
抱歉 ;) 如果这个问题有点主观，我很抱歉，但我无法想出更好的标题。如果您更了解的话，我会更正它。
在我的组织中，关于整个自动化测试和持续集成的事情有很多讨论，但有一个我经常听到的争论是这样的：
如果 截止日期已经确定，但只有我预计的一半？
我自己也是开发者，所以我能理解这一点。但我总是试图回应，不仅开发人员需要范式转变，管理人员也需要。
如果您是一名开发人员，并且您的估算被削减了一半，那么无论您的估算是什么，您都不会取得任何进展，无论您的问题多么复杂或微不足道。你需要管理人员的支持，即提供资金的一个人。
结论？
您能给我一些帮助吗？这是一个阅读有关开发/管理冲突的好网址、一本书或者个人见解吗？您是否在一家目前正在进行精益开发的瀑布公司中经历了这样的大型流程转变？或者你知道这个论点并且有一个聪明的答案吗？
请帮我重命名或移动这个问题。 :-)
更新
感谢您的所有回答！ :) 我想我必须澄清，我的观点不是管理层的“速度加倍”声明。这是关于开发人员的声明所带来的负面观点。
我能做些什么来帮助人们理解这不是软件开发中的默认设置吗？ PM 没有积极阻止编写好的代码，也许双方都需要更多地了解干净的代码库、良好的覆盖率和大量自动化测试的优点/缺点？
Ok, I think this question is at the wrong place and I'll head over to https://softwareengineering.stackexchange.com/ to read/ask about it. Thanks all for your answers up to this point. :)
apologies ;) I'm sorry if this question is a little bit subjective, but I can not come up with a better title. I'll correct it if you know something better.
In my organization there is a lot of buzz about this whole automated testing and continuous integration thing, but one argument I constantly hear is this:
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?
I'm a developer myself, so I can understand this. But I always try to respond that not only the developers need a paradigm shift, but the management too.
If you are a developer and your estimates are cut half, no matter what you estimate, you are not going anywhere, no matter how complex or trivial your problems are. You need the backup of the management guys, the One Guy who is giving the money.
Conclusion?
Can you give me some help, may it be a good URL to read about this development/management conflict, a book or maybe a personal insight? Did you survive a large process shift like this in a Waterfall company that is now doing Lean development? Or do you know this argument and have a clever answer to it?
And please, help me rename or move this question. :-)
Update
Thanks for all the answers already! :) I think I have to make clear that my point wasn't the "do it twice as fast" statement from management. It's about the negative point of view that comes with this statement from a developer.
Is there anything I can do to help people to understand that this is not the default in software development? That the PM is not actively preventing writing good code and that maybe both sides need a bit more education about the pros/contras of clean code bases, good coverage and lots of automated tests?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一个很好的例子是技术债务。这对经理很友好。想象一下你的信用卡。如果您在几周内积累了债务，这可能会有所帮助。日常购物无需携带现金，月底即可还清。
这就像发布前的紧缩。你承担了一些债务，然后很快就还清了。如果你一直收取费用却从不还清债务，那么债务就会开始复合。你想要的新功能会变得更加困难，因为你构建的基础并不健全。你积累的债务使你无法迅速采取行动。如果超出限额，即使是典型的小额购买也将无法完成。
您可能还想看看软件工程的事实与谬误。它讨论了估算以及在项目发展过程中不对其进行审查时可能造成的麻烦。
One good example is Technical Debt. It's manager friendly. Imagine your credit card. If you accrue debt for a few weeks that can be helpful. You don't need to carry around cash for daily purchases and you pay it off at the end of the month.
This is like a crunch before a release. You take on some debt and then pay it back soon. If you keep charging things and never paying off that debt it starts to compound. That new feature you want it more difficult because the foundation you're building on is unsound. The debt you've accumulated is keeping you from acting quickly. If you're over your limit even typical small purchases won't go through.
You might also want to take a look at Facts and Fallacies of Software Engineering . It talks about estimates and the troubles they can cause when they're not reviewed as the project evolves.
这听起来可能有些失败主义，但我曾在几家遇到此问题的商店工作过，而且它们从未改变过——或者更准确地说，我发现不可能从内部改变系统。
问题是，从坚持这种开发的管理层的角度来看，只要产品大致按时发布，并且客户购买它，目标就达到了。换句话说，只要能赚钱，质量并不重要。
现在，你、我和经验丰富的管理层都了解技术债务的长期成本。也许可以向理性的管理者解释技术债务的成本、程序员时间投资回报率的复合减少（迄今为止软件项目中最昂贵的部分），以及一个干净的、设计良好的、良好的项目的事实。经过测试的代码库意味着可以更快地实现新功能，并且可以将更多时间花在新功能上而不是修复错误上，从而导致发布之间的平均时间得到长期改进。
也许可以向你的管理层解释这一点，但我工作过的每个地方都存在这些问题，在他们意识到之前都需要经历严重的失败。这通常涉及团队的很大一部分人因沮丧而退出，或者由于不切实际的日程安排而导致质量下降而导致销售额大幅下降（进而导致大规模裁员）。不管怎样，尽管我听说组织在事后发生了变化。
简而言之，尝试解释技术债务的成本以及干净代码库的好处。从销售、发布和客户满意度方面来解释它，而不是从技术角度。如果这不起作用，请开始寻找新工作，因为糟糕的管理会导致糟糕的产品，而糟糕的产品会让你作为开发人员表现不佳。
It may sound defeatist to say this, but I've worked in a few shops that had this issue, and they never changed- or more accurately, I found that it was not possible to change the system from within.
The issue is that, from the perspective of the management that insists on this type of development, as long as the product is being released approximately on time, and the customers are buying it, goal accomplished. To put it another way, As long as you are making money, quality does not matter.
Now, you, I, and experienced management understand the long term cost of technical debt. It may be possible to explain to a rational manager the cost of technical debt, the compounding reduction in return on investment in programmer time (by far the most expensive part of a software project), and the fact that a clean, well designed, well tested code base means that new features can be implemented more quickly, and that more time can be spent on new features instead of fixing bugs- leading to a long term improvement in the mean time between releases.
It may be possible to explain this to your management, but every place I've worked that had these issues required a critical failure before they wised up. This usually involved a large portion of the team quitting from frustration, or a large drop in sales as quality diminished due to unrealistic scheduling (in turn leading to massive layoffs). Either way, although I've heard of organizations changing after the fact.
In short, try to explain the cost of technical debt, and the benefit of a clean codebase. Explain it in terms of sales, releases, and customer satisfaction, instead of from a technical perspective. If that doesn't work, start looking for a new job, because poor management leads to a poor product, and a poor product reflects poorly on you as a developer.
你的“估计被削减了一半”是什么意思？你的意思是你给出了一个估计，而管理层却说，“不，用一半的时间来做”？这是不可接受的。
必须有人反抗管理层。 （我说“某人”是因为我不知道你的等级制度。）天下没有免费的午餐。如果他们想要更快，那么他们就必须做出艰难而痛苦的权衡。他们必须确定优先级并放弃优先级较低的功能。
如果他们说：“不。我们现在就需要这一切。要早点做，否则就坚持下去。”他们可能会感到惊讶，也可能会感到不安，但你会赢得他们的尊重。当他们开始倾听时，变化就会发生。
管理和开发之间不需要有冲突。冲突发生在管理和时间之间。做事情需要时间，这不是你的错。他们的工作是做出艰难的决定，以便按时推出产品，而不会让开发人员过度劳累，直到他们筋疲力尽为止。仅仅说“错了，用一半的时间来做”就不是管理。这是幻想。
事实上，你的管理层可能会继续愚蠢。如果是这样，您可以尝试玩他们的游戏：提出一个您认为自动化测试非常安全的安全估计，然后将其加倍。当他们把工作时间缩短一半时大声抱怨，然后无奈地叹息。让他们感觉自己正在做自己的工作。任务完成！
What do you mean your "estimates are cut half"? Do you mean you give an estimate, and management says, "No, do it in half that time"? That is unacceptable.
Someone must push back against management. (I say "someone" because I don't know your hierarchy.) There is no such thing as a free lunch. If they want it sooner, then they must make hard, painful tradeoffs. They must prioritize and drop lower-priority features.
If they say, "No. We need it all now. Do it sooner or else," hold the line. They may be surprised, and they may be upset, but you'll earn their respect. The changes will come when they start listening.
There doesn't need to be a conflict between management and development. The conflict is between management and time. It's not your fault it takes time to do things. It's their job to make the hard decisions to get the products out on time without overworking developers until they quit in exhaustion. Just saying "Wrong, do it in half that time" is not management. It's fantasy.
In reality, your management will probably continue to be foolish. If so, you can try to play their game: come up with a safe estimate that you feel is very safe with the automated testing and then double it. Complain loudly when they cut the hours by half, then sigh in resignation. Allow them to feel they are doing their job. Mission accomplished!
优秀的产品经理不会进行评估。曾经！优秀的产品经理会从负责这项工作的人那里得到评估。他们不会改变它。他们可能会试图哄骗工人改变它，但由于工人是做这项工作的人，他们应该控制估计。
如果你有一位产品经理将你的估算减少了一半，请确保你的估算是书面的，然后用它向他解释（抱歉，性别偏见，英语中没有一个好的中性代词），并希望他的老板你的工作看起来只完成了一半，是因为他在修改你的估计。
巧妙地指出，如果他们不打算认真对待你的估计，他们应该让你一个人呆着，从他们的臀部中剔除任何旧数字。这将产生与错过最后期限和不满意客户相同的效果，但你不会浪费时间提供无论如何都会被忽略的数字。
无论如何，糟糕的 PM 和聪明的开发人员之间的冷战自然会导致这样的情况：你应该最初将你的估计加倍，这样减半就不会产生什么影响:-)
A good PM does not estimate. Ever! A good PM will get an estimate from the person who is going to do the work. They will not change it. They may try to coax the worker to change it but, since the worker is the one doing the job, they should be controlling the estimate.
If you have a PM who cuts your estimate in half, make sure your estimate was in writing and then use that to explain to him (sorry for the gender bias, English doesn't really have a good neutral pronoun) and hopefully his boss that the reason your work only seems half finished is because he was screwing around with your estimates.
Tactfully point out that, if they're not going to take your estimates seriously, they should leave you alone and just pluck any old number out of their derrière. That will have the same effect of missed deadlines and unhappy customers but without you wasting time providing numbers that are just going to be ignored anyway.
In any case, the cold war between bad PMs and smart developers will naturally lead to the situation where you should initially double your estimates so that the halving will have little effect :-)
这听起来似乎很明显，但我对这个问题的回答是：
我的管理层有一个问题，他们担心如果要求开发人员编写单元测试，他们将无法按时完成任务- 这是在瀑布公司尝试实施 TDD 时普遍关心的问题。所以我做出了这个声明，我们必须通过在代码之前编写测试并且不要错过最后期限来证明它:)实际上，当你习惯它时，它将允许编写更多代码。
It may sound obvious, but my answer to this question is:
I had a problem with my management who were concerned that developers would not be able to complete their tasks on time if they will be required to write unit tests - this is a common concern when trying to implement a TDD in a Waterfall company. So I made this statement and we had to prove it by writing tests before code and not missing the deadline :) Actually when you get used to it, it will allow to write even more code.
通常，如果您改进编程实践和代码质量，几乎肯定会加快开发速度，因为与编写单元测试和尝试让一切从一开始就正确相比，您将节省更多的调试时间。很少有商店在代码质量上花费的时间比节省的时间多。
另一个危险是管理层是否会干预这一过程，而不仅仅是在不可能的期限内完成任务。如果他们希望你在最后期限前编写代码，那么你真的无法使用好的实践。
Typically, if you improve your programming practices and code quality, you'll almost certainly speed up your development, as you'll save more time debugging than you will in writing unit tests and trying to make everything right to begin with. Very few shops are in the position of spending more time on code quality than it saves.
Another danger is if management meddles in the process, rather than just serves up impossible deadlines. If they expect you to cowboy code in order to make the deadline, you really won't be able to use good practices.