Agile MethodologiesDSDM XP and Scrum Based on Chapter

Agile Methodologies—DSDM, XP and Scrum Based on Chapter 21 of Bennett, Mc. Robb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4 th Edition), Mc. Graw Hill, 2010. © 2010 Bennett, Mc. Robb and Farmer

In This Lecture You Will Learn: · The characteristics of Agile software development · The key features of three leading Agile Methodologies: · DSDM · Scrum · e. Xtreme Programming (XP) 2 © 2010 Bennett, Mc. Robb 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) 3 © 2010 Bennett, Mc. Robb 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” 4 © 2010 Bennett, Mc. Robb 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 5 © 2010 Bennett, Mc. Robb and Farmer

Why RAD? • Traditional waterfall approach has various deficiencies • Also problems controlling iterative

Origins of DSDM • RAD became popular in early 1990 s, 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 7 © 2010 Bennett, Mc. Robb 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 8 © 2010 Bennett, Mc. Robb 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 Mo. SCo. W rules). 3. Collaborate. In DSDM all stakeholders are important, including end-users and resource managers. 9 © 2010 Bennett, Mc. Robb 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. 10 © 2010 Bennett, Mc. Robb and Farmer

DSDM Life Cycle • The DSDM life cycle has 7 phases: – Pre-Project –

Simplified DSDM life cycle preproject Feasibility Forward paths through process Backward paths to evolve the system Foundations postproject Deployment Exploration Engineering 12 © 2010 Bennett, Mc. Robb 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? 13 © 2010 Bennett, Mc. Robb and Farmer

DSDM Life Cycle • Foundations – Identifies overall scope of the project – Results in agreed high level functional and nonfunctional 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 14 © 2010 Bennett, Mc. Robb 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 15 © 2010 Bennett, Mc. Robb 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 16 © 2010 Bennett, Mc. Robb 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 17 © 2010 Bennett, Mc. Robb 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 18 © 2010 Bennett, Mc. Robb 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 19 © 2010 Bennett, Mc. Robb and Farmer

Timeboxes Activity within each phase is iterated as necessary A timebox occurs in an overall sequence of other timeboxes Consolidate Work Done Produce Deliverables Investigate / set objectives A timebox has three phases, each with a different focus of attention The end of a timebox is an absolutely inflexible deadline 20 © 2010 Bennett, Mc. Robb and Farmer

Mo. SCo. W 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 21 © 2010 Bennett, Mc. Robb 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 22 © 2010 Bennett, Mc. Robb 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 23 © 2010 Bennett, Mc. Robb and Farmer

Scrum Roles • Team members do the development work in whatever way they think best • Scrum. Master 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 24 © 2010 Bennett, Mc. Robb 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) 25 © 2010 Bennett, Mc. Robb 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 26 © 2010 Bennett, Mc. Robb 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” 27 © 2010 Bennett, Mc. Robb 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 28 © 2010 Bennett, Mc. Robb 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 29 © 2010 Bennett, Mc. Robb and Farmer

Underlying Principles of XP • 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 30 © 2010 Bennett, Mc. Robb and Farmer

Extreme Programming • XP also emphasises – embracing change is important and key to systems development – development staff are motivated by producing quality work 31 © 2010 Bennett, Mc. Robb 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 32 © 2010 Bennett, Mc. Robb 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 33 © 2010 Bennett, Mc. Robb 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 34 © 2010 Bennett, Mc. Robb 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 35 © 2010 Bennett, Mc. Robb 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 36 © 2010 Bennett, Mc. Robb 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 37 © 2010 Bennett, Mc. Robb 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 · e. Xtreme Programming (XP) 38 © 2010 Bennett, Mc. Robb and Farmer