问题
I work for a small software company with less than 10 programmers. Our software is installed in dozens of places across the world. Our code base is huge, due mostly to poor design and massive amounts of duplication of code (IMO). We have roughly 30 different projects, each with a total of about 600 KLOC with about 200 KLOC of that being our own homegrown code. When I got there in 2006, this code wasn't even under revision control. I've managed to convince powers that its important, and we now use a code control system (cs-rcs, not my choice but its better than nothin), and a bug tracking system. The huge missing piece is the total and complete lack of QA in the process. Our release process is non existant on paper, and in practice it consists of "hit ctrl-F9, copy binary to client, declare problem fixed."
Can anyone point me to some official papers or PHB-language documents or articles that can explain the blatant lunacy in this process? I'm sure the boss could hire some consultant to tell him this, and then he might believe it. But I'm just a lowly maintainer with a Software Engineering BS degree. And my ethnicity doesn't help me either. What's the best ammunition to use in this case?
回答1:
Tautologically, the only way to convince them is put them in front of something that is convincing. That thing could be drawn from a list such as:
- The foretold expensive disaster that prompts adoption of the previously-presented solution
- The unforetold disaster with a ready-made never-again solution
- A brilliantly persuasive foretelling of a disaster
- A brilliantly persuasive appeal to greed (saving the opportunity cost of a foretold disaster)
Or something else. In all these cases, someone is going to have to make the case at some point for the QA solution you propose, and that someone, from the looks of it, is going to have to be you. So I'd start learning about being persuasive.
How to Win Friends and Influence People should cost you a few bucks at most. Getting To Yes is also cheap.
How did you get agreement to source control? Can you keep chipping away, improving the process a small increment at a time?
Try Googling "change your organization", there looked to be some promising links.
And ultimately, remember that (as a wise man once said) if you can't change your organization then you should change your organization. There really is always an alternative.
回答2:
Your best ammunition in this case is to wait for the inevitable disaster. Once it happens, have all your ducks in a row with a plan that will cause this disaster to never occur again, one that stresses the costs of implementation being far lower than the disaster itself cost.
No amount of talk will make PHBs "get it" if they don't want "it" in the first place. Only a big slap in the face from that harsh master -- reality -- will persuade them in the end.
Oh, and while you're at it, update your resume and get looking. The disasters that tend to convince people they need QA are very similar to the kinds of disasters that kill companies.
回答3:
Money is your best bet - it hurts worst when it comes to paying.
I think the following image says it all:
(The image is from www.developertesting.com)
回答4:
Management isn't going to understand anything but two things: (1) Cost benefit & (2) Customer satisfaction. The 2nd one is hard to quantify but the first one is easy. You can spend $40k to $60k on a decent QA engineer who can come in and start making sense of the mess and start developing a plan around it. The cost benefit comes from making sure that a higher skilled engineer doesn't have to go spend 2 months tracking down a bug hidden in 100k lines of code.
There's another way to go about this... You can do what we are doing where I work. Start writing tests for the code at the beginning and then by the time you are done with the code if the test passes then you are golden. After the test passes then you have a test in place that will make sure if you ever break that code that you will know about it almost instantly. And if you get your fellow programmers to get in on that action then at least all the new code will be developed under a testing framework. Test driven development not only makes the process go faster (you already know what you want the result to be before you start coding) but it also helps refine your requirements in a hurry. Most importantly, with a little social engineering (working with your peers) you can change the development culture bit by bit until the process is complete.
回答5:
I can recommend The Toyota Way. The short version is often possible to order for free from toyota web sites. Management should have read it already, but apparently they haven't. Read it, digest it, make management read it. For inspiration I can truly recommend reading Lessons from Toyota's Long Drive (it's well worth the few bucks to get the PDF).
回答6:
Perhaps if you get some of your programmer colleagues to back you up, management will be a bit more willing to listen. You don't need to be a genius to realise that a huge, unwieldy code base is indicative of much room for improvement.
回答7:
Refer Joel's book
回答8:
If your management doesn't think QA is important, something so obvious and "common sense" to the point that any layman would agree with, then I don't think putting a bunch of academic papers, or anything else for that matter, to them will make any difference.
Your only hope is probably to try to put together a document which would show the cost savings, but I doubt that would help in this case.
回答9:
I worked in one department where a common pool rotated between development tasks and testing. This accomplished two things:
- highly skilled, efficient testers, who at worst knew what the code was trying to do, and how
- developers who knew their turn was coming to do testing, or who had just returned from testing. So the pain of testing bad code was known, as was the pleasure of testing good code.
The most respected guy in the whole group was a ruthless tester, and when developing, would produce zero defect software.
来源：https://stackoverflow.com/questions/432512/how-to-convince-management-that-qa-is-important