Philippe Kruchten - From Waterfall to Iterative Lifecycle ; A tough transition for project manager [2000].pdf - Project_Management ok - kmichalo1

From Waterfall to Iterative

Lifecycle –

A tough transition for

project managers

Philippe Kruchten

Rational Software White Paper

TP- 173 5/00

From Waterfall to Iterative Lifecycle

Table of Contents

Introduction ....................................................................................................................... 2

More planning work ......................................................................................................... 2

Trap: Overly detailed planning up to the end............................................................................................. 2

Acknowledging rework up-front ..................................................................................... 2

Trap: Project not converging...................................................................................................................... 3

Trap: Let’s get started, we’ll decide where to go later ............................................................................... 3

Trap: Falling victim of your own success ................................................................................................... 3

Putting the software first .................................................................................................. 3

Trap: Focus on the wrong artifact.............................................................................................................. 4

Hitting hard problems earlier .......................................................................................... 4

Trap: Putting your head in the sand ........................................................................................................... 4

Trap: Forgetting about new risks ............................................................................................................... 4

Clashes of lifecycle models................................................................................................ 4

Trap: Different groups operating on their own schedule ........................................................................... 5

Trap: Fixed-price bidding in inception....................................................................................................... 5

Accounting for progress is different ................................................................................ 5

Deciding on number, duration and content of iterations .............................................. 5

Trap: Pushing too much in the first iteration ............................................................................................. 6

Trap: Too many iterations .......................................................................................................................... 6

Trap: Overlapping iterations ...................................................................................................................... 6

A good project manager and a good architect................................................................ 7

Trap: Use the same person as the PM and the architect ............................................................................ 7

Conclusion.......................................................................................................................... 7

Acknowledgements............................................................................................................ 8

Further Reading ................................................................................................................ 8

From Waterfall to Iterative Lifecycle

Introduction

Although the Rational Unified Process ™ (RUP) advocates an iterative or spiral approach to the software

development lifecycle, do not believe for one second that the many benefits it provides come for free. Iterative

development is not a magical wand that when waved solves all possible problems or difficulties in software

development. Projects are not easier to set up, to plan, or to control just because they are iterative. The project

manager will actually have a more challenging task, especially during his or her first iterative project, and

most certainly during the early iterations of that project, when risks are high and early failure possible. In this

paper, I describe some of the challenges of iterative development from the perspective of the project manager.

I also describe some of the common “traps” or pitfalls that we, at Rational, have seen project managers fall

into through our consulting experience, or from reports and war stories from our Rational colleagues.

More planning work

Iterative development does not necessarily mean less work and shorter schedules. Its main advantage is to

bring more predictability to the outcome and the schedule. It will bring higher quality products, which will

satisfy the real needs of end-users, because you have had time to evolve requirements and evolve a design and

an implementation.

Iterative development actually involves much more planning and is therefore likely to put more burden on the

project manager: an overall plan has to be developed, and detailed plans will in turn be developed for each

iteration. It also involves continuous negotiation of tradeoffs between the problem, the solution and the plan.

More architectural planning will also take place earlier. Artifacts (plans, documents, models and code) will

have to be modified, reviewed and approved repeatedly at each revision. Tactical changes or scope changes

will force some continuous replanning. Thus, team structure will have to be modified slightly at each iteration.

Trap: Overly detailed planning up to the end

It is typically wasteful to construct a detailed plan end-to-end, except as an exercise in evaluating the global

envelope of schedule and resources. This plan will be obsolete before reaching the end of the first iteration.

Before you have an architecture in place and a firm grip on the requirements

which occurs roughly at the

LCA milestone

you cannot build a realistic plan.

So, incorporate precision in planning commensurate with your knowledge of the activity, the artifact or the

iteration being planned. Near term plans are more detailed and fine grained. Far term plans are maintained in

coarse-grained format.

Resist the pressure that unknowledgeable or ill-informed management may bring to bear in an attempt to elicit

a “comprehensive overall plan.” Educate and explain the notion of iterative planning and the wasted effort of

