Agile Methods

Theme 1 Software Processes
Focus on Extreme Programming
Ragnhild Van Der Straeten - ULB - Software Engineering and Project Management - 2011/2012
Roadmap
Agile Methods
Agile Manifesto Agile Principles Agile Methods Agile Processes Integrating Agile with Non-Agile Processes
2
Scrum, Crystall, ...
Learning Goals
How did agile methods come about? What are the principles of agility? How are agile processes carried out? Can agile processes be combined with nonagile ones?
Agile Development
Manifesto for Agile Software Development We are uncovering better ways of developing software by doing 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.
The Manifesto for Agile Software Development

Ragnhild Van Der Straeten - ULB - Gnie logiciel et gestion de projets - 2009/2010
4
Agile Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efcient and effective method of conveying information to and within a development team is face-to-face conversation.
5
Agile Principles

Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indenitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reects on how to become more effective, then tunes and adjusts its behavior accordingly.
6
Agile Cycle
SCRUM
Developed in early 1990s Based on assumption: development process is unpredictable and can only be dened by a loose set of Development team empowered to dene and
execute the necessary tasks to successfully develop software.
8
complicated activities.
SCRUM ow
Picture taken from http://www.visionpace.com/scrum.htm

9
Family of agile methods developed by Alistair Cockburn. All Crystal methodologies are built around three common
priorities:
Crystal
Crystal methods exhibit seven properties to varying

degrees:
Safety in the project outcome, Efciency in development, Habitability of the conventions
frequent delivery, close communication reective improvement personal safety focus
easy access to expert users technical environment with automated testing, conguration management, and frequent integration.
10
Integrating Agile with NonAgile Processes
Regardless of development process used: need to make trade-offs in deciding how

software enterprise.
E.g. how much effort to spend on planning a

extensively to pursue a phase before moving to another phase.
11
Agile/Non-Agile Tradeoff
Benefits of Agile !Motivates developers !Thoroughly tested, mostly !Easier to estimate each cycle !Responsive to customer !Always demonstrable software Costs of Agile "Hard for new participants "Sensitive to individuals "Hard to estimate full job "Limits team size "Questionable security
12
Integrating Agile with Non-Agile Methods: Non-Agile-driven

time
Requirements documentation Design documentation
1
*
4 2
*
5 Coding & test 3
System Testing
6
* High level
13
Integrating Agile with Non-Agile Methods: Agile-driven

Initial agile development Requirements documentation Design documentation Coding & test (including agility?)
14
Roadmap
Extreme Programming
Customer developer relationships. XP described. Phases in an XP project. Design and XP.

15
Learning Goals
Why applying XP? What are the values of XP? What are the main practices of XP? How to design in XP? How is an XP project carried out?
16
Extreme Programming (XP)

Point of XP: coping with change and Based on number of practices:
code, sustainable development, continuous integration,
uncertainty
small, frequent releases of the system, full-time engagement of customer, pair programming, collective ownership of the regular system releases, test-rst development, constant refactoring, simplest thing that can work.
17
Driving Metaphor
Driving a car is not about pointing the car in one direction and holding to it; driving is about making lots of little course corrections.
Do the simplest thing that could possibly work
18
Customer-Developer Relationships A well-known experience: The customer and the

developer sit in a boat in the ocean and are afraid of each other
Customer fears
They won't get what they asked for They must surrender the control of their careers to techies who don't care They'll pay too much for too little They won't know what is going on (the plans they see will be fairy tales)
Developer fears
They won't be given clear denitions of what needs to be done They will be given responsibility without authority They will be told to do things that don't make sense They'll have to sacrice quality for deadlines
Result: a lot of energy goes into protective

measures and politics instead of success
19
The Customer Bill of Rights

You have the right to an overall plan You have the right to get the most possible value out of every programming week You have the right to see progress in a running system. To steer a project, you need to know what can be accomplished within time and budget The most valuable things are worked on rst. Only a running system can give exact information about project state
You have the right to change your mind, to substitute functionality and Market and business requirements change. We to change priorities without exorbitant have to allow change. costs. You have the right to be informed about schedule changes, in time to choose how to reduce the scope to restore the original date.
XP works to be sure everyone knows just what is really happening.
20
The Developer Bill of Rights

You have the right to know what is needed, with clear declarations of priority. You have the right to produce quality work all the time. You have the right to ask for and receive help from peers, managers, and customers You have the right to make and update your own estimates. You have the right to accept your responsibilities instead having them assigned to you Tight communication with the customer. Customer directs by value. Unit Tests and Refactoring help to keep the code clean
No one can ever refuse help to a team member Programmers know best how long it is going to take them We work most effectively when we have accepted our responsibilities instead of having them thrust upon us
21
Customer makes business decisions Developers make technical decisions

Business Decisions Scope Dates of the releases Priority Estimates
Separation of Roles
Technical Decisions Dates within an iteration Team velocity Warnings about technical risks
The Customer owns what you get while the

developers own what it costs.
22
Describing XP
Values Principles
Practices
23
Basic XP Values
Communication Simplicity Feedback Courage Respect
communicate problems&solutions, teamwork eliminate wasted complexity change creates the need for feedback effective action in the face of fear care about you, the team, and the project
24
Principles
Humanity, Economics, Mutual Benet, Self-Similarity, Improvement, Diversity, Reection, Flow, Opportunity, Redundancy, Failure, Quality, Baby Steps, Accepted Responsibility Will not detail them -- they govern what the practices tend to accomplish So, on to the practices!
25
Primary Practices
Sit Together Whole Team Informative Workspace Energized Work Pair Programming Stories Weekly Cycle Quarterly Cycle
26
Slack Ten Minute Build Continuous Integration Test-First Programming Incremental Design
Stories
plan using units of customer-visible functionality name estimate 8 hrs Save with compression Currently the compression options are in a dialog subsequent to the save dialog. Make them part of the save dialog itself short description
index card
27
7 more User Stories

Students can purchase monthly parking passes
online.
Parking passes can be paid via credit cards. Parking passes can be paid via PayPal . Professors can input student marks. Students can obtain their current seminar schedule. Students can only enroll in seminars for which they
have prerequisites. browser.
Transcripts will be available online via a standard

28
Another example
29
User Stories vs. Use Case
Not the same artifact!
30
Sit Together
Develop in an open space big enough for the team
31
Informative Workspace
Workspace = about your work 15 seconds to convey how project is going shows important, active information drinks & snacks available, and clean
done this week this release
to be estimated
future
32
Pair Programming
Write all production programs with two
people sitting at one machine
Pair programmers:
make enough room, move keyboard and mouse keep each other on task brainstorm renements to the system clarify ideas take initiative when partner is stuck (less
frustration)
hold each other accountable to practices
33
Pair programming and privacy

Sometimes you might need some privacy then go work alone come back with the idea (NOT the code) quickly reimplemented with two benets the whole team, not you alone
34
Pair Programming
Rotate pairs frequently every couple of hours, at natural breaks in with a timer, every 60 minutes (or 30
minutes for difcult problems)
35
development
Pair Programming and Personal Space

Not everybody likes to sit close! Observe personal hygiene and health Sexual feelings are not in best interest of the
team
When uncomfortable pairing with somebody,

talk about it with someone safe
even when mutual
chances are that you are not the only one everybody needs to feel comfortable
36
Weekly Cycle
Plan work one week at a time. Do this on a meeting at the begin of each
implement this week.
week 1. Review progress. 2. Let customers pick a weeks worth of stories to 3. Break the stories into tasks. Team members sign up for tasks and estimate them. stories are completed
Start writing tests that will run when the
37
Ten-Minute Build
Automatically build the whole system and run
all of the tests in ten minutes
Note: if it takes longer than 10 minutes:

necessary
longer: will not be used (and errors result) shorter: not enough time to drink coffee maybe only rebuild changed part or test changes But: introduces errors. Only do this when
see.
Lowers stress: Did we make a mistake? Lets

38
Continuous Integration
Team Programming = Divide, Conquer, Integrate and test changes after no more than
a couple of hours Integrate
integration typically takes long when done at the end, risks the whole project
when integration problems are discovered more unpredictable it becomes
the longer you wait, the more it costs and the

