Robin Szemeti <[EMAIL PROTECTED]> writes:
> On Sat, 20 Jan 2001, you wrote:
>
> > One customer. On site. Full time. Absolute honesty. Get them on your
> > side. The are the people who are *paying* for this, they deserve
> > nothing but your honesty. Tell 'em about any problems and tell 'em
> > early. Tell 'em about successes and tell 'em early. Get the customer
> > rep onside and you have an advocated. Treat the customers like a
> > mushrooms and you don't get repeat business.
>
> sounds great ... when do we start.
>
> Seriously XP sounds like it should work .. I read the books I was
> convinced.
>
> The only thing that occasioanlly worries me about it is that my current
> client is still working his way up to being a mushroom. Apart from that
> the client has a total staff of 5. I cant see them sparing 20% of their
> workforce in order to sit and keep the developers comapny. Worse still I
> have not yet had a decision on anything in less than 24hrs. I think that
> would haold true even if they were on site too.
>
> So I am really keen to do an XP managed project ... if it really does
> work then that sfantastic, best result I could ever have. I suspect that
> it fails, just in different ways to other project managment systems.
>
> obvious ones:
>
> The client doesn;t send Big Chief to sit with the designers, instead
'designers' is kind of the wrong term with XP.
> they send Useless Minion. UM is positive and helpful and gives quick
> decisions ona whole variety of topics. And a week later turns up
> with changes handed down by Big Chief overiding those decisions.
> worse still the decisions handed down make no sense because he
> hasn;t been with the team and doesn;t undrstand whats going on.
This one is, potentially a problem. I'd say that, as a company
consulting with the company you make *bloody* sure that the client is
aware of the importance of the 'on site' customer, and of their status
as final arbiter. It's also stressed that the OSC can say "I'll get
back to you on that", but a lot of the time questions that need to be
answered are uncontroversial and can be answered trivially even by a
UM.
And because the XP approach advocates code that passes its tests at
all times, the political value of something that is actually doing
stuff can be useful too.
And if the Big Cheese does hand down decisions that override the
Minion then the contract between developer and client should stipulate
that the client pays for the wasted time.
And if this does happen then we should learn from this how to improve
our 'client interview' process. Which kind of implies that our sales
teams should work pairwise as well so that there's experienced
developers in on the interview too.
> Client has no concept about what software development is like and within
> a week or two cancels the entire thing 'some of those guys spent a whole
> week working and half the time couldnt even get it to run, by the end of
> the week all they'd done was write some strange "library" code and even
> that doesn;t seem to do anything'
Remember that, with the XP approach, library code doesn't get written so
much as it kind of happens. If you don't need it *now* you don't write
it. Add functionality as you require it.
>
> but hey .. next person organising a XP based project that needs a junior
> perl hacker .. gimme a shout ..
