IAD

Agile development and Extreme Programming

Evolution of Development Process Models

• ‘Software Engineering’ (1969)• Waterfall model – classic linear lifecycle (Royce 1970)• Throw-away Prototyping (early ’80s)• V model (Emphasis on Testing) late ’80s• Risk-driven Spiral Model ( Boehm 1988)• RAD (Rapid Application Development) 1991• JAD (Joint Application Development)• Formal methods (e.g. Z Sufrin 1982)• Rational Unified Process (RUP)• Wikipedia

Changing Forces• Speed, cost, capacity of computers

– 1960’s • too costly to be used for development : 2 MHz ,32k + 64k + tape : £100,000• turnaround time : 1 day

– 2000• 3Ghz, 500 Mb + 50Gb = £1000 • turnaround time: 60 secs --- overall 108 improvement

• Application domain– 1960’s : company and state number crunching– 2000 : + end-user development, consumer products, multimedia, internet

• Market pressure– 1960 : in-house automation of manual processes– 2000 : consumer products: time to market critical

• Programming language and style– 1960 : COBOL, Fortran – function libraries– 2000 : object-oriented languages, rich component base

• Organizational structure– 1960 : rigid, hierarchical bureaucracy– 2000 : fluid, flat, meritocracy

The Agile Alliance

• A group of writers, developers and consultants, mostly from the OO (object-oriented community)

• Martin Fowler – ex data analyst with the NHS – ‘UML Distilled’, ‘Analysis Patterns’

• Ken Beck and Ward Cunningham – Smalltalk gurus – CRC cards

• Steven Mellor – Real time systems

Agile manifesto - Values

• Individuals and interactions– Over processes and tools

• Working Software– Over comprehensive documentation

• Customer collaboration – Over contract negotiation

• Responding to change– Over following a plan

Keyword- ‘Developer’• No analyst / programmer distinction• Distinction is caused by the waterfall

model• Distinction causes need for documents

which have no long-term value and limit change

• Distinction not viable in the long-term – analysts get out of touch with rapidly-changing technology

Scrum

• Scrum is one of the older Agile methods originating in Japanese manufacture

• Organisation of a backlog of product features into iterative cycles (sprints)

• Organisation/renaming of roles • Some jargon• Video

Extreme Programming (XP)• Best known example of an agile method• Developed by Kent Beck and others

(Fowler, Jefferies) using internet discussion board – a wiki

• A disciplined method despite the ‘anarchist’ tag

• Customer requirements focus• Role specialisations – release manager,

coach … as required

XP Values

• Simplicity

• Communication

• Feedback

• Courage

12 elements• Small releases • The planning game• Continuous integration• Test-driven Development• Sustainable Pace• Whole team• Metaphor• Pair programming• Design improvement• Simple Design• Collective Code Ownership• Coding standards

Small releases

• Agile and XP methods are refinements of iterative methods

• Plan to release a functional system to the users about every month

• Release an iteration to the customer for customer tests every week

• Integrate to get a working system several times a day!

The Planning game

• Accurate prediction at the start of a project is too difficult

• So• STEER the project, little by little• Start with a collection of ‘user stories’,

tasks or units of functionality – developers estimate, together allocate to a release

• Make plan visible – task cards on a wall

Continuous integration

• Integration of multiple software components, hardware, networks is a very troublesome phase

• So do it frequently – Only small problems appear and can be fixed– There is always a working system to test, use

and as a common code base

Test Driven development

• Write the tests for a function first.• Then write the code to meet those tests –

and no more! Don’t anticipate future requirements (see Simple Design)

• Automate the testing, so that the tests can be rerun frequently

• Developers write the tests• Customer also writes tests for a release

Sustainable Pace (40hr week)

• Developers forced to work long overtime hours to meet unrealistic deadlines make more mistakes, and can actually cost time rather than save it

• So work hard, but keep to working week• Recognises the whole developer, and her

needs for rest, recreation and her life outside work

Whole Team (on-site customer)• Project is steered by a dedicated, full time

customer who works with the team• Customer develops user stories – broader

than use cases – a scenario of use of the system, which delivers useable functionality

• Stand-up meeting every morning – 15 minutes reporting briefly on progress yesterday, plan for today, issues

Metaphor

• A common vision of what the system is doing

• Common vocabulary to provide a jargon for the whole team

• e.g. a system requiring matching would be a ‘dating agency’

Pair Programming

• All programming done in pairs – one is the driver – at the keyboard, the other is the coach, critic, support

• Roles switch• Pairs switched about to spread knowledge

of technology, XP and the application• Novice/experienced programmer

combination develops team learning

Simple Design

• Do the simplest thing possible to pass the tests

• Don’t anticipate future requirements• ‘Spike’ – a simple end-to-end

implementation to prove basic idea/technology

Design improvement• Keeping the design simple requires constant

improvement – spotting common code and re-factoring (generalising and normalizing)into one place.

• Re-testing checks improvement hasn’t broken the code

• Good general structures emerge from the continuous work, doesn’t need up-front investment in design (which often turns out to be wasted)

Collective Code Ownership

• cf. Gerry Weinberg and egoless programming (1971)

• All code belongs to the team• Any member can fix code • No waiting because writer is busy or ill

Coding Standards

• Standards make code more shareable• Standards avoid personal styles e.g.

bracket placement, indenting• Good variable and method naming is

preferable to comments

Does XP work?• Survey in 2001

– 45 respondents– 50% finished projects– 44/45 would use XP again– Most useful

• Common code ownership• Testing

– Least useful• Onsite Customer• Metaphor

• Issues– Non-responders– Early adopters can fit new techniques through enthusiasm– Clash with Software Capability Maturity Model SW-CMM– Clash with QA procedures– Clash with sales – changed relationship with customer

Fitness for purpose

• Need to fit development approach to situation– Development Culture

• Developer values• Outsourcing• Contractual situation

– Risk of project failure– Volatility of requirements– Risk of software failure

Tutorial• Preparation

– Browse wiki site– Read the reviews of Beck’s and Fowler’s several

books on Amazon– Locate other web-based material which contributes to

the debate• Questions

– Which elements could you use in the development of the group project?

– Which elements could you not use in the development of the group project?

– How well would XP fit into any company you are familiar with? What would be the barriers to change?

References

• Wikipedia• Agile Manifesto• Iterative and Incremental Development• Extreme Programming Evaluation• XP Distilled• 8 reasons why XP wont work• Ian Sommerville

Next Week

• Model-driven development