ISD 3 Lecture 7

1
ISD 3 Lecture 7

• 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)

3
Changing Forces

• Speed, cost, capacity of computers
• 1960s
• 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
• 1960s 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
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

8
XP Values

• Simplicity
• Communication
• Feedback
• Courage

9
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

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

11
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

12
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

13
Test Driven development

• Write the tests for a function first.
• Then write the code to meet those tests and no
  more! Dont 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

14
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

15
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

16
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

17
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

18
Simple Design

• Do the simplest thing possible to pass the tests
• Dont anticipate future requirements
• Spike a simple end-to-end implementation to
  prove basic idea/technology

19
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 hasnt broken the
  code
• Good general structures emerge from the
  continuous work, doesnt need up-front investment
  in design (which often turns out to be wasted)

20
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

21
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

22
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

23
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

24
Tutorial

• Preparation
• Read the Bedoll paper, and others on Agile and XP
• Browse wiki site
• Read the reviews of Becks and Fowlers 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?