agile software development final
TRANSCRIPT
-
8/18/2019 Agile Software Development Final
1/71
G51FSE
Introduction to Software Engineering
Module Code : G51FSE
Agile Software DevelopmentPrepared by: Behrang Parhizkar (Hani)
-
8/18/2019 Agile Software Development Final
2/71
Table of Contents
Traditional Approach Waterfall Model & Spiral Model
Advantages & disadvantages
7 reasons to move to Agile methodology
Agile Software Development Scrum
-
8/18/2019 Agile Software Development Final
3/71
Lecture Goals Outline
Learn about Agile programming paradigm
Learn how Agile compares to Waterfall and Spiral
The popular agile methodsScrum, Extreme Programming (XP), Kanban Crystal
Clear, and DSDM (Dynamic Systems Development
Methods)
3
-
8/18/2019 Agile Software Development Final
4/71
Traditional approach
Deployment &
Maintenance
Requirements
Design
Implementation
TestingWaterfall
method
No way back
finish this step before moving to the next
Software develop in sequential order
-
8/18/2019 Agile Software Development Final
5/71
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 modelallowing 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 dynamicchanges in the requirements
Adjust scope during the life cycle
can kill a project
-
8/18/2019 Agile Software Development Final
6/71
Where to Use Waterfall Model
Requirements are very well knownProduct definition is stable
Technology is understood
New version of existing product
-
8/18/2019 Agile Software Development Final
7/71
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 changingcustomer requirements
-
8/18/2019 Agile Software Development Final
8/71
-
8/18/2019 Agile Software Development Final
9/71
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 softwaredevelopment process
They consume desired software only when over all
development processes have been completed (No earlyprototype)
No way of receiving continuous feedback (from
customer/stakeholder)
-
8/18/2019 Agile Software Development Final
10/71
As an example…
Let’s 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
-
8/18/2019 Agile Software Development Final
11/71
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 don’t 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 allrequirements in the beginning
Result: Over production of features
-
8/18/2019 Agile Software Development Final
12/71
What Standish Group Chaos Report Says
A survey has been conducted with customers about thefeatures (functions) used in traditional software
Features rarelyOr never used byEnd user
-
8/18/2019 Agile Software Development Final
13/71
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.
-
8/18/2019 Agile Software Development Final
14/71
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 continuouslyfor the business value.
-
8/18/2019 Agile Software Development Final
15/71
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
-
8/18/2019 Agile Software Development Final
16/71
So what are the main Challenges ?
Software teams are building something that does notexist 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 isdescribing 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.
-
8/18/2019 Agile Software Development Final
17/71
Requirements Uncertainty Principle
For a new softwaresystem, the
requirements will not be
completely known untilafter the users have
used it.
Watts HuphreyFather of Software quality
-
8/18/2019 Agile Software Development Final
18/71
Requ irements Changes are always welcome in Agi le
Ag i le understand that requirements changes are
inevi table and they are for the competi t ive advantageof the customer.
-
8/18/2019 Agile Software Development Final
19/71
7 Reasons to move to Agile
3. Big, Upfront Planning is not Practical
Recall: Because we assume we can collect all the requirements in thebeginning and freeze the requirements, so we also assume we can plan
everything upfront.
Assumption:
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
What we do:
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.
-
8/18/2019 Agile Software Development Final
20/71
How Good are the Project Planning Executing?
Failure Statistics from the Famous Standish Group’s
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:
The project is completed but over-budget, over the time
estimate, and offers fewer features and functions than
originally specified.
Project Impaired:
The project is canceled at some point during thedevelopment cycle.
Standish Group http://www.standishgroup.com
16.2%
52.7%
31.1%
-
8/18/2019 Agile Software Development Final
21/71
Standish Group: Project Success Factors
What were key factors for success ?
-
8/18/2019 Agile Software Development Final
22/71
Standish Group: Project Challenged Factors
What were key factors for challenges?
-
8/18/2019 Agile Software Development Final
23/71
Standish Group: Project Impaired Factors
What were key factors for impairment?
-
8/18/2019 Agile Software Development Final
24/71
Failure Statistics
No significant improvements over time
-
8/18/2019 Agile Software Development Final
25/71
What are the Success Factors?
http://www.drdobbs.com/architecture-and-design/defining-success/202800777
Item Percentage
Schedule 61.3 % It is more important to deliver a systemwhen 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/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777http://www.drdobbs.com/architecture-and-design/defining-success/202800777
-
8/18/2019 Agile Software Development Final
26/71
Big , Upfront planning is not possible in thesoftware development as the requirements
are not complete.
Agile focuses on Just in time planning
In Agile, planning also evolves alongwith the requirements.
-
8/18/2019 Agile Software Development Final
27/71
7 Reasons to move to Agile
4. Reviewing the working software is better than reviewing
the documents. Assumption:
Customers shall review the initial requirements and approve
them.
What we do:
Ask the customers to ‘sign off’ the requirements.
Reality:
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.
-
8/18/2019 Agile Software Development Final
28/71
In Agile, customers review actualworking software increments.
Customers’ feedback on the working
software are incorporated in the
requirement development.
-
8/18/2019 Agile Software Development Final
29/71
7 Reasons to move to Agile
5. Iterative and incremental development is better than
sequential waterfall developmentAssumption: (Iterative & Incremental Development)
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.
What we do:
Develop the software sequentially, with one big final delivery.
Reality:
When the customers actually get to see the final deliverables, itmay 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.
-
8/18/2019 Agile Software Development Final
30/71
Look at this case
Assuming a one year project starting on January:
Analysis
Design
Coding
Testing
Time
The cost of change increases
If customer cancel the
Project at this stage
Do we have half of
the solutions now ?
In the best case, the customer get a nice requirementAnalysis document and a nice design document withsome codes with several bugs.
-
8/18/2019 Agile Software Development Final
31/71
In Agile, software delivery is made to thecustomers frequently in short iterations.
Customers get small piece of prioritizedworking software once in 2 to 4 weeks.
-
8/18/2019 Agile Software Development Final
32/71
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.
-
8/18/2019 Agile Software Development Final
33/71
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 earlyas possible and as often as possible.
Agile is based on iterative model and not sequential
order.
-
8/18/2019 Agile Software Development Final
34/71
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 experiencedpeople 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
-
8/18/2019 Agile Software Development Final
35/71
http://agilemanifesto.org/
35
http://agilemanifesto.org/
http://agilemanifesto.org/http://agilemanifesto.org/
-
8/18/2019 Agile Software Development Final
36/71
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
-
8/18/2019 Agile Software Development Final
37/71
Principles of agile manifesto
The agile manifesto has 12 main principles:
1. Customer satisfaction2. Adapt to changing requirements
3. Deliver frequently
4. Work together frequently
5. Build projects with motivated individuals (It is important to provide an engaging atmosphere andall the tools necessary to create good software. Companies lose their best workers mostly because they don’t truly care
about them.)
6. Use Face to Face communication
7. Measure progress with working software
8. Maintain a constant pace ( Agile’s one of the advantages is the ability to precisely determine the amount of
time a project or feature will consume)
9. Pay attention to industrial progress
10. Simplicity is essential
11. Self organize
12. Reflect and adjust
37
-
8/18/2019 Agile Software Development Final
38/71
Five main principles
The 12 main principles can be condensed to the
following five:
1. Deliver Early and Often to Satisfy Customer
2. Welcome Changing Requirements3. Face to Face Communication is Best
4. Measure Progress against Working Software
5. Simplicity is Essential
The art of maximizing the amount of work not done
38
-
8/18/2019 Agile Software Development Final
39/71
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
-
8/18/2019 Agile Software Development Final
40/71
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 tomorrow’s problems; they
only solve today’s 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 additionalfunctionalities and improvements, your work load will
lighten, and you’ll achieve your goals
Ultimately, that is all the customer cares about
40
-
8/18/2019 Agile Software Development Final
41/71
That’s 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
-
8/18/2019 Agile Software Development Final
42/71
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 tocorrect the process
42
http://www.youtube.com/watch?v=Q5k7a9YEoUIhttp://www.youtube.com/watch?v=Q5k7a9YEoUIhttp://www.youtube.com/watch?v=Q5k7a9YEoUI
-
8/18/2019 Agile Software Development Final
43/71
Scrum
Rugby union:
A scrum is a way to
restart the game after an
interruption, where the
forwards of each sidecome together in a tight
formation and struggle to
gain possession of the
ball when it is tossed inamong them
Image source: wikipedia.org
43
-
8/18/2019 Agile Software Development Final
44/71
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
-
8/18/2019 Agile Software Development Final
45/71
Scrum Team
No. 1: Product owner
No. 2: The Scrum Team
No. 3: The Scrum Master
45
There are no roles in the team. Everyone should be able towork on everything
-
8/18/2019 Agile Software Development Final
46/71
Scrum Master
Scrum master is responsible for the Scrum process
Scrum Master is like a project manager
Three main roles:
1. Coach
2. Fixer3. Gatekeeper
Two main tasks:
1. Protecting team from outside disturbances
2. Removing obstacles
46
-
8/18/2019 Agile Software Development Final
47/71
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
-
8/18/2019 Agile Software Development Final
48/71
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
-
8/18/2019 Agile Software Development Final
49/71
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
-
8/18/2019 Agile Software Development Final
50/71
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 storypoints, then our average velocity is 25, or
(20 SP + 30 SP) divided by 2 iterations = 25 SP.
-
8/18/2019 Agile Software Development Final
51/71
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.
B d h
-
8/18/2019 Agile Software Development Final
52/71
Burndown chart
The burndown is a chart that shows how quickly you and yourteam are burning through your customer's user stories.It shows the total effort against the amount of work we deliver eachiteration
Image&Text source: http://www.agilenutshell.com/burndown
B d h t td
-
8/18/2019 Agile Software Development Final
53/71
Burndown chart contd.
Image&Text source: http://www.agilenutshell.com/burndown
B d h t td
-
8/18/2019 Agile Software Development Final
54/71
Burndown chart contd.
Image source: wikipedia.org
54
B d h t td
-
8/18/2019 Agile Software Development Final
55/71
Burndown chart contd.
Image&Texts source: wikipedia.org 55
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 hasbeen completed
At the end of the iteration (day 20), the sum should be 0 because there are no tasks left to
be completed
B d h t td
-
8/18/2019 Agile Software Development Final
56/71
Burndown chart contd.
Image&Texts source: wikipedia.org 56
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
B d h t td
-
8/18/2019 Agile Software Development Final
57/71
Burndown chart contd.
Image&Texts source:inpointform.net 57
If the actual remaining effort line is above the blue line for an extended period, then it meansadjustments 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
B
http://www.methodsandtools.com/archive/scrumburndown.phphttp://www.methodsandtools.com/archive/scrumburndown.php
-
8/18/2019 Agile Software Development Final
58/71
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
Th S
-
8/18/2019 Agile Software Development Final
59/71
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
-
8/18/2019 Agile Software Development Final
60/71
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
Scr m Time!
-
8/18/2019 Agile Software Development Final
61/71
Scrum Time!
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
Product: A web site that lets users search, compare, andreview apps for both Apple and Android platforms
Scrum for larger projects
-
8/18/2019 Agile Software Development Final
62/71
Scrum for larger projects
We agree that Scrum is ideal for small sized project
What about when we need a very large team working ona 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 dailyScrum 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 aneven higher level Scrum, and so on
62
Scrum Software Tools
-
8/18/2019 Agile Software Development Final
63/71
Scrum Software Tools
Axosoft:
Scrum Software Tools
-
8/18/2019 Agile Software Development Final
64/71
Scrum Software Tools
Scrumwise:
Scrum Software Tools
-
8/18/2019 Agile Software Development Final
65/71
Scrum Software Tools
Targetprocess:
Extreme programming (XP)
-
8/18/2019 Agile Software Development Final
66/71
Extreme programming (XP)
Perhaps the best-known and most widely used agile method.
Extreme Programming (XP) takes an ‘extreme’ approach to iterativedevelopment.
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 onlyaccepted 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 Sommerville’04 XP slides
66
XP values
-
8/18/2019 Agile Software Development Final
67/71
XP values
Communication
Use simple designs and common metaphors, talk continuously with yourprogrammers and customers
Simplicity
Extreme programming encourages starting with the simplest solution.Extra functionality can then be added later
Feedback
From the system: Unit tests
From the customer: Acceptance tests
From the team: Estimate the time to implement new requirements
Courage
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
-
8/18/2019 Agile Software Development Final
68/71
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 partner’s code
Simple Design
Stay away from confusion
Text source: Wikipedia.org 68
Pair programming
-
8/18/2019 Agile Software Development Final
69/71
Pair programming
Texts&Image source: wikipedia.org
69
Pair programming is an agile software
development technique in whichtwo 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 futureproblems to address.
--Laurie Williams
North Carolina State University
Computer Science
Differences Between Scrum and XP
-
8/18/2019 Agile Software Development Final
70/71
Scrum teams typically work in iterations (called sprints) that are
from two weeks to one month long. XP teams typically work initerations 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 remainsunchanged through the end of the sprint. XP teams are much more
amenable to change within their iterations. As long as the team
hasn’t started work on a particular feature, a new feature of
equivalent size can be swapped into the XP team’s iteration in
exchange for the unstarted feature.
Text source: Mike Cohn , Mountain Goat Software
70
Summary
-
8/18/2019 Agile Software Development Final
71/71
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