Home > Archive > Software Engineering > May 2006 > Is the Unified Software Development Process Agile?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is the Unified Software Development Process Agile?
|
|
| Generic Usenet Account 2006-05-21, 10:03 pm |
| Apologies in advance if you feel this is OT.
There are two contrasting opinions that I have heard here regarding
UP/RUP. One is that UP/RUP, although a big improvement over previous
methodologies, is still not Agile. According to this school of
thought, by delineating between Inception, Elaboration, Construction
and Transition phases, the Unified Process departs from the more
holistic view of incremental development, as propagated by the
Agilists. Therefore, UP/RUP is not Agile.
The other view is that UP/RUP is just a framework (and not a
methodology), and within that framework you can fit in both Agile and
non-Agile approaches. In other words, RUP/UP is as Agile/non-Agile as
you want it to be.
I am keen to know what the software community at large feels about this
issue.
Gus
| |
| phlip 2006-05-21, 10:03 pm |
| Generic Usenet Account wrote:
> There are two contrasting opinions that I have heard here regarding
> UP/RUP. One is that UP/RUP, although a big improvement over previous
> methodologies, is still not Agile.
RUP is Agile. The book /Agile & Iterative Development: A Manager's Guide/
by Craig Larman investigates using RUP, contrasting it with Waterfall, and
compares it with Evo, XP, and Scrum.
> According to this school of
> thought, by delineating between Inception, Elaboration, Construction
> and Transition phases, the Unified Process departs from the more
> holistic view of incremental development, as propagated by the
> Agilists. Therefore, UP/RUP is not Agile.
During those phases, developers write the same amount of source code and
tests. Those phases could be considered a management thing, outside the
scope of XP, which only specifies team behaviors.
> The other view is that UP/RUP is just a framework (and not a
> methodology), and within that framework you can fit in both Agile and
> non-Agile approaches. In other words, RUP/UP is as Agile/non-Agile as
> you want it to be.
If you do RUP in phases, you are not doing RUP. Read:
"How to Fail with the Rational Unified Process"
http://www.agilealliance.org/articl...kruchtenph/file
(Note one of the authors is Larman.)
"Step 1: Superimpose 'Waterfall' Thinking
Step 2: Apply the RUP as a Heavy, Predictive Process
Step 3: Avoid Object Technology Skills
Step 4: Undervalue Adaptive Iterative Development
Step 5: Avoid Mentors Who Understand Iterative Development
Step 6: Adopt the RUP in a Big Bang
Step 7: Take Advice from Misinformed Sources
"Conclusion:
We are confident that by following these seven steps, and applying the
checklist of misunderstandings, your adoption of the RUP and iterative
development will be a spectacular mess."
--
Phlip
| |
| Gabriel Claramunt 2006-05-23, 8:03 am |
|
"phlip" <phlip2005@gEEEmail.com> wrote in message
news:pan.2006.05.21.16.38.05.889142@gEEEmail.com...
> Generic Usenet Account wrote:
>
>
> RUP is Agile. The book /Agile & Iterative Development: A Manager's Guide/
> by Craig Larman investigates using RUP, contrasting it with Waterfall, and
> compares it with Evo, XP, and Scrum.
IMHO (and experience) RUP can be as agile as one wants, the difference is
that you must really know the structure of the process, and how everything
fits together (I guess that XP doesn't suffer from that: you can follow
blindly all the practices). Anyhow, the bigger the project, the better you
can apply RUP.
>
RUP has a solid justification for the fases, even separating the life cycle
in two major stages: "engineering" (Inception and Elaboration) and
"production" (Construction and Transition).
[color=darkred]
> During those phases, developers write the same amount of source code and
> tests. Those phases could be considered a management thing, outside the
> scope of XP, which only specifies team behaviors.
Well, not exactly. In a "typical" RUP project, in Inception phase, usually
the coding is for prototypes and small PoC. In Elaboration, probably the
code will be 20% of the application, but will define the architecture. In
Construction is when most of the coding will take place. In Transition no
major coding effort is usually done (mostly bugfixes or minor enhancements,
a major release probably will require a new cycle). But yes, from a
programmer POV there's no much difference between phases, but for a project
manager or architect, the difference is big! :-)
>
> If you do RUP in phases, you are not doing RUP. Read:
>
> "How to Fail with the Rational Unified Process"
> http://www.agilealliance.org/articl...kruchtenph/file
>
Excellent paper, but RUP has phases :-) Of course, they're not the waterfall
phases, these phases guides the goals of each iteration. IMHO the focus
Phases are the main distinctive characteristic of RUP.
> --
> Phlip
Regards
Gabriel
| |
|
|
|
| carlosrf82 wrote:
> http://www.ambysoft.com/unifiedprocess/agileUP.html
> Look at this!!
Various consultants have written papers describing what you should do if
someone accidentally mentions "extreme" and your boss starts shrieking and
ranting...
--
Phlip
[url]http://c2.com/cgi/wiki?Z Land[/url] <-- NOT a blog!!!
| |
| Generic Usenet Account 2006-05-23, 7:04 pm |
| carlosrf82 wrote:
> http://www.ambysoft.com/unifiedprocess/agileUP.html
> Look at this!!
Thanks a lot for posting this link. I found it very helpful. IMHO,
the crux of this debate is succinctly conveyed by the following
paragraph:
[Begin quote]
XP doesn't explicitly show how to create some of the artifacts which
management wants to see. This is an unfortunate attitude because XP is
a great process. On the other end of the spectrum is RUP, which
management seems to love but developers seems leery of due to the large
number of artifacts. This is also unfortunate because the RUP has a
lot to offer, and can be cut down to something quite useful (which is
exactly what IBM Rational recommends you do). The AUP lands between
the two, adopting many of the agile techniques of XP and other agile
processes yet retaining some of the formality of the RUP.
[End quote]
Gus
| |
| H. S. Lahman 2006-05-23, 7:04 pm |
| Responding to Account...
> The other view is that UP/RUP is just a framework (and not a
> methodology), and within that framework you can fit in both Agile and
> non-Agile approaches. In other words, RUP/UP is as Agile/non-Agile as
> you want it to be.
As others have indicated, I believe this is the correct view and I won't
belabor it.
What I would like to push back on is a quibble: the role of methodology
in software development. In a dictionary sense 'methodology' and
'process' are virtually synonymous. However, in software development
they are not.
The reason is that software development is schizophrenic in that there
is both a large intellectual content provided by the developer and a
large amount of routine grunt work (e.g., configuration management, test
automation, version control, etc.). So it is useful in software
development to distinguish between these two broad classes of activities
and we use the existing words to do that.
Generally 'methodology' is reserved for the largely creative
intellectual activities that go into software development. A
methodology provides rules, guidelines, practices, etc. that guide the
design at every level of software creativity (e.g., OOA, OOD, OOP).
Thus there are as many OO methodologies as there are OOA/D authors.
(Books like Fowler's "Refactoring" are also primarily methodological in
nature even though they apply to only OOP.)
Typically 'process' is reserved to describe the more mundane procedural
tasks that surround the intellectual activities of software design.
Process steps and activities are typically defined rigorously once and
are followed religiously. IOW, a process defines when one does various
activities and defines how to do those activities that are not creative.
Thus XP is a rigorously defined process while some placeholder
activities identified within it, such as refactoring, are methodological.
So my quibble is that RUP is really a /process/ framework, not a
methodological framework. One defines the specific processes one will
use locally, such as XP, and maps them into the RUP framework. It is
the local process that, in turn, defines where design activities take
place (i.e., when they are done and how they are supported by tools and
other activities like version control). But the methodological
activities themselves will be pretty much the same in any OO environment
(i.e., basic OOA/D/P) whether one uses RUP, XP or any number of other
frameworks/processes. (That is, whether one employs UML and a code
generator or CRCs and militant refactoring in the process, the OOA/D/P
design principles will be the same.)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| Generic Usenet Account wrote:
> [Begin quote]
> XP doesn't explicitly show how to create some of the artifacts which
> management wants to see. This is an unfortunate attitude because XP is
> a great process.
XP defines the minimum artifacts possible. Story cards, test cases,
acceptance tests, period. The rest are optional.
> On the other end of the spectrum is RUP, which
> management seems to love but developers seems leery of due to the large
> number of artifacts.
I have heard that RUP defines many artifacts and doesn't require all of
them.
Unfortunately, managers might require them, as a security blanket.
> This is also unfortunate because the RUP has a
> lot to offer, and can be cut down to something quite useful (which is
> exactly what IBM Rational recommends you do). The AUP lands between
> the two, adopting many of the agile techniques of XP and other agile
> processes yet retaining some of the formality of the RUP.
> [End quote]
How is RUP more formal than XP?
XP requires strict and very formal implementation procedures. TDD in place
of debugging, and acceptance tests that an onsite customer can author. That
sounds very exact and formal to me.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-05-24, 7:03 pm |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:HfZcg.14194$fb2.13857@newssvr27.news.prodigy.net...
> Generic Usenet Account wrote:
>
>
> XP defines the minimum artifacts possible. Story cards, test cases,
> acceptance tests, period. The rest are optional.
Unfortunately, managers might require them, as a security blanket.
>
>
> I have heard that RUP defines many artifacts and doesn't require all of
> them.
>
> Unfortunately, managers might require them, as a security blanket.
So XP development requires managers willing to take greater risks?
>
>
> How is RUP more formal than XP?
>
> XP requires strict and very formal implementation procedures. TDD in place
> of debugging, and acceptance tests that an onsite customer can author.
> That sounds very exact and formal to me.
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
>
| |
| Andrew McDonagh 2006-05-25, 7:03 pm |
| David Lightstone wrote:
> "Phlip" <phlipcpp@yahoo.com> wrote in message
> news:HfZcg.14194$fb2.13857@newssvr27.news.prodigy.net...
>
>
> Unfortunately, managers might require them, as a security blanket.
>
>
Thats ok, XP does not say you cant have them, it merely asks do you
really need them.
If the managers do require them (even as security blankets instead of
corporate standards/committees), then a Story card for their creation
should be made and it should be prioritized like any other story.
By making a story card for them, the managers get to see the
value-vs-cost of these, within the release plan.
>
> So XP development requires managers willing to take greater risks?
I would say 'different' risks.
Different as in, they come at different times, the risks are different
because the deliverables and phases of the project are different from
what they might be used to.
| |
| David Lightstone 2006-05-25, 7:03 pm |
|
"Andrew McDonagh" <news@andmc.com> wrote in message
news:e54sl7$otk$1@news.freedom2surf.net...
> David Lightstone wrote:
>
> Thats ok, XP does not say you cant have them, it merely asks do you really
> need them.
>
> If the managers do require them (even as security blankets instead of
> corporate standards/committees), then a Story card for their creation
> should be made and it should be prioritized like any other story.
>
> By making a story card for them, the managers get to see the value-vs-cost
> of these, within the release plan.
>
>
>
> I would say 'different' risks.
>
> Different as in, they come at different times, the risks are different
> because the deliverables and phases of the project are different from what
> they might be used to.
The intent was to note that in both situations RUP and XP a decision as to
which risks will or will not be taken must be made. In Phlip's post the
quote
"Unfortunately, managers might require them, as a security blanket." conveys
the image - because they may decide to not take certain risks, XP is better.
That is XP managers will be willing to take greater risks
| |
| Gabriel Claramunt 2006-05-26, 4:02 am |
| Incidentally, the first 2 phases of RUP, are mapped to the principal risks
of a software process:
1) Inception deals scope risk: what is the goal of the project / what are
you going to build
2) Elaboration deals with technology risks: how you are going to build that.
IMHO embbeding the main risks into the phases of the process is a good idea,
as you make risk management an integral part of the process, and not an
activity divorced from the main flow and performed only by the manager.
> The intent was to note that in both situations RUP and XP a decision as to
> which risks will or will not be taken must be made. In Phlip's post the
> quote
> "Unfortunately, managers might require them, as a security blanket."
> conveys the image - because they may decide to not take certain risks, XP
> is better. That is XP managers will be willing to take greater risks
>
>
| |
|
| Gabriel Claramunt wrote:
> Incidentally, the first 2 phases of RUP, are mapped to the principal risks
> of a software process:
> 1) Inception deals scope risk: what is the goal of the project / what are
> you going to build
> 2) Elaboration deals with technology risks: how you are going to build
> that.
>
> IMHO embbeding the main risks into the phases of the process is a good
> idea, as you make risk management an integral part of the process, and not
> an activity divorced from the main flow and performed only by the manager.
Many years ago, someone who had heard of "risk management" asked the XP
mailing list "What is XP's strategy for dealing with risk?"
Someone answered, "What is a fish's strategy for dealing with water?"
XP _is_ a strategy for dealing with risk. The two steps you wrote are narrow
ways to address specific risks in specific ways. I'm sure RUP has other
practices that reduce risk in general. And I'm sure RUP does not forbid the
following practices, just as XP doesn't forbid learning from other projects.
- put all engineers in one room. That way, when Alice and Bob encounter a
risk, Carl already knows what they are doing and can help
- onsite customer, to rapidly decide which discovered risks must be fixed in
this iteration, and which can wait
- test driven development, to reduce the risk of excess debugging
- refactoring, to reduce the very serious risk that code will grow crufty
and hard to change over time
- frequent releases, to reduce the risk that what users ask for isn't what
they need
- planning game, to reduce the risk the onsite customer doesn't know what we
will work on this w, and to sort features by business value. That reduces
the risk that we work on something unimportant and low-risk while a nasty
surprise lurks around the corner
- pair programming, to reduce the risk that I write something
unmaintainable, or you write something impenetrable, and I can't change it
later without you
- continuous integration, because delaying integration causes incredible
risk
- sustainable pace, because companies like Entertainment Arts have performed
studies showing that sleep deprivation is as bad as being drunk
- simple design, to reduce the risk I pad my resume
- acceptance tests, because the act of analyzing a feature is the act of
authoring its test cases. if you can't figure out a test for something, then
all your other analysis about it is going to cause risk
Now, what kinds of risks did you think XP couldn't address?
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-05-26, 7:03 pm |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:dSDdg.9$VE1.0@newssvr14.news.prodigy.com...
> Gabriel Claramunt wrote:
>
>
> Many years ago, someone who had heard of "risk management" asked the XP
> mailing list "What is XP's strategy for dealing with risk?"
>
> Someone answered, "What is a fish's strategy for dealing with water?"
>
> XP _is_ a strategy for dealing with risk. The two steps you wrote are
> narrow ways to address specific risks in specific ways. I'm sure RUP has
> other practices that reduce risk in general. And I'm sure RUP does not
> forbid the following practices, just as XP doesn't forbid learning from
> other projects.
>
> - put all engineers in one room. That way, when Alice and Bob encounter a
> risk, Carl already knows what they are doing and can help
>
> - onsite customer, to rapidly decide which discovered risks must be fixed
> in this iteration, and which can wait
>
> - test driven development, to reduce the risk of excess debugging
>
> - refactoring, to reduce the very serious risk that code will grow crufty
> and hard to change over time
>
> - frequent releases, to reduce the risk that what users ask for isn't what
> they need
>
> - planning game, to reduce the risk the onsite customer doesn't know what
> we will work on this w, and to sort features by business value. That
> reduces the risk that we work on something unimportant and low-risk while
> a nasty surprise lurks around the corner
>
> - pair programming, to reduce the risk that I write something
> unmaintainable, or you write something impenetrable, and I can't change it
> later without you
>
> - continuous integration, because delaying integration causes incredible
> risk
>
> - sustainable pace, because companies like Entertainment Arts have
> performed studies showing that sleep deprivation is as bad as being drunk
>
> - simple design, to reduce the risk I pad my resume
>
> - acceptance tests, because the act of analyzing a feature is the act of
> authoring its test cases. if you can't figure out a test for something,
> then all your other analysis about it is going to cause risk
>
> Now, what kinds of risks did you think XP couldn't address?
>
Little more than Marketing hype. ie same old same old XP mantra with the
work - risk - added to catch everybodies attention
Risk management is about identifying risks, deciding whether you want to
take them and more importantly having prepositioned strategies should the
risk become reality
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
>
| |
| Gabriel Claramunt 2006-05-27, 8:02 am |
| >Now, what kinds of risks did you think XP couldn't address?
Building the right product within reasonable time and cost with the choosen
technology: as the story goes, the XP flagship project (C3) was cancelled
and considered a complete failure by the sponsors, without even been capable
of covering the 10% of the payroll ....
But ok, don't get me started on XP, I was just speaking about RUP. :-)
I'm just saying that RUP _EXPLICITLY_ deals with some risks. The goals of
inception and elaboration are to minimize those risks.
Those "specific" risks are the most important risks affecting a software
project:
1) Are whe building the right product?
2) Can the project be completed within reasonable time and cost with the
choosen technology?
As the complexity of the project increases, those risk do too.
I see value on adding those to the process and involve the developers on the
risk reduction, and not leaving the risk management as a complete separate
activity performed by the project manager, or out of scope (as in the case
of XP)
Saying "What is a fish's strategy for dealing with water?" maybe is
appropiate: a fish doesn't have any known strategy for dealing with water
:-)
The fish can simply ignore the water, but ignoring the risks doesn't make
them go away, and the probability of a failure (definition of risk) keeps
high through the project.
From a pure developer POV, RUP is just a series of iterations, but when you
take the project organization view, it makes a lot of sense...
| |
| rmoldskr+usenet@online.no 2006-05-27, 8:02 am |
| In comp.software-eng Gabriel Claramunt <gabclar@internet.com.uy> wrote:
> Saying "What is a fish's strategy for dealing with water?" maybe is
> appropiate: a fish doesn't have any known strategy for dealing with water
Actually, fish have many _different_ strategies for dealing with water;
some cheap and inflexible, others complex but adaptable and yet others
niche specialities.
Flounders and shark don't deal with water in the same way, and that's
before getting into the more obvious cases such as flying fish, archer
fish or lungfish.
--
Leif Roar Moldskred
| |
| Dmitry A. Kazakov 2006-05-27, 8:02 am |
| On Sat, 27 May 2006 02:53:32 -0500, rmoldskr+usenet@online.no wrote:
> In comp.software-eng Gabriel Claramunt <gabclar@internet.com.uy> wrote:
>
> Actually, fish have many _different_ strategies for dealing with water;
> some cheap and inflexible, others complex but adaptable and yet others
> niche specialities.
>
> Flounders and shark don't deal with water in the same way, and that's
> before getting into the more obvious cases such as flying fish, archer
> fish or lungfish.
Hmm, I am not sure about the analogy. Fish dies without water. So would XP
without risk? That does not much look as an argument in favor of XP! (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
| |
| David Lightstone 2006-05-27, 8:02 am |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:dSDdg.9$VE1.0@newssvr14.news.prodigy.com...
> Gabriel Claramunt wrote:
>
>
> Many years ago, someone who had heard of "risk management" asked the XP
> mailing list "What is XP's strategy for dealing with risk?"
>
> Someone answered, "What is a fish's strategy for dealing with water?"
The someone was trying to evade the issue. Now if he had said - "What is a
fish's strategy for dealing with being out of water?" - I might take him
serious.
| |
|
| Gabriel Claramunt wrote:
[color=darkred]
> Building the right product within reasonable time and cost with the
> choosen technology:
You mean via frequent releases in order of business value?
Now here comes the old chestnut:
> as the story goes, the XP flagship project (C3) was cancelled and
> considered a complete failure by the sponsors, without even been capable
> of covering the 10% of the payroll ....
One goal of Agile development is to force problems to detect early. That's
why we insist on writing the highest value features first, and delivering
them as frequently as possible.
The C3 project's clients didn't take early delivery. The code worked well
enough for most of the payroll, and the code was proven to work correctly.
(It wasn't full of bugs or anything.) But the business side refused to
install it, for whatever reasons.
One reason was the takeover with Daimler.
So the C3 project represents successfully detecting a risk (obstinant
business side) very early. The failure, for whatever aspect of failure,
happened long after the risk was known.
And Daimler/Chrysler still uses XP for their in-house projects. Why would
they use it if _they_ thought it wouldn't work? Don't say "inertia"...
> But ok, don't get me started on XP, I was just speaking about RUP. :-)
> I'm just saying that RUP _EXPLICITLY_ deals with some risks. The goals of
> inception and elaboration are to minimize those risks.
And what if you discover a risk after those phases?
> Those "specific" risks are the most important risks affecting a software
> project:
> 1) Are whe building the right product?
Frequent releases in order of business value.
> 2) Can the project be completed within reasonable time and cost with the
> choosen technology?
Same answer. If you have the best team and tools, but can't produce the
first release, then you have successfully learned something about the
project. And you learn it long before wasting lots of money on it.
> As the complexity of the project increases, those risk do too.
> I see value on adding those to the process and involve the developers on
> the risk reduction, and not leaving the risk management as a complete
> separate activity performed by the project manager, or out of scope (as in
> the case of XP)
Risk management is not out of scope of XP.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Robert Martin 2006-05-28, 4:01 am |
|
[color=darkred]
There is a difference between ceremony and formality. RUP is high in
ceremony because it is rife with many phases, activities and artifacts;
but is informal because those activities and workproducts are not
necessarily coupled to getting the real end goal completed. XP/Agile
is low in ceremony because there are very few activities and
workproducts; but highly formal because those activities and
workproducts are directly coupled to the end goal. Indeed, the
workproducts are so formal that they execute. They are the unit tests,
and acceptance tests that specify the production code.
--
----
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Robert Martin 2006-05-28, 8:03 am |
| On 2006-05-26 00:36:41 -0500, "Gabriel Claramunt"
<gabclar@internet.com.uy> said:
> Incidentally, the first 2 phases of RUP, are mapped to the principal
> risks of a software process:
> 1) Inception deals scope risk: what is the goal of the project / what
> are you going to build
> 2) Elaboration deals with technology risks: how you are going to build that.
>
> IMHO embbeding the main risks into the phases of the process is a good
> idea, as you make risk management an integral part of the process, and
> not an activity divorced from the main flow and performed only by the
> manager.
I agree that assessing risk early is a good idea. The question is HOW
do you assess risk and how do you make certain that the risks are truly
answered?
Larger projects require more ceremony over this issue than smaller
project; but both require equal amounts of formality. In a very large
project you may need to spend a relatively short time creating a
backlog of risks to be addressed. In a smaller project that backlog
will be self-evident and requires no preliminary phase. In either case
addressing the risks is a matter of implementing small portions of the
risky features and measuring the results of that implementation. This
, of course, is where XP/Agile shines.
--
----
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Robert Martin 2006-05-28, 8:03 am |
| On 2006-05-26 09:00:41 -0500, "Phlip" <phlipcpp@yahoo.com> said:
> Many years ago, someone who had heard of "risk management" asked the XP
> mailing list "What is XP's strategy for dealing with risk?"
>
> Someone answered, "What is a fish's strategy for dealing with water?"
That was Kent.
> XP _is_ a strategy for dealing with risk.
I disagree. XP provides some tools for dealing with risk; however, XP
can also be a strategy to ignore risk. XP does not prevent teams from
roaring ahead implementing stories while remaining willfully ignorant
of the risk factors.
In order to deal with risk, people must work to understand the risk
areas and then prioritize them approriately.
In many smaller projects, high risk factors are typically the same as
high business value factors. So teams who follow business value first
will deal with risk up front. But there are projects where risk and
business value are not so closely associated. In those cases someone
must be actively identifying and prioritizing risks.
--
----
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Robert Martin 2006-05-28, 8:03 am |
| On 2006-05-26 23:11:19 -0500, "Gabriel Claramunt"
<gabclar@internet.com.uy> said:
> Building the right product within reasonable time and cost with the
> choosen technology: as the story goes, the XP flagship project (C3) was
> cancelled and considered a complete failure by the sponsors, without
> even been capable of covering the 10% of the payroll ....
That story has been told many times in many ways. You can interpret
the project as a success or as a failure. You can claim that they paid
two thirds of the pay grades, or one tenth of the employees. You can
claim it was the XP flagship project or that it was just another
project that happened to use XP. All that is moot.
XP has been around for a very long time now, and many project have used
it. There have been many spectacular successes as well as some
spectacular failures. But there has also been a ground swell of people
using it, or Agile techniques derived from it. So the old C3 argument
needs to be put away on a shelf and newer data should be used. After
all, if C3 had been done with RUP it would almost certainly have been
cancelled too.
> I'm just saying that RUP _EXPLICITLY_ deals with some risks.
No, it explicitly TELLS you to deal with risks. There's a big
difference. RUP does not guarantee that you have found all the risks
and prioritized them correctly. Neither does XP.
The XP strategy for risk is "Business Value First". If you implement
the high business value stories first, you are very likely to find the
high risk stories in with them. This is a decent strategy for many
small to medium sized projects. However, there are bigger projects in
which risk and business value are not strongly associated. For them
you need a RUP-like phase inception/elaboration phase in which you
explicitly hunt for the risks and find them. And THEN you still need
to work business-value first.
> The goals of inception and elaboration are to minimize those risks.
> Those "specific" risks are the most important risks affecting a
> software project:
> 1) Are whe building the right product?
> 2) Can the project be completed within reasonable time and cost with
> the choosen technology?
These are questions that must be asked continuously throughout the
project. It doesn't matter whether the project uses XP or RUP. If you
only deal with this up front, then you can find yourself in the same
situation that C3 found itself. The political landscape can change;
the financial motivations can change, and the project can go from
essential to irrelevant without your knowledge.
> From a pure developer POV, RUP is just a series of iterations, but when
> you take the project organization view, it makes a lot of sense...
It makes sense to follow some o the advice of RUP. The problem with
RUP is that it is so broad and encompassing that you can do pure
waterfall and claim it to be RUP. RUP is mostly a catalog of
practices, activities, workflows, and artifacts. This is good, but it
is too permissive.
Any good project manager will pick and choose from XP, RUP, SCRUM, etc,
etc, to put together the process that is right for the teams. That
process should include:
1. Very short iterations with measured progress.
2. Test Driven Development
3. Continuous Integration
4. Voice of the Customer: Business Value First.
5. Just in time requirments and planning.
6. intense collaboration and communication
7. PRIDE OF CRAFTSMANSHIP.
And others, possibly including risk backlogs. Not in priority order.
----
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| David Lightstone 2006-05-28, 10:02 pm |
|
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2006052808184875249-unclebob@objectmentorcom...
> On 2006-05-26 00:36:41 -0500, "Gabriel Claramunt"
> <gabclar@internet.com.uy> said:
>
>
> I agree that assessing risk early is a good idea. The question is HOW do
> you assess risk and how do you make certain that the risks are truly
> answered?
Is that a rhetorical question, or a claim of ignorance?
Based upon subsequent comments I will treat it as a claim of ignorance
See Elain Hall - Managing Risk
DeMarco & Lister - Waltzing With Bears
>
> Larger projects require more ceremony over this issue than smaller
> project; but both require equal amounts of formality. In a very large
> project you may need to spend a relatively short time creating a backlog
> of risks to be addressed.
Backlog of risks to be addressed!!!! Don't be silly. You never have a
backlog of risks. You can only have a backlog of risks that are ignored. Not
knowing which of the are significant, well that is what optimism is for,
none of them are really significant anyway, right?
> In a smaller project that backlog will be self-evident and requires no
> preliminary phase.
Should be evident, but there are process that are risk naieve. I strongly
suspect XP/Agile are amongst them
> In either case addressing the risks is a matter of implementing small
> portions of the risky features and measuring the results of that
> implementation. This , of course, is where XP/Agile shines.
Wrong!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!
> --
>
> ----
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
>
>
>
| |
| Gabriel Claramunt 2006-05-29, 4:11 am |
| > Risk management is not out of scope of XP.
Well, some risk are dealt explicity (like integration), but most of them are
ignored.
Maybe I should claim my own variation: RiXP
Instead of prioritizing by business value, the user stories are prioritized
based on risk: the riskier user stories are implemented first.
That would make the project's risk decrease noticeabily in each iteration.
Even more: if you had calculated the risk exposure for each user story, you
can sum all and and have the total risk exposure for the project, and you
can calculate the reduction of risk for each iteration and call it "risk
reduction velocity".
Well, if you want to implement RiXP, I'm open for consulting on :-)
Warm regards
Gabriel Claramunt
| |
|
| Gabriel Claramunt wrote:
[color=darkred]
> Well, some risk are dealt explicity (like integration), but most of them
> are ignored.
Example?
> Maybe I should claim my own variation: RiXP
> Instead of prioritizing by business value, the user stories are
> prioritized based on risk: the riskier user stories are implemented first.
That is Spiral, and it's the fulcrum of Barry Boehm's beef with XP.
> That would make the project's risk decrease noticeabily in each iteration.
The business value would not increase.
Now what if the biggest technical risk is "it won't scale", but the biggest
business risk is "we don't even have 1 user yet".
Get the one user. Then refactor and add features to make it scalable.
Test-driven development changes these formulas. It makes important things
easy to defer. Delaying expensive decisions until the last cheap responsible
moment is the heart of the "lean software development" ideals.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Gabriel Claramunt 2006-05-29, 4:11 am |
|
>
> No, it explicitly TELLS you to deal with risks. There's a big
> difference. RUP does not guarantee that you have found all the risks and
> prioritized them correctly. Neither does XP.
>
RUP doesn't guarantee that you will find all the risks, but one big risk in
software development is integration, both XP and RUP deals explicitly with
it: XP with "continuos integration" and RUP by iterations.
Goals (scope) and technology are also big risks for most of projects (if not
the biggest ones), the goals of the inception and elaboration phases in RUP
are aligned with the minimization of these risks.
And I find that a very good idea. :-)
Of course there are more risks, but those common to almost all software
projects I think are better managed if they're dealt explicitly in the
development process. Even in small projects, I found technology risks (you
always have a new framework, a new database, or a strange combination of
technologies where you are unsure of the results)
Most of the times, they're tied to business value and XP can deal with them,
but if they're not in the highest priority for business, they will not get
caught by the process.
>It makes sense to follow some o the advice of RUP. The problem with
>RUP is that it is so broad and encompassing that you can do pure
>waterfall and claim it to be RUP. RUP is mostly a catalog of
>practices, activities, workflows, and artifacts. This is good, but it
>is too permissive.
I saw that even from Rational, but you can do waterfall and claim to be RUP
in the same way you can do code and fix and claim to be XP: no way :-)
Specifically: how do you claim elaboration complete if you don't have an
executable and tested architecture with the critical use cases implemented?
Warm regards
Gabriel Claramunt
| |
| Robert Martin 2006-05-30, 4:02 am |
| On 2006-05-29 01:34:48 -0500, "Gabriel Claramunt"
<gabclar@internet.com.uy> said:
> Well, some risk are dealt explicity (like integration), but most of
> them are ignored.
> Maybe I should claim my own variation: RiXP
> Instead of prioritizing by business value, the user stories are
> prioritized based on risk: the riskier user stories are implemented
> first.
XP makes the (sometimes erroneous) assumption that risk and business
value are so closely related that you might as well just use business
value. Indeed this argument hold up under most situations and only
breaks down for the corner cases.
Something that is high risk, but low value is, in fact, low risk. The
technical risk may be high; but the impact of failure is low, and
therefore the business risk is low.
I have seen this fail only one or two times in the context of a highly
competative commodity environment with so many features that the
customer simply could not keep track of any but the NEW GLITZY features
that were going to sell this season's new version. The customers were
so focussed on the new features that they couldn't even think about the
core functionality.
In that instance we had to establish a special risk backlog so that
everybody was reminded that this project still had to do it's real job.
--
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Robert Martin 2006-05-30, 4:02 am |
| On 2006-05-29 01:43:17 -0500, "Gabriel Claramunt"
<gabclar@internet.com.uy> said:
>
>
> RUP doesn't guarantee that you will find all the risks, but one big risk in
> software development is integration, both XP and RUP deals explicitly with
> it: XP with "continuos integration" and RUP by iterations.
Actually the first time I saw the term "Continuous Integration" was in
Phillipe Kruchten's book on RUP.
> Goals (scope) and technology are also big risks for most of projects (if not
> the biggest ones), the goals of the inception and elaboration phases in RUP
> are aligned with the minimization of these risks.
> And I find that a very good idea. :-)
I think it's a fine idea. It's not what most people use those initial
RUP phases for, but that's a side point.
More importantly, in RUP those initial phases are populated by short
iterations that produce executable code. Risk, in RUP, is managed the
same way it is in XP, by creating executable releases that demonstrate
that the risk is, or can be, mitigated. The difference between XP and
RUP in this regard is that RUP makes the risk reduction exercise
explicit; while XP assumes that risk will be reduced if you implement
in business value order. This assumption holds true for most projects.
>
> Most of the times, they're tied to business value and XP can deal with them,
> but if they're not in the highest priority for business, they will not get
> caught by the process.
True. But in most cases the fact that they aren't high priority means
that the risk is not high.
>
[color=darkred]
> I saw that even from Rational, but you can do waterfall and claim to be RUP
> in the same way you can do code and fix and claim to be XP: no way :-)
> Specifically: how do you claim elaboration complete if you don't have an
> executable and tested architecture with the critical use cases implemented?
We completely agree that both can be abused. The difference is that
the XP community points out the abuse, rather loudly, and Rational
people are relatively silent (and even in some cases ecouraging of) the
abuse. IMHO.
--
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Robert Martin 2006-05-30, 4:02 am |
| On 2006-05-28 18:03:01 -0500, "David Lightstone"
<david._NoSpamlightstone@prodigy.net> said:
>
> Is that a rhetorical question, or a claim of ignorance?
> Based upon subsequent comments I will treat it as a claim of ignorance
Thank you for your kind indulgence. We ignorant folk are most humbly
grateful for your imminent knowledge and wisdom. The world would be a
far poorer place without your brightness.
--
Robert C. Martin (Uncle Bob)__| email: unclebob@objectmentor.com
Object Mentor Inc._ _ _ _ _ __| blog:__www.butunclebob.com
The Agile Transition Experts__| web:___www.objectmentor.com
800-338-6716_ _ _ _ _ _ _ _ __|
| |
| Laurent Bossavit 2006-05-30, 4:02 am |
| Phlip,
> Test-driven development changes these formulas. It makes important things
> easy to defer. Delaying expensive decisions until the last cheap responsible
> moment [...]
Yep. I just today had that conversation with the Customer on my current
project. "How about the SQL Injection Attack ?" That's both a risk, and
a chunk of work which challenges the "User Story" model - it doesn't,
per se, have business value.
That issue is neatly solved by using "User Anti-Stories" - stories
expressed from the point of view of The Attacker, e.g. "I am able to
bring down Customer's extranet". They have negative business value, and
can otherwise be subject to acceptance tests, etc.
Then, from a developer on the project: "Everybody knows the only way to
implement SQL Injection countermeasures is right at the start of the
project, before the codebase becomes littered with SQL request
constructions based on interpolating dirty variables."
That's true... *if* your coding practice allows the codebase to become
littered with such redundancies. Then protecting against SQL Injection
will cost more if you implement it later. Therefore it's more
professional to leave the Customer no choice as to when the protection
is implemented.
Since there are N security issues for which an equivalent argument
obtains, it follows that any significant Web project must either a)
spend 3 months on such issues before delivering any business-relevant
features, or b) rely on a humongous Web framework which none of the
developers on the team will entirely master, unless they wrote it -
which reduces to case a).
Enter TDD - which requires that, the second time you use "INSERT INTO"
or "SELECT FROM", you should factor out any common parts. Followed
diligently, TDD results in code where countermeasures to SQL Injection
can be added to the codebase at anytime, at constant cost - the cost of
modifying a couple methods.
The result - it's up to the Customer to decide when they want to pay the
cost of SQL Injection countermeasures. "Pay later" is an interesting
option, for instance when the project's further funding could well
depend on a demo scheduled to happen a couple iterations into the
project.
Laurent
| |
|
| Laurent Bossavit wrote:
> Yep. I just today had that conversation with the Customer on my current
> project. "How about the SQL Injection Attack ?" That's both a risk, and
> a chunk of work which challenges the "User Story" model - it doesn't,
> per se, have business value.
"Resist attacks" has business value, but it can't be tested. So it leads to
a Motherhood Story, which leads to standard operating procedures in each
iteration, such as a review of the current features' attack risks.
> Enter TDD - which requires that, the second time you use "INSERT INTO"
> or "SELECT FROM", you should factor out any common parts. Followed
> diligently, TDD results in code where countermeasures to SQL Injection
> can be added to the codebase at anytime, at constant cost - the cost of
> modifying a couple methods.
Uh, reading the SQL documentation and assembling parameterized queries is a
little more robust than concatenating strings all the time. "INSERT INTO " +
foo, etc.
And note that parameterized queries should also be the result of duplication
removal, both in your code and in your SQL library...
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Laurent Bossavit 2006-05-30, 4:02 am |
| Phlip,
> Uh, reading the SQL documentation and assembling parameterized queries is a
> little more robust than concatenating strings all the time.
Unless you're coding in PHP, but point well taken. :)
Laurent
| |
|
| Laurent Bossavit wrote:
>
> Unless you're coding in PHP, but point well taken. :)
Why is the language important? Can't you go PHP -> ORB -> a generic
parameterized query system -> any DB? or has ADO spoiled me??
So is this the source of PHP's reputation for weak security? If PHP is a
real language, can't someone _write_ a parameterized query system?
"select %s from %s", foo, bar
How hard could _that_ be???
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-05-30, 4:02 am |
|
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:200605291021448930-unclebob@objectmentorcom...
> On 2006-05-28 18:03:01 -0500, "David Lightstone"
> <david._NoSpamlightstone@prodigy.net> said:
>
>
> Thank you for your kind indulgence. We ignorant folk are most humbly
> grateful for your imminent knowledge and wisdom. The world would be a far
> poorer place without your brightness.
From your sarcasm I take it that both
(1) Your question was not rhetorical.
(2) you disagree with my evaluation of your subsequent comments.
Best of luck in your efforts to become informed.
> --
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
>
>
>
| |
| Laurent Bossavit 2006-05-30, 4:02 am |
| Phlip,
> Why is the language important? Can't you go PHP -> ORB -> a generic
> parameterized query system -> any DB? or has ADO spoiled me??
What's ORB ?
There seems to be a DB abstraction layer "out there" for PHP that does
have prepared statements. We might use that... Mostly I meant to use the
case of SQL Injection as a concrete illustration of what TDD brings.
Laurent
| |
| phlip 2006-05-30, 10:01 pm |
| Laurent Bossavit wrote:
> What's ORB ?
In theory it's "any Object Request Broker", but in practice it's just
either ActiveX or CORBA.
--
Phlip
|
|
|
|
|