|
|
|
|
|
|
|
|
|
|
| Increment Definition is concerned with planning a systems development (or systems integration) project so that the system is developed and delivered to the business in a series of increments. This increment definition technique is designed to be used with the Team Fusion for OO process (and derivatives of it). |
| The definition of increments is driven by Use Cases and Requirements. Increments are prioritized primarily according to business value delivered, but also taking into account technical risk and dependencies between increments. |
| This technique also covers allocating the work of an increment to multiple parallel teams, and planning how to integrate several streams of work. It is designed to be used in conjunction with the Timeboxing technique. |
| Incremental Delivery |
| The incremental delivery approach is based upon a 'divide and conquer' philosophy. It takes a large project and breaks it down into a series of increments. Each increment may be developed in parallel or serially with other increments depending upon technical dependencies and business priorities. |
| Using the incremental approach requirements and detailed designs can be evaluated at the beginning of each increment. Because an increment takes less time than the whole project, there is a better chance of developing more stable requirements successfully for the duration of an increment than for a whole project. Further (and this is an unpleasant reality) requirements definition is sometimes difficult so that some requirements only emerge when users start real work with an early increment or prototype of the application. |
| The Incremental approach differs from a succession of independent projects in that there is/are: |
|
|
|
|
|
| These views may be subject to revision at the start of each new increment. |
| Projects differ in the amount of change that is encountered. In some the key requirements and the software architectures are well known and stable throughout the project. In others there are recognized uncertainties that are only resolved during the second or later increments. In a few what was thought to be well known and stable turns out not to be. |
| In the Team Fusion for OO process delivery increments are defined during the Solution Definition stage. Each increment consists of an instance of the Evolutionary Delivery and Distributed Deployment stages. |
| Increment Plan |
| Increment Definition |
| This is a high level plan, listing the proposed increments and the timeframes within which it is planned to deliver them. |
| Each increment has a name, and an approximate effort estimate (e.g. person months). |
| Dependencies between increments are shown, and whether they will be delivered in sequence or parallel. |
| This is the detailed definition of a single increment. |
| It includes: |
|
|
|
|
| Step 1: Agree Increment Objectives and Constraints |
| Step 2: Identify Priority Increments |
| Step 3: Refine Increment Definition |
| Step 4: Create Increment Plan |
| Step 5: Define Increment Acceptance Criteria |
| Step 6: Plan Allocation of Work to Teams |
| Step 7: Define Integration Cycles |
| Increment definition is motivated by objectives and constraints, so it is important to have these explicit and agreed. They can often be derived from the project scope and objectives in the Project Plan. |
| Objectives may include: |
|
|
|
| Constraints may include: |
|
|
| As well as considering the required date for the first increment to be delivered, consider how frequently the business wants subsequent releases (e.g. once every three months, or six months, or even every month). This is related to the cost and complexity of rolling out incremental releases to the user base (i.e. number of sites, number of users, data migrations, user training, systems management). |
| Focus on identifying what should be delivered in the first (and to a lesser extent second) increment. |
| Two basic and often conflicting factors govern the choice of what should be included in the first increment(s): |
|
|
| Define these increments primarily from the business point of view - what use cases and requirements are required first. Also consider them from the architectural point of view - what technical subset is separable and could be delivered early. |
| If the system is small, it may be agreed that splitting to increments is not useful, and that the first 'increment' will deliver the entire system. |
| Refine the definition of the first one or two increments. From the use cases, identify what subset of the System Object Model would need to be implemented, and what subset of the System Architecture Model would have to be in place. |
| Use this more precise definition of scope (Use Cases, Requirements, System Objects, System Operations, architecture components) to prepare an effort estimate for the first increment (or two). |
| Assess whether this is compatible with resource and date requirements. Iteratively refine the scope and priorities until all parties feel that the best achievable solution has been defined. |
| Identify subsequent increments, and prepare a plan showing all the increments. The first one or two increments have been defined and estimated in detail, and represent an agreed commitment. In contrast the later increments are only defined in outline, and their contents and sequencing are provisional. |
| For the first increment, define (or update) Acceptance Criteria for each Requirement, in order to specify precisely what has to be delivered in this increment. |
| Ensure each criterion is described as a precise, user-defined measure which can be used to ensure the acceptability of the increment. |
| Acceptance criteria typically relate to business process measures (e.g. cycle time), to Use Cases (e.g. process 95% of letters without manual intervention), or to requirements (e.g. usability requirement of being able to use system after 1 hour training). |
| Decide whether the increment will be developed by a single team, or by two or more teams working in parallel. There are several reasons why multiple teams might be appropriate: |
|
|
|
| Though note that having several teams increases the management complexity of the project, increasing some areas of risk, and the overheads of communication, coordination, etc. |
| Decide what work to allocate to each team. Each team's work should be cohesive, and only loosely coupled to the work of other teams. The best way of achieving this is to divide the work along the lines of divisions in the software architecture, for example, if there is a services interface, one team might develop the client components which call the services, and another team the server components which implement the services. Each component should be the responsibility of a single team. |
| As part of project organization, decide on intergroup coordination arrangements - how teams will communicate with each other, resolve technical issues, etc. |
| One coordination approach is to nominate 'feature owners' - for each system operation, requirement, or other feature, there is one person who has an overview of what is needed from each component and team. This person has responsibility for seeing that the work by different people on design, integration and testing 'hold together' to deliver the feature satisfactorily. |
| If there are two or more parallel teams developing an increment, integration of the components needs to be planned. |
| One approach would be for each team to complete all their EVO cycles and to integrate at the end. This is undesirable, both because of the risk of serious incompatibilities only being discovered late, and because it would prevent the evolutionary delivery of whole system operations and use cases to the business for review. |
| At the other extreme, components from different teams could be integrated each EVO cycle before passing to users for review. This can work well, but there are situations in which this is not feasible (e.g. there is a high overhead time and cost to integrate the components). |
| A useful compromise is to have an intermediate level of cycle in the development process - an increment is divided into a number of integration cycles, each of which consists of two or more EVO cycles (see diagram below). The teams synchronize at the integration points. Work is allocated to integration cycles so that the same system operations (or other features) are developed across all teams, integrated at the integration points, and passed to the business for review. |
| The diagram shows an increment where two teams are working in parallel. The increment is divided into three integration cycles. Note how the teams can have different length EVO cycles, provided that they synchronize at the integration points. For example team A might be a server team, with 2 week EVO cycles, and team B a client team, with weekly EVO cycles for the GUI. |
| Step 1: Agree Increment Objectives and Constraints |
| Step 2: Identify Priority Increments |
| Step 3: Refine Increment Definition |
| Step 4: Create Increment Plan |
| Step 5: Define Increment Acceptance Criteria |
| Step 6: Plan Allocation of Work to Teams |
| In the hotel example, the top priority business objective is to install a new reservations system which enables centralized and local reservations, includes credit card authorization, and is integrated with the room allocation and guest payment systems. |
| The time constraint is that this system must be operational by May, in time to accept reservations for the next busy holiday season. This gives a 4 month development time-frame, and a month for deployment. |
| There are ambitious aspirations on architectural integration of multiple systems, including head office accounting systems and local point of sale systems. However this integration has less business value than the operational reservations system, so is considered lower priority. The architecture priority is to provide a reliable architecture to support initial functionality, with the flexibility to be extended in later increments. |
| Increment 1 |
| Increment 2 |
| Increment 3 |
| As the highest priority is hotel reservations and guest billing, a set of use cases to support this is selected for increment 1. A minimal set is selected - the subset of functionality on which it is viable for the system to be made operational. |
| Use cases are: |
|
|
|
|
|
| Requirements: |
|
|
| Improved integration of hotel systems with head office accounting systems is the second priority, to improve financial forecasting, budgeting and control, and reduce costs of manual aggregation of accounts. |
| Use cases are: |
|
|
|
|
| An allowance is also made in the plan for development effort for enhancements to the reservations system once there is feedback from use. |
| These use cases have an architectural requirement for a communications link between hotels and central accounting system |
| The focus of the third increment is to implement a Frequent Guest Program to reward frequent users with bonuses and discounts. |
| Use Cases are: |
|
|
|
|
| The architecture implications of the use cases for Increment 1 are: |
|
|
|
|
| The Use Cases are examined to identify which System Operations will need to be implemented. For example the Check In use case requires two : Find Guest Reservation and Allocate Room. |
| The System Operations are analyzed to identify which parts of the System Object Model they require to be implemented. Areas of the object model not required for these System Operations are deferred until later increments. The Increment Object Model is shown below. (The development of the example System Object Model is described in the System Object Modeling technique). |
| On the basis of the System Operations, Object Model and Architecture components it is possible to make a reasonable estimate of development effort. |
| The initial effort estimate indicates that the system cannot be developed in time for the business deadline. To achieve the deadline, some functionality is dropped from the increment - the business agrees that transfer of phone charges (as part of the Check Out use case) can initially be performed manually, this avoids the architectural effort to integrate the phone billing system. |
| A revised estimate, for example 20 person months over 4 elapse months, is acceptable. |
| Increments 1, 2 and 3 will be developed and deployed in sequence. |
| Increment 1 - Reservations and Guest Billing |
| 4 months development (20 person months) |
| Increment 2 - Central Accounts integration |
| 3 months development (12 person months) |
| Increment 3 - Frequent Guest and Phones |
| 3 months development (12 person months) |
| Increment 1: |
|
|
|
| In this example there is one central development site, and the work is allocated to a single development team which varies in size between 4 and 5 people. |
| Increment definition involves trying to reconcile what is desirable (for the business) with what is feasible (in terms of development effort, risk, architecture, technical dependencies, etc.). It requires different stakeholders and people with different expertise to communicate and collaborate on 'the art of the possible'. This is best achieved in a facilitated workshop session, using a JAD technique such as Interactive Development. |
| Increment definition is an iterative process. Formulating an initial incremental plan frequently exposes some problems or opportunities which lead to refinement and revision. Allow plenty of time and opportunity for both business and technical people to explore alternative ways of defining increments. |
| Malan, R., Letsinger, R. and Coleman, D (1995) Object Oriented Development at Work. Fusion in the Real World. Prentice Hall. ISBN 0-13-243148-3. |
| See Todd Cotton's chapter on Evolutionary Fusion. |
| Lorenz, M and Kidd, J. (1994) "Object Oriented Software Metrics", Prentice Hall, ISBN 0-13-179292-X. |
| Useful material on estimating the size and development effort for an object-oriented system. |
| Gilb, T. (1988) Principles of Software Engineering Management. Addison-Wesley. |
| Discusses approaches to and benefits of evolutionary delivery. |