 Methodology |
|
|
|
|
|
 Sapphire uses Agile Unified Process (AUP) guidelines for project
development, execution & anagement. AUP is a simplified version of the
Rational Unified Process (RUP). It describes a simple, easy to understand
approach to developing business application software using agile techniques
and concepts yet still remaining true to the RUP.
Figure 1 depicts the lifecycle of the AUP. The first thing that you'll notice is
that the disciplines have changed. First, the Model discipline encompasses
the RUP's Business Modeling, Requirements, and Analysis & Design
disciplines. Model is an important part of the AUP, as you can see, but it
doesn't dominate the process you want to stay agile by creating models and
documents which are just barely good enough. Second, the Configuration
and Change Management discipline is now the Configuration Management
discipline. In agile development your change management activities are
typically part of your requirements management efforts, which is part of the
Model discipline.
|
 |
The serial nature of Agile UP is captured in its four phases :
- Inception. The goal is to identify the initial scope of the project, a potential architecture
for your system, and to obtain initial project funding and stakeholder acceptance.
- Elaboration. The goal is to prove the architecture of the system.
- Construction. The goal is to build working software on a regular, incremental basis
which meets the highest-priority needs of your project stakeholders.
- Transition. The goal is to validate and deploy your system into your production
environment.
|
Disciplines are performed in an iterative manner, defining the activities which
development team members perform to build, validate, and deliver working
software which meets the needs of their stakeholders. The disciplines are:
Model. The goal of this discipline is to understand the business of the
organization,
the problem domain being addressed by the project, and to identify a
viable solution to address the problem domain.
- Implementation. The goal of this discipline is to transform your model(s)
into
executable code and to perform a basic level of testing, in particular
unit testing.
-
Test. The goal of this discipline is to perform an objective evaluation to
ensure
quality. This includes finding defects, validating that the system works
as designed, and verifying that the requirements are met.
-
Deployment. The goal of this discipline is to plan for the delivery of the
system and
to execute the plan to make the system available to end users.
-
Configuration Management. The goal of this discipline is to manage access
to
your project artifacts. This includes not only tracking artifact versions
over time but also controlling and managing changes to them.
-
Project Management. The goal of this discipline is to direct the activities
that takes
place on the project. This includes managing risks, directing people
(assigning tasks, tracking progress, etc.), and coordinating with people
and systems outside the scope of the project to be sure that it is
delivered on time and within budget.
-
Environment. The goal of this discipline is to support the rest of the effort
by
ensuring that the proper process, guidance (standards and guidelines),
and tools (hardware, software, etc.) are available for the team as
needed
|
Instead of the "big bang" approach where you deliver software all at once
you instead release it into production in portions (e.g. version 1, then version
2, and so on). AUP teams typically deliver development releases at the end
of each iteration into pre-production staging area(s). A development release
of an application is something that could potentially be released into
production if it were to be put through your pre-production quality assurance
(QA), testing, and deployment processes. In Figure 2 you see that the first
production release often takes longer to deliver than subsequent releases; in
the first release of a system you likely need to get a lot of the “plumbing” in
place and your team likely hasn't “gelled” yet enabling them to become
efficient at collaboration. The first production release may take you twelve
months to deliver, the second release nine months, and then other releases
are delivered every six months. An early focus on deployment issues not only
enables you to avoid problems it also allows you to take advantage of your
experiences during development. For example, when you are deploying
software into your staging area you should take notes of what works and
what doesn't, notes that can serve as the backbone of your installation
|
 |
The Agile UP is based on the following principles:
- Your staff knows what they're doing. People aren't going to read detailed process documentation, but they will want some high-level guidance
and/or training from time to time.
- Simplicity. Everything is described concisely using a handful of pages, not thousands of them.
- Agility. The Agile UP conforms to the values and principles of the Agile
Alliance.
- Focus on high-value activities. The focus is on the activities which actually
count,
not every possible thing that could happen to you on a project.
|
.
You can use any toolset that you want with the Agile UP.
If you want something in between XP and traditional RUP, a process that is
agile yet explicitly includes activities and artifacts which you're accustomed
to, then the AUP is likely for you. Many organizations are leery of XP because
it seems to be too light: 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.
Original Copyright © 2005-2006 Scott W. Ambler |
|
|
|
|
 |
| |
|
|
|
| |
|
 |
|
|
|
|
