Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Which one?

 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which of the process is best one? How do we choose? :roll:
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From which processes? For what purpose?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Choosing a process is a very difficult task. It depends on many variables: size of the team, experience of the team, nature of the project (space shuttle software will be written differently from the next cool game), distribution of the team, goal of the project - and political restrictions.
Why do you ask?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I often recommend Alistair Cockburn's Agile Software Development book. He gives a survey of a variety of methods and talks about how to choose one for a given project. He has great credentials and treats different ideas very fairly. He has some books and papers on his own Crystal methods which bring together a lot of good ideas, again with guidelines to fit the right process to the right project.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, a great book.
"Questioning Extreme Programming" also has four chapters on the topic, discussing the different goals of agile and non-agile processes and how to choose between them.
 
Avi Nash
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I want to know following things about using Agile/XP methodology for a project:
1. Since in this methodology there are no documents or or very minimal documents maintained, does this not affect if a developer leaves the project/company in the middle of the project?
2. This methodology is suited for projects or what size and teams of what size?
3. Also this methodology requires only very experiences and fast programmers, right?
thx
Avinash
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Since in this methodology there are no documents or or very minimal documents maintained, does this not affect if a developer leaves the project/company in the middle of the project?
XP tackles this "bus factor" via collective code ownership -- all production code should be produced in pairs, and people are encouraged to sign up for different tasks (i.e. avoiding unnecessary specialization within the team).
2. This methodology is suited for projects or what size and teams of what size?
Most recommend less than 12, 20 is doable with the right coach, and I've heard of successful implementations of even around 40 (needs serious customization and should not be attempted lightly). However, The XP for a staff of 5 is probably much different from the XP for 40.
3. Also this methodology requires only very experiences and fast programmers, right?
No, just disciplined programmers. Of course better programmers produce better results, (almost) regardless of the process used, but it's not a mandate that an XP team should be very experienced.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Avi Nash:
1. Since in this methodology there are no documents or or very minimal documents maintained, does this not affect if a developer leaves the project/company in the middle of the project?

Agile processes produce all the documents you need (anything else would be silly). They try to *reduce the needs* for documents in different ways:
- making more use of hotter forms of communication, such as face-to-face,
- making existing documentation more public (for example by having diagrams on a white board instead of burried under a pile of other documents)
- reducing the need for documenting the code by improving expressiveness of the code itself, and
- last but not least, critically observing wether a document really is needed and for how long.
2. This methodology is suited for projects or what size and teams of what size?

XP is best suited for teams that fit into one room. Beginners are adviced to use it for up to a dozen developers, but experienced coaches are known to effectively use it on teams above two dozen.
Agile processes can generally be used on bigger projects - for example, Alistair Cockburn's Crystal Methodology Family is suited for teams above several hundred developers.
3. Also this methodology requires only very experiences and fast programmers, right?

Wrong. What makes you think so?
 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Choosing a process is a very difficult task. It depends on many variables: size of the team, experience of the team, nature of the project (space shuttle software will be written differently from the next cool game), distribution of the team, goal of the project - and political restrictions.
Why do you ask?

Let us say that the team does not have much of experience.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Talking in terms "Cockburn levels" (to characterize a bit: 1 = newbie learning the "rules", 2 = pro learning to customize, 3 = guru not even thinking about it), a team full of level 1 developers should probably pick a process with explicit guidance and more rigor (to compensate the lack of skill for customizing a process to a situation).
Cockburn's Methodology Per Project article might be something you'd be interested in. It discusses the issues needed to be considered when choosing a process.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Talking in terms "Cockburn levels" (to characterize a bit: 1 = newbie learning the "rules", 2 = pro learning to customize, 3 = guru not even thinking about it), a team full of level 1 developers should probably pick a process with explicit guidance and more rigor (to compensate the lack of skill for customizing a process to a situation).

I agree. It would also be good to give them as much and early feedback on how they are doing as possible. In my humble opinion, XP probably would be a good fit, as it has both properties (being very specific about practices and providing lots of feedback).
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pradeep Bhat:
Which of the process is best one? How do we choose? :roll:


This is a topic I've tackled a few times. Check out:
http://www.agiledata.org/essays/differentStrategies.html
http://www.sdmagazine.com/documents/s=8958/sdm0312h/sdm0312h.html
You will likely discover that you need to mix and match, but do so intelligently, and that you need to tailor the process to meet your needs.
- Scott
 
Avi Nash
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Lasse and Ilja. I went through the site(s).
I have one more question. I want to know how the agile techniques are used for a maintenance and enhancement kind of projects.
-Avinash
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Avi Nash:
I want to know how the agile techniques are used for a maintenance and enhancement kind of projects.
There shouldn't be that many differences in the routines -- you still work in iterations (except for "emergency fixes", of course) and after every iteration you have to have a production-quality deployable. You get early feedback as soon as you deploy (well, in the case of bug fixes, you might hope that you don't get that feedback...).
The tricky part is probably doing TDD and automated testing, if applicable to the particular agile method. So, you've got some legacy code, possibly without any unit tests, nor acceptance tests. If you're lucky, you can try to keep your new development separate from the old codebase and keep the house clean "this side of the fence". If you can't do that (and this is the typical case), you have to refactor the legacy code in order to facilitate testing what you add or change in the codebase.
I think you should head out to the XP Yahoo Group and read this thread for some ideas and experiences regarding legacy code and XP.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Avi Nash:
Thanks Lasse and Ilja. I went through the site(s).
I have one more question. I want to know how the agile techniques are used for a maintenance and enhancement kind of projects.

An XP project actually is in enhancement/maintenance mode since iteration two! Seriously, the output of the first iteration is a fully functional system with the highest priority functionality. After that, everything the team does is maintaining and enhancing an existing system.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right! For some reason I was thinking only about legacy projects where the existing code hasn't been designed with testability in mind and which doesn't have unit tests...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Right! For some reason I was thinking only about legacy projects where the existing code hasn't been designed with testability in mind and which doesn't have unit tests...

Well, probably because it is the more common case...
But in that respect, maintaining a project using XP is not very different from introducing XP in a running development project.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic