IAD

1. IAD Agile development and Extreme Programming

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. XP Values • Simplicity • Communication • Feedback • Courage

10. 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

11. 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!

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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’

18. 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

19. 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

20. 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)

21. 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

22. 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

23. 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

24. 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

25. 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?

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

27. Next Week • Model-driven development