trying to predict details far into the future. An analogy that is useful: a car trip from New York to L.A. You

plan the overall route, but only need detailed driving instructions to get you out of the city and onto the first

leg of the trip. Planning the exact details of driving through Kansas, let alone the arrival in California, is

unnecessary as you may find that the road through Kansas is under repair and you need to find an alternate

route, etc.

Acknowledging rework up-front

In a waterfall approach, too much rework comes at the very end, as an annoying and often unplanned

consequence of finding nasty bugs during final testing and integration. Even worse, you discover that most of

the cause of the “breakage” comes from errors in the design, which you attempt to palliate in implementation

by building workarounds that lead to more breakage.

In an iterative approach, you simply acknowledge upfront that there will be rework, and initially a lot of

rework: as you discover problems in the early architectural prototypes, you need to fix them. Also, in order to

build executable prototypes, stubs and scaffolding will have to be built, to be replaced later by more mature

and robust implementations. In a healthy iterative project, the percentage of scrap or rework should diminish

From Waterfall to Iterative Lifecycle

rapidly; the changes should be less widespread as the architecture stabilizes and the hard issues are being

resolved.

Trap: Project not converging

However, iterative development does not mean scrapping everything at each iteration. Scrap and rework has

to diminish from iteration to iteration, especially after the architecture is baselined at the LCA milestone.

Developers often want to take advantage of iterative development to do gold plating: introducing yet a better

technique, to perform rework, etc. The project manager has to be vigilant as to not allow rework of elements

that are not broken, that are OK, or are good enough. Also, as the development team grows in size and as

some people are moved around, newcomers are brought in. They tend to have their own ideas on how things

should have been done. Similarly, customers (or their representatives in the project: marketing, product

management) may want to abuse the latitude offered by iterative development to accommodate changes,

and/or to change or add requirements with no end. This effect is sometimes called Requirements Creep .

Again, the project manager needs to be ruthless in making tradeoffs and in negotiating priorities. Around the

LCA milestone, the requirements are baselined, and unless the schedule and budget are renegotiated, any

change has a finite cost: getting something in means pulling something out.

And, remember that “perfect is the enemy of good.” (Or in French: “le mieux est l’ennemi du bien”).

Trap: Let’s get started, we’ll decide where to go later

Iterative development does not mean perpetually fuzzy development. You should not simply begin designing

and coding just to keep the team busy or with the hope that clear goals will suddenly emerge. You still need to

define clear goals, put them in writing and obtain concurrence from all parties; then refine them, expand them,

and obtain concurrence yet again. The bright side is that in iterative development, you need not have all the

requirements stated before you start designing, coding, integrating, testing and validating them.

Trap: Falling victim of your own success

An interesting risk comes near the end of a project, at the moment the “consumer bit” flips. By this we mean

that the users go from believing that nothing will ever be delivered to believing that the team might actually

pull it off. The good news is that the external perception of the project has shifted: whereas on Monday they

would have been happy if anything were delivered; on Tuesday, they become concerned that not everything

will be delivered. This is the bad news. Somewhere between the first and second beta, you find yourself

inundated with features people are concerned with making into the first release. Suddenly, these become

major issues. The project manager goes from worrying about delivering minimal acceptable functionality to a

situation where every last requirement now becomes “essential” to the first delivery. It is almost as though

when this bit flips, all outstanding items get elevated to an “A” priority status. The reality is that there is still

the same number of things to do, and the same amount of time with which to do them. While external

perception may have changed, prioritization is still very, very important.

If at this crucial moment the project manager loses his nerve and starts to cave in to all requests, he actually

puts the project in schedule danger again! It is at this point that he or she must continue to be ruthless and not

succumb to new requests. Even trading off something new for something taken out may increase risk at this

point. Without vigilance, one can snatch defeat from the jaws.

Putting the software first

In a waterfall approach, there is a lot of emphasis on “the specs” (i.e., the problem-space description) and

getting them right, complete, polished and signed-off. In the iterative process, the software we develop comes

first. The software architecture (i.e., the solution-space description) needs to drive early lifecycle decisions.

