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.
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
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.
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.
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 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."
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.
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.
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?
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 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
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
Share this...
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.
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.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
-
Global Rational User Group Community
Per Kroll is Chief Architect for IBM Rational Expertise Development and Innovation, an organization leveraging communities, portals, methods, training and services assets to enable customers and partners in software and systems development. Per is also the project leader on the Eclipse Process Framework Project, an open source project centered on software practices, and he has been one of the driving forces behind RUP over the last 10 years. Per has twenty years of software development experience in supply chain management, telecom, communications, and software product development. He co-authored The Rational Unified Process Made Easy - A Practitioner's Guide, with Philippe Kruchten, and Agility and Discipline Made Easy - Practices from OpenUP and RUP, with Bruce MacIsaac. A frequent speaker at conferences, Per has authored numerous articles on software engineering.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
