Alternative approaches Agile processes

(1)

R e v is io n e r 1 S e p te m b e r 2 0 0 0 D a te P A 1 0 0 1 Q T e m p la te 6 .0 N N A p p ro v e d

Alternative approaches

Agile processes

Sesam

Stockholm, 021023

Even-André Karlsson

(2)

Denmark – France – Germany – Ireland – Norway – Sweden – UK – USA

Agenda

n

Q-Labs and personal background

n

What is special about software?

n

State of the practice

n

People, Process, Tools, Technology

(3)

0 0 0 A ll ri g h ts r e se rv e d

n

Q-Labs Manages Software

Risks with World Class

Customers

n

Global Reach

Offices in:

n

France

n

Denmark

n

Germany

n

Ireland

n

Norway

n

Sweden

n

UK

n

USA

n

155 Employees

n

Highly Qualified Staff - many

with long term industrial

n

A Broad International Client Base,

e.g.

n

Alcatel, Axis, Ericsson, France

Telecom, Telia, Telenor

n

ABB, R. Bosch , EDF, IBM, Siemens,

Schneider Electric, Thomson

Detexis, Volvo

n

Atomic Energy Board of Canada,

FAA, Norwegian Ministry of Justice,

Swedish Civil Aviation

Administration

n

FMV, US Army TACOM

n

Provides state-of-the-art and

industrial-best-practice solutions

with quantifiable results

n

Owned by Ratos, Ericsson and Det

Norske Veritas (DNV)

(4)

Professional background

n

Ph.D. in computer science, Norway, 1990

n

Researcher, US & Esprit, 1990-1992

n

Principal consultant Q-Labs

n

Ericsson, ABB, Bosch, Alcatel,Lucent, Philips

n

Esprit project REBOOT

n

Many aspects of software engineering

n

Development tools

n

Team work

n

Architectures

n

Incremental development

(5)

What is special about software?

n

”Lack” of ”production” - ”only” design

n

Rate of change, Internet year, Murphy’s law

n

Complexity is increasing

n

Extent of software in products

Telecom

Automation

Automotive

Home

appliances

% of value

in software

100 %

(6)

State of the practice: Immature

n

Financial risks

n

Cost overruns

n

Not meeting requirements

n

Cancellations

n

Delays

n

Failures

(7)

What to address?

Technology

People

Process

Tools

(8)

Tools

n

Now in fashion again (last time in 80’s)

n

Two main consolidated suppliers:

n

Rational: RequisitePro, Rose, ClearCase

n

Telelogic: Doors, Tau, Continuus

n

Runner ups: Microsoft, Oracle

n

Problems/issues

n

Do they scale up

n

Maintenance and enhancement

n

Integration between phases and tools

(9)

Process

n

Three approaches:

n

Reference models: CMM, ISO, TickIt, Spice

n

Process solutions: Rational Unified Process

n

Minimal processes: eXtreme Programming

n

Problems/issues

n

Large efforts involved in process tailoring

n

Fitting process to problem

n

Generally moving to incremental development

(10)

People

n

Boehm identified this as the main impact

n

”Recent” advances

n

People Capability Maturity Model

n

Personal Software Process

n

Team Software Process

n

DeMarco and Lister: PeopleWare

(11)

Agile processes

n

People focus: Developer

n

Process focus: Support programming

n

Tools: Code is king

Modeling doesn’t make me

nervous!

(12)

Should it really look like this?

Why not like this?

Model/Document

Requirements

ReqPro/Doors

Code

Business

model, UML

Use case

model

Analysis

Model

Design

model

.

Code, test,

Code, test

The role of models

(13)

XP

n

Motivation

n

Process

n

12 Principles

(14)

Takes good things to extreme

n

If reviewing is good we will

review all the time => Pair

programming

n

If testing is good, everybody

will test all the time =>

automatic testing, writing tests

as specfications, parallel

customer test

n

If architecture and design is

good, we’ll make it part of

everybody’s daily business

(metaphor and refactoring)

n

If simplicity is good, we’ll

always make the simplest

thing that can run all test

cases

n

If integration testing is good,

we will do it several times a

day

n

If short iterations are good, we

will do them very short

-minutes and hours not weeks

and months

(15)

The cost of change

n

A simple design with no extras

n

Automated test will reduce lengthy studies - try and see

n

Lots of practice in modification (refactoring)

n

Only one level of documentation - the code

(16)

Back to basics

n

Coding - otherwise there is nothing

n

Testing - tells you when you have finished

coding

n

Listening - to know what to code and test

n

Designing - to keep coding, testing and

listening for ever

(17)

XP process

n

Planning

n

User stories

n

Planning game

n

Iterative development

n

Design

n

Coding

n

Testing

(18)

n

Customer writes what system must do for

them

n

Not detailed, 3 sentences

n

Basis for

n

Effort and risk estimates

n

Function test cases

n

Every user story shall take 1-3 weeks to

implement

(19)

Planning: Planning game

n

Business and technical people participate

n

Estimate each user story in terms of effort, risk

and priority

n

Make a card of each user story

(20)

Planning: Iterative development

n

Start every iteration with a meeting, and

plan what shall be done

n

Break user stories into design activities

n

Forbidden to implement something that is

(21)

Design

n

Simplicity is rule number 1

n

Always the simplest possible solution

n

If something can be simplified - change it.

n

Design is done together - CRC cards

n

Make spike for difficult technical problems

n

Never add functionality you believe will be

needed

(22)

Coding - 1

n

Customer always there

n

Participate in team

n

Detail user stories when needed

n

Function test and approval of system

n

A lot of time, but efficient in long run

n

Write test case before code

n

Forces developers to detail requirements

n

Forces writing of testable code

(23)

Coding - 2

n

Sequential releases: Focus on one iteration

n

Integrate often, several times a day

n

Collective ownership of code: all can

change code

n

Optimise at the end: First Work, so Right then

Fast

(24)

Testing

n

Unit test

n

Automatic test suites

n

Ensures that ”everything” is tested

n

Function test

n

Based on user stories

(25)

12 principles

n

The planning game

n

Small releases

n

Metaphor

n

Simple design

n

Testing

n

Refactoring

n

Pair programming

n

Collective ownership

n

Continuous integration

n

40 hour week

n

On site customer

n

Coding standards

(26)

Why should we work this way?

n

Easy to see progress - good project control, fast

feedback and high motivation.

n

Always a stable system (good quality assurance).

n

Easier to find faults and less re-work.

n

New faults are introduced during the last 24 hours.

n

Designers and testers work together - direct feedback.

n

Less documentation - avoids several levels of hand

over, interpretation and re-writing.

n

System competence - increased flexibility and

commitment.

(27)

Agile processes and modeling

n

Compatible if

one

model replaces code

n

SDL/SDT

n

RoseRT

n

UML 2.0 - Realtime

n

Modeling is OK on the whiteboard

n

Complete models apart from code are not

agile

n

Requirements models (req database, elaborate

use cases)