Originally posted by Pradeep Bhat:
Are there phases in XP like we have it in RUP( Requirements, Analysis). If yes, what are they? Are they same as in RUP.
XP is said to be light weight process because it requires less documentation. So, I want to know what are the documents that are required in RUP but not in XP.
I'm no RUP expert, but as far as I know RUP, as a process *framework*, doesn't actually require anything. It's just that it suggests so many artifacts that most teams seem to end up producing tons of detailed use cases, UML diagrams, test plans etc. pp.
RUP says "you might need A, and perhaps B, possibly C, D might be a good idea, E sometimes is quite valuable, etc. pp."
XP says "you are quite save if you start with X. Figure out the rest as you go."
RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process.
I have to think about this. As far as I know, there actually is a difference between iterative and incremental processes. Need to research that, though. (I think Alistair Cockburn has written something about it somewhere on the web...)
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
Originally posted by Pradeep Bhat:
2. XP is said to be light weight process because it requires less documentation. So, I want to know what are the documents that are required in RUP but not in XP.
Originally posted by Pradeep Bhat:
3. RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process. Isn't there a feedback in RUP as well.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
XP uses what I call "nano-increments", function add in a 15-minute to 4-hour session, tested, and then checked in. Those don't get delivered to the user, of course. The "iterations" in XP are hidden - they just happen all the time, part of business-as-usual. In most organizations, both increments and iterations are larger and need to be scheduled / managed.
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
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Grady Booch, one of the originators of RUP, sometimes says he can live with customizing RUP to almost be XP all except for "emergent architecture". He characterizes architecture as decisions that are "expensive to change later" and prefers more of the up-front approach to that area.
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
Originally posted by dinaker prasad:
RUP is a plan driven process
plan driven and agile are completelty different concepts/methodologies.
XP incorporates some[a very little] plan driven framework to achieve discipline and flexibility.
plan driven process are like CMM, CMMI, RUP , where you have anchor points or milestones which guide the project.
in Agile, it depends a lot on feed-back, so the sucess here depends upon the expertise of your architects/PM/any personal working on the project.
Plan driven is a highly risk driven process,
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
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
[QB]Sorry to be such a cynic, but I think what draws management to plan-driven processes is a lack of trust in their people.
stan,i agree with you on your above statement but its not totally lack of trust its also because of personal shortfall. personal shortfall has always been the NUMBER 1 risk. In big organizations[like DoD etc] projects have 100-200 people working with schedule spanned over 3-5 years. For situations like these where uncertainity is very, high plan driven process suit the orgranization better.
risk management is not all about planning, its about identify things that can go wrong and fix them before its out of hand. in case of RUP, iterations are totally based on risk. you consider the highest risk items to be addressed first.
In agile process it depends more on people and their feedback on activities. The problem in agile with inexperinced people leading/architecting is their denial that risk exists.
The 5 critical decision factors [represeting 5 dimensions] that can be considered when choosing between a displined process and agile are
1.criticality
2.size
3.Personal
4.Dynamism
5.Culture
there are a couple of supply chain mangement companies who have succesfully adopted a 40%plan driven and 60% agile process. but these percentages depend up those 5 decision factors.
thanks
dinaker
Originally posted by dinaker prasad:
personal shortfall has always been the NUMBER 1 risk.
In big organizations[like DoD etc] projects have 100-200 people working with schedule spanned over 3-5 years. For situations like these where uncertainity is very, high plan driven process suit the orgranization better.
risk management is not all about planning, its about identify things that can go wrong and fix them before its out of hand. in case of RUP, iterations are totally based on risk. you consider the highest risk items to be addressed first.
In agile process it depends more on people and their feedback on activities. The problem in agile with inexperinced people leading/architecting is their denial that risk exists.
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
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by dinaker prasad:
All all of these orgranizations drive on 90%Plan-drive & 10% agile process.
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
Originally posted by Ilja Preuss:
Well, then the XP answer would be that the typical project can be done in a way that there is near to zero "architecture".
I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Originally posted by Jeff Langr:
I prefer Booch's definition--that the architecture represents decisions that are expensive to change later, i.e. directly tying it to cost.
[snip]
Unless you have a top-notch, crack team that are absolute refactoring nazis, you will have a tough time evolving a solid architecture. I've seen too many shops that found this out the hard way.
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
Originally posted by dinaker prasad:
1.criticality
2.size
3.Personal
4.Dynamism
5.Culture
For large size and high complexity systems, what i have noticed is they have more plan-driven activites compared to agile activities.
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
Originally posted by Ilja Preuss:
When you define architecture that way, it's a no-brainer to say that emerging architecture is unreasonable - your certainly shouldn't "emerge" something that's hard to change.
Books: Pragmatic Unit Testing in Java, Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Originally posted by Warren Dew:
Ilja Preuss:
I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).
For many projects, I think that's a very questionable assumption.
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
Originally posted by Pradip Bhat:
Ilja ,
Are there workflows in Xp? thanks
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
Originally posted by Ilja Preuss:
You mean like in http://www.extremeprogramming.org/map/project.html ?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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
Originally posted by Stan James:
Some practitioners have adapted XP to larger roups with good success. Martin Fowler has published some papers on using XP with teams up into 100-150 range at Thoughtworks. With the mods for large teams I guess you could argue whether it's still XP or something new.
Another option is to turn your large team into many smaller teams, though there are surely challenges in doing that, too.
All in all, giant teams are not an indicator for selecting XP.
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
You could argue that. But why would you care?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Pradeep Bhat:
3. RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process. Isn't there a feedback in RUP as well.
Originally posted by Fintan Conway:
Hi Pradeep,
Incremental and Evolutionary both create a system in small increments (iterations). Therefore, both are iterative. The difference is in the Agility of the approaches. For incremental approaches you develop in iterations towards the system as it was originally designed. (Ready - Aim - Fire - Fire - Fire).
For evolutionary approaches you assess at the end of each iteration whether the system requirements have changed (normal with most end-users / projects) and readjust the next iteration towards the changed system. (Ready - Aim - Fire - Aim - Fire - Aim - Fire).
In my opinion architecture refers to what is *technically* important for the project (e.g. infrastructure) rather than important requirements.
HTH,
Fintan
Originally posted by Pradip Bhat:
How much days a iteration normally runs into ? Is there any difference in the number of days in RUP and XP?
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Scott Ambler:
Just thought I'd pop in and clear up a few misconceptions:
1. Evolutionary is typically defined as iterative + incremental. XP and RUP are both evolutionary in nature.
2. Agile can be defined as evolutionary done in a highly collaborative manner. XP is definitely agile. RUP can be instantiated in an agile manner, but often isn't (unfortunately).
3. In RUP testing can (and likely should) be done every day. The Test discipline runs through all phases.
4. Test-driven development (TDD) is an important part of XP.
5. You can do TDD on a RUP project if you like, and many people do.
6. Asking the "X vs. Y" question likely isn't a great way to learn. Asking "how do X and Y compare" is likely a much better way to learn because you discover how to use the best of each technique.
- Scott
SCJP 1.5, SCEA, ICED (287,484,486)
Don't get me started about those stupid light bulbs. |