Transcript מצגת של PowerPoint

Agile Methodologies
(including: XP & Scrum)
By Avi Wortzel
22.03.2007
Agenda



Problems in software development.
What is a Methodology.
The Agile methodology.




The eXtreme Programming (XP) methodology.





The Agile Manifesto.
Stepping towards Agile Development.
Well-known agile methodologies.
The XP lifecycle.
The Original 12 Practices.
When to use XP.
The Scrum methodology
Our best practices.
Problems in software development
 Schedule
slips
 Business misunderstood
 Defect rate
 Project cancelled
 System goes sour
 Business changes
Schedule slips
 Many

Examples: Netscape 6
 Some

projects are not delivered on time
deadlines cannot be moved
Example: Y2K
 What
if:
most business value is delivered on time
Business misunderstood
 Without
direct communication, developers
have to guess what the customer wants.
 What
if:
an on-site customer steers development
Defect rate
 The
software is put in production, but the
defect rate is so high that it isn’t used.
 What
if: you have automated testing
Project cancelled
Size of project
Early
On-Time
Delayed
Cancelled
Sum
1 function point
14.68%
83.16%
1.92%
0.25%
100.00%
10 function points
11.08%
81.25%
5.67%
2.00%
100.00%
100 function points
6.06%
74.77%
11.83%
7.33%
100.00%
1,000 function points
1.24%
60.76%
17.67%
20.33%
100.00%
10,000 function points
0.14%
28.00%
23.83%
48.00%
100.00%
100,000 function points
0.00%
13.67%
21.33%
65.00%
100.00%
Average
5.53%
56.94%
13.71%
23.82%
100.00%
Table 1: Percentage of projects early, on-time, late, canceled
(from Patterns of Software Systems Failure and Success, by Capers Jones)
Project cancelled
 What
if:
short releases deliver at least some useful
working software, reflecting investment to
date.
System goes sour
 Software
is put into production
successfully, but after a couple of years
the cost of making changes or the defect
rate rises so much that the system must
be replaced.
 What
if:
the design is simple and the code quality
is high
Business changes
 New
laws, market changes: business
priorities change
 What
if:
the customer can change their mind,
substitute functionality, and change
priorities
Economics of software development
cost of change
Requirements
Analysis
Design
Implementation
Testing
Production
What if…
cost of change
Time
What it Methodology?
(In software engineering and in project management)
“A methodology is a codified set of practices
(sometime accompanied by training materials,
formal educational programs, worksheets, and
diagramming tools) that may be repeatably
carried out to produce software.
Software engineering methodologies span many
disciplines, including project management,
analysis, specification, design, coding, testing,
and quality assurance.” (Wikipedia)
What is Agile?
 “The
ability to move or think easily and
quickly“ (http://www.answers.com).
 In software development, “agile” tends
to mean “the ability to respond to
change.”
The Agile Manifesto
The focal values honored by the agilists are presented in the following:
 Customer’s satisfaction:

By a rapid, continuous delivery of useful software

Even late changes in requirements are welcomed
 Time to market:

Working software is delivered frequently (weeks rather than
months)
 Communication:

Close, daily, cooperation between business people and
developers

Face-to-face conversation
 Human factor:

Projects are built around motivated individuals, who should be
trusted

Continuous attention to technical excellence and good & simple
design
 Regular adaptation to changing circumstances
Focal aspect in Agile
 Focus
only on the necessary functions
at first hand.
 Deliver them fast.
 Collect feedback.
 React to the received information.
What makes a development
methods an agile one?

When software development is incremental
(small software release, with rapid cycles ).
 Cooperative (customer and developers
working constantly together with close
communication).
 Straightforward (The design & code are easy
to learn and to modify, well documented).
 Adaptive (can make last moment changes).
“Sweet spots” for successful project
(by Alistair Cockburn 2002)





2 to 8 people in one room (communication &
community).
On-site customers (Short & continuous feedback
cycles)
Short increments (One to three months, allow
quick testing and repairing).
Fully automated regression tests (Unit &
functional tests stabilize code and allow
continuous improvement)
Experienced developers speeds up the
development time from 2 to 10 times, compared
to a slower team members.
Some of the well-known agile
software development methods:









Extreme Programming)XP( - 1999
Scrum - 1993
Agile Modeling - 2002
Adaptive Software Development (ASD) - 2000
Crystal Clear and Other Crystal Methodologies - 2002
Dynamic Systems Development Method(DSDM( - 1997
Feature Driven Development - 2002
Lean software development - 2002
Agile Unified Process(AUP( - 2000
What Is eXtreme Programming?

eXtreme Programming (XP) is a software
engineering methodology.
 The most popular in agile methodologies.
 Evolved from the problems:


long development cycles of traditional
development models.
XP combines best practices in a different way.
The XP lifecycle
Exploration phase
 The
customer writes out the story cards.
 Each story card is a feature to be added.
 Development team decides on tools,
technology and practices.
 Building a prototype of the system.
The exploration phase takes between a few
weeks to a few months
Story card
The XP lifecycle
Planning phase
 Sets
the priority order for the stories.
 Agree on the first small release (no more
than tow months for the first release).
 The programmers first estimate each story
requires.
The planning phase itself takes a couple of days
The XP lifecycle
Iterations to release phase



Includes several iterations before the first release.
Each iteration takes one to four weeks to implement.
The first iteration creates a system with the architecture is the
whole system.
 The customer decides the stories for all other iterations.
 The functional tests created by the customer are being run at
the end of every iteration.
 At the end of the last iteration the system is ready for
production.
The Iterations to release phase takes one to tree months
The XP lifecycle
Productionizing phase

Requires extra testing and checking of the
performance before the system can be released.
 New changes may still be found and the
decision has to be made if they are included in
the current release.
 The postponed ideas and suggestions are
documented for later implementation during,
e.g., the maintenance phase.
The Productionizing phase takes one to tree weeks
The XP lifecycle
0
Maintenance phase

The XP Project must both:
 keep the system in the production running
 while also producing new iterations.
 The maintenance phase requires an effort also for
customer support tasks.
 The development velocity may decelerate.
 This phase may require incorporating new people
into team and changing the team structure.
The Maintenance phase takes ...
The XP lifecycle
0
Death phase

This phase is near when the customer does no
longer have any stories to be implemented.
 This required that the system satisfies customer
needs also in others respects (e.g., concerning
performance and reliability).
 This is the time in the XP process when the
necessary documentation of the system is finally
written as no more changes to the architecture,
design or code are made.
 Death may also occur if the system is not
delivering the desired outcomes, or if it becomes
too expensive for further development.
The Original 12 Practices












The Planning Game
On-Site Customer
Small Releases
Testing
Simple Design
Pair Programming
Refactoring
Continuous Integration
Collective Ownership
Coding Standards
Metaphor
40-Hour Week
Planning Game


This stage includes release planning & Iteration Planning.
“Requirements collection” phase:




The customer write stories.
The customer set priority for each story.
The developers estimate the costs and risks.
The “Planning Game” phase:


Calculating all the parameters of risks, priorities and coats.
Creating a list of tasks.
This help to get a real estimation based on the real team’s
performance.
 The release is generally from 1 to 3 month, and each iteration
is generally from 1 to 3 weeks.

Planning Game
Story
Priority Cost
Story card 1
Story card 2
Story card 3
3d
1
0
5
5d
5d
On-Site Customer
 The
main idea in XP is based on project
community.
 The customer attends and is available on
site to clarify stories, identify and solve
requirements problem quickly.
 Reducing the developers waiting time for
decisions.
 The communication is more effective
(without organization politics).
On-Site Customer
Small Releases





Time-boxing - the deadline is fixed, and the
deliverables are adjusted.
Immediate ROI (Return of investment): small
release with enough business values.
Fast feedback.
Easy to guidance.
The customer feels that the application is always
under a developing process, and that he has
quick influence abilities.
Testing

Acceptance Testing:






Written by the customer, based on the story cards.
To check that the system implements all the requires.
All acceptance tests executed in each iteration (part of the
regression testing)
Usually as automation tests.
Using to measure the project progress.
Unit Testing:





Written by the programmer.
Automation tests.
Coverage testing - Checking all your code.
Running the unit tests in a daily process, before check-in and
before & after refactoring.
Use the xUnit framework.
Testing: Test-Driven Development

Likely the most innovative XP practice
 Developer writes a unit test prior to writing code
 Developer writes just enough code to make the unit test
pass
 Developer refactors to ensure code is simple and clean.
 Developer continues until acceptance test passes.
 Unit Testing makes your developer lives easier:
 Easier to find bugs
 Easier to maintain
 Easier to understand
 Easier to Develop
Simple Design

Design the most simple possible solution that
can be implemented at the moment:




Passes all the tests.
No duplicate code.
Fewest possible classes and methods.
See the whole picture before jumping to write
code.
 Involves a lot of people in thinking of a solution.
 Simple designs reduce programmer’s questions.
Simple Design
Pair Programming



All production code is written in pairs.
Includes two people that are sitting on one computer, with one
keyboard and one mouse.
Benefits:

15% less output than 2 solo programmers.

Higher quality code :Continuous code review, better design, less defects.

Confidence to add or change the system.

Teach each other how the system works (reduced risks).

Learn from partner’s knowledge and experience (enhances technical
skills).
 Research shows that pairing can be more effective than solo programming.
 Short-term costs made up by long-term benefits.
 Contributes to avoidance of knowledge debt.
Pair Programming
Refactoring (Design Improvement)
 Improves
the design of existing code
without changing its functionality.
 Design becomes everybody’s daily
business.
 Always improve quality of the code.
 Easy to make when using unit tests & pair
programming.
Refactoring (Design Improvement)
Continuous Integration

Move to the next task only after the current task
pass the integration tests.
 Integration occurs several times a day.
 Daily builds – part of the integration process.
 Benefits:



Forces bug fixing to occur immediately
Avoiding a situation when the integration occurs only
next to the deployment.
reducing the changes after merging.
Collective Ownership
 Any
one can make changes to any part of
the code at anytime.
 No queuing bottlenecks:

No need to wait for someone else to fix
something.
 Everyone
responsible for code integrity.
Coding Standards
 Consensus
of coding style and practices.
 Code conventions:

consider when using Pair Programming,
Refactoring and Collective Code Ownership.
 Method

commenting:
The code should explain itself:
 If your code needs a comment to explain it, rewrite it.
 If you can't explain your code with a comment, rewrite it.
Coding Standards
Who breaks the standard in this picture?
Metaphor
 For
the team to communicate, it needs a
common language to talk about the
system.
 The ideal model and language is that of
the actual problem domain (DomainDriven Design).
 The ideal model evolves, and can take
time.
40-Hour Week

Development is like a marathon, not a sprint.
 A maximum of 40 hours working week.
 Week overtime is allowed but not sequentially.
 Tired developers make more mistakes, which
slows you down more in the long run.
 Investing in people’s personal lives, will give you
more in the long run of the project.
40-Hour Week
Development is like a marathon, not a sprint.
Additional Practices
 The
stand-up meetings.
 Big visible charts.
 Team culture.
…
Patterns & Practices Offices (Redmond)
Pros vs. Cons

Pros:

That increases the customer satisfaction.

That designed to deliver the software your customer needs when it is
needed.

It emphasizes team work.




Dynamically changing requirements.
Risky projects.
Small teams.
Cons:






Complex system.
Distributed teams.
Special physical environment.
Culture shift can be difficult for developers and managers:
• coding standards, automated testing.
• pair programming.
Requires experienced OO developers.
May not get a customer on-site
Scrum
 Scrum
is an Agile process or framework
for managing Agile projects.
 It is a project management process,
certainly not a methodology, as that would
be too heavy.
Scrum
Scrum roles
I don't think so,
I'd
beGood
committed
idea, but
Why
don't
Hey,
whywe call
you'd
only
be
whatand
do
you
itdon't
'Ham
Eggs'?
we open
involved
want
to call it?
a restaurant?
Scrum
Scrum Sprint
 A Sprint
is a time-boxed period of time
(one month).
 Sprint contains:





Sprint planning
Sprint goal
Sprint review
Sprint retrospective
Release sprint(*)
Daily Scrum Meeting

A short status meeting that is time-boxed to 15 minutes and is
held daily by each Team.
 During the meeting the Team members:
 synchronize their work and progress
 report any impediments to the Scrum Master for removal.
 Each Team member should respond to the following
questions:
 What have you done since the last Daily Scrum regarding
this project?
 What will you do between now and the next Daily Scrum
meeting regarding this project?
 What impedes you from performing your work as
effectively as possible?
Sprint Review




The main goal of the sprint review meeting is to present
the project status on the end of the sprint.
We usually invite managers, product owners, users
and everyone who are interested to see the project
progress.
For a good brainstorm we should demonstrate the
product functionality (only a complete work that we
committed at the beginning of the sprint). It will help us to
clarify the items that will add on the next sprint.
On those meetings the team should talk about what
went wrong and what went right on the last sprint.
Scrum Review
Scrum retrospective

The main goal of the retrospective meeting is to
look back on last sprint, and to think together
how can we improve our enjoyable and
productive work on the next sprint?
 The sprint review looks at "What" the team is
building whereas the Retrospective looks at
"How" they are building.
 In this meeting the team can talk about all the
things that affect on the product development.
Scrum
Product Backlog

A product backlog is a prioritized list of project
requirements with estimated times.
 Estimates are in days.
 Priority should be assigned based on the items
of most value to the business or that offer the
earliest Return on Investment.
 This list should evolve, changing as the business
conditions or technology changes.
Product Backlog in TFS
Sprint Backlog
 A list
of tasks that defines a Team's work
for a Sprint.
 Tasks are estimated in hours, usually 1-16
Impediment List

Anything around a Scrum project that impedes
its productivity and quality is an impediment.
 The Scrum Master responsible to remove any
impediment that is stopping the team from
producing production quality code.
 The impediment list is simply a set of tasks
that the Scrum Master uses to track the
impediments that need to be solved.
Impediment List in TFS
What are the benefits of using
Scrum?
 The
benefits of Scrum is the ability to
respond more quickly to your competition.
 The ability to






develop and implement
high value high priority software
quickly
to increase your return on investment
to increase your costumer satisfaction
to increase the quality of your product
References
 http://www.xprogramming.com
 http://www.extremeprogramming.org
 http://weblogs.asp.net/rosherove
 http://en.wikipedia.org
 http://www.scrumalliance.org
 http://scrumforteamsystem.com
 http://xp123.com/xplor/xp0206a
 And
more…
Questions?
The End
Avi Wortzel
http://blogs.microsoft.co.il/blogs/aviwortzel