Introduction
The Rational Unified Process (RUP) has become a defacto standard for
many organizations as they look to improve their software development
processes. Unfortunately, transitioning to RUP is an arduous and risky
process as teams struggle with adjusting to an iterative style of
development. As a witness to many process improvement efforts utilizing
RUP, I've found most are little more than reinventions of an
organization's existing practices. The result is a pseudo-iterative
style of development that favors excessive documentation manifest as
RUP artifacts, a predictive and plan-driven approach providing no clear
barometer to gauge success, and a tendency to revert to traditionally
flawed practices as teams succumb to the pressures of project
deadlines. Certainly, RUP should not be blamed for the failure, but
often times that's the case, casting a dark shadow on iterative
development and making teams ever more leary to consider agile
development.
RUP's Beauty
I must admit that RUP is a beautiful piece of work. Use Case Driven.
Architecture Centric. Iterative and Incremental. To the unsuspecting
development team, it offers the wonderful promise of traceability.
Develop a Use Case Specification. Realize each use case scenario with
sequence diagrams through analysis and design. Analyze sequence
diagrams for common flows (reuse). Create a view of participating
classes for each use case. Allocate classes to components.
Architectural analysis and design. And so on. Traceability throughout
the development lifecycle. There are even tools available that support
the process.
Yet in all its glorious wonder, it is RUP's ceremonial beauty that
is also it's downfall. We can unneccessarily argue that it's not an
inherent flaw of RUP, but more so due to manifestations of RUP. Teams
attempt to stabilize architecture early. They tend to avoid
construction until requirements are stable. They create iteration plans
but do not deliver after each iteration. But a process with infinite
variability and implementation baggage is destined to fail.
Herein lies the problems with many manifestations of RUP.
- Iterations don't deliver. The purpose of iterative and
incremental development is to deliver functional software at the end of
each iteration, where each iteration results in incremental growth of
the system. All too often, teams fail to achieve this goal, or make
adjustements when they don't. Instead, many RUP iterations resemble
nothing more than traditional waterfall phases broken down into smaller
timeboxes. The result is multiple requirements iterations, following by
multiple analysis and design iterations, followed by multiple
implementation iterations, etc.
- Traceability cannot be achieved. Many folks are quite
enamored with traceability. Changes to requirements can be traced
through the analysis and design model into the code through the
components and onto the executable nodes. But traceability is
fundamentally flawed due to syncrhonization issues across artifacts.
Teams do not possess the discipline necessary to maintain consistency
across all artifacts, making the source code the only true artifact
representing the current state of the system.
- Emphasizing process improvement. The complexity and infinite
variability of RUP make it a methodologists process, not a developer's
process. Passing a CMMI appraisal may be important, but delivering
quality software is the ultimate goal. Achieving one does not guarantee
the other.
- Artifact centric. RUP teams utilize Use Cases and Use Case
Specifications to gather and elicit requirements and detailed class and
sequence diagrams that capture the vision for architecture and design.
They create software development plans, test plans, and deployments
plans. Probably many others. But in many cases, reviewing how a team
works before and after RUP will show that little else has changed other
than the artifacts produced.
- Addressing the wrong problem. In many cases, we hope that
RUP will result in more stable requirements and accurate estimates. But
it cannot solve problems inherent to software development. Instead of
emphasizing process to stabilize requirements, process must emphasize
managing change. Instead of improving predictive estimating, process
must emphasize measuring based on experience and trends. Neither of
these are possible if we aren't delivering iteratively.
Software Matters
If you've read any of my blogs or articles, you'll know I stand firm on a few key points.
- Process doesn't matter, practices do. I don't care to debate
the merits of process, be it RUP, Scrum, or any other. I find value in
the numerous practices embedded within each, but do not feel that
adopting any process verbatim is the right solution for any team.
- agile is always good. Agility is defined by your teams
ability to deliver functional software. Unless I'm missing something,
the goal of any software development initiative is to deliver software.
- The source code is the only artifact that matters. Systems
are never judged based on the beauty of the architecture diagram or the
completeness of the requirements specification. These only provide a
false sense of progress and security. Systems are judged based on
whether the software delivered meets the user's needs.
- Increased agility requires more than practice or process. It
requires tools, infrastructure, and a codebase that allows the team to
respond to change. Yes...the team. That's pretty important too.
- Iterative ain't always agile. See first bullet, and
recognize that if you are forcing people to conform to process over
embracing process evolution, you'll find it difficult to realize high
degrees of agility.
A Better RUP
RUP and agility are not mutually exclusive. RUP has the potential to
increase agility by improving a team's ability to deliver software
iterative and incrementally. To do so however requires teams to avoid
the common problems when adopting RUP, and focus on that which is truly
important - software delivery. Using RUP as a process framework, while
complementing it with agile practices such as test driven development,
continuous integration, and a strategy for tracking running tested
features will yield higher degrees of success. Teams will generate the
constant feedback, increase the collaboration, and develop the engaging
relationship with business stakeholders that are important to any
successful software development effort. Adopting practices to address
the pain points on a project will help avoid the problem caused by
sudden and radical shifts in development philosophy. Considering the
dynamics and strengths of the team throughout the process improvement
initiative is imperative. Eliminating waste created by artifacts that
don't directly contribute to creating high quality source code will
speed software delivery.
Improving a team's development process is good, so long as the folks
pushing the process recognize that the goal of the process improvement
effort must be delivering quality software over implementing ceremonial
processes. RUP is one way to begin. As your team or organization works
to improve process, don't be constrained to only RUP. Consider
alternatives. The first step in improving your ability to deliver
software is recognizing that a problem exists. Begin by understanding
the problem. Are you having software quality issues? Are development
efforts simply taking too long? Constantly exceeding your budget?
Aren't able to meet business objectives? Constrained by resources?
Something else? Or everything? Quite simply, you must recognize your
pain, identify it's cause, and eliminate it. Then...do it again.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form