Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:




Extreme Programming

Message Forum - Archive, Page 3


Message Index

McConnell: The best alternative to XP
Eric Herman eric-NO-SPAM@igps.org

re: McConnell: The best alternative to XP
Matt

getting jollies out of knocking things is great but...
his XP-ness nonexistent@none.com

re: A Nautical Analogy
Ilja Preuss preuss@disy.net

I donīt have to jump off a cliff to know its not a good way to travel
Ilja Preuss preuss@disy.net

Doctor, it doesn't hurt as much when I...
Dave Rooney dave.rooney.no.spam@mayford.ca

re: Doctor, it doesn't hurt as much when I...
Matt Stephens

re: Doctor, it doesn't hurt as much when I...
Dave Rooney dave.rooney.no.spam@mayford.ca

Anyone know Matt personally?
Jack Jack@sprat.com

Yes, I have known Matt for years
Dino

re: Anyone know Matt personally?
an incompetent programmer

"Trying to project from an article to someone's  personality is a little di ...
Jack Jack@sprat.com

Oh Lordy
Dino

Trying to reach Matt
Laurent Bossavit laurent.sr@bossavit.com

I have emailed Matt
Dino

We need pros and cons
ErikE edvalson@hotmail.com

Invite
Laurent Bossavit laurent@bossavit.com

refactoring
Bruce Tobin btobin@columbus.rr.com

Hindsight
Dino

re: Hindsight
Bruce Tobin btobin@columbus.rr.com

Amateur
Joel

Productive - Proactive comments
Anonymous person m@m.com

re: Productive - Proactive Comments
Dave Rooney dave.rooney.no.spam@mayford.ca

re: Productive - Proactive comments
Matt Stephens

Where's the proof of concept?
RA Cooper racooper@hampsters.fsnet.co.uk

re: Where's the proof of concept?
Matt Stephens

re: Where's the proof of concept?
Dave Rooney dave.rooney.no.spam@mayford.ca

XP and J2EE are at odds
new to xp anon@anon.com

Hi,     "The case against XP" is the best article I read in a long tim ...
Lidor SharpDevelopment@eSmartWeb.com

extremedayjob.tripod.com/totheextreme
Bill Lumberg

Pair Programming for Training New-Hires?
Mark Poff Mark.Poff-1@ksc.nasa.gov

Re: Pair Programming for Training New-Hires?
Ravi V rsv29 at yahoo.com

how to xp
shaohua ma shaohuam@yahoo.ca



The Messages

McConnell: The best alternative to XP
"The best alternative to XP, or any other reactive development methodology, is simply to develop software properly. Read the Steve McConnell books cover to cover, learn from them, and apply the principles that he describes. Heīs got it right."

This advice, you may be surprised to learn, is already near the hearts of many members of the XP community.

Steve McConnell gave a talk to the Seattle XP group last week. It was a good event, sparking some great conversation points, like where XP might fit and where it might not.

One topic centered around McConnellīs idea of a methodolgy "ToolBox" ... in breif, look at the problems at hand, and find the best tools for the job. He asked the group how many people were using 100% of XP by the book, and no one was. Lots of people were doing "about 75%" of XP.

What this tells me is that programmers are smart people. They are problem solvers. They arenīt going to mindlessly apply McConnellīs writings or the writings of XP. They will think about things, try things that are likely to work, and most importantly, try to learn.

Eric Herman eric-NO-SPAM@igps.org
Seattle, WA, USA

Sun Apr 14 21:44:05 EDT 2002
re: McConnell: The best alternative to XP
I agree - no one project is the same, therefore no single process is likely to be an exact match.

I think the industry is moving towards this idea of a process toolbox, where you tailor a process according to your project (including an evaluation of the people involved). RUP already does this, but is daunting to most people because you effectively start with everything and chip away at the bits you donīt want.

There are better efforts elsewhere in the industry - e.g. Agile Modeling (AM) can be selectively applied to an existing process (agile or otherwise).

Matt
London, England

