Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
Duncan
Guest
|
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
JXStern
Guest
|
 Posted: Sat Mar 24, 2007 9:16 pm Post subject: Re: Reducing Risk and Increasing the Probability of Project |
 |
|
On 24 Mar 2007 03:51:49 -0700, "Duncan" <dhaughey@hotmail.com> wrote:
Eh.
| Quote: |
Ask a few telling questions:
How long is an iteration?
The answer should be anywhere from a few days
to a maximum of about four weeks. Answers of
three months or more should indicate the process
is still waterfall with long feedback cycles
with the associated high risk of getting it
badly wrong before being able to rectify the situation.
|
On what is an average project for me that involves five to ten
developers, I'd say six to eight weeks is more like optimal.
| Quote: |
What is delivered at the end of each iteration?
The answer should be a demonstration of some actual
working software to the users, during which they will
have the opportunity to provide feedback. If the
answer is documents for sign-off, then they are
missing the point.
|
No, no, no. This is where I'm almost extreme. If you don't deliver
full production code, to the end-users, and put it into production
immediately, you are not even doing iterative.
(this is where I cannot reconcile myself at all to the language in RUP
books, they call it "iterative" if everybody drinks a beer at regular
intervals, or something)
Of course, if you are delivering to production every time, you can see
why an iteration needs to be a little longer.
| Quote: |
When do you the users see what they are going to get?
The answer should be at the end of every (short) iteration.
An answer of "only during acceptance testing prior to delivery"
is just not acceptable.
|
Sure, they see at the *end* of any iteration, but they should see
prototypes or drawings near the *beginning* of every iteration. If
delivery occurs at every iteration, there is acceptance testing at
every iteration, so this guy's answer makes no sense - because he's
using a RUP-ish idea of iteration, apparently.
| Quote: |
When do you intend to start integration testing?
The answer should be that integration testing is a continuous
activity that occurs during each iteration.
|
Yeah, "continuous" may be an overstatement, but it's certainly done
every iteration, and generally many times during each iteration.
| Quote: |
How do you manage risk?
The answer should be that there is a regular assessment
of risk, quantified in terms of probability and impact
to the development schedule along with proposed mitigation
strategies. The project manager should maintain a
running risk list, available for inspection by
all people associated with the project.
|
The funniest parts of RUP are when they talk about "risk".
You're driving from New York to California, how do you manage risk?
Answer if you discuss "risk" the way so many IT books do: everything
you do, is "managing risk", from driving with your eyes open, so you
don't fall to the risk of running off the road, to stopping every few
hours for rest and refreshment, so you don't black out from low blood
sugar, and the car doesn't fill up with piss. If you drive with your
eyes open, give yourself an "A" for risk-management. Ha.
Answer if you actually speak meaningfully about risk: The methodology
is a map of "risk" mitigations, and any risks SPECIFIC TO YOUR PROJECT
are generally handled by higher-level fallback plans. Yeah, also
avoiding dumb moves like changing platforms in mid-project, but that's
practically at the "keep your eyes open" level.
J. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Sat Mar 24, 2007 10:00 pm Post subject: Re: Reducing Risk and Increasing the Probability of Project |
|
|
"JXStern" <JXSternChangeX2R@gte.net> wrote in message
news:j5ma03ph2lui3jmut8icjla75nu5akll35@4ax.com...
| Quote: |
On 24 Mar 2007 03:51:49 -0700, "Duncan" <dhaughey@hotmail.com> wrote:
|
1) The credibility of the Standish Report has been recently questioned.
This might require us to revise some of the commonly accepted statistics.
2) Risk management is an important part of software practice, but it
requires much more mathematical sophistication than is reflected
in the Web site shown.
3) Many excellent software projects have been completed and deployed
using variations on the Waterfall method. However, naive application
of that method does lead to increased risks.
4) New approaches to software practice appear constantly, and each seems
to have its advocates. There is a kind of religiofication of methods,
and
and evangelical zeal for them. A method such as RUP, or any of the
other
so-called iterative methods requires as much, probably more, discipline
and
experience than the many variations of Waterfall, Spiral, etc.
5) There is no single process that substitutes for good management, good
planning,
and good people. A good process, under control of an incompetent team,
will not improve the quality of the software. On the other hand, I have
seen
projects with questionable process get put together just fine under the
leadership
of a good project manager with good people.
6) Any kind of engineering is ultimately a people-driven effort. This is why
we spend
so much time, money, and other resources educating engineers. It would be
useful
if we spent the same effort training software professionals.
Unfortunately, once a
software person learns a programming language and a few tricks, s/he seems
to think
that is all there is to know.
7) Software engineering is more than programming, more than process, and more
than
adopting the latest clever buzz-word methods. A good software engineer
needs to
be an engineer first, then a software engineer. However, an engineer
needs to realize
the limitations of traditional engineering in the managment of software.
The subtle
relationships between engineering and software engineering, programming and
engineering
technology, and the associated tradeoffs are seldom appreciated. Those
who emphasize
programming are as much at fault for the quality of software as those who
succumb to
to folly of relying on processes and methods.
Richard Riehle |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Sun Mar 25, 2007 1:26 am Post subject: Re: Reducing Risk and Increasing the Probability of Project |
|
|
Responding to Duncan...
Why is it that in all of these expositions of IID vs. Waterfall nobody
adjusts for scale? Answer: because (A) they want to make "waterfall" an
unqualified pejorative because it rolls off the tongue better in mantras
than "monolithic waterfall" and (B) they want to imply that they are
providing something new to replace waterfall models.
In fact, the risk benefits in the paper are primarily due to changing
the scale of the waterfall model, not eliminating it. Each iteration of
the IID executes exactly the same waterfall steps; all that is changing
is the scope of the steps. Since they are smaller they are more
manageable and, consequently, less risky.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Bjorn Reese
Guest
|
| Posted: Sun Mar 25, 2007 3:29 pm Post subject: Re: Reducing Risk and Increasing the Probability of Project |
|
|
adaworks@sbcglobal.net wrote:
| Quote: |
1) The credibility of the Standish Report has been recently questioned.
|
Do you have any references?
--
mail1dotstofanetdotdk |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Mon Mar 26, 2007 6:05 am Post subject: Re: Reducing Risk and Increasing the Probability of Project |
|
|
"Bjorn Reese" <breese@see.signature> wrote in message
news:46065b88$0$4158$ba624c82@nntp02.dk.telia.net...
| Quote: |
adaworks@sbcglobal.net wrote:
1) The credibility of the Standish Report has been recently questioned.
Do you have any references?
An article in the Communications of the ACM several issues |
ago. It was written, if I recall, by Bob Glass.
Richard Riehle |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
212 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
