1

Evolutionary Development

                                                                                      

T. Gilb

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

5

The Generic Agile Life cycle 

6

XP

• Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements”

• Key Name: Kent Beck.• Where invented: USA• Year first used: Pre-2000• First used on: C3 project Chrysler; 8 developers.• Now used on: All over the place by different groups/people.

7

Small Cross-Functional Teams

Concept XP Scrum Crystal Orange DSDM

Number of teams 1 team per project 1 – 4 or more Variable; up to 40 people so probably 1 – 10 or so.

1 – 6

Team size 3 – 16 5 – 9 4 – 8 2 – 6

Team Members / Roles

Customer, Programmer, Tester, Tracker, Coach

Scrum master, Experienced Engineer, Junior Engineer, [QA Tester], [Writer]

Business Analyst-Designer, Designer-Programmer, UI Designer, [Tester ]

Team Leader, Ambassador User, [Advisor User], Senior Developer, Developer, Scribe

Project Roles Big Boss Project Manager/ Scrum master, Product Owner

Sponsor, Project Manager, Architect, Technical Facilitator, Design Mentor

Visionary, Executive Sponsor, Project Manager, Technical Co-ordinator, Facilitator

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

23

Predictive v Adaptive Some Key Issues

• Scope – breadth & depth of organisational effect

• Size – time, HR, number of functions, transaction volumes

• Complexity – systemic/organisational, deterministic/algorithmic

• Nature – of project, organisation, environment• Volatility – requirements, markets, technologies

24

Predictive V Adaptive

• Adaptive– Uncertain or volatile requirements– Responsible, talented and motivated developers– Customer who understands and is willing to commit to the

success of the project

• Predictive– A large development team (say 100+)– A fixed price, fixed scope contract

Martin Fowler, The New Methodology, Found at http://martinfowler.com/articles/newMethodology.html