AGILESoftware Development

ProcessRichard Thomas

Software Development Life Cycle ModelsCode and Fix• Little to no planning• Most frequently used model• Immediately start developing, fix problems as they

occur• Keep going until you think you’re done• Tempting choice when under tight schedule• See immediate results• Problems found late on in development are costly to

remedy

Software Development Life Cycle ModelsWaterfall• Emphasis on design in the initial stages• Document and planning intensive• Good for quality controlled environments• A classic software development model• Widely used in government / large company projects• Results are not seen until late in the development

System Requirements

Software Requirements

Architectural Design

Detailed Design Coding Testing Maintenance

Software Development Life Cycle ModelsModified Waterfall• Try to allow some of the stages to overlap• Reduces the documentation and cost of switching

between stages• Allowing some Design before finishing the Requirements

can help with the Requirements understanding• Hard to know when a particular stage is complete• Tend to put off major decisions, increasing expense

System Requirements

Software Requirements

Architectural Design

Detailed Design Coding Testing Maintenance

Software Development Life Cycle ModelsPrototyping• Begin development before the requirements are fully

understood• Build the prototype, adjust the requirements, repeat

until the objectives are fully understood• Gives the false impression of early progress• Prototypes can often be built on compromises that are

to be addressed later, making it an ineffective foundation for the future solution• Very similar to code and fix

Software Development Life Cycle ModelsSpiral• Emphasises risk management – find major problems

early• Break project into a set of risks that need dealing with• Attack each risk in a spiral:• Analysis• Design• Implementation• Testing

• Very experimental approach

AGILESoftware Development Process

“Walking on water and developing software from a specification

are easy if both are frozen”

- Edward V Berard

The AGILE Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over Processes and tools• Working software over Comprehensive documentation• Customer collaboration over Contract negotiation• Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick

Individuals and Interactions

• In AGILE development, self-organization and motivation are important, as are interactions like co-location and pair programming.

Individuals and interactions over Processes and tools

Working Software

• Working software will be more useful and welcome than just presenting documents to clients in meetings.

Working software over Comprehensive documentation

Customer Collaboration

• Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.

Customer collaboration over Contract negotiation

Responding to Change

• AGILE development is focused on quick responses to change and continuous development.

Responding to change over Following a plan

12 Principles of AGILE

1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than months)4. Close, daily cooperation between business people and developers5. Projects are built around motivated individuals, who should be trusted6. Face-to-face conversation is the best form of communication (co-location)7. Working software is the principal measure of progress8. Sustainable development, able to maintain a constant pace9. Continuous attention to technical excellence and good design10. Simplicity—the art of maximizing the amount of work not done—is essential11. Self-organizing teams12. Regular adaptation to changing circumstances

AGILE Methods

• Adaptive Software Development (ASD)• Agile Modelling• Agile Unified Process (AUP)• Crystal Methods (Crystal Clear)• Disciplined Agile Delivery• Dynamic Systems Development Method (DSDM)• Extreme Programming (XP)• Feature Driven Development (FDD)• Lean software development• Scrum• Scrum-ban

AGILE Summary

• Accept and embrace change• Provide early, frequent software releases• Close, frequent collaboration• Continuous testing• Trust• Software-based progress measurement• Technical excellence

Success Rate

Steven Rakitin

“yet another attempt to undermine the discipline of software engineering”Rakitin translated the manifesto bullet

“Working software over comprehensive documentation”into

“We want to spend all our time coding. Remember, real programmers don’t write documentation.”

This is disputed by proponents of Agile software development, who state that developers should write documentation if that's the best way to achieve the relevant goals, but that there are often better ways to achieve those goals than writing static documentation

Conclusion

• A good agile team picks and chooses the management and technical practices that best work for them.• When trying to adopt Agile practices, there will be a ton

of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success.• Those who are searching for reasons why it will fail –

well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls fake agile.

VI Shots podcasts

• http://vishots.com/37