Thu Apr 18 11:49:27 EDT 2002
getting jollies out of knocking things is great but...
... it's not helping. Unfortunately I am compelled to be an anonymous coward due to my position of criticizing the people that pay my bills.
<p>
Here is the main point:
<p>
** The vast majority of software developers suck **
<p>
Most projects are cluelessly run. Success is either through good fortune or a few good developers killing themselves.
<p>
Those that have created this forum and those read this forum are in the minority of the software developers that don't suck. But down in the trenches, working with many different organizations (dot com, fortune 500, government), I'm appalled at the lack of knowledge and apathy. Basic language constructs, fundamental OO concepts, basic tool use are all poorly mastered.
<p>
RUP and other phasist processes are a waste of time with such people. Most "processes" do nothing to help this poor hapless souls do their job better. I read the message above from the guy above who thinks he's doing something like XP. He talks about how difficult the GUI is to test. I know for certain from this statement that his design leaves a lot to be desired: all the logic is no doubt in the GUI. MVC anyone? You have to have a clue to build decent software.
<p>
The benefit of XP that I've seen so far is it forces everyone on a team to actually learn something about software development. If they can't hack it, they need to get out. God knows it's hard enough to get a job without the clueless masses sucking down jobs, producing worthless software, at $70,000+ a pop.
<p>
But XP will of course fail, just as other processes will fail. The calls I've seen on this forum for an honest dialog are roundly dismissed by Matt Stephens, a developer with a whopping 10 years of experience who apparently knows everything about software already. Good for you Matt; unfortunately, the bulk of developers out there aren't as smart as you.
<p>
Most processes to date don't work. They make people feel better by offering up lots of fancy documents and diagrams. RUP hasn't worked either. Time to give it up.
<p>
Instead of wasting unbelievable amounts of time with this site to bad mouth something (jealousy about all the press perhaps?) perhaps you could direct your genius to solving the problems that XP purports to solve. Yes, there are flaws in XP. Yes, the people defending it to the hilt here are dogmatic and often offer contradictory answers. But the basic concept of a process that actually tries to help the programmers with their day to day work is where things need to head. Blanket dismissals of a process out of misdirected anger (and homophobia) are not productive.
<p>

his XP-ness nonexistent@none.com
Colorado, US

Fri Apr 26 20:35:17 BST 2002
re: A Nautical Analogy
"[...] itīs a mistake to think that RUP is necessarily heavyweight. In any project you just use the parts of RUP that you feel you need, i.e. it can be very lightweight. Itīs up to you."

Yes. And one of these instances of RUP is called dX, which is just a slightly modified XP: http://www.objectmentor.com/publications/RUPvsXP.pdf

Ilja Preuss preuss@disy.net
Karlsruhe, Germany

Fri May 10 14:47:40 BST 2002
I donīt have to jump off a cliff to know its not a good way to travel
Climbing has *always* been a better way - until someone developed the paraglider...
Ilja Preuss preuss@disy.net
Karlsruhe, Germany

Fri May 10 14:52:38 BST 2002
Doctor, it doesn't hurt as much when I...
My development team has just finished shipping a new release of an application that had a reputation for being late, full of bugs, and had a terrible communications gap between the developers and the client. After I came on board late last year, I pitched XP to the various powers that be, and they bought into the idea.

We used about 9.5 of the 12 practices, delivered more functionality than was scoped for the release, had only 3-4 minor bugs in final acceptance testing, and shipped on the date we promised. I was the only team member that worked any OT over the 4 months, and that was about 2 hours to track down a problem that was driving me nuts.

In this case we adapted XP to the local environment (Kent Beck talked about that!). We only had 3 developers, so Pair Programming was out of the question for most of the time, although we did do some. The developers were already co-located with the client team, so that wasn't an issue. The client already managed their own requirements (although not on index cards - hence the 9.5!), and were more than happy to sit with us to review the requirements and perform estimation.

