Post on 27-Dec-2015
© 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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
Why RAD?
• Traditional waterfall approach has various deficiencies
• Also problems controlling iterative development
7
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
DSDM Life Cycle
• The DSDM life cycle has 7 phases:– Pre-Project– Feasibility– Foundations– Exploration– Engineering– Deployment– Post-Project
12
© 2010 Bennett, McRobb and Farmer
Simplified DSDM life cycle
Forward pathsthrough process
Backward paths to evolve the system
Exploration
Engineering
Feasibility
Foundations
post-project
pre-project
Deployment
13
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
Extreme Programming
• XP also emphasises– embracing change is important and key to
systems development– development staff are motivated by producing
quality work
32
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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
© 2010 Bennett, McRobb and Farmer
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)