• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RUP Versus RAD!!

 
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi can anybody tell me the difference between RAD and RUP?? and usefull links?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For a pretty good overview of RUP, you could try the Wikipedia description. They also have a page on Rapid Application Development.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
RUP is notoriously hard to nail down. An important activity in RUP is customizing the process by choosing which parts to use and which to ignore. It's so flexible that it can wind up being reasonably compatible with just about any other popular method you can come up with.

I haven't heard much about RAD as described on the Wikipedia for a long time. Except I just filled out a "skills self assessment" at work and it asked how good I thought I was at RAD. Sheesh, not very, thank you.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Lasse that RAD is Rapid Application Development in the context of process. In the context of IBM, Rational it is Rational Application Developer (the IDE10). Should lead to some nice confusion!
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might find The Agile Unified Process (AUP) to be an interesting instantiation of the RUP.

- Scott
 
vijaya bacina
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks to all
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Ambler:
You might find The Agile Unified Process (AUP) to be an interesting instantiation of the RUP.


I've done the agile process before. It some ways I like it, in other ways I don't. I find that what it really does is encourage team members to be proactive, ergo if you have a team that is all ready proactive its not really neccessary and can be burdensome. Alternatively, if you have a team that only does the bare minimum and never really looks ahead or considers the consequences of their actions, then its a winner.

I've seen that for some people its an enlightening experience that forces them to become more proactive then they were before, others, I feel it just gives them another way to seem productive without being so.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Selikoff:
if you have a team that is already proactive [an agile process] is not really neccessary and can be burdensome.


How so? I'd be interested in hearing more.

Originally posted by Scott Selikoff:
Alternatively, if you have a team that only does the bare minimum and never really looks ahead or considers the consequences of their actions, then [an agile process] is a winner.


Really? I'd say that with that kind of a team, any process is a loser...

Originally posted by Scott Selikoff:
others, I feel [an agile process] just gives them another way to seem productive without being so.


Would you like to tell us more about how these people seem more productive without being so?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Selikoff:
I've done the agile process before.



Mhh, as there is not one Agile process, but a whole family of processes that simply more or less share a common value system, I wonder what you are talking about. What process exactly did you use?

I find that what it really does is encourage team members to be proactive, ergo if you have a team that is all ready proactive its not really neccessary and can be burdensome.



Every team has a process. An already proactive team might well use its own incarnation of an Agile process, without even knowing. So, like Lasse, I'm not sure how "burdensome" enters the picture.


I've seen that for some people its an enlightening experience that forces them to become more proactive then they were before, others, I feel it just gives them another way to seem productive without being so.



As Agile processes inherently measure progress by delivering running tested software every couple of weeks, I'm not sure how one could seem productive without being so...
 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since there's was multiple feedback requested, here's some of my stories. I believe we used Agile with Scrum to be specific. I think the tagline from the Scrum website is "It's About Common Sense". The difficulty with common sense is that its not all that common.

The first example of Agile being negative: This is partially related to management who took the notion that there should be daily 10 minute check up meetings to mean that we should have 30-60 minute 8am meetings every single day. The whole concept of the meetings was short, brief, and really only as required. Coming in an hour early to sit around while people talked for up to an hour didn't really increase my productivity. The meetings are really only to encourage people who waits weeks at a time to report problems to others to come forward quicker and get help. If you spend a good amount of time walking to people's desks and handling problems as they come, the meetings aren't as important.

Second example: A lot of feedback I heard from people was "Wow, this works so great, I would have never found out the results of my actions [...] until much later on". In the waterfall model, what we were transitioning from, there's an emphasis on one-piece at a time and people don't tend to consider future actions. Agile forces them to see and consider future actions quicker because of the short iterations. To some, especially those teams that are really bad about never looking ahead, this can be an enlightening experience that they never would have considered before.

And the last example... I've seen people waste *hours* discussing Agile philosophies pretending as if they were getting work done... no make that *days*. On top of that, since we had a daily status meeting, the goal seemed to be who could check off the most things faster which resulted in people inventing tasks for themselves during planning then solving them over the course of weeks. This one you can't really get around, some people are determined to do nothing and finding such individuals can be a daunting task.

Oh and one note, we implemented Agile in proof of concept scenario without having customers or requirements analysts... so the concept of producing 'deliverables' every few weeks was seriously open to interpretation and lead to days/weeks wasted discussing what proper testing is at which point the result was "well do every possible level of testing, unit/system/whitebox/blockbox/etc".
[ January 06, 2006: Message edited by: Scott Selikoff ]
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The examples you brought up shouldn't be attributed to agile software development, but instead to the organization where you were working.

- Scott
 
Scott Selikoff
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps, although I merely bring them up to point out that agile is not fool-proof, as in any methodology. I'm sure there are companies out there who've adopted agile that have done far worse, despite the credos of the philosophy.

On the plus side, the story about people suddenly considering their future actions is, I believe, a positive one. Although you can tell people to plan ahead and that what they do has future impact on everyone else, without showing them ways of understanding/overcoming this, they are left to do things their own way, such as: "You mean I don't have to wait months to realize the specification I was designing was inherently wrong for our customers?". These are definitely good and money saving realizations.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Selikoff:
Perhaps, although I merely bring them up to point out that agile is not fool-proof, as in any methodology. I'm sure there are companies out there who've adopted agile that have done far worse, despite the credos of the philosophy.



In my opinion the crux is that adopting the *practices* isn't what makes you Agile - adopting the *value system* is. The practices only teach you a way to implement the value system *iff* you care about the values.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Selikoff:
The first example of Agile being negative: This is partially related to management who took the notion that there should be daily 10 minute check up meetings to mean that we should have 30-60 minute 8am meetings every single day. The whole concept of the meetings was short, brief, and really only as required. Coming in an hour early to sit around while people talked for up to an hour didn't really increase my productivity.



I can imagine that. But the Daily Scrum is meant to be a *Stand Up* Meeting (not a "Sit Down") - for a reason.

The meetings are really only to encourage people who waits weeks at a time to report problems to others to come forward quicker and get help. If you spend a good amount of time walking to people's desks and handling problems as they come, the meetings aren't as important.



Mhh, we do have all developers sitting in one room and pair program regularly - and still the daily stand ups seem to have value. But they never last longer than ten minutes...

I've seen people waste *hours* discussing Agile philosophies pretending as if they were getting work done... no make that *days*.



Seems like a coach might have been a good idea...

Oh and one note, we implemented Agile in proof of concept scenario without having customers or requirements analysts...



I'm don't understand why a proof of concept wouldn't have a customer...
 
Cob is sand, clay and sometimes straw. This tiny ad is made of cob:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic