The Agile Movement

Modelos de Procesos y Metodologías de Ingeniería de software

Mayo de 2014

Universidad de CaldasFacultad de IngenieríasMaestría en Ingeniería Computacional

¡Welcome!

ContentAgile Methologies

The Agile Manifesto

Concrete agiles examples

CMMI & Agile

Sources• Gerard O’Regan, Introduction to Software Process Improvement, Springer2011. ISBN 978-0-85729-171-4

• Kenneth S. Rubin. Essential Scrum : a practical guide to the most popularagile process. Copyright 2013 Pearson Education, Inc. ISBN 978-0-13-704329-3

• Scott Ambler and Mark Lines. Disciplined Agile Delivery. A Practitioner’sGuide to Agile Software Delivery in the Enterprise. Copyright 2012, IBMPress. ISBN 978-0-13-281013-5.

• Joachim Rossberg and Mathias Olausson. Pro Application LifecycleManagement with Visual Studio 2012. Apress, 2012. ISBN 978-1118314081

• Alan Shalloway et al. Essential Skills for the Agile Developer - A Guide toBetter Programming and Design. Copyright © 2012 Pearson Education, Inc.ISBN 978-0-321-54373-8.

• Paul E. McMahon. Integrating CMMI® and Agile Development. 2011Pearson Education, Inc. ISBN 978-0-321-71410-7.

Agile Introduction (I)

The Agile methodology / Agile development is asoftware development methodology that claimsto be more responsive to customer needs thantraditional methods.

Agile Introduction (II)Agile has a strong collaborative style of working and itsapproach includes the following:

– Aim is to achieve a narrow fast-flowing value stream

– Feedback and adaptation employed in decision-making

– User stories and sprints are employed

– Stories are either done or not done

– Iterative and incremental development is employed

– A project is divided into iterations

– An iteration has a fixed length (i.e. Timeboxing is employed)

– Entire software development life cycle is employed for theimplementation of each story

– Change is accepted as a normal part of life in the Agile world

Agile Introduction (III)– Delivery is made as early as possible

– Maintenance is seen as part of the development process

– Refactoring and evolutionary design employed

– Continuous integration is employed

– Short cycle times

– Emphasis on quality

– Stand-up meetings

– Plan regularly

– Direct interaction preferred over documentation

– Rapid conversion of requirements into working functionality

– Demonstrate value early

– Early decision-making

A tale about Agile (I)

In 2001 a group of people met at a Utah ski resort to talk, ski,relax, and try to find common ground for software development.This is the result:

“We are uncovering better ways of developing software bydoing 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, wevalue the items on the left more.”

A tale about Agile (II)That is, while there is value inthe items on the right, we valuethe items on the left more.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

www.agilemanifesto.org (I)

“On February 11-13, 2001, at The Lodge atSnowbird ski resort in the Wasatch mountains ofUtah, seventeen people met to talk, ski, relax, andtry to find common ground and of course, to eat.What emerged was the Agile SoftwareDevelopment Manifesto. Representatives fromExtreme Programming, SCRUM, DSDM, AdaptiveSoftware Development, Crystal, Feature-DrivenDevelopment, Pragmatic Programming, and otherssympathetic to the need for an alternative todocumentation driven, heavyweight softwaredevelopment processes convened.”

www.agilemanifesto.org (II)

the Agile Manifesto lays down the following principles:

• Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.

• Welcome changing requirements, even late indevelopment. Agile processes harness change for thecustomer’s competitive advantage.

• Deliver working software frequently, from a couple ofweeks to a couple of months, with a preference to theshorter timescale.

• Business people and developers must work togetherdaily throughout the project.

www.agilemanifesto.org (III)• Build projects around motivated individuals. Givethem the environment and support they need, and trustthem to get the job done.

• The most efficient and effective method of conveyinginformation to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development.The sponsors, developers, and users should be able tomaintain a constant pace indefinitely.

• Continuous attention to technical excellence andgood design enhances agility.

www.agilemanifesto.org (IV)• Simplicity—the art of maximizing the amount of worknot done—is essential.

• The best architectures, requirements, and designsemerge from self-organizing teams.

• At regular intervals, the team reflects on how tobecome more effective, then tunes and adjusts itsbehavior accordingly.

More about Agile history in:http://setandbma.wordpress.com/2012/03/23/agile-history/

