© 2010 bennett, mcrobb and farmer1 agile methodologies—dsdm, xp and scrum based on chapter 21 of...

© 2010 Bennett, McRobb and Farmer 1

Agile Methodologies—DSDM, Agile Methodologies—DSDM, XP and ScrumXP and Scrum

Based on Chapter 21 of Bennett, McRobb and Farmer:

Object Oriented Systems Analysis and Design Using UML, (4th Edition),

McGraw Hill, 2010.

2

© 2010 Bennett, McRobb and Farmer

In This Lecture You Will Learn:

The characteristics of Agile software development

The key features of three leading Agile Methodologies: DSDM Scrum eXtreme Programming (XP)

3


Agile Software Development

• Agile approaches to development are linked by the Agile Manifesto, which emphasises:– People over process– Software over documentation– Collaboration over contracts– Change over plans

(paraphrased from agilemanifesto.org)

4


Characteristics of Agile Methodologies

• All agile approaches share a few characteristics:– Iterative development– Flexible, empowered teams– A “lightweight” approach - i.e. a preference for

producing working code rather than analysis or design models

– E.g. proponents of XP claim that “the code is the model”

5


Dynamic Systems Development Method

• DSDM predates the Agile Manifesto• It is a management and control framework for

Rapid Application Development• RAD aims to build a working system rapidly• Prototyping aims to build elements of a system

(a partial system) quickly• Similar development environments can be used

for both• A prototype may incrementally become a

working system

6


Why RAD?

• Traditional waterfall approach has various deficiencies

• Also problems controlling iterative development

7


Origins of DSDM

• RAD became popular in early 1990s, due to various deficiencies of waterfall lifecycle

• DSDM created in 1994, to define the structure and controls for a RAD project

• Does not specify the development methodology

• Has been used with SSADM (a structured methodology) and OO

8


DSDM Project Management

• DSDM takes a radical perspective on project control

• Historically, requirements were fixed, while resources were allowed to vary

• DSDM fixes resources for the project (time available and budget), then delivers only what can be achieved within these limits

9


DSDM Principles

• The latest version, DSDM Atern is based on 8 principles.

1. Focus on business need. Fitness for purpose is the essential test for all products.

2. Deliver on time. Deadlines are never sacrificed for lower priority requirements (relates to timeboxing and MoSCoW rules).

3. Collaborate. In DSDM all stakeholders are important, including end-users and resource managers.

10


DSDM Principles

4. Never compromise quality. For this reason, testing is integrated throughout the life cycle.

5. Develop iteratively. Allows the project to converge on an accurate business solution.

6. Build incrementally from firm foundations. Partial solutions are acceptable if they satisfy an immediate need, and this encourages feedback from users.

7. Communicate continuously and clearly.8. Demonstrate control.

11


DSDM Life Cycle

• The DSDM life cycle has 7 phases:– Pre-Project– Feasibility– Foundations– Exploration– Engineering– Deployment– Post-Project

12


Simplified DSDM life cycle

Forward pathsthrough process

Backward paths to evolve the system

Exploration

Engineering

Feasibility

Foundations

post-project

pre-project

Deployment

13


DSDM Life Cycle

• Feasibility– Determines whether the project is suitable for

a DSDM approach– Typically lasts only weeks– Should also address the following questions

• Is the computerized information system technically possible?

• Will the benefit of the system be outweighed by its costs?

• Will the information system operate acceptably within the organization?

14


DSDM Life Cycle

• Foundations– Identifies overall scope of the project– Results in agreed high level functional and non-

functional requirements– Maintainability objectives set at this stage determine

the quality goals for the remainder of the project:• maintainable from initial operation• not necessarily maintainable when first installed

but this can be addressed later• short life-span system that will not be subject to

maintenance

15


DSDM Life Cycle

• Exploration– Development of prototypes to elicit detailed

requirements– These may ultimately be delivered as

operational systems—for operational use and non-functional requirements

– Includes analysis models as well as prototypes

16


DSDM Life Cycle

• Engineering– Prototypes developed to the point where they

can be used operationally– Distinction between exploration and

engineering is not clear-cut – Project may move back and forth between

these phases for several iterations

17


DSDM Life Cycle

• Deployment – Install latest increment and train users– Review how well requirements have been met– May return to earlier phases:

• To Engineering to complete non-functional requirements

• To Exploration to complete functional requirements• To Foundations if a new functional area has been

identified

18


Timeboxing

• Fixes resource allocation for a project or a part of a project

• Limits time available for refinement of requirements, design, construction and implementation as appropriate

• Each timebox has a set of prioritised objectives

19


Timeboxing

• Each timebox produces one or more deliverables

• Within a timebox, there are 3 main concerns– Investigate what needs to be done

(determines the direction of work)– Develop and refine the specified deliverables– Consolidate the work prior to the final

deadline

20


Timeboxes

A timebox has three phases, each with a different focus of attention

Activity within each phase is iterated as necessary

Invest

igate

/

set

ob

ject

ives

Pro

duce

D

eliv

era

ble

s

Conso

lidate

W

ork

Done

A timebox occurs in an overall sequence of other timeboxes