The big difference was communication and iterative development. Previously, the developers were explicitly told not to let the client play with the system (or even see screen shots) until development was done. The rationale was that there might be changes, so everything would be wrong (didn't make much sense to me either!). The client wouldn't see the system until final acceptance testing, during which there was a big panic to fix a whole whack of problems and misinterpretations of the requirements.

By using XP (or our flavour of it), the client was actively involved - to their delight - during the whole development cycle. We delivered a working copy of the system for them to test at the end of each iteration, thus spreading their workload out and catching any big issues early. The client performed a final, full acceptance test phase, which they completed a week early. All in all, it was a tremendous success.

I think the big difference here is that we adapted XP to fit the circumstances. We already had a client who was involved and willing to do as much as possible to help. It might be worth noting that our 'client' was actually a small group of business analysts who were more of a proxy for the end users. The analysts were able to make 85-90% of the decisions required, which made the turnaround time much faster on any questions we had. Once we started delivering the iterations on time, everyone bought into the idea.

Personally, I disagree with anyone who speaks of XP in absolutes, i.e. if you aren't doing all 12 practices, it isn't XP. Whatever. I'd rather ship a clean product on time, on budget, than attain a label. Fine, then I'm not doing XP, I'm just making my clients happy. I can live with that! :)

Dave Rooney dave.rooney.no.spam@mayford.ca
Ottawa, Canada

Wed May 15 17:20:15 BST 2002
re: Doctor, it doesn't hurt as much when I...
I'm glad to hear the project was a success -- that's always a good thing to hear.

3 developers suggests that it was quite a small project. I think I've maintained elsewhere that XP is better suited to very small projects where the entire team is co-located (ideally in the same room).

It's really when things start to scale up, or when one (or all three) of the developers suddenly leaves, or when peoples' memories play tricks and they disagree on what was previously verbally agreed, that things can go awry.

Out of interest, was there any kind of "official" process in place before you joined? If the project was in that much trouble (especially with such a small number of developers), then any process would have to be an improvement!

Anyway thanks for the story,

Matt Stephens
London, England

Thu May 16 13:32:19 BST 2002
re: Doctor, it doesn't hurt as much when I...
Matt,

It was a smaller development team, yes. We were also located within 10-12 feet of each other, which was another contributing factor.

As for the project itself, the release we completed had over 130 individual 'items' that more or less corresponded to user stories - a couple were 'change the label on this field to x', while some others where 'implement all 20 items in change request y'. Now this was version 3.0 of the system (actually the fourth or fifth to hit production, with a 1.2 and 1.5 in there), so there was virtually no infrastructure work to be done. Having said that, we were adding and changing code in crucial parts of the application. The single biggest difference was adding automated unit testing. What took 15-20 minutes to test in previous versions was taking 5 seconds.

I have to agree that the smaller team is a large factor in XP's success. I don't, however, think that we can lump large team with large system. A smaller team working more efficiently will be just as successful, if not more so. I saw that years before I ever heard of XP.

Dave...

Dave Rooney dave.rooney.no.spam@mayford.ca
Ottawa, Canada

Mon May 20 04:35:49 BST 2002
Anyone know Matt personally?
I'm just wondering if he's as arrogant and condescending in person as he comes across in this article. I'm neither a proponent or opponent of XP, but the tone of this article in no way lends credibility to what Matt is saying.

His tone implies that he's God's gift to programming, and all he is doing here is acting as a troll. FYI, a troll is someone who writes something inflammatory just to get reactions from others.

So any "dumb programmers" as Matt calls you, want to comment on what it's like to work with this guy? Based on this article alone, I wouldn't want to.

Jack Jack@sprat.com

Mon Jun 03 21:53:25 BST 2002
Yes, I have known Matt for years
Not arrogant,

That's my job.

A pleasure to work with.

Sorry you don't like the article.
Can't please all the people all the time.

Trying to project from an article to someone's
personality is a little difficult, as has
been shown from your innacurate appraisal of
his personality.

If you like his article hence he is a good guy.
If you don't hence he is bad.

Making personal comments isn't useful.

Whether he's a nice person, bad person, good
programmer, bad programmer, that doesn't change
the validity or otherwise of his comments.

Making "He probably kicks dogs and smells of poo"
kind of comments is just childish.

Dino.

Dino

Tue Jun 04 11:40:48 BST 2002
re: Anyone know Matt personally?
I for one take great offence to being called stupid.

an incompetent programmer

Tue Jun 04 13:12:42 BST 2002
"Trying to project from an article to someone's
personality is a little difficult, as has
been shown from your innacurate appraisal of
his personality.

If you like his article hence he is a good guy.
If you don't hence he is bad."

OK, so he's a good guy but a lousy writer. ;-)

My point was that he comes across as condescending and arrogant. You're right in that it's difficult to judge someone's character by reading what they write. Written text is always subject to misinterpretation, which is why the best authors write in a tone that is difficult to misconstrue.

I believe Matt could have gotten his points across without referring to most programmers as "dumb", for example. I highly doubt that Matt has even met, let alone worked with, "most programmers". He should have worded it as, "most programmers I've worked with are dumb."

Jack Jack@sprat.com

Thu Jun 06 14:49:11 BST 2002
Oh Lordy
"When pedants attack!"

So people can't say most anymore, without
saying "IMHO", "In my opinion".

What a flaccid and redundant request.

That's like bitching at someone for having
their own opinions and believing them.

Please forgive him for the crime of assuming
that the world can be modelled based on his experiences, but that's how most sapient life forms get on in life. Yes, it has risks, but if
we assume no patterns, no correlations, then we are barred from making any statements until the universe ends and we've done a total stock take.

"Most women have breasts", "Aaah, but you can't prove it". For fucks sake! I thought I'd heard the last of that kind of reasoning back in the playground.

Let him say "most", and we will let you think he
is arrogant. And both of you can carry a little error on your soul, as do us all.

He writes an important article about XP, and its dangers and you bitch about a turn of phrase.
Wood. Trees.

Dino

Sun Jun 09 02:15:44 BST 2002
Trying to reach Matt
Hello Matt,

I tried reaching you at matt@softwarereality.com. Unfortunately mail from my ISP to yours is being unaccountably bounced. I tried a previous address of yours at pipex.com, which is no longer valid.

This forum is the quickest way to reach you that I can think of.

Is there an alternate address I could use that is less likely to bounce mail from noos.net ? If so, please email me (laurent@bossavit.com) to let me know.

Thanks.


Laurent Bossavit laurent.sr@bossavit.com
Paris, France

Thu Jun 20 01:33:43 BST 2002
I have emailed Matt
Yes, his email provider seems to be sticking
in their broken anti-spam software, even though
they never asked his permission.


Dino

Thu Jun 20 23:31:33 BST 2002
We need pros and cons
It was good to see an evaluation of XP that doesn't sound like the cheerleading squad from my high school days. I've been trying to find information about XP but 90% of the info out there is reminiscient of a telemarketer's sales call: everything sounds so good but what's the catch? Mr. Stephens' evaluation of XP has helped confirm my instincts that there are some problems inherent in the XP methodology. All too often (especially in the IT industry) new ideas are implemented without the proper evaluation of the pros and the cons. The end result is that what was thought to be a miracle cure for everything turns out to be snake oil
ErikE edvalson@hotmail.com
MN, USA

Fri Jun 28 16:27:12 BST 2002
Invite
(In case mail isn't getting thru...)

Matt,

I will be in London on July 9-10, to chat with the Extreme Tuesday Club. Would you be available to meet me for a pint on that occasion ?

Laurent Bossavit laurent@bossavit.com
Paris, France

Wed Jul 03 23:00:56 BST 2002
refactoring
In my experience (also ten years; like you I'm a relative newbie) refactoring always pays dividends that more than repay the time spent on it. While it is true that time spent refactoring code that works is time that could be spent on some other problem, it is also true that the refactored code generally proves useful in another context almost immediately, resulting in a net time savings. You might argue that if enough upfront time had been spent designing the routine properly in the first place, the refactoring would not have been necessary. The insight behind XP, though, is that hindsight is always more accurate than foresight.



Bruce Tobin btobin@columbus.rr.com
Columbus, OH, USA

Fri Jul 05 14:41:32 BST 2002
Hindsight
> The insight behind XP, though, is that hindsight
> is always more accurate than foresight.

And the insight that XP people fail to grasp is that hindsight is more expensive then foresight.

Now there's the rub. If it wasn't the case then
we'd all leave everything till the last day of the project, and finish it all in a trice,
bathed in the warm glow of our gained wisdom.

Software dev, software change is NOT FRICTIONLESS.


Dino

Fri Jul 05 18:09:39 BST 2002
re: Hindsight
Dino writes:
> And the insight that XP people fail
> to grasp is that hindsight is more
> expensive then foresight.

I don't see how you can believe the XP practitioners fail to grasp this when practically all of the XP practices are designed to reduce the expense of using hindsight. You seem to think the people you're arguing with are idiots. Hint: they aren't.



Bruce Tobin btobin@columbus.rr.com

Sat Jul 06 16:28:30 BST 2002
Amateur
"Only amateurs try to come up with 'fancy' moves"

That is a fantastic conclusion. It is definately
the most effective and encompassing statement of
the article.

1) With insult, it strongly concludes the authors
thoughts about XP and the XP community.

2) It also defines the article itself, as a 'fancy' move.

I appreciate the time the author spent to learn
and present this information. Unfortunately, it
is stained by mud throwing and name calling. I
definately took this article with a "pinch of
salt". I will refrain from writing further because I am confused as to whether the author
was encouraging provocation with the insults he
needlessly included in the article.

Joel
Montreal, Canada

Tue Jul 09 04:31:15 BST 2002
Productive - Proactive comments
I read the list of comments with a strong distaste and confusion. It seems to me the whole point of a forum is to share ideas and thoughts.

Of course people must agree to disagree, but let's not get petty and Republican about this - ok cheap shot, but really mean-spirited comments like the cheap shot above only serve to fog the already complex issues we deal with everyday.

I for one have not been able to adopt or embrace XP, but at the same time after years of fighting with RUP I am definitely wanting a more agile and sensible process to work with. What this forum and other forums need to do is focus on how we can help each other instead of showing off how sarcastic and clever we can all sound.

Let's leave our egos at home -- that should be the first and most important point in adopting a development process - team building and team work, without which everything is going to be a struggle to achieve.

M


Anonymous person m@m.com
Salt Lake City, USA

Tue Jul 16 16:09:46 BST 2002
re: Productive - Proactive Comments
To Anonymous person m,

Come over to the dark side...er, I mean the XP mailing list at:
http://groups.yahoo.com/group/extremeprogramming/

Even Grady Booch posts there, and is quite up front about how he believes that XP and RUP can coexist.

Dave Rooney
Mayford Technologies
http://www.mayford.ca

Dave Rooney dave.rooney.no.spam@mayford.ca
Ottawa, Canada

Wed Jul 17 02:12:48 BST 2002
re: Productive - Proactive comments
I agree with you, Anonymous person m. A lot of people seem to have taken my criticism of XP very personally. One or two people have also confused the lively, humourous tone of the article with arrogance.

It seems that people are not "allowed" to stand up and say "I think something's wrong" (whether in a satirical or serious tone) without being flamed for their troubles.

It's a shame, because (as the opening paragraph at the top of this page hints), this forum could turn into a constructive discussion of what is really wrong with XP, how it could be fixed etc.

If that means first of all "fixing" whatever you feel is inaccurate in the article, then that's fine by me. Tell me what you think is wrong, just don't bother posting blanket dismissals or personal attacks that add more noise than signal to the discussion.

Anyway, the XP mailing list mentioned by Dave also makes for an entertaining and informative read.

Matt Stephens
London, England

Sun Jul 21 11:48:00 BST 2002
Where's the proof of concept?
Anyone here got any evidence that XP works? Apart from Dave Rooney (dave.rooney.no.spam@mayford.ca, posted
Wed May 15 17:20:15 BST 2002), has anyone here actually used XP? If I've missed it, I apologise, but I'm too lightweight to read any post over 5 lines. Just a pointer, here or offline, would be most helpful.

RA Cooper racooper@hampsters.fsnet.co.uk
Southampton, UK

Mon Jul 22 13:49:43 BST 2002
re: Where's the proof of concept?
I'm sure there are other examples, but the "flagship" XP project was C3, a payroll system for Chrysler, which was cancelled after four years of development.

The upward spiral ("we're going to replace their many payroll applications with a single application!") is described here:
http://www.c2.com/cgi/wiki?ChryslerComprehensiveCompensation

And the downward ebb ("uh, it was cancelled") is here:
http://www.c2.com/cgi/wiki?CthreeProjectTerminated

I'd be interested if anyone sees this as a potential problem with the on-site customer arrangement (where it's the "real" customer and not a proxy). The problem seems to be that the person who will be signing off the requirements and putting your payment cheque in the post is often different to the people (users, clerks, managers etc) who provide the actual requirements (and give some insight into the problems behind the requirements).

