Agile Software Development:

Practices through Values

C Sc 335Rick Mercer

2

Goal and Outline

Main Goal:

– Suggest practices, values, and some process for

completing a final project on time that is better than

any one could do it in in four times the time.

Outline

– Distinguish Waterfall (plan driven) from Agile

– 11 Practices of quality software development

– Four values of Extreme Programming (XP)

3

Waterfall Model

Waterfall was described by 1970

Understood as– finish each phase

– don’t proceed

till done

W. W. Royce criticized this– proposed an

iterative approach

4

Became Popular

Management liked phases to easily set deadlines

Customers provide all requirements

Analysts translate requirements into specification

Coders implement the specification

Reviews ensure the specification is met

Testing is performed by others (QA)

Maintenance means modifying as little as possible

– old code is good code

Change is hard (and costly)

5

Sprial

Dr Barry Boehm proposed a spiral approach

6

Waterfall

It became popular– This process is still is used a lot

Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software – In his study, 87% of all projects failed

– The waterfall process was the "single largest contributing factor for failure, being cited in 81% of the projects as the number one problem."

[1] Agile and Iterative Development:

a Manager's Guide, Addison-Wesley Professional, 2003

7

Extreme Programming (XP)

As of 2009, about 14 years of growth

– About 25% of new project are Agile

Set of SE practices that produce high-quality

software with limited effort

Many books, first by Kent Beck:

Extreme Programming–Embrace Change,

Addison-Wesley, 2000,

ISBN 0-201-61641-6

http://www.extremeprogramming.org/

8

Extreme Programming

XP is

– a disciplined approach to software development

– code centric: no reckless coding, test-first

– successful because it emphasizes customer involvement and promotes team work

– not a solution looking for a problem

– One of several "agile" (can adapt to change) software development processes

http://www.agilealliance.org/

9

Essence of XP