The end of a timebox is an absolutely inflexible deadline

Invest

igate

/

set

obje

ctiv

es

Pro

duce

D

eliv

era

ble

s

Conso

lidate

W

ork

Done

Invest

igate

/

set

obje

ctiv

es

Pro

duce

D

eliv

era

ble

s

Conso

lidate

W

ork

Done

21


MoSCoW Rules

• Heuristic to help prioritise requirements – (Must, Should, Could, Want)– Must have requirements are crucial– Should have requirements are important– Could have requirements are less important– Want to have but not this time around

requirements can reasonably be left for development in a later increment

22


Scrum: a framework for developing complex products

• Unusually, “Scrum” is not an acronym - it derives from rugby

• In Scrum, people are either pigs or chickens– Pigs are full team members, chickens are

everyone else– Some chickens can specify a product, but no

chicken can tell a pig how to do their work

23


Scrum Framework

• This mainly consists of:– Roles of the people– Timeboxes (borrowed from DSDM)– Artefacts produced or used by the team– Rules about who can do what

• Scrum has no defined lifecycle, although it does insist on an iterative approach

24


Scrum Roles

• Team members do the development work in whatever way they think best

• ScrumMaster coaches and motivates the team and ensures that Scrum rules are followed

• Product Owner has the power to decide when an increment is “done”

• These roles are the only pigs, all others are chickens

25


Scrum Timeboxes

• As in DSDM, all work iterations and meetings are timeboxed

• Required meetings include:– Sprint Planning Meeting– Daily Scrum– Sprint Review Meeting

• Known as Scrum’s ceremonies, these meetings punctuate each sprint (a 2 to 4 week work iteration)

26


Scrum Artefacts

• Four key artefacts are continuously updated as the project proceeds:– Product Backlog: a prioritised list of

requirements, maintained by Product Owner.– Release Burndown: a graphic estimate of the

total work needed to complete the project.– Sprint Backlog and Sprint Burndown are

similar, but apply to the current Sprint, not the project as a whole

27


Scrum Rules

• The process of Scrum is defined by its rules, which include:– Scrum teams are self-organizing, and no

formal leader is imposed– Only pigs can talk during a Daily Scrum– Chickens cannot tell pigs how to do their work– Only the Product Owner can define what it

means to say that an increment is “done”

28


Extreme Programming

• XP is a novel combination of elements of best practice in systems development

• First publicized by Kent Beck (Beck, 2000)

• Known for its use of pair programming but has other important aspects

29


Underlying Principles of XP

• Communication. XP highlights the importance of good communication among developers and between developers and users

• Simplicity. XP focuses on the simplest solution for the immediate known requirements

30


Underlying Principles of XP

• Feedback. Feedback in XP is geared to giving the developers frequent and timely feedback from users and also in terms of test results. Work estimates are based on the work actually completed in the previous iteration

• Courage. Urges the developer to throw away code that is not quite correct and start again. Essentially the developer has to leave unproductive lines of development despite personal investment in the ideas

31


Extreme Programming

• XP also emphasises– embracing change is important and key to

systems development– development staff are motivated by producing

quality work

32


Requirements Capture in XP• Based on user stories that describe the

requirements– written by the user– basis of project planning and the development of test

harnesses

• Very similar to use cases though some proponents of XP suggest that there are key differences in granularity– typical user story is about three sentences with no

technology indicated– Developers get detailed descriptions from the customer

when they start developing

33


XP Activities

• The planning game involves quickly defining the scope of the next release from user priorities and technical estimates. The plan is updated regularly as the iteration progresses

• The information system should be delivered in small releases that incrementally build up functionality through rapid iteration

• A unifying metaphor or high level shared story focuses the development

34


XP Activities

• The system should be based on a simple design• Programmers prepare unit tests in advance of

software construction and customers define acceptance tests

• The programme code should be restructured to remove duplication, simplify the code and improve flexibility—this is known as refactoring, and is discussed in Fowler (1999) in detail

35


XP Activities

• Pair programming means that code is written by two programmers using one workstation

• The code is owned collectively and anyone can change any code

• The system is integrated and built frequently each day. This gives the opportunity for regular testing and feedback

36


XP Activities

• Normally staff should work no more than forty hours a week

• A user should be a full-time member of the team

• All programmers should write code according to agreed standards that emphasise good communication through the code

37


Using XP

• Best suited to projects with a relatively small number of programmers—say no more than ten

• Critical to maintain clear communicative code and to have rapid feedback– If these are not possible then XP would be

problematic

• XP not sympathetic to using UML for analysis & design

38


Summary

In this lecture you have learned about Some characteristics of Agile software

development The key features of three leading Agile

Methodologies: DSDM SCRUM eXtreme Programming (XP)

39


References

• DSDM Consortium (2007)

• Schwaber (2009)

• Beck (2004)

(For full bibliographic details, see Bennett, McRobb and Farmer)

© 2010 bennett, mcrobb and farmer1 agile methodologies—dsdm, xp and scrum based on chapter 21 of...

Documents

farmer dsdm principles

iterative development

farmer origins of dsdm

dsdm atern

farmer dsdm life cycl

working system slide

oo slide

model slide