Matt Stephens
London, England

Mon Jul 22 20:50:04 BST 2002
re: Where's the proof of concept?
Have a look at:

1) http://www.c2.com/cgi/wiki?ExtremeProgrammingProjects

2) http://www.technologyreview.com/articles/wo_sherman071902.asp

3) http://www.salon.com/tech/feature/2002/05/29/extreme_programming/index.html

4) http://www.nwfusion.com/careers/2002/0128man.html

Or just go to Google:
http://www.google.com/search?as_q=articles&num=10&hl=en&ie=UTF-8&oe=UTF-8&btnG=Google+Search&as_epq=extreme+programming&as_oq=&as_eq=&lr=&as_
ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&safe=images

Dave Rooney
Mayford Technologies
http://www.mayford.ca

Dave Rooney dave.rooney.no.spam@mayford.ca
Ottawa, Canada

Tue Jul 23 13:46:50 BST 2002
XP and J2EE are at odds
Early on in learning J2EE I found that Sun was pushing a developer "role" approach: app deployer, server side developer ( ejb ), client developer ( servlet ), UI developer ( JSP ). Even in many pattern discussions the idea is to create clean seperation between software layers so that entirely different groups can perform the work without intense interaction. In other words,you'd have two or three people develope EJB's used by the web tier team.