• SEMAT Deal (www.semat.org)

• The new deal for software development(http://www.software-development-experts.com/the-new-deal.aspx)

But, be careful with “Deals”

• Ongoing changes to requirements areconsidered to be normal in the Agile world,and it is believed to be more realistic tochange requirements regularly throughout theproject rather than attempting to define all ofthe requirements at the start of the project.

• The methodology includes controls tomanage changes to the requirements, andgood communication and early regularfeedback are an essential part of the process.

Agile features - changes

• A story may be a new feature or a modification to an existingfeature. It is reduced to the minimum scope that can deliverbusiness value, and a feature may give rise to severalstories.

• Stories often build upon other stories and the entire softwaredevelopment life cycle is employed for the implementation ofeach story. Stories are either done or not done, i.e. there isno such thing as a story being 80% done. The story iscomplete only when it passes its acceptance tests.

• Stories are prioritized based on a number of factors including

– Business value of story

– Mitigation of risk

– Dependencies on other stories

Agile features – user stories

• Sprint planning is performed before the start of aniteration. The goal is to assign stories to the iterationto fill the available time. The estimates for eachstory and their priority are determined, and theprioritized stories are assigned to the iteration.

• A short morning stand-up meeting is held dailyduring the iteration and attended by the projectmanager and the project team. It discusses theprogress made the previous day, problem reportingand tracking, and the work planned for the dayahead. A separate meeting is conducted for issuesthat require more detailed discussion.

Agile features – planning

• Once the iteration is complete the latest productincrement is demonstrated to an audience includingthe product owner.

• This is to receive feedback as well as identifyingnew requirements.

• The team also conducts a retrospective meeting toidentify what went well and what went poorly duringthe iteration. This is to identify improvement actionsfor future iterations.

Agile features – delivery

• Agile employs pair programming and a collaborativestyle of working with the philosophy that two headsare better than one.

• This allows multiple perspectives in decision-makingand a broader understanding of the issues.

Agile features – pair programming

• Software testing is very important and Agilegenerally employs automated testing for unit,acceptance, performance, and integration testing.

• Tests are run often and aim to catch programmingerrors early. They are generally run on a separatebuild server to ensure all dependencies arechecked.

• Tests are re-run before making a release.

• Agile employs test driven development with testswritten before the code. The developers write codeto make a test pass with ideally developers onlycoding against failing tests.

• This approach forces the developer to write testablecode.

Agile features – testing

• Refactoring is employed in Agile as a design andcoding practice.

• The objective is to change how the software iswritten without changing what it does.

• Refactoring is a tool for evolutionary design wherethe design is regularly evaluated and improvementsimplemented as they are identified.

• The automated test suite is essential in showing thatthe integrity of the software is maintained followingrefactoring.

Agile features – refactoring

• Continuous integration allows the system to be builtwith every change.

• Early and regular integration allows early feedbackto be provided.

• It also allows all of the automated tests to be run,thereby identifying problems earlier.

Agile features – integration

• AMDD

• Agile Modelling - Scott Ambler

• http://www.agilemodeling.com/style/

• TDD

• Refactoring

• Unit Testing

• Continuous Integration

• Pair development

• User stories

• Releasing

Most representative contributions

• http://www.extremeprogramming.org/

• http://xprogramming.com/index.php

• Extreme Programming (XP) is adeliberate and disciplined approachto software development. It stressescustomer satisfaction, an importantpart of the Agile Manifesto. Themethodology is designed to deliverthe software the customer needs,when it is needed. XP focuses onresponding to changing customerrequirements, even late in the lifecycle, so that customer satisfaction(business value) is assured

eXtreme Programming (I)

• All code to be included in a production release is created by twopeople working together at a single computer. This shouldincrease software quality without impacting time to delivery.

• The software should be delivered to the customers as early aspossible and a goal is to implement changes as suggested. XPstresses that the developers should be able to courageouslyrespond to changing requirements and technology based on thisfoundation.

• XP have user stories. These serve the same purpose as usecases, but are not the same. They are used to create timeestimates for the project and also replace bulky requirementsdocumentation. The customer is responsible for writing the userstories and they should be about things that the system needs todo for them. Each user story is about three sentences of textwritten by the customer in the customer’s own terminology withoutany technical software jargon that a developer might use.

eXtreme Programming (II)

• XP also emphasizes teamwork. Managers, customers, anddevelopers are all part of a team dedicated to delivering high-quality software. XP implements a simple and effective way tohandle team work.

• There are four ways XP improves software team work;communication, simplicity, feedback, and courage.

• It is essential that XP programmers communicate with theircustomers and fellow programmers. The design should be simpleand clean. Feedback is supplied by testing the software from thefirst day of development.

• Testing is done by writing the unit tests before even writing thecode. This is called TDD and has started to become a very wellused practice in many projects, not only agile ones.

• Another important issue is that XP stresses the importance ofdelivering working software in increments so that the customercan give feedback as early as possible. By expecting that this willhappen, developers are ready for implementing changes.

eXtreme Programming (III)

SCRUM

Source: http://www.mozaicworks.com/agile/scrum/Source: SCRUM México http://scrum.org.mx/?page_id=7

“the rugby approach” (1986) - Harvard Business Review

Takeuchi and Nonacha argued that small cross-functional teams produced the best results from a historical viewpoint.

http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Development%20Game.pdf

SCRUM (II) Source: http://www.axosoft.com/scrumvideo

SCRUM (III) Source: Disciplined Agile Delivery

The Scrum lifecycle

• Product backlog (work item list)

• Value-driven lifecycle

• Daily Scrum (coordination meeting).

• Sprint review and demonstration

• Sprint retrospective

• User story driven development (usage-drivendevelopment).

See: http://www.implementingscrum.com/

SCRUM (IV)

• Release planning: it suggests abstracting the project plan toa higher level that describes higher level milestones such asdelivery of small increments of demonstrable functionality.These higher level plan items can then be allocated to aset of sprints (iterations) over the life of the project.

• Sprint planning (iteration planning): At the beginning of thesprint/iteration the team plans in detail what they will deliverand how they will do the work. This involves taking a set ofhighest priority requirements off the backlog and thendecomposing these requirements into detailed tasks. Theteam estimates this work and commits to the product ownerthat they will deliver the work according to the plan that theyhave created themselves.

SCRUM (V)

You must know the Disciplined Agile Delivery ofScott Ambler, in order to understand the valueof EPF process and libraries.

Key Issue

• Agile Modeling (AM) is a practice-basedmethodology for effective modeling anddocumentation of software-based systems.

• At a more detailed level AM is a collectionof values, principles, and practices formodeling software that can be applied ona software development project in aneffective and lightweight manner.

• AM was purposely architected to be a sourceof strategies that can be tailored into otherbase processes.

Agile Modelling (I)

• With an Agile Model Driven Development (AMDD)approach you typically do just enough high-levelmodeling at the beginning of a project to understandthe scope and potential architecture of the system.

• During construction iterations you do modeling aspart of your iteration planning activities and thentake a just-in-time (JIT) model storming approachwhere you model for several minutes as a precursorto several hours of coding.

• AMDD recommends that practitioners take a test-driven approach to development although does notinsist on it

Agile Modelling (II)

Agile Modelling (III)

Source: Disciplined Agile Delivery

Agile Modelling (IV)

Source: Disciplined Agile Delivery and http://www.agilemodeling.com/

Agile Modelling Features•Active stakeholder participation

•Architecture envisioning

•Document continuously

•Document late

•Executable specifications

•Iteration modeling

•Just barely good enough artifacts (sufficient artifacts)

•Look-ahead modeling

•Model storming

•Multiple models

•Prioritized requirements (work item list)

•Requirements envisioning

•Single source information

•Test-driven development (TDD)

Other agile methodologies• Lean Development

• Kanban

• DSDM

• ASD

• Crystal

Comparison from DAD S. Ambler

Comparison from DAD S. Ambler

CMMI & Agile (I)

The CMMI model is not a set of dictated

practices. It is a model that is intended to be

used to “reason” about our processes to help

us ask the right questions leading to an

understanding of our weaknesses and areas

of needed improvement.

CMMI & Agile (II)

Source: Integrating CMMI and Agile Development

CMMI & Agile (III)

Source: Integrating CMMI and Agile Development

How CMMI and Agile Help Each Other (I)

Source: Integrating CMMI and Agile Development

Source: Integrating CMMI and Agile Development

How CMMI and Agile Help Each Other (II)

How CMMI and Agile Help Each Other (III)

Source: Integrating CMMI and Agile Development

Questions?

Thanks