Transcript Document
Agile Methodology &
Programming
Ric Holt
July 2009
1
Reaction to “Pure” Waterfall Model
• Around 1990, writing and discussion of
more fine grained and more adaptive
methodologies.
• Need for faster development, notably
when spec is not well known and teams
are small.
2
Agile Programming [2001]
[Wikipedia]
• Development methodology based on
– Iterative development
– Collaboration
– Self-organizing teams
– Goal: New release at end of each interaction
– Ideally: face-to-face team interactions
– Ideal team size: 7 +/- 1
– Daily meetings/interactions, perhaps with
client
3
Definition of the term “manifesto”
• A public declaration of principles, policies,
or intentions, especially of a political
nature.
4
Agile Software Development =
Agile Manifesto [2001]
• Individuals and interactions over
processes and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a
plan
5
Principles behind the Agile
Manifesto
1.
2.
3.
4.
5.
6.
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 efficient and effective
method of
conveying information to and within
a development
team is face-to-face conversation.
7.
8.
9.
10.
11.
12.
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
indefinitely.
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
reflects on how to become more
effective, then tunes and adjusts
its behavior accordingly.
6
Extreme Programming
• A software methodology
• A type of agile programming
• Has short development cycles (called
boxes) & releases
• Advocates: pair programming, ongoing
unit testing, flat management structure,
frequent communication among team &
with customer
7
Possible drawbacks of extreme
programming [Beck 1996]
• Lack of overall specification
• (In)ability to scale up to large projects
8
The game of rugby --- similar to
American football
• Scrum. Packs of opposing players push
against each other for possession of the
ball
• Once a team gets the ball, it attempts to
“sprint” to the goal line.
9
The rugby scrum
10
The rugby “sprint”
wesleying.blogspot.com/2009/03/mens-club-rugb..
11
Scrum Development [1986]
• Scrum: incremental framework for
managing complex work (such as new
product development) commonly used
with agile software development.
12
Three major roles in scrum
1) ScrumMaster, who maintains the
processes (typically in lieu of a project
manager);
2) Product Owner, who represents the
stakeholders; and
3) Team, a cross-functional group of about
7 people who do the actual analysis,
design, implementation, testing, etc.
13
Daily Scrum (15 minute meeting)
• What have you done since yesterday?
• What are you planning to do by today?
• Do you have any problems preventing you
from accomplishing your goal?
14
Burndown chart
http://www.xqual.com/resources/images/scrum_burndown_chart.gif
15
Sprint Planning Meeting
• Plan next 15-30 days
• Select what work is to be done
• Prepare the Sprint Backlog that details the
time it will take to do that work, with the
entire team
• Identify and communicate how much of
the work is likely to be done during the
current sprint
• Eight hour limit
16
Sprint Review Meeting
• Review the work that was completed
and not completed
• Present the completed work to the
stakeholders (a.k.a. "the demo")
• Incomplete work cannot be
demonstrated
• Four hour time limit
17
Sprint Retrospective
• All team members reflect on the past
sprint.
• Make continuous process
improvement.
• Two main questions are asked in the
sprint retrospective: What went well
during the sprint? What could be
improved in the next sprint?
• Three hour time limit
18
Scrum diagram
www.methodsandtools.com/archive/archive.php?id=18
19