Agile Software Development Final

8/18/2019 Agile Software Development Final

1/71

G51FSE

Introduction to Software Engineering

Module Code : G51FSE

Agile Software DevelopmentPrepared by: Behrang Parhizkar (Hani)


2/71

Table of Contents

Traditional Approach Waterfall Model & Spiral Model

Advantages & disadvantages

7 reasons to move to Agile methodology

Agile Software Development Scrum


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


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


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


6/71

Where to Use Waterfall Model

Requirements are very well knownProduct definition is stable

Technology is understood

New version of existing product


7/71


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/71


9/71


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)


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


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


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


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.


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.


15/71


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


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.


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


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.


19/71


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.


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%


21/71

Standish Group: Project Success Factors

What were key factors for success ?


22/71

Standish Group: Project Challenged Factors

What were key factors for challenges?


23/71

Standish Group: Project Impaired Factors

What were key factors for impairment?


24/71

Failure Statistics

No significant improvements over time


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


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.


27/71


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.


28/71

In Agile, customers review actualworking software increments.

Customers’ feedback on the working

software are incorporated in the

requirement development.


29/71


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.


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.


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.


32/71


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.


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.


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


35/71

http://agilemanifesto.org/

35

http://agilemanifesto.org/

http://agilemanifesto.org/http://agilemanifesto.org/


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


53/71

Burndown chart contd.

Image&Text source: http://www.agilenutshell.com/burndown

B d h t td


54/71


Image source: wikipedia.org

54

B d h t td


55/71


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


56/71


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


57/71


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


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


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


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!


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


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


63/71


Axosoft:



64/71


Scrumwise:



65/71


Targetprocess:

Extreme programming (XP)


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


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


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


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


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


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

Documents

Agile Software Development Final