aspose file tools*
The moose likes Agile and Other Processes and the fly likes XP for offshore development ... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "XP for offshore development ..." Watch "XP for offshore development ..." New topic
Author

XP for offshore development ...

Varun Narula
Ranch Hand

Joined: Nov 19, 2001
Posts: 90
How effective would use of XP be for offshore projects where client interaction is strictly through the Net in form of email, reports and chat?


There are only 10 types of people in this world; those who understand binary and those who dont<p>Varun Narula <br />SCJP, SCWCD, IBM-486 (UML)
Tiger Scott
Ranch Hand

Joined: Mar 01, 2001
Posts: 223
XP does require heavy invlovement of clients on a day-to-day basis. XP may not be the most suited methodoloy for offshore. Offshore already has several issues to contend with. A more formal methodology like RUP would be much more suited.
HTH
Sanjay
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Actually I don't quite agree that it cant be done. It will require more work but it could be done.
Let me explain :-
The main strength of offshore development is that its gets done across different time-zones (my opinion).
Lets take as example the company I work for. A lot of our development work gets done in India. We are located in the Netherlands. There is a very short period when our work-times overlap but mostly when we relax/sleep , they work and vice versa.
Now what could be done is that our offshore team allocates a member or members of their team to represent the clients. The ideal situation would be that the Indian team send their client representatives over for a few weeks to see how the clients they represent work and what they actually do.
They then go back and play their "acting roles". Transcripts get made off the mayor sessions between the client and developers and sent over to the Netherlands, at the end of the working day in India. The real clients then review the transcripts and pass their comments back to the "actors". These actors will then get the comments at the start of the next day and adapt their roles accordingly for the days sessions.
Gradually these actors will become better at representing the clients they "play"
Now pse note this is an idea I've been walking around with for awhile and nothing else, but remember ideas create solutions
[ February 19, 2002: Message edited by: Johannes de Jong ]
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
Originally posted by Johannes de Jong:
Now what could be done is that our offshore team allocates a member or members of their team to represent the clients.

Proxy pattern!
Varun Narula
Ranch Hand

Joined: Nov 19, 2001
Posts: 90
Johannes..
I understand your concept of a team member playing the client's role - but to what extent can the team member become the 'client'...
how would these issues be resolved - requirements change, quality and implementation ?
Further, how much would the real client interact with his 'proxy' or the development team ??
Any answers ?
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
But to what extent can the team member become the 'client'...
The team member never becomes the client.
how would these issues be resolved - requirements change, quality and implementation ?
Solid communication rules between the "actor" and the client he represents can overcome this. I'd have to give it some more though how this will work though. remember its only an idea
Further, how much would the real client interact with his 'proxy' or the development team ??
Daily via e-mail and at least once a week face-to-face via webcam. Off course real meetings will have to take place from time to time as well.
Doug Wang
Ranch Hand

Joined: Oct 05, 2001
Posts: 445
Originally posted by Mapraputa Is:

Proxy pattern!

Hi Map,
Are you joking?


Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Varun Narula
I think this statement By Alan Cooper
"Yeah, except with a slight difference. You would coach the development team and I would coach the interaction design team, and the interaction design team would act as a bridge between the customer and the developers. The thing is, the customer is just not going be imaginative and will not visualize a "bigger thoughts"; their "bigger thoughts" are going to be very small."
The "interaction design team" he is talking about could be seen as the type of role for the "actor" I had in mind.
For the full text see Kent Beck vs. Alan Cooper
[ February 22, 2002: Message edited by: Johannes de Jong ]
Varun Narula
Ranch Hand

Joined: Nov 19, 2001
Posts: 90
The "interaction team" could also be a third party who subcontracts the work further on ...
These subcontractors themselves do not do any development but act as a 'bridge' betweent the two. of course he has his to be paid his fees for these services.
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
I like that , great idea
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
These subcontractors themselves do not do any development but act as a 'bridge' betweent the two.
This would really worry me. It looks much too close to one of the biggest development anti-patterns I've seen.
The problem is that if someone (or some team) is a required part of the development process, but produces no testable output, how can you ever know if what they are doing is good or bad. If you can't tell if their work is good or bad, you can't ever learn from it and improve it.
For me this is one of the key points about the modern crop of programmer-focussed methodologies, and their disdain for UML, lengthy use-case documents, up-front design teams and so on. Teams whose output cannot be tested have neither incentive nor mechanism to ensure they get it right. If you eliminate such teams from your process, and instead go direct from customer (tested by product sales, business success, client complaints etc.) to programmer (tested by the your software test process, customer fault reports etc.) All stages of the process can learn and improve.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
Frank,
I see where you're coming from. One thing I like to do to make sure that things like UML diagrams and use cases are correct (as correct as possible) is to have the people doing that work go on and develop the code. If they don't get the up front stuff right then they've made more work for themselves. I look at being able to write code as the reward for having to produce the documentation. I mean, would you rather code or write use cases? It may not be a perfect solution but it does provide some motivation.
John


The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I may be a soured by working with bloated corporates, but I encounter a lot of people who would far rather waffle in meetings, pontificate at a whiteboard or produce miles of paper than cut a single line of code. Sometimes I think they prefer this because of the lack of accountability, rather than the applicability of their skills.
Someone may disagree with your design or your document or your presentation, but that just opens the door to more fun discussions and more untestable work. If what you produce can't be tested, then no one can ever definitively say that what you have done is wrong or right.
So when things do go wrong, the blame "rolls downhill" until it finds something which can be tested. Whack the programmers with a big stick, withhold bonuses from the sales guys; it can't be the fault of our brilliant "designers" and crack "requirements" team that the product is crap
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
Hmm, you've obviously experienced this first hand.
However, I've never been at a company where the sales guys have had their bonuses withheld or cut.
I've met my share of people, mainly "senior" software people, who don't want to write code. I do my best to make sure they're not involved in my projects. Stating out front the "You design it, you code it" rule helps. (Maybe I can call this a pattern? "No Throwing Things Over the Wall"?)
How can you design if you don't keep up-to-date on what you can do with code? Sorry, I feel a rant coming on so I'll just stop and say "I know what you mean." I've spent most of my career in aerospace which (usually) requires lots of documentation. I just try to make the best of the situation.
John
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by John Wetherbie:
One thing I like to do to make sure that things like UML diagrams and use cases are correct (as correct as possible) [...]

What do you mean by "correct"?
In his book Alistair makes the point that asking for "as perfect as possible" documentation will waste a lot of effort. Instead he motivates to ask for "just enough" documents to let the team effectively communicate, making as much use of more broadband communication channels (like face-to-case communication, video etc.) as possible.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
Correct in the sense that they accurately reflect how the system works, the design of a class, or the interaction between objects without large amounts of rework. I personally find that producing lots of documentation is not good but there are lots of places that require you to do this. So if you have to produce documentation try to structure things such that the documents do have meaning and are as useful as possible.
Some projects that I am familiar with require that the code and documentation match up at the end. So try to get as close to what the code will look like so you reduce the amount of effort keeping things in synch.
I think I'm talking about "as perfect as possible" too, it's just that what has been specified "as possible" has been set pretty high.
John
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by John Wetherbie:
[...]I personally find that producing lots of documentation is not good but there are lots of places that require you to do this.

"Required" in a technical or in a political sense?

Some projects that I am familiar with require that the code and documentation match up at the end. So try to get as close to what the code will look like so you reduce the amount of effort keeping things in synch.

Depending on the motivation of producing the documentation, it could be an alternative to produce it after the code has stabilized - towards the end of the project.
Kind Regards, Ilja
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1449
There are political and technical reasons but the political, at least in my opinion, outweigh the technical. The customer says they want these docs. You could make an argument that they aren't necessary, etc. but then they will most likely 1) ignore you or 2) fire you.
To a certain extent this is OK as long as you can point out the costs. The big cost containment aspect of XP from what I can tell is that you have short cycles and at the end the customer sees what they paid for. If you can do the same thing with analysis products maybe you can change their mind. (Recall, though, that the context of this discussion is software projects in the aerospace industry. The customer, usually a government or large international org, like INTELSAT, don't change very easily.)
Producing documentation towards the end is an interesting idea and it certainly happens with user guides, etc. From what I can tell organizations that want lots of artifacts up front want you to prove that you can do the job before you actually prove you can do the job (That is, before you produce a good working system within budget and on schedule.). So if you do a good job in analysis and design (and how do you measure that, going back to Frank's point) you'll do a good job producing and testing the software. There seems to be a disconnect in that thinking but that seems to be the appraoch taken on lots of projects.
John
Joe Gilvary
Ranch Hand

Joined: May 11, 2001
Posts: 152
A technical reason to have some accurate documents
is so that you can ramp up new development staff
more quickly.
I reviewed a deliverable for one agency that was
supposed to include the required documentation,
including UML diagrams. What they got was a Rose
reverse engineered class model. About as useful as
Javadoc with no developer comments.
On another project I found no documentation at
all. I was there two weeks and then left for a
previously scheduled vacation. I returned to find
that I was to be the lead on the backend EJBs two
weeks later. I can tell you I would have been
delighted to have documentation then. I spent
my time with the departing EJB lead creating the
documentation as my means of learning the system.
Then I maintained it as the system evolved. When
they brought the next person on a couple months
later, I could show her how the components
interacted.
Simply keeping Javadoc up to date for the methods
and variables in the classes can be a tremendous help,
and really not that big a burden. I'm a true believer
in up to date technical documentation now.
Thanks,
Joe
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: XP for offshore development ...