G51FSE
Introduction to Software Engineering
Module Code : G51FSE
Agile Software Development
Prepared by: Behrang Parhizkar (Hani)
Table of Contents
Traditional Approach
Waterfall Model & Spiral Model
Advantages & disadvantages
7 reasons to move to Agile methodology
Agile Software Development
Scrum
Lecture Goals Outline
Learn about Agile programming paradigm
Learn how Agile compares to Waterfall and Spiral
The popular agile methods
Scrum, Extreme Programming (XP), Kanban Crystal
Clear, and DSDM (Dynamic Systems Development
Methods)
Traditional approach
Requirements
Design
Implementation
Waterfall
method
Testing
Deployment &
Maintenance
Software develop in sequential order
No way back
finish this step before moving to the next
Traditional approach contd.
Advantages:
Very logical and well organized
Specialized professionals in
each domain
Tracking each step quite easier
It helps to find error easier
Easy to understand, easy to use
If everything goes well, splendid!
Documentation is produced at
every stage of a waterfall model
allowing people to understand
what has been done.
Disadvantages:
Only suitable for the small size
projects.
Difficult to estimate time and cost
for each stage
Constant testing of the design is
needed.
High amount of risk and
uncertainty
Not suitable to handle dynamic
changes in the requirements
Adjust scope during the life cycle
can kill a project
Where to Use Waterfall Model
Requirements
are very well known
Product definition is stable
Technology is understood
New version of existing product
Traditional approach contd.
Waterfall and Spiral are heavy top-down
approaches
Inflexible structure of product
Well-defined sequence of
independent development phases
Many problems with these approaches
A lot of waiting time for developers
Tons of documentation
Can result in costly unnoticed errors
and buggy code
Hard to incorporate new or changing
customer requirements
Issues of Traditional Software Development
Unclear requirements
Requirements change
Lack of involvement of the customers
Accuracy of estimation
Uneven loading of the resources
Last minute correction is very difficult
Not much time for testing
No time to fix test defects
Lot of documentation
Schedule and cost overruns
Customers not happy
Traditional approach contd.
Developers skills more important than attitudes
Customer almost out-of-the development loop
I.e. customers do not have a voice in the software
development process
They consume desired software only when over all
development processes have been completed (No early
prototype)
No way of receiving continuous feedback (from
customer/stakeholder)
As an example
Lets imagine that we want to create a blog engine; considering the
following method:
Create the blog display page; deliver it to the customer
Create the user management and membership feature; deliver it
to our customer
Add commenting capability and management; deliver it to the
customer
So on and so forth
It is a simple approach, but the customer sees the real progress of
his software and gives you immediate feedback on each new feature
It may be perfect or require tweaking, but you can quickly respond to
changes: a win-win situation
Texts source: net.tutsplus.com
10
7 Reasons to move to Agile
1.
Ambiguous Requirements
Assumption: Customers can (and shall) identify all
the requirements in the beginning
What we do: Ask customers what they want
When they really dont know
Ask them to sign off the requirements
How many of customers comfortable to sign off
the requirements form at the beginning ?
The Reality: Customers may not know all
requirements in the beginning
Result: Over production of features
What Standish Group Chaos Report Says
A survey has been conducted with customers about the
features (functions) used in traditional software
Features rarely
Or never used by
End user
Example
What is the most popular software product you have
ever used?
Excel ? Word ? Powerpoint ?
How many features are in MS Word ? (1264)
What percentage of the features of MS Word do you use
?
You might end up with less than 10% of the features.
Most of the software products have a lot of features
which are rarely or never used.
One of the reason could be: Freezing requirements at
the beginning.
Agile understand all requirements can not
be collected in the beginning of the project.
So, Requirements are collected throughout
the development cycle.
And the requirements are never frozen in
Agile .
Requirements are prioritized continuously
for the business value.
7 Reasons to move to Agile
2. Requirements Changes are Inevitable
Assumption: Cost of change increases during the
development, so freezing the requirements is absolutely
required in the beginning
What we do:
Freeze the requirements in the beginning
Penalize the customers for adding things later
Do strict change control
Reality: New ideas may emerge at any time, even just before
the major delivery.
Competitors released a new features so your clients
must do as well.
Result: changes anyway happen and both the development
team and the customers are unhappy with them
So what are the main Challenges ?
Software teams are building something that does not
exist in the beginning
The customers is attempting to describe what they
imagine this non-existent product should be.
Our developers then try to imagine what the customer is
describing and build the product they believe they heard
the customer describe.
Interestingly, the first opportunity anyone has to truly see
if the product built is one that customer really needs is
after development is complete.
Requirements Uncertainty Principle
For a new software
system, the
requirements will not be
completely known until
after the users have
used it.
Watts Huphrey
Father of Software quality
Requirements Changes are always welcome in Agile
Agile understand that requirements changes are
inevitable and they are for the competitive advantage
of the customer.
7 Reasons to move to Agile
3. Big, Upfront Planning is not Practical
Recall: Because we assume we can collect all the requirements in the
beginning and freeze the requirements, so we also assume we can plan
everything upfront.
Assumption:
What we do:
Software is so simple that development can be planned from
beginning to end.
All projects variables (scope, cost, resources, schedule, risk) can
be predicted in the beginning
Upfront planning is possible and enough
Prepare a detailed plan in the beginning
We strictly track the progress as per this plan
Reality: Big, upfront planning is difficult, planning shall also
evolve along with the requirements.
Result: Lets look at the standard industry survey result.
How Good are the Project Planning Executing?
Standish Group http://www.standishgroup.com
Failure Statistics from the Famous Standish Groups
Chaos Report:
365 respondents (from small, medium & large companies)
Major industry segments (banking, health, insurance, etc)
8380 software applications
Survey Result:
Project Success:
The project is completed on-time, on-budget, with all features
and functions as initially specified.
Project Challenged:
52.7%
The project is completed but over-budget, over the time
estimate, and offers fewer features and functions than
originally specified.
Project Impaired:
16.2%
31.1%
The project is canceled at some point during the
development cycle.
Standish Group: Project Success Factors
What were key factors for success ?
Standish Group: Project Challenged Factors
What were key factors for challenges?
Standish Group: Project Impaired Factors
What were key factors for impairment?
Failure Statistics
No significant improvements over time
What are the Success Factors?
Item
Percentage
Schedule
61.3 %
It is more important to deliver a system
when it is ready to be shipped than to
deliver it on time.
Scope
87.3 %
Meeting the actual needs of stakeholders
is more important than building the
system to specification.
Money
79.6 %
Providing the best return on investment
(ROI) is more important than delivering a
system under budget.
Quality
87.3 %
Delivering high quality is more important
than delivering on time and on budget.
Staff
75.8 %
Having a healthy, both mentally and
physically, workplace is more important
than delivering on time and on budget.
http://www.drdobbs.com/architecture-and-design/definingsuccess/202800777
Big
, Upfront planning is not possible in the
software development as the requirements
are not complete.
Agile
In
focuses on Just in time planning
Agile, planning also evolves along
with the requirements.
7 Reasons to move to Agile
4. Reviewing the working software is better than reviewing
the documents.
Assumption:
What we do:
Ask the customers to sign off the requirements.
Reality:
Customers shall review the initial requirements and approve
them.
Most customers are not comfortable reviewing the documents
and approve them in the beginning.
Customers are rather happy in reviewing the working software.
If you show them a demo of software, they are happy, but if
you give them a bunch of documents, they are very
uncomfortable.
Result: The relationship starts in the unpleasant note.
In
Agile, customers review actual
working software increments.
Customers
feedback on the working
software are incorporated in the
requirement development.
7 Reasons to move to Agile
5. Iterative and incremental development is better than
sequential waterfall development
Assumption: (Iterative & Incremental Development)
What we do:
Develop the software sequentially, with one big final delivery.
Reality:
Software development shall be done in sequence and step by
step manner.
Customers can wait until the completion of the project for getting
the final product.
When the customers actually get to see the final deliverables, it
may be very different from what they thought they would get.
It is too late to change anything.
Result: Most of the customers are unhappy with the
deliverables.
Look at this case
Assuming a one year project starting on January:
Analysis
Time
Design
If customer cancel the
Project at this stage
Coding
Testing
The cost of change increases
Do we have half of
the solutions now ?
In the best case, the customer get a nice requirement
Analysis document and a nice design document with
some codes with several bugs.
In
Agile, software delivery is made to the
customers frequently in short iterations.
Customers
get small piece of prioritized
working software once in 2 to 4 weeks.
7 Reasons to move to Agile
6 . Delivery through small steps is better than a single huge
delivery at the end of delivery life cycle.
7. Frequent reflection by the project team is very important.
The reflection should happened almost every month in a one
year project rather than once at the end of the project.
Summary
Agile understand requirement will be always unclear.
Agile understand Customer may not know everything in
the beginning.
Agile starts with what customer currently know and
quickly show a demo of software based on the initial
customer requirements. (Requirements changes are
welcome in Agile)
Agile allow just in time planning throughout the project.
Agile show the working software to the customer as early
as possible and as often as possible.
Agile is based on iterative model and not sequential
order.
Surely there has to be another way?
Is it not possible to generate code in a unified yet flexible
manner?
Agile methods are a potential solution
There were a bunch of very talented and experienced
people developing some serious software
These developers observed other companies and
development teams, and how their processes made their
work easier
They compiled their observations to create the Agile
Manifesto
Texts source: net.tutsplus.com
34
http://agilemanifesto.org/
http://agilemanifesto.org/
35
Agile Software Development
Agile SD is a way of thinking about project management
Based on iterative and incremental development
Requirements as well as solutions evolve together
Collaboration between cross-functional, self-organising
teams
Teams kept small (5-9 people)
36
Principles of agile manifesto
1.
2.
3.
4.
5.
The agile manifesto has 12 main principles:
Customer satisfaction
Adapt to changing requirements
Deliver frequently
Work together frequently
Build projects with motivated individuals (It is important to provide an engaging atmosphere and
all the tools necessary to create good software. Companies lose their best workers mostly because they dont truly care
about them
6.
7.
8.
9.
10.
11.
12.
.)
Use Face to Face communication
Measure progress with working software
Maintain a constant pace (Agiles one of the advantages is the ability to precisely determine the amount of
time a project or feature will consume)
Pay attention to industrial progress
Simplicity is essential
Self organize
Reflect and adjust
37
Five main principles
The 12 main principles can be condensed to the
following five:
1.
2.
3.
4.
5.
Deliver Early and Often to Satisfy Customer
Welcome Changing Requirements
Face to Face Communication is Best
Measure Progress against Working Software
Simplicity is Essential
The art of maximizing the amount of work not done
38
Progress measure
Primary measure of progress is in terms of working
software, not lines of code.
Agile projects measure progress by the amount of
software that is currently meeting customer needs
They are 30% done when 30% of required
functionality is working AND deployed
Progress is not measured in terms of phases or
creating documents
Keeps on top of customer satisfaction and allows for
more realistic and updated estimation of costs
39
Keep it Simple
This refers to the art of maximizing the amount of work
NOT done
Agile projects always take the simplest path consistent
with their current goals
They do not try to anticipate tomorrows problems; they
only solve todays problems
High-quality work today should provide a simple and
flexible system that will be easy to change tomorrow if the
need arises
Only do the job the client wants, without any additional
functionalities and improvements, your work load will
lighten, and youll achieve your goals
Ultimately, that is all the customer cares about
40
Thats a bit Abstract!
The agile ethos is a bit abstract from the process of
actually applying the principles in a sound methodology
Different people interpret the manifesto in different
ways
The popular agile methods
Scrum, Extreme Programming (XP), Kanban, Crystal
Clear, and DSDM (Dynamic Systems Development
Methods)
The other methods available are Agile Unified Process
(AUP), Agile Modeling, Adaptive Software Development,
FDD (Feature Driven Development), and Lean Software
Development.
41
Scrum
A typical, but detailed, Agile methodology
One of the best Agile software development method
See http://www.youtube.com/watch?v=Q5k7a9YEoUI for
a very good 10 min. introduction
Manage a prioritized list of needs on a product backlog,
collaborate through daily standup meetings, exhibit the
product upon iteration completion, use retrospectives to
correct the process
42
Scrum
Rugby union:
A scrum is a way to
restart the game after an
interruption, where the
forwards of each side
come together in a tight
formation and struggle to
gain possession of the
ball when it is tossed in
among them
Image source: wikipedia.org
43
Product backlog
Product backlog contains all
user stories (requirements) of
features that the product
needs/could have
Product backlog is meant to
grow over time
44
Scrum Team
No. 1: Product owner
No. 2: The Scrum Team
No. 3: The Scrum Master
There are no roles in the team. Everyone should be able to
work on everything
45
Scrum Master
Scrum master is responsible for the Scrum process
Scrum Master is like a project manager
Three main roles:
1. Coach
2. Fixer
3. Gatekeeper
Two main tasks:
1. Protecting team from outside disturbances
2. Removing obstacles
46
Release planning
Team and customer pick features from product backlog
This creates a release backlog
Release backlog features are assigned priority
Release backlog features are assigned effort estimates
Release is split in a number of sprints
47
Scrum sprint
Sprints last approximately 3 30 days
Each release consists of 4-12 sprints
Duration of sprint is proportional to release interval
Sprint backlog lists features included per sprint
48
Monitoring progress
Per the Agile manifesto, progress is measured in terms
of functionality added
Time to complete features in active sprints drawn in a
burndown chart
Burndown chart is updated daily
Burndown velocity can be measured from chart
Team estimates daily how much time is required per
remaining feature
49
How to calculate Velocity
Scenario:
Our team delivers 3 user stories. The sum of the story
points equals 20. Our velocity is then 20.
If, in the next iteration, our team delivers 30 story
points, then our average velocity is 25, or
(20 SP + 30 SP) divided by 2 iterations = 25 SP.
Some concepts
Imagine you want to go to a trip. You know your trip will
be 1000 miles long. This is the size. Another variable
is the time. You want to pass this 1000 miles in 5 days.
This is a duration.
It is possible to calculate planned velocity as 1000 miles
per 5 day.
Velocity therefore defines how much of progress are
you able to do.
When we are talking about story points, we are talking
about the size.
Burndown chart
The burndown is a chart that shows how quickly you and your
team are burning through your customer's user stories.
It shows the total effort against the amount of work we deliver each
iteration
Image&Text source: http://www.agilenutshell.com/burndown
Burndown chart contd.
Image&Text source: http://www.agilenutshell.com/burndown
Burndown chart contd.
Image source: wikipedia.org
54
Burndown chart contd.
Projected line: is a straight line that connects the start point to the end point
At day 0 (the first day of the iteration), the remaining effort is at its highest because nothing has
been completed
At the end of the iteration (day 20), the sum should be 0 because there are no tasks left to
be completed
Image&Texts source: wikipedia.org
55
Burndown chart contd.
Actual Work Remaining Line: shows the actual work remaining
At the start point, the actual work remaining is the same as the ideal work remaining but as time
progresses, the actual work line fluctuates above and below the ideal line depending on how
effective the team is
Image&Texts source: wikipedia.org
56
Burndown chart contd.
If the actual remaining effort line is above the blue line for an extended period, then it means
adjustments have to be made to the project. This could mean dropping a task, assigning
additional resources, or working late, all of which can be unpleasant
What should be the correct Y-axis parameter to determine remaining effort
http://www.methodsandtools.com/archive/scrumburndown.php
Image&Texts source:inpointform.net
57
Bugs
Bugs traditionally wreak havoc to project planning
In scrum a defect backlog is maintained per sprint
Often dedicated bug kill sprints are introduced
58
The Scrum
Daily meeting
Meeting should be held standing
Keep people on their toes
Keep meetings short and to the point
Discusses what was done yesterday
Discusses what will be done today
Excellent tool to spot issues as they arise
59
The Scrum Questionnaire
(retrospectives )
Each Sprint ends with a retrospective. At this meeting, the
team reflects on its own process. They inspect their
behavior and take action to adapt it for future Sprints.
Every team member has to answer three question:
1. What have I done since last meeting?
2. What will I do until the next meeting?
3. What problems have I encountered?
During scrum meeting only team speaks.
60
Scrum Time!
Product: A web site that lets users search, compare, and
review apps for both Apple and Android platforms
Get together in teams of 5
Assign roles
Create a time planning:
Product backlog
1st release
Sprints of 1st release
Initialise burndown chart
Hold day-1 Scrum meeting
Present your time planning
61
Scrum for larger projects
We agree that Scrum is ideal for small sized project
What about when we need a very large team working on
a single project, or on closely related projects in a large
programme?
Possibly using Scrum of Scrums technique
Each team meets every day and holds their daily
Scrum as usual. One or two representatives from each
Scrum team attend a higher level Scrum to coordinate
across teams. And on very large teams, one or two
representatives from the higher level Scrum attends an
even higher level Scrum, and so on
62
Scrum Software Tools
Axosoft:
Scrum Software Tools
Scrumwise:
Scrum Software Tools
Targetprocess:
Extreme programming (XP)
Perhaps the best-known and most widely used agile method.
Extreme Programming (XP) takes an extreme approach to iterative
development.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;
All tests must be run for every build and the build is only
accepted if tests run successfully
Software should be tested frequently during development
Extreme programming advocates testing code literally every few
minutes, after every minor change
Extreme programming works best for relatively small projects with a
small number of good programmers
Text source: Ian Sommerville04 XP slides
66
XP values
Communication
Simplicity
From the system: Unit tests
From the customer: Acceptance tests
From the team: Estimate the time to implement new requirements
Courage
Extreme programming encourages starting with the simplest solution.
Extra functionality can then be added later
Feedback
Use simple designs and common metaphors, talk continuously with your
programmers and customers
Code for today, and not tomorrow
Refactor as appropriate
Be willing to throw code away
Respect
Trust your team members not to submit nonworking code
67
XP practices
The XP practices we will emphasize are:
Pair Programming
Teams of two people
Test Driven Development
Writing lots of tests, and writing them early
Continuous Integration
Putting code together as you write it, not at the last minute
Coding Standards
Learn and follow well-established conventions
Collective Code Ownership
You are responsible for your partners code
Simple Design
Stay away from confusion
Text source: Wikipedia.org
68
Pair programming
Pair programming is an agile software
development technique in which
two programmers
work together at one workstation.
One, the driver,
writes code while the other,
the observer or navigator,
reviews each line of code as it is typed in.
The two programmers switch roles frequently.
While reviewing, the observer also considers
the strategic direction of the work, coming up
with ideas for improvements and likely future
problems to address.
--Laurie Williams
North Carolina State University
Computer Science
Texts&Image source: wikipedia.org
69
Differences Between Scrum and XP
Scrum teams typically work in iterations (called sprints) that are
from two weeks to one month long. XP teams typically work in
iterations that are one or two weeks long.
Scrum teams do not allow changes into their sprints. Once the
sprint planning meeting is completed and a commitment made to
delivering a set of product backlog items, that set of items remains
unchanged through the end of the sprint. XP teams are much more
amenable to change within their iterations. As long as the team
hasnt started work on a particular feature, a new feature of
equivalent size can be swapped into the XP teams iteration in
exchange for the unstarted feature.
Text source: Mike Cohn , Mountain Goat Software
70
Summary
Agile software development is a software
development/project management approach
Agile projects incrementally create an evolving product
Agile uses small cross-functional teams with heavy
commitment of the customer
Scrum/XP Agile methodologies