Four variables in software development: – Cost, Time, Quality, Scope (# features)

Four Values– Communication, Simplicity, Feedback, Courage

Five Principles– Provide feedback, assume simplicity, make incremental

changes, embrace change, quality work

Practices (or fewer, or more, or subject to change)– Planning game, small releases, simple designs, automated testing,

continuous integration, refactoring, pair programming, collective ownership, Continuous Integration, on-site customer, coding standard

10

Cost of change

Costof

change

time

Waterfall

XP

11

Cost of the Project

Paraphrasing two companies from Agile

When we bid projects, we charge $X for doing it

Waterfall and $X/2 for doing it Agile

12

Goal and Outline

Main Goal:

– Suggest practices, values, and some process for completing

a final project on time that is better than any one could do it in

in four times the time.

Outline

– Distinguish Waterfall (plan driven) from Agile

– 11 Practices of quality software development to use on your

final project

– Four values of Extreme Programming (XP)

13

Practices: Planning Game

The planning game involves story cards, which

are short descriptions of a feature

– Provide value to customer

– Independent of each other

– Testable

Customer write stories cards and prioritize them

Developers estimate how long a story takes

14

Practices: The planning game

Business decisions (customer)

– Scope: which “stories” should be developed

– Priority of stories (features)

– Release dates

Technical decisions (developers)

– Time estimates for features/stories

– Elaborate consequences of business decisions

– Team organization and process

– Scheduling

15

Practices: Estimation

Based on similar stories from the past

Team effort

We get good at estimation simply by just doing it

Ideal Engineering Time (IET)– could be points

Velocity = IET/Calendar Time– we can do 20 points each week

– "Customer, which 20 points do you want next week?"

16

Practices: Small Releases

Releases should be as small as possible

Should make sense as a whole

Put system into production ASAP

– Fast feedback

Deliver valuable features first

Short cycle time

– Planning 1-2 months rather than 6-12 months

– Or in our case, 2.5 weeks rather than 5 weeks

17

Practices: Simple design

The “right” design

– Runs all tests

– No code duplication, No code duplication

– Fewest possible classes

– Short methods

– Fulfills all current business requirements

Design for today not the future

– But design so the system can change

18

Practices: Testing

Software should be tested, but it is often spotty

or overlooked

Automatic testing (JUnit, for example) help us

know that a feature works and it will work after

refactoring, additional code, and other changes

Provides confidence in the program

19

Testing

Write tests at the same time as production code

– Unit tests developer

– Feature/acceptance tests customer

Don't need a test for every method

Testing can be used to drive development and design of code

Allows for regression testing

– Do changes break previously working code

20

SIM/SQS http://www.simgroup.com/Consultancy/regression.html

Regression Testing

– re-testing of a previously tested program following

modification to ensure that faults have not been

introduced or uncovered as a result of changes.

– Regression tests are designed for repeatability, and are

often used when testing a second or later version of the

system under test.

– Regression testing can be carried out on all applications,

including e-Commerce and web-based systems .

21

Testing

Strong emphasis on regression testing

– Unit tests need to execute all the time

Unit tests pass 100%

Acceptance tests (we haven't seen these) show

progress on which user stories are working

Other testing frameworks include

– JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit

22

Can't unit test always

Won’t have unit tests for

– GUIS: There are testing frameworks to simulate and

test user interaction, but not this course

– Network, use visual inspection while running

– Randomness: Some strategies might have some

randomness, which can be hard to work with

23

Practices: Refactoring

Restructure code without changing the

functionality

Goal: Keep design simple

– Change bad design when you find it

– Remove dead code

Examples at Martin Fowler's Web site:

http://www.refactoring.com/ see online catalog

24

Practices: Pair programming

Write production code with 2 people on one machine– Person 1: Implements the method

– Person 2: Thinks strategically about potential improvements, test cases, issues

Pairs change all the time. Has advantages such as– No single expert on any part of the system

– Continuous code reviews, fewer defects

– Cheaper in the long run, and more fun

– Can you form a team of 4 and have everyone see all code?

Problems:– Not all people like it

– Pairs need to be able to work together

25

Practices: Collective ownership

All code can be changed by anybody on the team

Everybody is required to improve any portion of

bad code s/he sees

Everyone has responsibility for the system

Individual code ownership tends to create

experts

26

Practices: Continuous integration

Integration happens after a few hours of development

Checkout build with your changes, Make sure all tests pass (green bar)

In case of errors:

– Do not put changes into the build

– Fix problems

Checkin the system to the common repository

Repeat

We will use CVS to store your code

27

Continuous Integration

Find problems early

Can see if a change breaks the system more

quickly -- while you remember the details

Small increments

28

Practices: Coding standards

Coding Standard

– Naming conventions and style

– Least amount of work possible: Code should exist

once and only once

Team has to adopt a coding standard

– Makes it easier to understand other people’s code

– Avoids code changes because of syntactic

preferences

29

Practices: On-site customer

Many software projects fail because they do not deliver software that meets business needs

Real customer has to be part of the team

– Defines business needs

– Answers questions and resolves issues

– Prioritizes features

30

Outline

Main Goal:

– Suggest practices, values, and some process for completing

a final project on time that is better than any one could do it in

in four times the time.

Outline

– Distinguish Waterfall (plan driven) from Agile

– 11 Practices of quality software development to use

on your final project

– Four values of Extreme Programming (XP)

– Process considerations adapted from Scrum

31

Values: Communication

Communication

– Customer centric (write "Stories")

– Pair programming

– Task estimation

– Iteration planning

• What to do in the next time period

• May be weekly goals

– Design sessions

32

Values: Simplicity

Simplicity

– Choose the simplest thing that will work

– Choose the simplest design, technology,

algorithm, technique

33

Values: Feedback

Feedback very important

– Small Iterations

– Frequent deliveries

– Pair programming

– Constant code review

– Continuous integration (add often to the build)

– automated unit tests (JUnit, for example)

34

Values: Feedback

Compiler feedback: seconds

Pair programming feedback: half minutes

Unit test feedback: few minutes

Acceptance testing: half hours

– Customers write these, no can do in 335

Customer feedback: daily (or several times/week in our case)

Iteration feedback: weekly

FeedBack?

35

Agile ManifestoManifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

36

Outline

Main Goal:

– Suggest practices, values, and some process for completing

a final project on time that is better than any one could do it in

in four times the time.

Outline

– Distinguish Waterfall (plan driven) from Agile

– 11 Practices of quality software development to use

on your final project

– Four values of Extreme Programming (XP)

37

335 Final Project

SLs and Rick are the customers

– Projects still TBD

– Will choose teams/projects next Thursday 28-Oct

As customers, we reserve the right to change

requirements :-)