ISD 3 Lecture 7 Agile development and Extreme

ISD 3 Lecture 7 Agile development and Extreme Programming

Evolution of Development Process Models • ‘Software Engineering’ (1969) • Waterfall model – classic linear lifecycle (Royce 1970) • Throw-away Prototyping (early ’ 80 s) • V model (Emphasis on Testing) late ’ 80 s • 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)

Changing Forces • Speed, cost, capacity of computers – 1960’s • too costly to be used for development : 2 MHz , 32 k + 64 k + tape : £ 100, 000 • turnaround time : 1 day – 2000 • 3 Ghz, 500 Mb + 50 Gb = £ 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 (objectoriented 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 rapidlychanging technology

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 (40 hr 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 refactoring (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 – Read the Bedoll paper, and others on Agile and XP – 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 currency converter? – Do you think XP would be useful in the conduct of student projects? – How well would XP fit your placement company and the project you were involved in? What would be the barriers to change?