I've just begun XP and it seems to be at odds with this, developers will create the servlets, ejbs, and even touch the db schema in a days work, without a strong design of the api's between each tier ( web, enterprise, client). I'm not making any strong statement either way about which one is better, just noticed that they seem to be going in opposite directions, and that is a problem if you're attempting to do XP on a large J2EE project.

new to xp anon@anon.com
TX, US

Sat Aug 31 17:17:54 BST 2002
Hi,

"The case against XP" is the best article I read in a long time about software development.
I think most of the problems in SWD process origin from a chaotic approach such as xp.
Leaving everything to pure chance, documenting nothing, designing nothing and hoping for the best are things that could only be done in the software industry.
No other industry acts like this. Nor should it.

I especially liked the part about the code review. I can't agree more. I also addressed this issue in my article: http://sharpdevelopment.esmartweb.com/CodeReview/Pandora/Pandora.htm

Lidor

Visit: http://SharpDevelopment.eSmartWeb.com

Lidor SharpDevelopment@eSmartWeb.com
-, Israel

Sat Sep 21 18:15:02 BST 2002
extremedayjob.tripod.com/totheextreme
All you need know about extreme job sports
Bill Lumberg

Mon Sep 30 19:33:57 BST 2002
Pair Programming for Training New-Hires?
My organization practices neither XP or (specifically) pair programming as a rule, but I'm trying to find ways to have new-hires come up to speed faster. I'd like to implement a pilot program to put fairly inexperienced programmers into a pair programming environment for their first couple of assignments. Does anyone out there have any personal experience, anecdotes, horror stories, etc., as to what I might expect? Do you think this is a bad idea, or something worth trying?
Mark Poff Mark.Poff-1@ksc.nasa.gov
Kennedy Space Center, USA

