[software industry] Dev/Test/PM
Dec. 10th, 2003 01:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ravencallscrowsThis is geared toward those of you who work in or have an understanding of the software industry. If it doesn't make sense to those of you outside this context, my apologies.
I'm beginning to wonder if the MS approach didn't in some way spoil me from a QA perspective. Yeah, at MS, test takes it rough and hard, and without lubrication. But then again, test expects that they're getting the short end of the stick, and braces somewhat to deal with it. Project management exists to manage the product- the concept of one person owning and driving where development on a particular feature is going. Development and test have some say in the process- in as much as dev defines what they can and can't do; and test defines where functionality is or isn't, and how proposals may impact other features. PM sets deadlines for work, and administers- dare i say manages the workflow of the project- and makes the final decisions, including scheduling deliverables. Dev and test have some degree of push back, but in the end, project management makes the decisions.
At Cavedog, the approach was a little different. Because the Online Gaming group was fairly small, we didn't really have people in a PM role aside from a very high level- the folks who determined when the product needed to RTM. Decisions got made on what to do and when in small meetings- which could range anywhere from three to four people up to the whole group- which was still twenty or so. What's more, development, art, and test made these decisions by general consensus- and they were almost always unanimous, because when serious objections were voiced or questions were raised, they got talked out. As a group we set the timetable for work items- usually at the weekly Monday morning "Chewing the Bone" meeting, and if that schedule needed to be adjusted for something unexpected- either advanced or pushed back- it was on the small scale that these things happened.
At my current employer, which shall be referred to as V.net, things are significantly different, at least from my perspective. I've yet to determine exactly what it is that PM does here, other than acting as an interface layer between the business and the technology and the people involved on both sides. I can define what PM doesn't seem to do: PM doesn't seem to write documentation or feature specs; PM doesn't seem to set hard timelines; PM doesn't seem to drive the direction of development. The more i think about it, the more PM seems to just be a wetware interface level between business people and technology people.
My colleague and i comprise an entire test team. We seem to be pretty solidly on the same wavelength when it comes to what the product needs and in what priority. Our focus is specifically a maintenance role- we test fixes to the currently deployed product, verify functionality and that no other functionality is broken by the fixes. We're scheduled to have a release coming up by the 19th of the month, and have reached a code freeze where the only things which are being checked in are fixes to existing code. He's leaving for vacation on the 18th, so we want to move our sign-off up three days to the 16th- so that we have the chance to get as many fixes implemented as possible and tested, but still both eyeball the product and sign off on it.
We don't have any particular vested interest in how many- or what- fixes go into this release. We've got a list of nineteen fixes presently in the process. Of these, eleven have had fixed checked in and have been confirmed. We've also regressed the fixes from the last few releases, verifying that all is still working. That leaves eight issues- seven open ones and one new one. They're all fairly low severity/priority.
Here's where it gets interesting. We want to release Tuesday, so that we have all hands available just in case there are any trainwrecks. Given the nature of our build process, one can't be too sure. So, we want to be able to build tonight and deploy to test servers tomorrow- which would give us all day Thursday, Friday morning (Friday at 11:30 is a corporate holiday event- which kills the rest of the day), and Monday to do an acceptance pass on the build, which we're treating as a release candidate. Should be no problem having it good to go by Tuesday. But we need our developers to check in which of the eight open issues they can- we want to release as much as possible, obviously.
Of those eight, two are almost certainly punted to the next release- they'd each require six to eight hours of dev work, which means they're not going to happen by the end of the day today. The other six? No estimates of dev time on them at all.
So, this is where we need PM to step in and make the call as to what's shipping and what's punted. Unfortunately, neither of the project managers seems to be capable of making the call, which is leaving QA driving the process. Not a happy situation, because we're not supposed to be driving.
I want specs. And time schedules. And documentation, damnit.
All in all, though, this is still a much better environment than working in Office was. At least we won't have eight release candidates of a major release dumped on us in the week and a half before they're going to go live.
I'm beginning to wonder if the MS approach didn't in some way spoil me from a QA perspective. Yeah, at MS, test takes it rough and hard, and without lubrication. But then again, test expects that they're getting the short end of the stick, and braces somewhat to deal with it. Project management exists to manage the product- the concept of one person owning and driving where development on a particular feature is going. Development and test have some say in the process- in as much as dev defines what they can and can't do; and test defines where functionality is or isn't, and how proposals may impact other features. PM sets deadlines for work, and administers- dare i say manages the workflow of the project- and makes the final decisions, including scheduling deliverables. Dev and test have some degree of push back, but in the end, project management makes the decisions.
At Cavedog, the approach was a little different. Because the Online Gaming group was fairly small, we didn't really have people in a PM role aside from a very high level- the folks who determined when the product needed to RTM. Decisions got made on what to do and when in small meetings- which could range anywhere from three to four people up to the whole group- which was still twenty or so. What's more, development, art, and test made these decisions by general consensus- and they were almost always unanimous, because when serious objections were voiced or questions were raised, they got talked out. As a group we set the timetable for work items- usually at the weekly Monday morning "Chewing the Bone" meeting, and if that schedule needed to be adjusted for something unexpected- either advanced or pushed back- it was on the small scale that these things happened.
At my current employer, which shall be referred to as V.net, things are significantly different, at least from my perspective. I've yet to determine exactly what it is that PM does here, other than acting as an interface layer between the business and the technology and the people involved on both sides. I can define what PM doesn't seem to do: PM doesn't seem to write documentation or feature specs; PM doesn't seem to set hard timelines; PM doesn't seem to drive the direction of development. The more i think about it, the more PM seems to just be a wetware interface level between business people and technology people.
My colleague and i comprise an entire test team. We seem to be pretty solidly on the same wavelength when it comes to what the product needs and in what priority. Our focus is specifically a maintenance role- we test fixes to the currently deployed product, verify functionality and that no other functionality is broken by the fixes. We're scheduled to have a release coming up by the 19th of the month, and have reached a code freeze where the only things which are being checked in are fixes to existing code. He's leaving for vacation on the 18th, so we want to move our sign-off up three days to the 16th- so that we have the chance to get as many fixes implemented as possible and tested, but still both eyeball the product and sign off on it.
We don't have any particular vested interest in how many- or what- fixes go into this release. We've got a list of nineteen fixes presently in the process. Of these, eleven have had fixed checked in and have been confirmed. We've also regressed the fixes from the last few releases, verifying that all is still working. That leaves eight issues- seven open ones and one new one. They're all fairly low severity/priority.
Here's where it gets interesting. We want to release Tuesday, so that we have all hands available just in case there are any trainwrecks. Given the nature of our build process, one can't be too sure. So, we want to be able to build tonight and deploy to test servers tomorrow- which would give us all day Thursday, Friday morning (Friday at 11:30 is a corporate holiday event- which kills the rest of the day), and Monday to do an acceptance pass on the build, which we're treating as a release candidate. Should be no problem having it good to go by Tuesday. But we need our developers to check in which of the eight open issues they can- we want to release as much as possible, obviously.
Of those eight, two are almost certainly punted to the next release- they'd each require six to eight hours of dev work, which means they're not going to happen by the end of the day today. The other six? No estimates of dev time on them at all.
So, this is where we need PM to step in and make the call as to what's shipping and what's punted. Unfortunately, neither of the project managers seems to be capable of making the call, which is leaving QA driving the process. Not a happy situation, because we're not supposed to be driving.
I want specs. And time schedules. And documentation, damnit.
All in all, though, this is still a much better environment than working in Office was. At least we won't have eight release candidates of a major release dumped on us in the week and a half before they're going to go live.
