Ivano Malavolta

Agile development

VRIJEUNIVERSITEITAMSTERDAM

Waterfall vs agile: poor visibility

Waterfall vs agile: poor quality

Waterfall vs agile: too risky

Waterfall vs agile: can’t handle change

The agile approach

Risks and features

http://www.testingthefuture.net/wp-content/uploads/2011/12/waterfall_versus_agile_development.png

Agile manifesto

We are uncovering better ways of developingsoftware 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 onthe right, we value the items on the left more.

http://www.agilemanifesto.org

How does it work in practice?

You make a list You start executing

You estimate You update the plan “@run-time”

You set priorities

Agile iterations

Technical tools: unit tests

Snippet of test code for exercising some functionality of the product à codified requirements

We will have a dedicated course on testing

Technical tools: test-driven development

Write tests firstRefactoring is less risky now

Technical tools: continuous integrationMerging all the developers’ working copies many times a day à it allows to make sure that all the code integrates, all the unit tests pass, and a warning if anything goes wrong

image from http://newmedialabs.com/

An implementation: SCRUM

AAA

An implementation: SCRUM

http://www.flickr.com/photos/magia3e/6233729753/

An implementation: SCRUM

Burndown chart = how much work is left

Scope changes• The engineering team

missed features in the UI mockups when we created the release backlog

• Integrations into other AdWords features were overlooked

• The rate of change in AdWords APIs is very high.

Critical evaluation of the agile method+ Acceptance of change à less risky+ Frequent and short iterations+ Emphasis on working code+ Associating a test with every piece of functionality

+ tests are a key resource within the project

+ Continuous integration (and delivery)+ Planned– Tests as a replacement for specifications– Feature-based development & ignorance of

dependencies– No quality plan– Dismissal of a priori architecture work

– actually, dismissal of everything which is non-shippable

References

Suggested readings

1. Striebeck, M., "Ssh! We are adding a process... [agile practices],"Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006

2. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner,Tony Gorschek, Pekka Abrahamsson, Software development instartup companies: A systematic mapping study, Information andSoftware Technology, Volume 56, Issue 10, October 2014, Pages1200-1218, ISSN 0950-5849

3. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process. InProceedings of the on Future of Software Engineering (FOSE 2014).ACM, New York, NY, USA, 1-12.

ContactIvano Malavolta |

Assistant professorVrije Universiteit Amsterdam

iivanoo

i.malavolta@vu.nl

www.ivanomalavolta.com