Mon Oct 14 12:31:41 BST 2002
Re: Pair Programming for Training New-Hires?
I think pair programming for new hires is worthwile to pursue.
Early on in my carrer we had to pair up to do programming(Not an XP experiment but a shortage of computers was the driving force ;)). I would say that it was extremely helpful.
One thing to keep in mind is that make sure the 2 programmers are more or less on the same skill level.
The benefits as I see
-It will help the programmers to bond and teach them to work together.
-It will help instill some collective responsibilty in the new hires.
-Such an exercise will also identify future prima donnas(SmartAss guys who refuse to work in a team and believe they are God's gift to mankind).

We were able to work reasonably well for about a month. After that individual aspirations started taking priority. Most of us wanted to work seperately to establish our own identity as programmers. Fortunately the computers arrived 6 weeks into this experiment and we were able to continue working together as a team. Feel free to e-mail me if you have any questions.
HTH
Ravi.

Ravi V rsv29 at yahoo.com
Alpharetta GA, USA

Wed Oct 23 23:46:11 BST 2002
how to xp
Our group has just started xp recently. I have some concerns and i'd like to see if any of you can help.
1. onsite expert. this is a big issue, as no requirement doc is supposed to be produced. first, the expert really has play three roles: end user, domain expert and decision maker. the last two roles are almost always belong to two people. we'd done a much better job without xp if we could find somebody who can take on all three roles at the same time, and on site, day in and day out.
2. requirement. the question is how is the final work get accepted without a requirement. if the final product satisfy EVERYBODy, it's fine. Now if it's not, who's responsible?
3. design. our practice is to carve the work need to be done into small chunks that would fit into a 2-3 days work. But if there is no design, how is that done? in the end, we basically had a hands-up, hands-down to decide the amount of hours needed. It's hard to see how accurate since the work is captured as ideal time and we don't really track what you've spent on overhead.

I'll stop at this point today.

shaohua

shaohua ma shaohuam@yahoo.ca
san jose, ca, usa

Wed Nov 13 22:58:57 GMT 2002

 

Page 1 (earliest)

Page 2

Page 3

Page 4


<< Back to XP Central


<< Back to Software Reality


All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright Đ 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.