39
Using Continuous Integration Synchronous

After a task is nished, you integrate and run the
tests
Asynchronous
Immediate feedback for you and your partner After submitting changes, the build system notices
something new, builds and tests the system, and gives feedback by mail, notication, etc. started already
Feedback typically comes when a new task is Pair programmers might have been switched
40
Test-rst Programming
Write a failing automated test before changing Addresses many problems:
code
Scope creep: focus coding by what the code

should do, not on the just in case code
Coupling and cohesion: If its hard to write a test,

there is a design problem (not a testing problem)
Trust: clean working code + automated tests Rhythm: gives focus on what to do next
efcient rhythm: test, code, refactor, test, ...

41
Incremental Design
Invest in the design of the system every day.
Waterfall and similar approaches Can work with XP because of the other practices
Strive to the design of the system an excellent t for the needs of the system that day
Completely opposite to lots of other practices
Note: you need to invest in design!
Automated tests, continuous integration, ... not just implement story after story after story...
42
Corollary Practices
Real Customer Involvement Incremental Deployment Team Continuity Shrinking teams Root-Cause Analysis Shared Code Code and Tests
43
Single Code Base Daily Deployment Negotiated Scope Contract Pay-Per-Use
Stages in XP Project
Initiation Release Planning Release (each Release is typically 1 -6 months)
Iteration 1 (typically 1 -3 weeks) Iteration 2
:
User Stories
Iteration n
44
User stories capture requirements
replaces use cases made by the customer used to create time estimates for release planning
tests
User stories are used to create acceptance

verify proper implementation of story
45
Design and XP
XP says: Design is daily activity, and Use the incremental design

simplest solution that works
46
When to design in XP
Just enough to get feedback for next iteration Therefore
deferred until decision can be used immediately deploy software sooner make decisions with certainty avoid living with bad decisions maintain pace of development
47

Agile Methods

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Methods

Uploaded by

Copyright:

Available Formats

Theme 1 Software Processes

Focus on Extreme Programming

Scrum, Crystall, ...

The Manifesto for Agile Software Development

Picture taken from http://www.visionpace.com/scrum.htm

Crystal methods exhibit seven properties to varying

Safety in the project outcome, Efciency in development, Habitability of the conventions

frequent delivery, close communication reective improvement personal safety focus

Integrating Agile with NonAgile Processes

Regardless of development process used: need to make trade-offs in deciding how

E.g. how much effort to spend on planning a

extensively to pursue a phase before moving to another phase.

Integrating Agile with Non-Agile Methods: Non-Agile-driven

Requirements documentation Design documentation

5 Coding & test 3

Integrating Agile with Non-Agile Methods: Agile-driven

Customer developer relationships. XP described. Phases in an XP project. Design and XP.

Extreme Programming (XP)

Do the simplest thing that could possibly work

Customer-Developer Relationships A well-known experience: The customer and the

Result: a lot of energy goes into protective

The Customer Bill of Rights

XP works to be sure everyone knows just what is really happening.

The Developer Bill of Rights

Customer makes business decisions Developers make technical decisions

The Customer owns what you get while the

7 more User Stories

Transcripts will be available online via a standard

User Stories vs. Use Case

Not the same artifact!

hold each other accountable to practices

Pair programming and privacy

Pair Programming and Personal Space

When uncomfortable pairing with somebody,

even when mutual

Start writing tests that will run when the

Note: if it takes longer than 10 minutes:

Lowers stress: Did we make a mistake? Lets

the longer you wait, the more it costs and the

Using Continuous Integration Synchronous

Scope creep: focus coding by what the code

Coupling and cohesion: If its hard to write a test,

efcient rhythm: test, code, refactor, test, ...

Completely opposite to lots of other practices

Note: you need to invest in design!

Single Code Base Daily Deployment Negotiated Scope Contract Pay-Per-Use

User stories capture requirements

User stories are used to create acceptance

XP says: Design is daily activity, and Use the incremental design

You might also like