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 10 8 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 manufactureScrum Organisation of a backlog of product features into iterative cycles (sprints) Organisation/renaming of roles Some jargon Video

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