 | Level: Introductory Per Kroll, Manager of Methods, IBM Rational, IBM
15 Sep 2007 
from The Rational Edge: This article explores OpenUP, a recently developed process framework for software development, focused on agile practices derived from the Rational Unified Process. The author uses sidebar commentary to explain OpenUP to RUP-savvy readers.
From The Rational Edge.
Author's note: I dedicate this article to Brian Lyons, component lead for OpenUP within the EPF project, and co-founder, CEO, and CTO of Number Six Software, who died in a motorcycle accident on Labor Day. For more information, please see http://www.eclipse.org/epf/general/blyons_tribute.php
A couple of years ago, several colleagues
1
and I started to think about how you could create a stripped-down version of the IBM® Rational Unified Process®, or RUP®,
2
reflecting an agile approach to using RUP, while at the same time leverage all the good things we liked in other agile processes, such as Scrum
3
and XP.
4
We started this work inside IBM, but soon realized that we needed insights and experiences from a broader set of people.
The work was contributed to Eclipse under the Eclipse Process Framework (EPF)
5
project, and we continued co-developing the process with roughly twenty people from a dozen companies. Some of us had done agile implementations of RUP, others were on the Dynamic System Development Method (DSDM)
6
board of advisors or had created Agile Model Driven Development (AMDD);
7
others practiced Scrum
8
. What we noticed was a lot of synergy, with a small set of commonly occurring notions of how to develop software, often presented differently. Rather than creating a new process from scratch, we endeavored to harvest and synthesize the work of many people and many processes.
Last month we finally released OpenUP 1.0.
9
However, OpenUP is not the end product, but merely the first in an ongoing evolution of expected OpenUP releases. OpenUP will evolve as we learn more about what works, and what does not work, and we invite you all to co-develop OpenUP through the EPF project.
Here, I present extracts from OpenUP. I contributed the original version of this article to to EPF, and it was then further evolved and improved by the many members of the EPF project. I especially want to thank Brian Lyons, Nate Oster, and Liz Carroll from Number Six Software for their contributions. My observations and comments appear as a running sidebar commentary, providing my perspective on this introduction to OpenUP, and making comments aimed specifically at people that may already have an interest in RUP.
What is OpenUP?
|
Lean: From the Lean Manufacturing concept, we apply a similar emphasis on high-quality results, eliminating waste, dealing with change, and focusing on customer value.
Agile philosophy: OpenUP conforms to the principles of the Manifesto for Agile Software Development see (www.agilemanifesto.org)
Extended: IBM is one of what I expect to be many organizations that plan to provide an extension. We are currently working on refactoring RUP so it constitutes a set of extensions to OpenUP. This will mean that you can start with a small, open source process, and add additional content as needed, allowing you to create different variants of RUP and other processes.
Micro-increments: XP talks about baby-steps. Scrum evolves work in a similar fashion through its iteration backlog.
|
|
OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
Personal effort on an OpenUP project is organized in micro-increments, as shown in Figure 1. These represent short units of work that produce a steady, measurable pace of project progress (typically measured in hours or a few days). The process applies intensive collaboration as the system is incrementally developed by a committed, self-organized team. These micro-increments provide an extremely short feedback loop that drives adaptive decisions within each iteration.
Figure 1: OpenUP Layers: micro-increments, iteration lifecycle, and project lifecycle
|
Iterations: All agile processes are iterative.
Self-organize: Self-organization is a key part of Scrum, among other agile processes.
Iteration lifecycle: The iteration lifecycle comes from the Eclipse Way.
Project lifecycle: Many executives are now complaining that they have no oversight of their many agile projects. We think that distinct management milestones are crucial to fixing this problem.
|
|
OpenUP divides the project into iterations: planned, time-boxed intervals typically measured in weeks. Iterations focus the team on delivering incremental value to stakeholders in a predictable manner. The iteration plan defines what should be delivered within the iteration, and the result is a demo-able or shippable build. OpenUP teams self-organize around how to accomplish iteration objectives and commit to delivering the results. They do that by defining and "pulling" fine-grained tasks from a work items list. OpenUP applies an iteration lifecycle that structures how micro-increments are applied to deliver stable, cohesive builds of the system that incrementally progress towards the iteration objectives.
OpenUP structures the project lifecycle into four phases: Inception, Elaboration, Construction, and Transition. The project lifecycle provides stakeholders and team members with visibility and decision points throughout the project. This enables effective oversight, and allows you to make "go or no-go" decisions at appropriate times. A project plan defines the lifecycle, and the end result is a released application.
Iteration lifecycle
Iterations in OpenUP keep the team focused on delivering incremental customer value every few weeks by delivering a fully tested demo-able or shippable build (product increment). This creates a healthy focus on value to the stakeholders, ensuring that whatever is worked on furthers their goals. Decision-making must happen faster since there is no time for endless debate. Iterative development focuses on producing working code, reducing the risk of analysis-paralysis. Frequent demonstration of working code provides feedback mechanisms that allow course corrections to be taken as needed.
|
Product increment: Unfortunately, too few RUP customers produce fully tested builds at the end points of their iterations, so we wanted to make this very explicit.
Work items: Having one thing to prioritize makes life easier, versus having different prioritized lists for different types of requirements, defects, enhancement requests, etc.
Agile estimation: Agile teams estimate more than other teams do. Many non-agile pracitioners do not realize this. Agile development is disciplined.
Stable builds: This avoids a commonly occurring problem where teams at the end of the iteration do not produce anything that is of sufficiently high quality to be usable... Test-Driven Development makes it easier, but is often not sufficient.
|
|
Iteration planning, estimation, and progress tracking are centered on work items. The iteration plan is created by selecting the top-priority work items. Agile estimation techniques are used to understand how many work items can safely fit within the time-boxed iteration, and work items are filtered to ensure that the chosen work items will allow the team to deliver upon iteration objectives agreed to by stakeholders. Progress is demonstrated through continuous completion of many small work items.
Just as a project goes through a lifecycle, iterations go through a lifecycle with a different focus for the team depending on whether you are in the first versus the last week of the iteration (see Figure 2 below
10
). An iteration starts with an iteration planning meeting that is a few hours long. The initial one or two days are typically focused on further planning and architecture to, among other things, understand the dependencies and logical ordering of work items, and architectural impacts of the work to be done. Most of the time during an iteration is spent on executing the micro-increments. Each micro-increment should deliver tested code to a build, as well as validated artifacts. To give additional discipline, stable builds are produced at the end of each week. More attention is spent on these builds to make sure that the quality is not eroding and issues are dealt with early so the success of the iteration isn't jeopardized. The last week or last few days of the iteration typically have a stronger emphasis on polishing and bug fixing than earlier weeks, even though new features are added as appropriate. The goal is to never let quality erode, thus ensuring that a high-quality useful product increment is produced at the end of the iteration. The iteration ends with an assessment (with stakeholders) of what was built, and a retrospective to understand how to improve the process for next iteration.
Figure 2: An iteration goes through a lifecycle with a stronger focus on planning and architecture early and a stronger focus on bug-fixing and stabilization toward the end.
|
Team members: Compare how Toyota revolutionized car manufacturing by, among other things, making the team central to how cars were built. Teams built cars, and took shared ownership of the end result. Every team member was asked to help improve the way work was done.
Self-organization: Self-organization and the iteration lifecycle are two practices not captured in RUP today. If you want to adopt RUP in an agile fashion, you should consider adding these two practices to the many iterative RUP practices.
|
|
Team members work more effectively if they can influence what they do and how they do it, rather than operating in an environment where they are told what to do. In order to motivate team members to do their best, give the team the ability and responsibility to organize their work and determine how to best meet their commitments. This also helps them collaborate to ensure that the right skills are applied to the appropriate tasks. Self-organization impacts many areas, including how planning and commitments are made (by a team, not by individuals), how work is assigned (team members sign up instead of getting assigned), and how team members view their role in the project (team member first, job function second).
Self-organization requires a few things to work:
- "Transparency and commitments are crucial to aid in team communication and to bring out the best in the team members. Open communication about the team's commitments related to the iteration lifecycle, and personal commitments made relative to micro-increments ensure that execution problems are vetted and the right people are focused on solving them.
- "Coaching is required to help teams self organize and to remove barriers for success. The assumption is that the project manager is the coach. This requires that the project manager avoid a command-and-control style of management in favor of a coaching style. This has been a key recommendation in management books for the last two decades, but some project managers may still not be able to make that transition."
Micro increments
|
Short feedback loop: A goal of agile development is to shorten feedback loops. I often find that team members work for weeks on something without properly sharing what they do, leading to inefficiencies. Scrum addresses this through Daily Scrums. OpenUP says that you may do it that way, and/or you may also leverage common infrastructures for managing work items.
Develop solution increment: Ideally, use Test-Driven Development as you develop solution increments.
|
|
Personal contribution on an OpenUP project is organized in micro-increments. A micro-increment represents the outcome of a few hours to a few days of work for one, or typically a few people collaborating to reach the goals of the iteration. The concept of a micro-increment helps the individual team member to partition their work into small units so that each delivers something of measurable value to the team. Micro-increments provide an extremely short feedback loop that drives adaptive decisions within each iteration.
A micro-increment should be well defined, and you should be able to track the daily progress of each micro-increment. Micro-increments are specified and tracked by a work item. Change sets represent the physical outcome in terms of the files that are modified as part of completing the work item. Let's have a look at some sample micro-increments:
-
Identify Stakeholders. Defining the Vision is a task that can drag on for weeks, so to ensure that you make and track daily progress, divide the task into small and well-defined micro-increments. Describing and getting buy-in on what Stakeholders to put into a Vision document will lead to a meaningful result, and may take only a few hours or at most a few days, and thus represents a suitable micro-increment.
-
Develop Solution Increment.
Defining, designing, implementing, and testing a use case or even a scenario can take weeks or longer. To ensure continuous progress, you should seek to divide the work into smaller increments, each of which can be done in a couple of days. A more suitable micro-increment may be to only define, design, implement, and test a subflow of a use case or step within a scenario.
-
Agree on Technical Approach for Persistency. Agreeing on your technical solution may take quite some time, so you need to narrow the task to something that can be defined and agreed to in a short time. One way to partition the work is according to the issues you need to resolve, such as persistency or reporting. This micro-increment will probably involve defining requirements, surveying available assets, prototyping, and documenting the decisions.
-
Plan Iteration. This micro-increment could include setting up a meeting for creating the iteration plan, doing some preparation for the meeting, such as reviewing candidate work items, coaching the team through the iteration planning meeting, and posting the iteration plan for easy access. The end result is something complete and measurable, a posted plan that has buy-in from the team.
Your application evolves in micro-increments through simultaneous execution of a number of work items. By openly sharing progress on your micro-increments through daily team meetings and team collaboration tools, you achieve the transparency and insight into each other's work required for effective teamwork. At the same time, you demonstrate continuous progress by evolving your application one micro-increment at the time.
|
Micro increments: Maybe this is an opportunity for a later enhancement to OpenUP?
Map: Too many people take processes too literally. Rely on common sense, and use the process for learning and inspiration.
|
|
OpenUP provides a set of activities. Each activity is captured as a set of tasks, steps within tasks, and guidance. Even though micro-increments are not an explicit construct in the process, you will find descriptions of how to carry out a set of related micro-increments that are commonly found in projects within the activity. OpenUP does not provide a complete description of potential micro-increments, and each organization should consider adding their own "recipes" for commonly occurring micro-increments.
OpenUP provides a powerful learning tool and makes it easier to find relevant guidance by outlining when you are most likely to carry out various tasks. This is done through a visualization of the delivery process, which provides a time-based organization of the tasks within the context of a Project Lifecycle. As an example, you are more likely to agree on a technical approach early in the project. This doesn't mean you wouldn't make technical decisions late in the project. A process is like a map: Use it to understand the big picture and as a reference, but when reality and the map don't match, trust reality.
Project lifecycle
|
Stakeholders: "Stakeholder" is a broad term. This includes executives and other people sitting on money and determining strategic direction. The project lifecycle should provide them with specific decision points where they can give a go/no-go to continue the project.
Phases: These phases were taken from the RUP and they hearken back to the milestones that Barry Boehm introduced into his spiral model.
|
|
The project lifecycle provides stakeholders with oversight, transparency, and steering mechanisms to control project funding, scope, risk exposure, value provided, and other aspects of the process.
Each iteration delivers a product increment, which provides an opportunity for stakeholders to understand what value has been delivered and how well the project is tracking. It also gives the development team the opportunity to make changes to the project to optimize the outcome.
OpenUP organizes iterations into a set of phases. Each phase ends with a milestone aimed at providing oversight by raising and answering a set of questions that are typically critical to stakeholders:
-
Inception. Do we agree on project scope and objectives, and whether or not the project should proceed?
-
Elaboration. Do we agree on the executable architecture to be used for developing the application and do we find that the value delivered so far and the remaining risk are acceptable?
-
Construction. Do we find that we have an application that is sufficiently close to being released that we should switch the primary focus of the team to tuning, polishing, and ensuring successful deployment?
-
Transition. Is the application ready to release?
| |
Cancelled: All agile processes provide some level of visibility at the end of each iteration. However, we are saying that you need to have a smaller number of very explicit decision points. In IBM, we make explicit decisions at each project milestone where each of marketing, services, sales, development, finance, legal, and so on, get to vote.
|
|
If the answer is Yes to the above questions at the phase review, the project continues. If the answer is No, the phase is delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may determine that the project should be cancelled.
One of the objectives of the project lifecycle is to focus on two key stakeholder drivers: risk reduction and value creation. The OpenUP phases focus the team on risk reduction related to the questions to be answered at the end of the phase, while tracking value creation, as shown in Figure 3.
Figure 3: Risk reduction (red curve) and value creation (green curve) during the project lifecycle
|
Risk: My view is that most agile processes do not focus enough on risk mitigation, or at least not on making it sufficiently explicit. Most of us work in environments where we need to make reasonable predictions to allow the broader organization to operate effectively. Predictions will always have some level of imprecision, but there is great value in being able to make them more precise sooner rather than later.
OpenUP: At this stage, there are two members of the OpenUP family. One is the basic OpenUP process, the other is the basic OpenUP process with some additional extensions from DSDM, referred to as OpenUP/DSDM. Other extensions are being planned by various organizations.
|
|
Risk is a manifestation of the likelihood of unexpected things happening to the project, and risk stands in the way of value creation. Risk is directly proportional to uncertainty in estimates, and stakeholders typically want to know sooner rather than later what value the project can deliver in the stipulated time. In many cases, you reduce risk when you create value by implementing and testing the most critical capabilities. However, there are situations where risk reduction and immediate value creation are at odds with each other. Let's look at an example. At the end of Elaboration you want to drive down as much technical risk as possible and deliver a stable architecture. The team needs to show that they do have an executable architecture, with a few selected scenarios that can be executed, and with a risk list that reflects the mitigation of many key technical and other risks. This risk reduction needs to be balanced with the value of the running code. What constitutes the right balance for one project may be different for the next one.
OpenUP -- influenced by Scrum, Eclipse Way, XP, and RUP
The OpenUP family of processes aims at addressing a broad variety of project types while sharing a set of common characteristics. These are the key principles behind OpenUP:
- Collaborate to align interests and share understanding
- Evolve to continuously obtain feedback and improve
- Focus on the architecture early to minimize risks and organize development
- Balance competing priorities to maximize stakeholder value
| |
Types: As mentioned in the introduction, IBM intends to provide a set of extensions, which really constitutes a future version of RUP.
|
|
Processes in the OpenUP family are written as extensions to the core OpenUP process, which embraces a pragmatic, agile philosophy focusing on the collaborative nature of software development. This core OpenUP process is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
By adding process plug-ins, extensions to OpenUP can be created that address a variety of development concerns, such as service-oriented architecture (SOA), geographical distribution, model-driven architecture, and embedded systems. Tool-and technology-specific guidance can be added, such as guidance on Java 2 Enterprise Edition (J2EE), and a variety of development tools. Some of these extensions can be quite modest, adding for example just tool-specific guidance to existing tasks, while others could be quite comprehensive, creating processes that provide a radically expanded scope with new or altered artifacts, new or altered tasks, and new or altered roles.
As stated above, to qualify as members of the OpenUP family, extended processes must comply with the key principles of OpenUP and be written as extensions to the OpenUP core process.
Extensions to OpenUP can be:
- Used internally by an organization
- Open source as a part of the EPF project
- Made freely available outside the open source licenses of Eclipse (EPL, see http://www.eclipse.org/legal/epl-v10.html)
- Sold commercially
Notes
1 The pre-cursor to OpenUP, Basic Unified Process, was primarily developed by Bruce MacIsaac, Ricardo Balduino, and Per Kroll.
2
http://www.ibm.com/software/awdtools/rup/
3
http://www.scrumalliance.org/
4 Beck, K., Andres, C. Extreme Programming Explained: Embrace Change, 2nd Edition, Addison Wesley, 2005.
5
http://www.eclipse.org/epf/
6 DSDM Consortium, DSDM. See http://www.dsdm.org/products/
7 Ambler, S.W. The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. Addison Wesley, 2006.
8
The Eclipse Way is, among several places, available through the JAZZ Project:
http://www.jazz.net
9
http://www.eclipse.org/epf/downloads/openup/openup_downloads.php
10 See also http://Jazz.net for access to Eclipse Way.
Resources
About the author | 
| | Per Kroll is development manager for RUP and the IBM Rational Method Composer, and the project leader on the Eclipse Process Framework Project, an open source project centered on software practices. He is responsible for IBM Rational's strategy in the process area. Per has twenty years of software development experience in supply chain management, telecom, communications, and software product development. He is author of the books The Rational Unified Process Made Easy -- A Practitioner's Guide (Kroll and Kruchten), and Agility and Discipline Made Easy -- Practices from OpenUP and RUP (Kroll and MacIsaac). Per is a frequent speaker at conferences and author of numerous articles on software engineering. |
Rate this page
| |