Customers do not buy specs; it is the software product that is the main focus of attention throughout, with both

specs and software evolving in parallel. This focus on “software first” has some impact on the various teams:

testers, for example, may be used to receiving complete, stable specs, with plenty of advanced notice to start

testing; whereas in an iterative development, they have to begin working at once, with specs and requirements

that are still evolving.

From Waterfall to Iterative Lifecycle

Trap: Focus on the wrong artifact

“I am a project manager, so I should focus on having the best set of management artifacts I can; they are key

to everything.” Not quite true! Although good management is key, the project manager must ensure in the end

that the final product is the best that can be produced. Project management is not an exercise in covering

yourself by showing that you have failed despite the best possible management. Similarly, you may focus on

developing the best possible spec because you have been hurt by poor requirements management in the past;

this will be of no use whatsoever if the corresponding product is buggy, slow, unstable and brittle.

Hitting hard problems earlier

In a waterfall approach, many of the hard problems, the risky things, and the real unknowns are pushed to the

right in the planning process, for resolution in the dreaded system integration activity. This leaves the first half

of the project as a relatively comfortable ride, where issues are dealt with on paper, in writing, without

involving many stakeholders (testers, etc.), hardware platforms, real users or the real environment. And then

suddenly, the project enters integration Hell and everything breaks loose. In iterative development, planning is

mostly based on risks and unknowns, so things are tough right from the onset. Some hard, critical and often

low-level technical issues have to be dealt with immediately, rather than pushed out to some later time. In

short, as someone once said to me: in an iterative development you cannot lie (to yourself or to the world)

very long. A software project destined for failure should meet its destiny earlier in an iterative approach.

One analogy is of a university course in which the professor spends the first half of the semester on relatively

basic concepts, giving the impression that it is an easy class that allows students to receive good marks at the

mid-term with minimal effort. Then suddenly, an acceleration occurs as the semester comes to a close wherein

the professor tackles all the challenging topics shortly before the final exam. At this point, the most common

scenario is the majority of the class buckles under the pressure, performing lamentably on the final exam. It is

amazing that otherwise intelligent professors are amazed at this repeated disaster, year after year, class after

class. A smarter approach would be to front-load the course, tackling 60% of the work prior to the mid-term,

including some challenging material. The correlation to managing an iterative project is to not waste precious

time in the beginning solving non-problems and accomplishing trivial tasks. The most common reason for

technical failure in startups: “They spent all their time doing the easy stuff.”

Trap: Putting your head in the sand

It is often tempting to say: “This is a delicate issue, a problem for which we need a lot of time to think. Let us

postpone its resolution until later, which will give us more time to think about it.” The project then embarks

on all the easy tasks, never dedicating much attention to hard problems. When it comes to the point where a

solution is needed, hasty solutions and decisions are taken, or the project derails. You want to do just the

opposite: tackle the hard stuff immediately. I sometimes say: “If a project must fail for some reason, let it fail

as soon as possible, before we have expended all our time and money.”

Trap: Forgetting about new risks

You performed a risk analysis in inception and used it for planning, but then forgot about risks that develop

later in the project. They come back to hurt you later. Risks should be re-evaluated constantly, on a weekly, if

not, monthly basis. The original list of risk you developed was just tentative. It is only when the team starts

doing concrete development (software first) that they will discover many other risks.

Clashes of lifecycle models

The manager of an iterative project will often see clashes with his environment and other organizations such

as top management, customers, and contractors, who have not adopted or even understood the nature of

iterative development. They expect completed and frozen artifacts at key milestones, they do not want to

review requirements in small installments, they are shocked by rework, and they do not understand the

purpose or value of some ugly architectural prototype. They perceive iteration as just fumbling purposelessly,

playing around with technology, developing code before specs are firm, and testing throwaway code.

At minimum, make your intentions and plans clearly visible. If the iterative approach is only in your head and

on a few whiteboards shared with your team, you will run into trouble later on.

Philippe Kruchten - From Waterfall to Iterative Lifecycle ; A tough transition for project manager [2000].pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: