1 evolutionary development t. gilb. the agile alliance a group of writers, developers and...
TRANSCRIPT
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