XP and Rational Unified Process
Dmitriy Lapshin
Has anybody reviewed the fusion of XP and Rational Unified Process? I'd be
interested in any opinions of XP practitioners.
--
Dmitriy Lapshin
X-Unity Unit Testing and Integration Environment
http://x-unity.miik.com.ua
Matthew Dunn
> Has anybody reviewed the fusion of XP and Rational Unified Process?
Yes, check out the following paper by Robert Martin that proposes
a mimimal RUP process based on XP called dX (note that the acronym is
XP upside down!) :
http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
Cheers,
Matt
--
*************************************\
Matthew Dunn
Analyst/Programmer
Wizard Information Services
http://wizardis.com.au
**************************************/
Dmitriy Lapshin
> Yes, check out the following paper by Robert Martin that proposes
> a mimimal RUP process based on XP called dX (note that the acronym is
> XP upside down!) :
Thanks for your response, I've alreagy got this paper on my hard drive :-)
What I wanted is live opinions from well..to say so, real programmers, who
heavily use XP in their projects..Unfortunately, what is written in books
and articles is not always applicable to real life.
David Van Camp
"Dmitriy Lapshin" <unk...@nonexistent.com> wrote in message
news:3d58f265$1...@nexus.validio.com.ua...
> Hello group,
>
> Has anybody reviewed the fusion of XP and Rational Unified Process? I'd be
> interested in any opinions of XP practitioners.
>
and XP practices. There really is only limited overlap. It works OK. The
major problems are mostly on the RUP side. Is there a specific question?
You are welcome to review my 'Best Practices' article, which addresses some
of the issues for project managers, in the articles section of
www.davidvancamp.com.
--
David Van Camp.com :: Software Development Consulting
Patterns, Reuse, Software Process Improvement
http://www.davidvancamp.com
Visit the OO Pattern Digest :: http://patterndigest.com
A catalog of condensed patterns, books and related resources
Dmitriy Lapshin
> I've and others I've known (besides Bob) have successfully incorporated
RUP
> and XP practices. There really is only limited overlap. It works OK. The
> major problems are mostly on the RUP side. Is there a specific question?
Yes, there's one. RUP suggests some kind of up-front design, with detailed
class diagrams, sequence diagrams and other UML artifacts, while XP tells
"do the simplest thing that could possibly work" and only architecture (AKA
metaphor) should be defined up-front. I'm really interested in impressions
of applying both approaches while mixing XP and RUP, which one works better
and when?
For the unit testing framework I am working on, XP style (simplest design
and refactoring) works quite right, but it is rather simple application...
> You are welcome to review my 'Best Practices' article, which addresses
some
> of the issues for project managers, in the articles section of
> www.davidvancamp.com.
Oh, thanks, I will definitely visit it.
Keith Ray
"Dmitriy Lapshin" <unk...@nonexistent.com> wrote:
> Hello David,
>
> > I've and others I've known (besides Bob) have successfully incorporated
> RUP
> > and XP practices. There really is only limited overlap. It works OK. The
> > major problems are mostly on the RUP side. Is there a specific question?
>
> Yes, there's one. RUP suggests some kind of up-front design, with detailed
> class diagrams, sequence diagrams and other UML artifacts, while XP tells
> "do the simplest thing that could possibly work" and only architecture (AKA
> metaphor) should be defined up-front. I'm really interested in impressions
> of applying both approaches while mixing XP and RUP, which one works better
> and when?
Check out the book Agile Modeling, and the web site associated with it.
It describes how modelling works in XP, and how modelling in RUP can be
agile.
"Agile Modeling"
by Scott W. Ambler;
ISBN 0-471-20282-7
The Agile Modeling (AM) Home Page
<http://www.agilemodeling.com>
<http://www.agilemodeling.com/essays/agileModelingXP.htm>
--
C. Keith Ray
David Van Camp
> Hello David,
>
> > I've and others I've known (besides Bob) have successfully incorporated
> RUP
> > and XP practices. There really is only limited overlap. It works OK. The
> > major problems are mostly on the RUP side. Is there a specific question?
>
> Yes, there's one. RUP suggests some kind of up-front design, with detailed
> class diagrams, sequence diagrams and other UML artifacts, while XP tells
> "do the simplest thing that could possibly work" and only architecture
(AKA
> metaphor) should be defined up-front. I'm really interested in impressions
> of applying both approaches while mixing XP and RUP, which one works
better
> and when?
>
> For the unit testing framework I am working on, XP style (simplest design
> and refactoring) works quite right, but it is rather simple application...
>
understand what you are about to do. Typically I'll model the high-level
interfaces and packages and the major relationships between them at the
beginning of a project. Then I'll iterate thru analysis / design / develop
as needed to break the problems down into manageable chunks.
But, the size and complexity of the problems / project / teams should be the
driving factors. Risk also must be understood: could a defect in your system
kill people? Then you'd better spend a lot of time verifying the correctness
of the system! Or would it be a minor inconvenience that affects only a few
users? If so, it would be hard to justify the cost of a large upfront
effort.
RUP does not state how much analysis or design work to do, rather it
provides workflows for doing it and suggests every conceivable document a
project might need. Conversely, XP does not say much about what to do up
front -- just the simplest thing needed. So your needs drive the decision.
As Keith noted, Agile Modeling provides more guidance -- better guidance
than either RUP or XP, IMO.
Ambler states in Agile Modeling and XP
(http://www.agilemodeling.com/essays/agileModelingXP.htm):
"What confuses many people regarding XP and documentation is that XP doesn’t
specify potential documents to create during development. This is unlike
the Unified Process (Kruchten, 2000; Ambler, 2001b) which suggests a slew of
potential project artifacts. Instead, the suggestion is to work together
with your project stakeholders in an environment of rapid feedback and trust
them to determine the things that they need, not just documents but any type
of project enhancements (Jeffries, 2001b). Once again, you need to have the
courage to trust the people involved with the project. In the essay Agile
Documentation I discuss a collection of documents that you may choose to
create and provide advice for when to consider creating them."
Let me also add that while RUP specifies a very large number of documents,
few, if any, projects ever produce all of them. Part of the tailoring
process for RUP is to determine what documents you want/need and what you do
not.
Uncle Bob (Robert C. Martin)
<unk...@nonexistent.com> wrote:
>Yes, there's one. RUP suggests some kind of up-front design, with detailed
>class diagrams, sequence diagrams and other UML artifacts,
Not quite. RUP projects are broken up into four phases. All these
phases are composed of iterations. Every iteration delivers
executable software. Thus, while class diagrams and sequence diagrams
*may* be created in RUP (and most ancillary RUP documentation *does*
seem to imply that they will) they are not call created up front.
They are created as part of a series of iterations, each of which
produces executable code.
In reality, RUP does not demand any of the artifacts mentioned. You
can run a RUP project without ever drawing any UML. On the other
hand, you cannot run a RUP project without delivering executable
software every iteration.
>while XP tells
>"do the simplest thing that could possibly work" and only architecture (AKA
>metaphor) should be defined up-front.
Again, this isn't quite right. XP does not demand that the metaphor
be estaplished up front. Indeed, you may not find the metaphor for
many iterations. You may never find a reasonable one. XP suggests
that architecture evolve from iteration to iteration (just as RUP
suggests).
>I'm really interested in impressions
>of applying both approaches while mixing XP and RUP, which one works better
>and when?
The main differences between RUP and XP is the amount of ceremony that
RUP allows, and in the size of the iterations. Both are iterative,
both demand executable deliveries each iteration, but XP demands very
short iterations (2-3 weeks) while RUP allows for iterations as long
as 6 months in very large projects. XP is very aggressive about
limitting documentation. The rule in XP is that no document is
produced unless there is an immediate and significant need. RUP has
no such constraint and many RUP users seem to think that the
production of documents is recommended by RUP even when there is no
immediate or significant need.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
You and I can enjoy the experience of not always seeing
eye-to-eye, but we can also respect each other, even when
you might find some idea of mine totally ludicrous.
-- Richard Riehle
David Van Camp
"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
news:otuqlu43v2v5u0udu...@4ax.com...
> On Thu, 15 Aug 2002 09:50:26 +0300, "Dmitriy Lapshin"
> <unk...@nonexistent.com> wrote:
>
> >Yes, there's one. RUP suggests some kind of up-front design, with
detailed
> >class diagrams, sequence diagrams and other UML artifacts,
>
> Not quite. RUP projects are broken up into four phases. All these
> phases are composed of iterations. Every iteration delivers
> executable software. Thus, while class diagrams and sequence diagrams
> *may* be created in RUP (and most ancillary RUP documentation *does*
> seem to imply that they will) they are not call created up front.
> They are created as part of a series of iterations, each of which
> produces executable code.
The Rational RUP workflows (as delivered with the 'RUP product' by Rational)
show very specific workflows with many documents eminating from those
workflows. Most of the workflows are not programming activities and this is
very specifically stated in the RUP dictionary(s).
However, you are correct in that all of these workflows and outputs are
really suggestions. On is not required to do all tasks in RUP. Indeed, RUP
should be tailored and part of the tailoring is deciding what workflows and
what workflow outputs (and thier exact forms) that you require in your
circumstance.
But, while RUP certainly *does* break workflows into four major phases, RUP
does not absolutely specify that these are iterations, nor does it specify
how tight the iterations must be. Rational has truely become the Microsoft
of SD processes, as they have (I am told) Rational marketeers and
consultants in the field claiming that the phases can be done as a waterfall
if the client so wants.
How's that for flexible? :D
> In reality, RUP does not demand any of the artifacts mentioned. You
> can run a RUP project without ever drawing any UML. On the other
> hand, you cannot run a RUP project without delivering executable
> software every iteration.
Are you sure? The incredeble maliability and flexibility of this process
sometimes leave me unsure...... Perhaps that should be 'shouldn't' instead
of 'cannot'?
> >while XP tells
> >"do the simplest thing that could possibly work" and only architecture
(AKA
> >metaphor) should be defined up-front.
>
> Again, this isn't quite right. XP does not demand that the metaphor
> be estaplished up front. Indeed, you may not find the metaphor for
> many iterations. You may never find a reasonable one. XP suggests
> that architecture evolve from iteration to iteration (just as RUP
> suggests).
And this is an area I have significant problems with. How can you introduce
a metaphore (or architecture) late in the process without causing
significant rework? It will spontainiously appear in it's own right? I've
been on many projects using many techniques, but I've never even seen a hint
that this could ever possibly happen -- at least it has no better chance
than a collection of monkeys and typewriters ....
Purpose, Process, Architecture, System metaphore and other such trivial
drivel have, IME, ALWAYS required significant up-front planning. No you
might not always get them quite right at first, but, I have never seen any
of them spontainiously appear and integrate themselves in an ongoing
project. And I would be shocked into coma, i think, if i ever did. The
further on the project is, the greater the effort needed to integrate such
concepts.
> >I'm really interested in impressions
> >of applying both approaches while mixing XP and RUP, which one works
better
> >and when?
>
> The main differences between RUP and XP is the amount of ceremony that
> RUP allows, and in the size of the iterations. Both are iterative,
> both demand executable deliveries each iteration, but XP demands very
> short iterations (2-3 weeks) while RUP allows for iterations as long
> as 6 months in very large projects. XP is very aggressive about
> limitting documentation. The rule in XP is that no document is
> produced unless there is an immediate and significant need. RUP has
> no such constraint and many RUP users seem to think that the
> production of documents is recommended by RUP even when there is no
> immediate or significant need.
Well, RUP offers templates for every possible document under the sun
(almost -- I know people who found additional missing docs -- O! lucky them!
:) But, yes, RUP does not, in fact (seem to), require all or even a major
subset of these documents. But, this fact is not really made very clear by
Rational.
And I already mentioned Rational selling RUP as a waterfall....... so RUP is
(at least according to some Rational marketeers) not strictly iterative
(although the writings of Booch, Rumbaugh and Jacobson indicate a very
different view), but rather an all flexible, fully applicable solution to
every problem known to mankind.
Sorry, I got a bit carried away with sarcasm. My apologies.
Anyway, Bob, my point is not to critise your point of view on RUP, since I
very much agree with it, but rather to point-out that Rational has been
highly inconsistent in its presentation of these matters. Since Rational
does not seem to consistently agree with these (your/my) viewpoints, readers
must take your (and my) POV as an alternate suggestion. I hope they do. But,
they must understand that it does not represent any 'official' stance by
Rational, particularly since Rational seems (AFAICT) unable to form one.
Personally, I wish I knew what Rational's 'official' stance is. At least
that way I could address it!
Ron Jeffries
wrote:
>> Again, this isn't quite right. XP does not demand that the metaphor
>> be estaplished up front. Indeed, you may not find the metaphor for
>> many iterations. You may never find a reasonable one. XP suggests
>> that architecture evolve from iteration to iteration (just as RUP
>> suggests).
>
>And this is an area I have significant problems with. How can you introduce
>a metaphore (or architecture) late in the process without causing
>significant rework? It will spontainiously appear in it's own right? I've
>been on many projects using many techniques, but I've never even seen a hint
>that this could ever possibly happen -- at least it has no better chance
>than a collection of monkeys and typewriters ....
Well, David, try to go with me here for a moment. Suppose we started with just
all the code you and I could write today. And suppose that code did some part of
the whole application, end to end ... just not very much. And suppose that we
carefully crafted that code into good objects.
Then suppose tomorrow we added more function, and again crafted the code into
good objects. As we got architectural ideas, we would put them in as soon as (a)
we had them and (b) there was room for them in the code we then had.
I've done this a lot now, and what happens is that the architecture grows rather
smoothly with the program. You do have to think about it ... in this case it was
your good ideas, and mine if I had any, that kept us bringing the architecture
out of the shadows.
>
>Purpose, Process, Architecture, System metaphore and other such trivial
>drivel have, IME, ALWAYS required significant up-front planning. No you
>might not always get them quite right at first, but, I have never seen any
>of them spontainiously appear and integrate themselves in an ongoing
>project. And I would be shocked into coma, i think, if i ever did. The
>further on the project is, the greater the effort needed to integrate such
>concepts.
I don't think anyone is saying that they will SPONTANEOUSLY appear. What we're
saying is that if you are really shipping software every two weeks, software
that does part of the application, you can add in the architecture as you go
along. It's the mind of the programmer/designer that creates the architecture,
and there's LOTS of planning ... it's just not done up front.
We're not making this up (nor did you claim we were). All the agile
spokesmodels, not just the evil Bob and Ron, are reporting that this has been
and can be done. It's time for folks to find out how we're doing it, and to help
us explain how to do it, and when to do it.
Want to sit down for a week or two and build some code? It could be arranged.
Does this make sense? I think so ... I'm doing it. Am I explaining it well
enough? There I have my doubts. ;->
Help me out ... how can we explore this idea better.
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Kent Beck
"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
news:otuqlu43v2v5u0udu...@4ax.com...
> In reality, RUP does not demand any of the artifacts mentioned. You
> can run a RUP project without ever drawing any UML. On the other
> hand, you cannot run a RUP project without delivering executable
> software every iteration.
I might say "in theory". There is a community of practice that we also refer
to when say something like "In RUP, they..." and in that community,
substantial documentation beyond code and tests is normal.
Kent
Dmitriy Lapshin
> Not quite. RUP projects are broken up into four phases. All these
> phases are composed of iterations. Every iteration delivers
> executable software. Thus, while class diagrams and sequence diagrams
> *may* be created in RUP (and most ancillary RUP documentation *does*
> seem to imply that they will) they are not call created up front.
> They are created as part of a series of iterations, each of which
> produces executable code.
Yes, but as far as I remember RUP structure, architecture
is established mostly through the Elaboration phase?
When construction is started, the design is left almost unchanged.
And, software is delivered aftre the complete cycle
(Inception-Elaboration-Construction-Transition),
unlike XP, where, in general, every iteration results in software release.
> In reality, RUP does not demand any of the artifacts mentioned. You
> can run a RUP project without ever drawing any UML. On the other
> hand, you cannot run a RUP project without delivering executable
> software every iteration.
Well, this may be possible during the Construction phase, but not
during the Inception or Elaboration where "production" programming does
not take place at all.
> Again, this isn't quite right. XP does not demand that the metaphor
> be estaplished up front. Indeed, you may not find the metaphor for
> many iterations. You may never find a reasonable one. XP suggests
> that architecture evolve from iteration to iteration (just as RUP
> suggests).
Could you please point me to the source where this is true for RUP
(i mean exactly from iteration to iteration)? All info I have on RUP
does not tell me something like this.
> The main differences between RUP and XP is the amount of ceremony that
> RUP allows, and in the size of the iterations. Both are iterative,
> both demand executable deliveries each iteration, but XP demands very
> short iterations (2-3 weeks) while RUP allows for iterations as long
> as 6 months in very large projects. XP is very aggressive about
> limitting documentation. The rule in XP is that no document is
> produced unless there is an immediate and significant need. RUP has
> no such constraint and many RUP users seem to think that the
> production of documents is recommended by RUP even when there is no
> immediate or significant need.
Oh, that's I wanted to hear :-) Thanks.
Dmitriy Lapshin
> I've done this a lot now, and what happens is that the architecture grows
rather
> smoothly with the program. You do have to think about it ... in this case
it was
> your good ideas, and mine if I had any, that kept us bringing the
architecture
> out of the shadows.
The approach you have shown is strongly based on Refactoring, right?
You mean, write code that satisfies current requirements, when there's
some functionality to add, refactor in such way that the architecture will
be flexible enough to fit new needs (but not more flexible than necessary
at the moment), and add new code?
Do I understand your idea right?
At least, that's how it was depicted in XP and Refactoring books I read...
Ron Jeffries
wrote:
>> Not quite. RUP projects are broken up into four phases. All these
>> phases are composed of iterations. Every iteration delivers
>> executable software. Thus, while class diagrams and sequence diagrams
>> *may* be created in RUP (and most ancillary RUP documentation *does*
>> seem to imply that they will) they are not call created up front.
>> They are created as part of a series of iterations, each of which
>> produces executable code.
>
>Yes, but as far as I remember RUP structure, architecture
>is established mostly through the Elaboration phase?
>When construction is started, the design is left almost unchanged.
>And, software is delivered aftre the complete cycle
>(Inception-Elaboration-Construction-Transition),
>unlike XP, where, in general, every iteration results in software release.
If you look at the activity diagrams in RUP, you'll see that they do anticipate
that design and architecture continue throughout the project, though (of course)
most of it is in the beginning.
And they say clearly -- but not often -- that you should ship software after
every iteration.
XP and RUP aren't all that different in the minds of those who invented them,
but RUP in practice seems to forget a lot of what RUP says in principle. That
happens with XP as well, of course.
Anyway, they're not that incompatible in principle. In practice, it's a local
option and depends on the organization's values more than anything else, in my
opinion.
Regards,
Ron Jeffries
wrote:
>> I've done this a lot now, and what happens is that the architecture grows
>rather
>> smoothly with the program. You do have to think about it ... in this case
>it was
>> your good ideas, and mine if I had any, that kept us bringing the
>architecture
>> out of the shadows.
>
>The approach you have shown is strongly based on Refactoring, right?
>You mean, write code that satisfies current requirements, when there's
>some functionality to add, refactor in such way that the architecture will
>be flexible enough to fit new needs (but not more flexible than necessary
>at the moment), and add new code?
>
>Do I understand your idea right?
>At least, that's how it was depicted in XP and Refactoring books I read...
Yes. You seem to be understanding what I seemed to be saying. ;->
Regards,
Keith Ray
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
> On Mon, 19 Aug 2002 10:46:58 +0300, "Dmitriy Lapshin"
> <unk...@nonexistent.com>
> wrote:
[...]
> >Yes, but as far as I remember RUP structure, architecture
> >is established mostly through the Elaboration phase?
> >When construction is started, the design is left almost unchanged.
> >And, software is delivered aftre the complete cycle
> >(Inception-Elaboration-Construction-Transition),
> >unlike XP, where, in general, every iteration results in software release.
>
> If you look at the activity diagrams in RUP, you'll see that they do
> anticipate
> that design and architecture continue throughout the project, though (of
> course)
> most of it is in the beginning.
[...]
Here are some quotes from Grady Booch on the Extreme Programming mailing
list, about RUP.
> [egb> ] the same is true of every one of the other artifacts. An
> architecture document might manifest itself as a BFUG (big fat ugly
> document), as in the case of the JSF avionics (lots of stakeholders are
> going to pay lots of money to build something that does a bit more than,
> say, a shopping cart app on a retail web site, like, um, defend the nation),
> it might manifest itself as a model, it might just be some sketching on a
> white board; it might even just be a skeleton executable. The point it, it
> is something that does happen in a reasonable flow of events, so we name it,
> make it manifest, define what it is and what it isn't and expect the team to
> make intelligent decisions (self-empowerment is a rup principle, too...)
> about what they actually create.
>
> [egb> ] one of the naive meltdown applications of the rup is to use all 18
> roles and 41 artifacts. No one does that...just those organizations who
> either a) fear code or b) really shouldn't be allowed in front of a computer
> without adult supervision....in any case, they would probably fail no matter
> what process they try to apply, unless there some forcing function (a
> mentor, for example) to get them off the mark.
and...
> Ok, I'm about to tell you everything you need to know about the RUP...all
> else is simply details.
>
> First, the essence of the RUP may be expressed in its six best practices.
> These are not an invention, but instead are a reflection of what we've seen
> in working with literally tens of thousands of projects over the past 20
> years, codifying what works in successful organizations and what is
> noticeably absent in unsuccessful ones:
>
> 1. Develop iteratively (every project has a regular rhythm, manifest as a
> series of continuous, regular releases of executables)
>
> 2. Model visually (we model so that we may better reason about the systems
> we are trying to build; the UML exists as the standard means of visualizing,
> specifying, constructing, and documenting these artifacts of a
> software-intensive system)
>
> 3. Manage requirements (everything is driven by use cases/stories which are
> continuously discovered, refined, and managed in the rhythm of the project,
> and so in turn drive unit and systems test as well as the system's
> architecture and therefore implementation)
>
> 4. Control changes (change is good insofar as it is directed by aggressively
> attacking the risks to success in the system)
>
> 5. Continuously verify quality (test continuously, using the use
> cases/stories as the baseline, and use these tests to measure progress and
> identify risks along the way)
>
> Use component-based architectures (one grows a system's architecture through
> each iteration; we validate and verify the system's essential architecture
> early on so as to aggressively attack all technical risks and to raise the
> level of abstraction for the rest of the team by explicitly making manifest
> the design patterns/mechanisms and architectural patterns that pervade the
> system.
>
> Second, there are a few implicit practices:
>
> 1. Develop only what is necessary
> 2. Focus on valuable results, not on how the results are achieved
> 3. Minimize the production of paperwork
> 4. Be flexible
> 5. Learn from your mistakes
> 6. Revisit your risks regularly
> 7. Establish objective, measurable criteria for your progress
> 8. Automate what is human-intensive, tedious, and error-prone
> 9. Use small, empowered teams
> 10. Have a plan
>
> Third, there's some terminology worth noting, so that we level set the
> vocabulary of the process to all stakeholders:
>
> 1. The conduct of a project tends to follow four major phases, the end of
> each which represents an important business gate: inception (when the
> business case for the project is established and the basic boundaries of
> what's in and what's out of that case are drawn; at the end of inception we
> can say "yes, we should do this"), elaboration (gated by the establishment
> of the system's essential use cases and architecture, representing a direct
> attack that confronts the essential technical risks to the system; at the
> end of elaboration we can say "yes, we know we can do this"), construction
> (wherein the system is grown through the successive refinement of the
> system's architecture, along with the continuous discovery of the system's
> desired behavior; at the end of construction we can say "yes, the system is
> in a place where it may be fully deployed to its users" [it may have been
> incrementally deployed during construction, of course]), and finally,
> transition (wherein the business decision is made that aggressive investment
> in the system is no longer necessary, and the system enters a plateau of use
> and maintenance; at the end of transition we can say "this system is at end
> of life")
>
> 2. Since the RUP is about deploying systems for which software is an
> essential element (acknowledging that executables are the essential artifact
> that's produced continuously but that this labor has a business, economic,
> and technological context whose stakeholders contribute), there are several
> disciplines that engage in the development activity: business modeling,
> requirements, analysis and design, implementation, test, deployment,
> configuration and change management, project management, and environment.
> These disciplines represent different stakeholders, different views into the
> system, and different skill sets. Each discipline has its own rhythm, but
> all in harmony with the essential construction rhythm of the project as a
> whole.
>
> 3. In the conduct of a project, the RUP provides a common vocabulary for
> those things that get created during a project (artifacts), the roles/skill
> sets who create those things (workers) and the concurrent, interweaving
> workflows that those workers typically follow to manipulate those artifacts
> (activities).
>
> That's all you really need to know...
>
> Really.
Uncle Bob (Robert C. Martin)
<ms...@davidvancamp.com> wrote:
>...while RUP certainly *does* break workflows into four major phases, RUP
>does not absolutely specify that these are iterations, nor does it specify
>how tight the iterations must be. Rational has truely become the Microsoft
>of SD processes, as they have (I am told) Rational marketeers and
>consultants in the field claiming that the phases can be done as a waterfall
>if the client so wants.
I've seen this recommended. It took me months to recover from seeing
that. This is something Rational badly needs to get under control. I
am reasonably certain that the originators of RUP, and the thought
leaders at Rational, do not agree with that recommendation.
>> In reality, RUP does not demand any of the artifacts mentioned. You
>> can run a RUP project without ever drawing any UML. On the other
>> hand, you cannot run a RUP project without delivering executable
>> software every iteration.
>
>Are you sure? The incredeble maliability and flexibility of this process
>sometimes leave me unsure...... Perhaps that should be 'shouldn't' instead
>of 'cannot'?
When I think of RUP, I think of the people who originated it. I know
many of them, and I think I understand their values and opinions.
>> XP does not demand that the metaphor
>> be estaplished up front. Indeed, you may not find the metaphor for
>> many iterations. You may never find a reasonable one. XP suggests
>> that architecture evolve from iteration to iteration (just as RUP
>> suggests).
>
>And this is an area I have significant problems with. How can you introduce
>a metaphore (or architecture) late in the process without causing
>significant rework?
Think of it as an evolution. As the project proceeds, the developers
drive the design in a certain direction. At first the direction is
not well known, but as time passes that direction becomes clearer and
clearer.
Sometimes, as the requirements shift and change, a new direction will
begin to assert itself. *Then* there might be some rework; though
even then the changes can be done iteratively over time. The new
direction was not visible from the requirements that existed at first.
It only manifested itself as the requirements changed. So an up-front
architecture would not have saved you from this rework.
It's remarkable how quickly the direction begins to assert itself in
an XP project. One of the reasons for this is that every iteration
goes from beginning to end. Iterations are not focussed on
subsystems, they are focussed on features. Thus, every iteration is a
view to the big picture.
Think of each iteration as a small section of a hologram. The whole
picture is in each small section, you just have a restricted view.
With each iteration you less and less restrictions on the view.
>It will spontainiously appear in it's own right? I've
>been on many projects using many techniques, but I've never even seen a hint
>that this could ever possibly happen -- at least it has no better chance
>than a collection of monkeys and typewriters ....
I have. Indeed, in all the projects I have worked on, this effect has
asserted itself. The developers knew far better what the
artchitecture of the system *should* have been, once they were well
into the project.
>Purpose, Process, Architecture, System metaphore and other such trivial
>drivel have, IME, ALWAYS required significant up-front planning. No you
>might not always get them quite right at first, but, I have never seen any
>of them spontainiously appear and integrate themselves in an ongoing
>project.
The fact that the architecture arises spontaneously does not mean that
the architecture doesn't take work to derive. It does! Lots of work.
It's just that the developers have more and more information with each
new iteration. Each new batch of information solves more of the
architecture puzzle.
I agree, architecture requires up=front planning. However, I don't
define "up-front" as meaning "pre-code". I think you have to write
some code up front to find the real architecture.
>And I would be shocked into coma, i think, if i ever did. The
>further on the project is, the greater the effort needed to integrate such
>concepts.
So we work hard to get the data we need to resolve the architecture.
But that work has to include building some of the code. Otherwise the
architecture is based only on conjecture.
>
>Well, RUP offers templates for every possible document under the sun
>(almost -- I know people who found additional missing docs -- O! lucky them!
>:) But, yes, RUP does not, in fact (seem to), require all or even a major
>subset of these documents. But, this fact is not really made very clear by
>Rational.
Agreed. That's a problem. It's a problem that I'd like to help them
solve. That's why Object Mentor has partnered with Rational to build
the XP Plug-in for RUP.
>And I already mentioned Rational selling RUP as a waterfall....... so RUP is
>(at least according to some Rational marketeers) not strictly iterative
>(although the writings of Booch, Rumbaugh and Jacobson indicate a very
>different view), but rather an all flexible, fully applicable solution to
>every problem known to mankind.
Clearly any good marketeer would try to warp their product into that
state. IMHO Rational has let their marketting people do their jobs a
little too well.
>
>Anyway, Bob, my point is not to critise your point of view on RUP, since I
>very much agree with it, but rather to point-out that Rational has been
>highly inconsistent in its presentation of these matters.
Agreed.
Uncle Bob (Robert C. Martin)
<unk...@nonexistent.com> wrote:
>Robert,
>
>> Not quite. RUP projects are broken up into four phases. All these
>> phases are composed of iterations. Every iteration delivers
>> executable software. Thus, while class diagrams and sequence diagrams
>> *may* be created in RUP (and most ancillary RUP documentation *does*
>> seem to imply that they will) they are not call created up front.
>> They are created as part of a series of iterations, each of which
>> produces executable code.
>
>Yes, but as far as I remember RUP structure, architecture
>is established mostly through the Elaboration phase?
Yes.
>When construction is started, the design is left almost unchanged.
>And, software is delivered aftre the complete cycle
>(Inception-Elaboration-Construction-Transition),
>unlike XP, where, in general, every iteration results in software release.
The only word I disagree with above is 'unlike'. The iterations of
inception and elaboration produce executable releases. The
architecture is established at the end of elaboration, but only by
building several iterations of software. This is very similar to XP.
It is not quite correct to say that the architecture does not change
after elaboration -- it does. However, by the end of elaboration it
has reached a relatively stable state. Architectural hanges
thereafter are hopefully minimal.
>> In reality, RUP does not demand any of the artifacts mentioned. You
>> can run a RUP project without ever drawing any UML. On the other
>> hand, you cannot run a RUP project without delivering executable
>> software every iteration.
>
>Well, this may be possible during the Construction phase, but not
>during the Inception or Elaboration where "production" programming does
>not take place at all.
Though that's a common view, it is incorrect. Production programming
takes place in *all* phases of RUP, including Inception and
Elaboration. Many people think that these two phases are equivalent
to Analysis and Design in the Waterfall model. They are not. Within
each phase there may be many iterations, and each iteration results in
executable code. ("The Rational Unified Process", Phillipe Kruchten,
p7.)
>> Again, this isn't quite right. XP does not demand that the metaphor
>> be estaplished up front. Indeed, you may not find the metaphor for
>> many iterations. You may never find a reasonable one. XP suggests
>> that architecture evolve from iteration to iteration (just as RUP
>> suggests).
>
>Could you please point me to the source where this is true for RUP
>(i mean exactly from iteration to iteration)? All info I have on RUP
>does not tell me something like this.
See Kruchten above. Inception and Elaboration are all about the
establishment of the architecture through many iterations of
executable releases.
David Van Camp
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
> On Sat, 17 Aug 2002 06:10:31 GMT, "David Van Camp"
> <ms...@davidvancamp.com> wrote:
> When I think of RUP, I think of the people who originated it. I know
> many of them, and I think I understand their values and opinions.
That I can certainly respect. While I've never met any of them, I never seen
or heard any indication that that had such a fuzzy view of what SD is about.
Rational marketeers, however...... :)
Sorry, I simply don't buy it. I've been though this 'evolution' too many
times. I call it 'redesign'. It is painful and labor intensive. To call it
'refactoring' is not to give it justice.
This is like saying that Windows was first concived as rectangles and icons
(which, perhaps, it was) and that it could then have been simply morphed
into views and projections. But, the disconnect between theses two
'metaphores' goes far beyond a simple refactoring of code -- it requires a
complete redesign. MS had the advantage of years of study and analysis of
Apple and, before them, Xerox. And, still, look how poorly they did on the
first few versions? (and, some people think, later ones....)
The Metatphor drives the vision, not the other way. If the vision has minor
flaws, ok, no big deal, you fix that. But, if the vision -- the Metaphor --
is flawed, you have a really big job to correct that. That means the entire
architecture must be, at least, reconsidered. I would not consider that a
simple iteration. That's (potentially) big (unless you are only making minor
adjustments, of course.).
> >It will spontainiously appear in it's own right? I've
> >been on many projects using many techniques, but I've never even seen a
hint
> >that this could ever possibly happen -- at least it has no better chance
> >than a collection of monkeys and typewriters ....
>
> I have. Indeed, in all the projects I have worked on, this effect has
> asserted itself. The developers knew far better what the
> artchitecture of the system *should* have been, once they were well
> into the project.
I do not believe you. Provide a specific example where an architecture
simply truely 'grew' out of the requirements with no initial planning. I
have *never* seen this happen in any environment -- excepting only projects
that were very similar to those had been very recently been construted by
the participants (and, in which case, the architecture was, as expected,
very similar to the previous, for good or ill.) Or really, really small
projects.
I'm sorry, I cannot even begin to concieve of a system of any reasonable
complexity that started with no architecture, but a coherent architecture
none the less spontaniously arose of its own accord. Minor refactorings,
sure, but an entire architecture? No way. Not unless you stopped,
re-evaluated and re-designed.
Don't get me wrong -- understanding what the architecture "should have been"
is normal in all projects I've ever been in. Spontaniously resurecting that
architecture from the 'ashes' of the some undefined architecture, now,
that's a whole 'nother thing.
> >Purpose, Process, Architecture, System metaphore and other such trivial
> >drivel have, IME, ALWAYS required significant up-front planning. No you
> >might not always get them quite right at first, but, I have never seen
any
> >of them spontainiously appear and integrate themselves in an ongoing
> >project.
>
> The fact that the architecture arises spontaneously does not mean that
> the architecture doesn't take work to derive. It does! Lots of work.
> It's just that the developers have more and more information with each
> new iteration. Each new batch of information solves more of the
> architecture puzzle.
Yes, well, of course. But, the higher-level structures and the Metaphore (if
there is one), THAT is what I am refering too. That must be flexible, of
course. But, it must be concrete as well.
This sounds like the difference between a bunch of drunken guys vs. a VERY
RESPECTED ARCHITECTURAL FIRM deciding how to build a house:
- drunken guys: Yeah, let's put the foundation here, and build a wall here
and .... hey gimme another beer .. and...
- ARCHITECTS: We must spend 12 months evaulating the site then we'll decide
the precise bedroom sizes then .....
OK, that was a bit extreme, but still, but I DO live in the Adirondacks
where ... (oh, never mind)... :D
Neither approach works (IME) for software development. We must have a well
formed plan before we start. Yes, we learn more as we do more, but the
underlying architecture cannot change drasticly with each iteration -- we
would just be producing mud if it did. Upfront planning must make
fundamentatl architectural choices.
Metaphor, IF one is selected, becomes the driving philosophy behind any
architecture. To 'evolve' a metaphore is to evolve an architecture. I've
been there. I've never seen such evolution work well in a production
environment (I *have* seen it work in a research environment, however, but
only where there was a willingness to 'throw one away,' which is, of course,
another XP axiom.)
Final note: After re-reading you msg, It occurs to me that you are saying
that a suitable metaphore *might* be found sometime during development that
JUST SO HAPPENS to well represent the system. That might be an interesting
occurance -- one I've never seen and would expect to be a rare, but not an
impossible happening.
However, as aways with metaphores, I would still worry that, once a
metaphore is selected that seems to match, the impedence mismatch between
the metaphore and the actual system grows over time causing unnecessary
problems in the future. This has been a particular problem with many UI
developments. Consider the many attempts to 'improve' the desktop metaphor
by focusing and expanding on the 'office' or 'desk' metaphores -- none were
successfull, except Microsoft, which chose to ignore the metaphor in any
literal sense.
One must always keep in mind: a metaphore is not the system, and no system
is a metaphore. By the dictionary definition of metaphor: The application of
a word of pharase to an object or concept which it does not literally
denote, in order to suggest comparison with another object or concept, as in
"A mighty fortress is our God".... (Websters)
So, too close a relience on metaphore is dangerous. Allowing metaphore to
decide the architecture of a system is dangerous. And, choosing an
overriding metaphore to guide system development late in the process might
(IMHO) be very hazardous.
Michael
>
> Yes, check out the following paper by Robert Martin that proposes
> a mimimal RUP process based on XP called dX (note that the acronym is
> XP upside down!) :
>
> http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
I just read this chapter and I was disappointed. The author took XP, added
a few terms from the RUP, gave it a new name, and is presenting this as a
new process. It's not a new process, it's XP.
I'm curious what book this chapter was taken from?
Michael
Per Strömgren
<please_do...@hotmail.com> wrote:
>> http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
>
>I just read this chapter and I was disappointed. The author took XP, added
>a few terms from the RUP, gave it a new name, and is presenting this as a
>new process. It's not a new process, it's XP.
>
>I'm curious what book this chapter was taken from?
It's from a still to be published third edition of Grady Booch's
"Object Oriented Analysis and Design with Applications.", if I'm not
mistaken.
Per.
Michael
>
> It's from a still to be published third edition of Grady Booch's
> "Object Oriented Analysis and Design with Applications.", if I'm not
> mistaken.
I think it's a mistake to call it "dX". Last thing we need is a new
process, especially when it's just a copy of another process. I think it'd
be much better to just called it "RUP with XP" or something like that.
Ron Jeffries
wrote:
>> > Has anybody reviewed the fusion of XP and Rational Unified Process?
The story is kind of a metaphor. Its point is: XP is entirely consistent with
RUP. The twist is, the letters "XP" upside down are "dX".
Jeff Grigg
> Hi Dmitriy,
> > Has anybody reviewed the fusion of XP and Rational Unified Process?
>
> Yes, check out the following paper by Robert Martin that proposes
> a mimimal RUP process based on XP called dX (note that the acronym is
> XP upside down!) :
>
> http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
"Michael" wrote...
> I think it's a mistake to call it "dX". Last thing we need is a new
> process, especially when it's just a copy of another process. I think it'd
> be much better to just called it "RUP with XP" or something like that.
OK, here's the story:
"dX" is "XP". Just print it and turn the piece of paper over.
Yes it is Extreme Programming. It doesn't need another name because
it is Extreme Programming.
So why the "dX" obfuscation?
Well... When the cadre of TopManagement PointyHairedBosses dictates
that "you must use RUP; no deviation from the corporate standard is
allowed; that all that "Extreme Programming" stuff is just too radical
and dangerous to contemplate." Then you say "OK, we'll use the 'dX'
customization of RUP. It is RUP." (It also happens to be Extreme
Programming, but you don't have to tell them that. ;-)
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:rkppmu4jiaiqbh6pm...@4ax.com...
> On Wed, 28 Aug 2002 05:17:29 +0200, "Michael"
<please_do...@hotmail.com>
> wrote:
>
> >> > Has anybody reviewed the fusion of XP and Rational Unified Process?
> >>
> >> Yes, check out the following paper by Robert Martin that proposes
> >> a mimimal RUP process based on XP called dX (note that the acronym is
> >> XP upside down!) :
> >>
> >> http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
> >
> >I just read this chapter and I was disappointed. The author took XP,
added
> >a few terms from the RUP, gave it a new name, and is presenting this as
a
> >new process. It's not a new process, it's XP.
> >
> >I'm curious what book this chapter was taken from?
>
> The story is kind of a metaphor. Its point is: XP is entirely consistent
with
> RUP. The twist is, the letters "XP" upside down are "dX".
Nice metaphor, wrong description -its rotated 180 degrees (axis
perpendicular to the page)
Following the spirit of XP reasoning (abduction) - that is a mistake which
can be made by someone who is deslexic (spelled wrong, the reading disorder
which Wodrow Wilson had in case you can not figure out the word from the
poor spelling), ergo you must have that disorder
David B Lightstone
"Jeff Grigg" <jgr...@mo.net> wrote in message
news:c794c0fd.02082...@posting.google.com...
Ha HA, ever hear the espression Fradulent Pretext? How about
Misrepresentation?
There are torts which cover such conduct.
Now that you are on record, hopefully you will be successful with each
future dX "scam"/project
Good luck
Michael
> it is Extreme Programming.
>
> So why the "dX" obfuscation?
> Well... When the cadre of TopManagement PointyHairedBosses dictates
> that "you must use RUP; no deviation from the corporate standard is
> allowed; that all that "Extreme Programming" stuff is just too radical
> and dangerous to contemplate." Then you say "OK, we'll use the 'dX'
> customization of RUP. It is RUP." (It also happens to be Extreme
> Programming, but you don't have to tell them that. ;-)
This is making way too complicated. Why would management accept dX any more
than they'd accept XP?
A better approach would be to explain to them the differences and how they
can co-exist, instead of inventing a new name and tricking them.
Michael
Uncle Bob (Robert C. Martin)
<please_do...@hotmail.com> wrote:
>> > Has anybody reviewed the fusion of XP and Rational Unified Process?
>>
>> Yes, check out the following paper by Robert Martin that proposes
>> a mimimal RUP process based on XP called dX (note that the acronym is
>> XP upside down!) :
>>
>> http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
>
>I just read this chapter and I was disappointed. The author took XP, added
>a few terms from the RUP, gave it a new name, and is presenting this as a
>new process. It's not a new process, it's XP.
It is certainly XP. I named it dX, which is XP upsidedown. However,
the process is also an instance of RUP. It conforms to all the
necessary facets or RUP without violating any of the spirit of RUP.
>I'm curious what book this chapter was taken from?
Originally it was slated to be the "Process" chapter in the third
edition of Booch's "Object Oriented Analysis and Design with
Applications", which he, I, and Jim Newkirk were co-authoring.
Unfortunately that project fell through about three years ago. So,
now, the paper is simply a paper, and is not a chapter in any book.
However, there are sections of that paper in the current XP Plug-in
for RUP. See http://www.rational.com/products/rup/xprog.jsp
Uncle Bob (Robert C. Martin)
There is no trickery involved. dX is a valid instance of RUP.
Uncle Bob (Robert C. Martin)
<david.lightst...@prodigy.net> wrote:
>"Jeff Grigg" <jgr...@mo.net> wrote in message
>> So why the "dX" obfuscation?
>> Well... When the cadre of TopManagement PointyHairedBosses dictates
>> that "you must use RUP; no deviation from the corporate standard is
>> allowed; that all that "Extreme Programming" stuff is just too radical
>> and dangerous to contemplate." Then you say "OK, we'll use the 'dX'
>> customization of RUP. It is RUP." (It also happens to be Extreme
>> Programming, but you don't have to tell them that. ;-)
>
>
>Ha HA, ever hear the espression Fradulent Pretext? How about
>Misrepresentation?
>There are torts which cover such conduct.
The point is that dX *is* a valid instance of RUP. There is no fraud
here. Developers who desire to do XP, but who are constrained by
their management to use RUP, can feel safe about using dX.
Of course, now, they can get the RUP/XP plug-in from Rational
(http://www.rational.com/products/rup/xprog.jsp) which will guide them
through what we used to call dX.
David B Lightstone
"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
> On Wed, 28 Aug 2002 18:27:20 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >"Jeff Grigg" <jgr...@mo.net> wrote in message
>
> >> So why the "dX" obfuscation?
> >> Well... When the cadre of TopManagement PointyHairedBosses dictates
> >> that "you must use RUP; no deviation from the corporate standard is
> >> allowed; that all that "Extreme Programming" stuff is just too radical
> >> and dangerous to contemplate." Then you say "OK, we'll use the 'dX'
> >> customization of RUP. It is RUP." (It also happens to be Extreme
> >> Programming, but you don't have to tell them that. ;-)
> >
> >
> >Ha HA, ever hear the espression Fradulent Pretext? How about
> >Misrepresentation?
> >There are torts which cover such conduct.
>
> The point is that dX *is* a valid instance of RUP. There is no fraud
> here. Developers who desire to do XP, but who are constrained by
> their management to use RUP, can feel safe about using dX.
If you claim it is RUP who am I to disagree. The fraud and
misrepresentation occur when your are told not to use XP and suggest dX
instead
Phlip
> The point is that dX *is* a valid instance of RUP. There is no fraud
> here.
PDFT, Holmes.
--
Phlip
http://www.greencheese.org/DontPlanDesigns
-- DARE to resist drug-war profiteering --
Uncle Bob (Robert C. Martin)
<david.lightst...@prodigy.net> wrote:
>If you claim it is RUP who am I to disagree.
I don't know.
>The fraud and
>misrepresentation occur when your are told not to use XP and suggest dX
>instead.
Clearly if the stakeholders are rejecting XP on the basis of its
practices, then replacing XP with dX would be fraudulent. On the other
hand, the rejection of XP may be based upon brand. The stakeholders
may want to know that the process being used is one that is well
branded. dX carries the RUP brand and so may satisfy the stakeholders
in the same way that brand named products satisfy consumers in a way
that generic products don't.
Uncle Bob (Robert C. Martin)
<please_do...@hotmail.com> wrote:
>This is making way too complicated. Why would management accept dX any more
>than they'd accept XP?
For the same reason that you might buy Captain Crunch, but reject the
exact same cerial in a generic package. Brand often makes a lot of
difference.
David B Lightstone
"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
> On Sat, 31 Aug 2002 11:08:38 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >If you claim it is RUP who am I to disagree.
>
> I don't know.
>
> >The fraud and
> >misrepresentation occur when your are told not to use XP and suggest dX
> >instead.
>
>
>
> Clearly if the stakeholders are rejecting XP on the basis of its
> practices, then replacing XP with dX would be fraudulent. On the other
> hand, the rejection of XP may be based upon brand. The stakeholders
> may want to know that the process being used is one that is well
> branded. dX carries the RUP brand and so may satisfy the stakeholders
> in the same way that brand named products satisfy consumers in a way
> that generic products don't.
The branding argument is amusing. A pitch to the ignorant. Just give them
warm and fuzzy feelings. I doubt if the XP brand is causing any use
rejections
The issue becomes forcing a reconsidation by means of a name change, a
misrepresentation. Once they have decided, it is over, the end. Sort of
like creating confusion about the practices but changing them ever so
slightly every once in a while. The results of productive feedback and
cretive product positioning
Phlip
>>If you claim it is RUP who am I to disagree.
>
> I don't know.
UB, please turn your troll detector settings a little higher.
- recidivism
- insinuation
- alternative opinions based on the >name< of the topic
- negative attention craving
--
Phlip
http://www.greencheese.org/HatTrick
-- Got in trouble at StarBucks. I tried to order
"A double latte mocha and a body piercing." --
Phlip
> Uncle Bob (Robert C. Martin) wrote:
>
>>>If you claim it is RUP who am I to disagree.
>>
>> I don't know.
>
> UB, please turn your troll detector settings a little higher.
>
> - recidivism
> - insinuation
> - alternative opinions based on the >name< of the topic
> - negative attention craving
I forgot the biggest one:
- learning your current settings & staying just under them
--
Phlip
http://www.c2.com/cgi/wiki?RatAndTuyen
-- But all the other programmers were doing it! --
Uncle Bob (Robert C. Martin)
>Uncle Bob (Robert C. Martin) wrote:
>
>>>If you claim it is RUP who am I to disagree.
>>
>> I don't know.
>
>UB, please turn your troll detector settings a little higher.
>
> - recidivism
> - insinuation
> - alternative opinions based on the >name< of the topic
> - negative attention craving
Employing negative feedback means you have to cross the threshold from
time to time. There's no way around it.
Uncle Bob (Robert C. Martin)
<david.lightst...@prodigy.net> wrote:
>
>"Uncle Bob (Robert C. Martin)"
><u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
>news:pq13nugfereg4gom2...@4ax.com...
>> Clearly if the stakeholders are rejecting XP on the basis of its
>> practices, then replacing XP with dX would be fraudulent. On the other
>> hand, the rejection of XP may be based upon brand. The stakeholders
>> may want to know that the process being used is one that is well
>> branded. dX carries the RUP brand and so may satisfy the stakeholders
>> in the same way that brand named products satisfy consumers in a way
>> that generic products don't.
>
>The branding argument is amusing. A pitch to the ignorant.
When you go to the grocery store, do you buy Oreo cookies, or the
generic equivalent?
I agree that there is a certain amount of ignorance involved with
brand loyalty, but that doesn't mean it isn't a very powerful force.
>The issue becomes forcing a reconsidation by means of a name change, a
>misrepresentation.
No, there's no misrepresentation. Rather, invoking a brand provides
an endorsement. Some folks are just more comfortable when they have
endorsements. Remember the old saw: "Nobody every got fired for
buying IBM"?
>Once they have decided, it is over, the end. Sort of
>like creating confusion about the practices but changing them ever so
>slightly every once in a while. The results of productive feedback and
>cretive product positioning
A distaste for marketing is common amongst engineers.
David B Lightstone
"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
> On Sun, 01 Sep 2002 12:03:45 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >
> >"Uncle Bob (Robert C. Martin)"
> ><u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
> >news:pq13nugfereg4gom2...@4ax.com...
>
> >> Clearly if the stakeholders are rejecting XP on the basis of its
> >> practices, then replacing XP with dX would be fraudulent. On the other
> >> hand, the rejection of XP may be based upon brand. The stakeholders
> >> may want to know that the process being used is one that is well
> >> branded. dX carries the RUP brand and so may satisfy the stakeholders
> >> in the same way that brand named products satisfy consumers in a way
> >> that generic products don't.
> >
> >The branding argument is amusing. A pitch to the ignorant.
>
> When you go to the grocery store, do you buy Oreo cookies, or the
> generic equivalent?
>
> I agree that there is a certain amount of ignorance involved with
> brand loyalty, but that doesn't mean it isn't a very powerful force.
Well that all depends on what the grocery store carries. I don't know to
many grocery stories what offer perpackaged XP for sale. I do know of a
number of notorious authors who find it important to market their writtings
and apparently several versions of the methodology about which they write
>
> >The issue becomes forcing a reconsidation by means of a name change, a
> >misrepresentation.
>
> No, there's no misrepresentation. Rather, invoking a brand provides
> an endorsement. Some folks are just more comfortable when they have
> endorsements. Remember the old saw: "Nobody every got fired for
> buying IBM"?
When trolls and aliases start giving the recomendations it is just
marketing. When an informed party invokes the brand it is an endorsement.
For all but a few experts it is little more than name recognition.
>
> >Once they have decided, it is over, the end. Sort of
> >like creating confusion about the practices but changing them ever so
> >slightly every once in a while. The results of productive feedback and
> >cretive product positioning
>
> A distaste for marketing is common amongst engineers.
A distaste for making decisions based upon marketing influences is the
common characteristic. Marketing is a reality which all must face.
Fortunately only a few marketing agents can reach the heights of management
decision making authority where brand identification is a meaningful
criteria. Those few are a rare breed. You can never tell whether they are
marketing or developing technology.
Jeff Grigg
> >> that "you must use RUP; no deviation from the corporate standard is
> >> of RUP. It is RUP."
> "David B Lightstone" <david.lightst...@prodigy.net> wrote:
> >Ha HA, ever hear the espression Fradulent Pretext? How about
> >Misrepresentation?
> >There are torts which cover such conduct.
"Uncle Bob (Robert C. Martin)" wrote...
> The point is that dX *is* a valid instance of RUP. There is no fraud
> here. Developers who desire to do XP, but who are constrained by
> their management to use RUP, can feel safe about using dX.
>
> Of course, now, they can get the RUP/XP plug-in from Rational
> (http://www.rational.com/products/rup/xprog.jsp) which will guide them
> through what we used to call dX.
Certainly if those with legitimate authority object to particular
practices, such as pair programming, it would be dangerous and
dishonest to go ahead and do them under a fraudulent name. But in
real life, I find that the most significant barriers to a project's
progress are not the actual policies, but the misunderstandings and
logical fallacies of those policies that go on in people's minds.
I haven't done the dX/RUP thing, but I have used RUP when the customer
insisted that "we must do methodology 'S' instead:" Working with a
large customer, our group proposed a solution we had been successful
with in a number of similar situations before; it was based on a
customization of RUP we had developed to deal with that kind of
project. "But we have a problem with this." said our customer, "Out
top management recently considered all the methodologies of the
industry and declared that the standard for our company is
'methodology S', and that all projects must follow it. We can't let
you use RUP because top people in our company tell us that
'methodology S' is the required corporate standard." [That last
sentence contains a logical fallacy -- like "I'm not sure I can allow
you to wear wingtip shoes *because* the corporate dress code says you
must wear a white shirt" (...and says nothing about shoes.)]
I studied "methodology S" and found it to be primarily a numbering and
naming standard -- a standard for organizing the documents you
produce. (It also listed many common and industry standard documents
you might produce, but declared them all optional -- your choice as to
which ones to produce.)
So I renamed and updated our RUP documents to fully comply with the
naming and formatting standards of "methodology S." Where document
templates were given, I reformatted our content into their standard
format. In all discussions with the customer, we used "methodology S"
terminology and names. We knew that we were still also in compliance
with RUP -- doing both RUP and 'methodology S', but there was nothing
to be gained by "rubbing their noses" in it. Their people audited our
project, reviewed all our documentation, and found our project to be
fully compliant with the 'methodology S' guidelines. The project was
successful and everyone walked away happy. (Just don't tell them
about the "RUP" part; it'll just upset them. ;-)
When the customer says "I can't let you do 'X' *because* you have to
follow this guideline 'Y'." and the guideline 'Y' would let you do
'X', then someone is confused by the names, and doesn't really know
what is allowed or forbidden.
David B Lightstone
Your argument was so confusing that I gave up trying to follow it.
I think you are saying - first create fud as to the meaning of the
constraints and then do what you want to do
John Roth
"David B Lightstone" <david.lightst...@prodigy.net> wrote in
message news:O_Id9.222$hU6.80...@newssvr17.news.prodigy.com...
I'm surprised. I found his description quite clear. Possibly that's
because I've lived through the situation several times.
I wouldn't call what's going on FUD. I'd call it a bad case of
senior management being in a state of denial over what's happening
in their shop.
In other words, if you've got a document based methodology, and
all of the documents are optional, what have you got? Nothing of
any use whatsoever to anyone, frankly. Except, of course, the
people who want to continue doing the job the same way they
have always done it, and appear to be obeying senior management
directives while effectively ignoring them.
And that was the _client_ company's standards we're talking about.
John Roth
>
>