|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 28
Messages: 28
Messages: 28
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tech Talk: Vincent Massol on Agile Offshore Methodologies
In this interview, Vincent discusses how agile methodologies can be used in offshore, collaborative development. He looks at various communication tools used between projects, how two teams apply continuous integration using Maven and plugins such as CheckStyle, DBunit, and Clover. He also looks at how Cactus and Mock Objects can be used for testing and integration.
Watch Vincent Massol's Interview
|
|
|
Message #106098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk: Vincent Massol on Agile Offshore Methodologies
I've been working for the last 6 month on a project in an Agile offshore fashion.
And also, what was interesting about that project is that open-source is used EVERYWHERE: from the DB to all the frameworks and tools.
We were using intensively CVS (remote connection via SSH), Yahoo Messenger and Scarab (for issue tracking system) for communication.
I have to admit that a tool like scarab was probably the most important tool for us bc it help us to keep track of ALL the informations & documents.
And there is Ant, but Im seriously thinking about moving to Maven.
BTW, here the result of that project:
http://www.americandiamond.com
|
|
|
Message #106105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agile Offshore - sounds like an OxyMoron
> If you want to be Agile, don't Offshore!
Yes, agile and offshore are too big trends that appear to be in conflict with each other. It is pretty clear that going offshore is going to make a project less agile.
However, the issue becomes more interesting if you were to claim, "If you want to go offshore, don't be agile". This is more open to debate. Some companies are going offshore, like it or not. There are many reasons why a company go offshore, e.g. cutting costs, appeasing shareholders, moving closer to clients or other business units. The point is, these are higher-level issues which are unlikely to be overridden by considerations of the appropriate development process.
So having decided to go offshore, what is the best process to use? With developers removed from the business and/or distributed themselves, a conventional document-driven process seems tempting. But it will be interesting to see how approaches as in the interview, and in "distributed XP" balance things.
What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.
|
|
|
Message #106107
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it can work
I was team lead on a short project that developing a stockmarket trading game using all open source tools and a somewhat agile method. (not agile enough in my opinion). the team was geographically dispersed, and I think this causes the communication tools (messenger, email, bug track system, task tracking, project planning etc) and their use to become vitally important.
One thing i found was that it was difficult to get good feedback from developers if they didn't want to give it to you. when they sit next to you it's easy to see when they are struggling with something. but when they are remote, you don't see the body language so easily and sometimes you don't pick up on things quick enough. it is people's natural instinct to tell you everything's ok and not to admit to lacking understanding or being at an impasse because they feel it is an admission of failure. whereas in a normal team you can pick this up without having to be told, "i'm not sure what's going on".
will there ever be a transcript of this? my work won't let streams in through the firewall.
but having experienced doing it i'm not going to knee-jerk the whole idea, unlike some others.
|
|
|
Message #106108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agile Offshore - sounds like an OxyMoron
> What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.
communication tools are of central importance. if the tools or their use, fail, the whole thing falls in a screaming heap.
regs
scot.
|
|
|
Message #106119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agile Offshore - sounds like an OxyMoron
"If you want to be Agile, don't Offshore!"
"Offshore" is not just outsourcing a project to talented programmers in India, China, Russia or France where people earn work for "peanuts". France is a joke by the way, they're not really talented or programmers :-).
Wouldn't life be great if we could all run everything from a single team working in the same room? Agile heaven!
Sadly though we don't always have that luxury, it's not just outsourcing that moves things offshore but also companies with worldwide offices, and companies that have partnered with another in another country. Even development that needs to take place partly on a customer site in another country is still technically offshore.
So, having pointed out a few of many possible "legitimate" offshore situations it would then seem equally legitimate to try to develop them as agilely as possible.
We have developers in three different countries covering 7 hours of time zone. We use CruiseControl and Maven to manage builds, CVS over SSH for source. SSH for programmers to log into various different machines to run tests since we have client hardware to run performance tests but not in every location.
We use Tomcat (5) for Cruiscontrol results, Maven sites and Jira which we use for issue and bug management. Jira is the "dog's bollocks" as we say in England, all of our customers use it for product feedback. MoinMoin Wiki for documentation, and Jive for project reporting and customer comments.
Good stuff Vincent, shame about the accent though :-)
|
|
|
Message #106127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tell Your Manager Offshoring Requires CMM Level 5
I wonder about the naivity of programmers these days. More often, the question is not how can we make offshoring successful but rather what can we do to sabotage it.
Much like religion, Agile methodology can be used to dupe workers into teamwork, even when it is not in their best interest.
In the old days, programmers use to joke about writing nasty, undocumented code to retain job security. Well, it is now a real political issue. Offshoring is not a fate we should just learn to accept. Certainly, the fat cats would like us to think so. However, it is something we have control over, as long as we recognize that the many opportunities available for political action.
Now that unions have become useless vestiges of the past, we have to resort to subtler means of coercion than going on strike. We need a methodology that is designed to protect the worker from corporate greed, one that embraces deceptive communication tactics, e.g. writing gobs of documentation that appear to transfer knowledge generously but really provide useless fluff with sutble gaps and misleading inaccuracies.
If you think the company you work for is your friend, take another look at the employment agreement you probably signed, the one that strips away your right to sue or retain copyrights to anything you write outside of work, even a love poem to your girlfiend.
Also, consider the way many companies maximize their profits not by producing great software but by selling "maintenance" contracts for correcting flaws in crappy software sold for pennies. Not so different from Mafia protection, I would say.
I ask all you naive programmers, should we not treat these companies any differently than how they treat their customers and their employees?
I happen to like Agile methodology, but I just don't feel that it is appropriate in adversarial situations like those that involve American workers getting screwed by offshoring contracts.
In fact, I would suggest that we convince management that reaching CMM level 5 is the only way to make offshoring successful. They'd probably fall for that. Let the offshoring projects get bogged down in bureacracy. Let's keep Agile methodology for times where we want to succeed!
|
|
|
Message #106147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MoinMoin
> MoinMoin Wiki for documentation
LOL, nice name. Moin, moin is only used where I live here in the north but we say it all the day long.
Moin, moin!
-- Andreas
|
|
|
Message #106152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Agile Offshore - sounds like an OxyMoron
> What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.
Hi Michael,
Yes, you're right. The practices are very similar as in non-distributed mode but there are some tuning required. Some examples:
- Even though we are using short iterations (2 weeks), we need to have the use cases for those iterations very well defined (i.e. in UML for example). this is especially true if the business analysis has been done centrally (i.e. not by the persons doing the development). In XP, you might have meetings to spread verbally the knowledge and only draw the hard cases on some boards. This is not really possible with offshore.
- Frequent travels are required. We have lots of exchanges on both sides.
- Most importantly, the teams must have a local coach/project lead. You can't expect to manage directly individual people through the wire. It's not effective and leads to confusion and it emphasizes communication issues due to cultural differences.
That said, I've found that agile processes help a lot to attenuate the problems due to distance. This is quite normal as agile processes emphasizes constant feedbacks to reduce risks. Whereas succeeding an onsite project may not necessarily require applying agile techniques, I've found that agile methodologies are really useful (I hesitate to say mandatory :-)) for offshore project. Of course to be precise we would need to define what I mean by agile methodologies. I probably only use a subset of all possible practices. My emphasis is on continuous integration and constant feedback.
Thanks
-Vincent
|
|
|
Message #106166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tell Your Manager Offshoring Requires CMM Level 5
<none none>
In fact, I would suggest that we convince management that reaching CMM level 5 is the only way to make offshoring successful. They'd probably fall for that. Let the offshoring projects get bogged down in bureacracy. Let's keep Agile methodology for times where we want to succeed!
<none none/>
He, he !! Excelent idea !
Also, take a look :
http://www.nytimes.com/2004/01/06/opinion/06SCHU.html
BTW, im from Brazil. We can take some projects too and we are waiting for the promisse of "Free Trade Commerce". Then may be we could sell some orange juice, airplanes, and off course, some bananas too ! :)
Work in IT areas or wharever product you can imagine isn't a birthright so let´s start to finally change the way we think the world.
Rodolfo
|
|
|
Message #106171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MoinMoin
They say it in Luxembourg too, the other funny one was "Multzite" or something like that. I heard it a lot when I lived in Stuttgart.
MoinMoin is a damn good Wiki, really easy to set up either stand-alone or with a web server.
-John-
|
|
|
Message #106174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The only way to offshore is to Agile!
>> If you want to be Agile, don't Offshore!
But if you DO offshore, make it agile! (if you want it to work)
In my mind one of the biggest risks of off-shore/outsourced development is making sure that you get what you want, and making sure that it will work reliably, and that it will be maintainable. Its too easy (due to above-mentioned limitations of communication) for them to develop what THEY think you require, slap together a mess that you wont be able to maintain.
Frequent Release Cycles - you NEED to know if they are going off-track - they need the feedback to help them understand your problem.
Continuous Integration - you need to detect integration problems immediately.
Testing - you want to have some measure of reliability - and you want the tests to be the "ultimate" documentation. You want to be able to maintain the system, so you want to have the safetly-net of tests and you want to have the simplicity that TDD brings about.
Planning - you want to prioritise the development so that you get the most important stuff first (so you can be confident they know what they are doing - and because only you know what will provide immediate business benefit.
-Nick
|
|
|
Message #106175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
It's funny to read about agile off-shore methodologies when we have been applying them for more than two years. 90% of the tools and practices described by Vincent are EXACTLY the some ones used by us. It seems to be the right (and only?) way to success.
The biggest challenge was not the technical challenge, it was the management of remote teams. Management of people from different cultures (China, Canada, India, USA and Spain), from different time zones (9 hours of difference between Vancouver and Madrid!) really broke my nerves!
But Vincent, please, don't tell me communication is easy with all these new tools, because I don't care about wiki, instant messaging, video conferences... pick up the receiver and dial up, that's all! The problem is that... I almost went to bed when the guys in Vancouver started working!
Time zones is the biggest problem of offshore development. South Americans... you should get a lot of offshore development from USA due to this problem!
I know this problem very well, because I start to work after 10:00AM in order to have a couple of extra hours of overlapping with my colleagues in California.
Regards
Diego
|
|
|
Message #106180
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Communication, communication!!!
Hi Diego,
> The biggest challenge was not the technical challenge, it was the management of remote teams. Management of people from different cultures (China, Canada, India, USA and Spain), from different time zones (9 hours of difference between Vancouver and Madrid!) really broke my nerves!
> But Vincent, please, don't tell me communication is easy with all these new tools, because I don't care about wiki, instant messaging, video conferences... pick up the receiver and dial up, that's all! The problem is that... I almost went to bed when the guys in Vancouver started working!
[snip]
I've never said it was easy, have I? :-) What I'm saying is that using agile practices makes it easier (see Nick's post which is exactly to the point). I agree that cultural gap is hard and only improves with experience on both sides (what I call offshore-ability of people, which has to be groomed and developed). BTW, this is one of the reason why using a good Pivotal Provider with experience helps (you can also discover it to yourself but it'll take longer).
WRT timezones, I haven't much experience as I've been working on 2 big offshore projects for the past 2.5 years and they were between Europe and India (only 4.5 hours of time differences). It isn't at all a problem for us. The offshore team is coming to work late and leaving late which gives us a good overlap (there's only about 2 hours of isolation). I'm sure it's harder with greater timezones.
WRT the "new" tools: on our project people are using chat about 80% of the time they're communicating. It really helps. Picking the phone is good from time to time but cannot be done all the time, at every minutes, for different reasons:
- it is expensive
- the line quality is not always good and it is sometimes hard to understand the other person clearly (especially if they speak a language that is not your native language)
- but more importantly, it is *disruptive*. The person at the other end has to answer right away even if he/she's doing something else. With chat, it doesn't happen.
I'm not saying you shouldn't pick up your phone. We do pick it up roughly twice a week per person but the rest of the time we use chat/email/wiki/cvs/jira/trips/etc.
Thanks
-Vincent
|
|
|
Message #106189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Communication, communication!!!
Actually, it was like a pain in the *** when I started with daily conference calls with chinese developers, with very poor english, we decided to start using the email. Since the development teams almost never overlapped, instant messaging and chat could not be applied. I'm working in a new project, and instant messaging really works, but the 'voice language', just like the body language, it is really important. Normally, messages written by non native english speakers sounds rude, even though the intention is not to be aggresive.
Everybody knows colleagues at work that write very aggresively (and copying to the top management...), and when you meet them, everything runs smoothly. Sometimes is so easy to screw up everything just with a wrong adjective in an email...
Besides, you can be critic with your boss by phone, but not in an email. :-)
Good Interview, BTW
Diego
|
|
|
Message #106195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
We found a lot of the countries east of Europe (as far as India) will often delay their day to coincide with their parent company. I think there's a greater problem in the US due simply to the fact that they’re isolated in a thin slice of time zones.
The key is constant and regular communication with continuous integration; they need to get used to a quick response from an ICQ message whether you're downstairs or 2000 miles away. When they check something in that breaks the build everyone needs to know within minutes, preferably seconds. Working long hours is often needed to cover the larger gaps though, i.e. West Coast US from Europe.
Anyway, you guys in the US can stop worrying about outsourcing; the US$ is becoming so week that you won't be able to afford places like India, China etc. They're going to start re-outsourcing the work we Europeans give them back to the US to save money. :-)
-John-
|
|
|
Message #106204
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
John Davies: We found a lot of the countries east of Europe (as far as India) will often delay their day to coincide with their parent company. I think there's a greater problem in the US due simply to the fact that they’re isolated in a thin slice of time zones.
I always thought that isolation was measured as the number of time zones away from New York City you find yourself.
John Davies: Anyway, you guys in the US can stop worrying about outsourcing; the US$ is becoming so week that you won't be able to afford places like India, China etc. They're going to start re-outsourcing the work we Europeans give them back to the US to save money. :-)
When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :)).
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!
|
|
|
Message #106213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Communication, communication!!!
[snip]
> Everybody knows colleagues at work that write very aggresively (and copying to the top management...), and when you meet them, everything runs smoothly. Sometimes is so easy to screw up everything just with a wrong adjective in an email...
[snip]
You're 100% right. This is very often a cause of miscommunication which escalates in unnecessary problems. Whenever someone starts working for the first time with someone else, we always try to set up a face to face meeting (travel). We've found that everything thereafter works smoothly. Whenever we have have not done this, it was much more difficult.
-Vincent
|
|
|
Message #106217
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tech Talk: Vincent Massol on Agile Offshore Methodologies
Well these theories are floating since some time.
Where they become effective is one demonstrated success story. In my experience
it is important for professionals to apply apt commansence and customize these
practices to suite the solution/scenario.
I have seen couple of products where architect/leads applied agile mechanics
to just apply them purpose and they failed.
One needs to understand, customize, run a proof of concept then apply.
Hari.
|
|
|
Message #106222
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
"When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :))."
You mean you have hot water now ? :))
Yann
|
|
|
Message #106240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agile and Rup and offshoring...
I am not sure we should look at the traditional models and Agile as mutually exclusive.
In my experience I have found the following to work in offshore development
1. Try to really finalize and freeze the requirements in Inception and Elaboration phases and then manage the changes via Change Requests(small purchase orders).
Also , Document every small little requirement (stuff like button placement , Text formatting , etc)
This is probably the traditional approach of doing things but I think it works in context with offshore development . Generally the offshore company is doing a Fixed Bid project and if you do not have signed confirmed requirements (documented to the level to a very detailed level) you are invariably going to run into conflicts.
2. Some of the practices from agile are like to gospel to offshore development. "Continuous Intigration" . The importance of this I think is more in offshore development then in one location because the intigration solves to communication problem to some extent.
3. "Continuos Feedback" . "Continuous Intigration" leads to continuous feedback and hence faster turn around cycles.
|
|
|
Message #106241
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
Cameron: I always thought that isolation was measured as the number of time zones away from New York City you find yourself.
So Bogata isn't isolated but London is? :-) The point was that you're a long way from most of the "usual" outsourcing destinations.
I've no idea why you'd want water coming out of your faucets, we use taps. Most of the double tap systems were put in while you guys were still burning witches, I've not seen one for decades.
:-)
Peace to you too!
-John-
|
|
|
Message #106242
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication is the big challenge
As vincent mentioned it is a bigger problem when you are working between time zones that do not have an overlap . Eg California and India.
The following practices have made my life a bit better (I certainly dont imply normal).
1. Schedule a Meeting involving (CHAT / Phone and / Netmeeting) daily at an odd hour for atleast 1/2 hour. Cant avoid the odd hour because there is no overlap.
2. Prepare for this meeting in advance everyday and do not prolong discussions on a topic for more than 5-10 minutes. I mean do not brain storm on the call.
3. All Brainstorming and discussions should be done via Text (Email/ Wiki/ message boards)
4. have a code of conduct for posting messages on various internal message based forums. (like PM issues / Architecture / Business requirements).
5. Learn from the way people communicate on other open source projects like hibernate , etc
|
|
|
Message #106486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Communication, communication!!!
> When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :)).
Do worry, it is coming. I half overheard a news item that the new building code will require new bathrooms to have combined taps so as to avoid scalding. Wusses.
The change is probably a consequence of Princess Margaret seriously scalding her feet half a decade ago.
|
|
|
Message #108615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RAD and ODC
Some ODC's usually adopt what they call 'RAD'. We usually don't generate code ( like MDA ) or do anything special. We take the easy way out 8-\ by spending 24 hours in the office and delivering something very rapidly. There is no design
or proper architecture work done. Bugs crawl all over us later on and again we
deal with that by living in the office.
We started looking at RUP. Can't RUP be agile enough for ODC's ?
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
