Shari wrote:
> I have to say, the team aspect of development/programming is what I
like best about it.
> That's what is the most appealing aspect of XP to me. Stronger
involvement with all members.
> With UML, here anyway, it seems to happen like this:
<snipped>
That sounds like a formal nightmare. No wonder it's not working well
for you - the programmers have no input, no 'feel' for the project,
and feel like drones. You feel powerless, having neither contact with
the clients nor with the programmers.
Suggestion:
Attend all the client meetings you can get your hands on. If you're
doing the design, you need to get a feel for the client's /real/
requirements. Ideally, get some time to talk to the client yourself,
to ask questions, to get clarifications. In your current workplace,
that may not be possible. But it'd be good.
Then TALK WITH the coders. Say 'the client seems to want X, Y and Z;
with A, B and C to follow later on'. Get THEIR input in the design.
Involve them from the start. Promise to get back to them with a
rough design within a certain time frame. Do that. Get their review of
the design - they'll have been thinking about it too.
Rinse and repeat till you have a design you and they can all live with.
Freeze that document - snapshot the spec & design docs at this point.
Then *stay involved* with the coders. Go back to them. Ask them where
the design is at odds with their experiences during implementation.
Fix those places. Your job now is to produce an actual-design document,
which might have absolutely nothing in common with the original
design-snapshot you froze last paragraph. :) Hopefully it has something
in common, though. :)
Actually, the actual-design document is more a by-product. Your job is
to keep the design /smooth/. To smooth over design conflicts between
programmers, and to make sure they have a visible track to stay on. You
may or may not be able to keep them on that track, but you can at least
keep it *visible* to them, and keep it where they can sort of cluster
somewhere around it.
Your current workplace may not allow you to do that. If that's the case,
my advice is to move - your management may be too concerned with keeping
a heirarchical model, and not sufficiently concerned with code or people.
Moving may, of course, not be an option. :/ In which case, maybe you
can play politics (iewww) till you can do some approximation of this.
I'm really blathering on with this topic .. hopefully I'm making sense.
Jenn V.
--
"Do you ever wonder if there's a whole section of geek culture
you miss out on by being a geek?" - Dancer.
[EMAIL PROTECTED] Jenn Vesperman http://www.simegen.com/~jenn/
--
"Do you ever wonder if there's a whole section of geek culture
you miss out on by being a geek?" - Dancer.
[EMAIL PROTECTED] Jenn Vesperman http://www.simegen.com/~jenn/
_______________________________________________
techtalk mailing list
[EMAIL PROTECTED]
http://www.linux.org.uk/mailman/listinfo/techtalk
