Recognizing Software Debt - Beyond Agile Puget Sound

Recognizing
So+ware
Debt

Wednesday, November 30, 2011

Chris
Sterling
Co-‐founder
of
Agile
Advantage
and
VP
of

Engineering
(www.AgileAdvantage.com)

Author
of
Book
“Managing
SoAware

Debt:
Building
for
Inevitable
Change”
Consults
on
soAware
technology,
Agile

technical
pracKces,
Scrum,
and
eﬀecKve

management
techniques
CerKﬁed
Scrum
Trainer
Email:
chris@agileadvantage.com

InnovaKon
Games®
Trained
Facilitator Web:
h3p://www.agileadvantage.com
Follow
me
on
Twi0er:
@csterwa
Open
Source
Developer Blog:
h3p://www.ge8ngagile.com
Hashtag
for
presenta:on:
#swdebt

2

Go
to
ImpedimentMonkey.com!!!

Send
an
email
to
Louie@impedimentmonkey.com
to

get
invited
with
your
ﬁrst
impediment
now!!! 3

Agenda
Managing
SoAware
Debt • ConKnuous
IntegraKon
• An
Overview • Quality
Dashboards
Types
of
SoAware
Debt Release
Management
• Technical • The
Power
of
2
Scripts:

• Quality Deploy
and
Rollback
• ConfiguraKon
Management • ConKnuous
IntegraKon
• Design • Automated
PromoKon
• PlaUorm
Experience • Turn
On/Off
Features

Balancing
Signal
to
Noise Exercise
• DefiniKon
of
Done • SoAware
Debt
Management

Strategy
• Source
Control
Management

4

Managing
So+ware
Debt
An
Overview


THE
DISECONOMIES
OF
SCALE
IN

SOFTWARE
DEVELOPMENT*
Project
size
is
easily
the
most
signiﬁcant

determinant
of
eﬀort,
cost
and
schedule
[for
a

soIware
project].

*
“SoIware
Es:ma:on:
Demys:fying
the
Black
Art
“
–
Steve
McConnell


Big
Ball
of
Mud
“A
Big
Ball
of
Mud
is
a
haphazardly
structured,
sprawling,
sloppy,

duct-‐tape-‐and-‐baling-‐wire,
spagheZ-‐code
jungle.
These
systems

show
unmistakable
signs
of
unregulated
growth,
and
repeated,

expedient
repair.
Informa:on
is
shared
promiscuously
among

distant
elements
of
the
system,
oIen
to
the
point
where
nearly
all

the
important
informa:on
becomes
global
or
duplicated.
The

overall
structure
of
the
system
may
never
have
been
well
deﬁned.
If

it
was,
it
may
have
eroded
beyond
recogni:on.
Programmers
with
a

shred
of
architectural
sensibility
shun
these
quagmires.
Only
those

who
are
unconcerned
about
architecture,
and,
perhaps,
are

comfortable
with
the
iner:a
of
the
day-‐to-‐day
chore
of
patching
the

holes
in
these
failing
dikes,
are
content
to
work
on
such
systems.”
*
*
Brian
Foote
and
Joseph
Yoder,
Big
Ball
of
Mud.

Fourth
Conference
on
Pa0erns
Languages
of
Programs
(PLoP
'97/EuroPLoP
'97)

Mon:cello,
Illinois,
September
1997


Lack
of
emphasis
on
so'ware
quality
a2ributes

contributes
to
decay


Types
of
So+ware
Debt


Why
not
just
call
it
all
“ Technical
Debt”
Technical
debt
tended
to
focus
more
on

programming
aspects
of
soIware
delivery
and

leI
out
full
soIware
development
life
cycle
Each
type
of
soIware
debt
can
be
managed
and

monitored
using
diﬀerent
tools
and
approaches
Focusing
on
managing
each
type
of
soIware

debt
simpliﬁes
crea:on
of
an
overall
strategy
that

promotes
holis:c
perspec:ve

11

Types
of
SoIware
Debt
Technical
Debt:
These
are
the
ac:vi:es
that
a
team
or
team

members
do
not
to
do
well
now
that
will
impede
future

development
if
leI
as
is.
Quality
Debt:
There
is
a
diminishing
ability
to
verify
the
func:onal

and
technical
quality
of
soIware:
the
“Break/Fix”
mentality.
ConﬁguraHon
Management
Debt:
Integra:on
and
release

management
become
more
risky,
complex,
and
error-‐prone.
Design
Debt:
The
cost
of
adding
features
is
increasing
toward
the

point
where
it
is
more
than
the
cost
of
wri:ng
from
scratch.
PlaJorm
Experience
Debt:
The
availability
and
alignment
of
people

to
business
objec:ves
that
involve
soIware
changes
is
becoming

more
limited
or
cost-‐prohibi:ve.

8


Principle:
No
maOer
what,
the
cost
of

addressing
so+ware
debt
increases

with
Hme.


Balancing
Signal
to
Noise
at
Scale


Balancing
Signal
Indicators

Value

Quality Constraints
Source:
Jim
Highsmith (Schedule,
Cost,
Scope)

15

DefiniMon
of
Done
-‐
Assert
Quality
Acceptance defined criteria for each Code checked in with reference to
user story US#/Task#
Unit tests written and passed Tested on FE
Code compiles with no errors and no Integration test written & passes
warnings
Test code reviewed
New code doesn’t break existing code
Environment requirements documented
Test case review (Dev to review test
Interface document updated/added
case written)
and checked in to SVN
Architectural impact assessed and
Acceptance criteria verified complete
artifacts updated if necessary
All P1-P3 bugs for the story are
Comments in code
closed
Error codes added
Test approves user story
Code reviewed by peer
Story demonstrated to product owner
and accepted on Target Platform

16

Release
DefiniMon
of
Done
Every
release
should
have
clear
quality
criteria
With
a
“Release
Defini:on
of
Done”
you
can

understand
targets
be0er
Measure
the
gap
between
the
teams’
Defini:on

of
Done
and
a
Release
Defini:on
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents

significant
risk
to
schedule


TradiMonal
Source
Control
Management

18

TradiMonal
Source
Control
Management

Main
Branch

18

TradiMonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Main
Branch

18

TradiMonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Debt Main
Branch

Death
March

18

TradiMonal
Source
Control
Management

Code
Complete
Version
1 Integrate
for
Branch Version
2

Debt Main
Branch

Death
March

{
Debt
accrues
quickly
within
stabilizaHon
periods

18

Flexible
Source
Control
Management

19

Flexible
Source
Control
Management

Main Branch

19

Flexible
Source
Control
Management

Version 1

Main Branch

19

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

19

Flexible
Source
Control
Management

Version 1 Version 2

Main Branch

{
Not Easy! Must have proper infrastructure to do this.

19

ConMnuous
IntegraMon

20

Quality
Dashboard
-‐
Sonar

21

Quality
Dashboard
-‐
Sonar

22

Quality
Dashboard
-‐
Sonar

23

Quality
Dashboard
-‐
Sonar

24

Early
Warning
Signs

Early
Warnings:
•Broken
Builds
•Broken
Automated
Tests
•Broken
Custom
Thresholds

25

Early
Warning
on
Quality
Dashboard

Early
Warnings:
•Design
Debt
in
Duplica:on
(DRY)
•Technical
Debt
in
Code
Complexity
•Quality
Debt
in
Bug
DB
(Break/Fix)
•Other
Custom
Thresholds

26

Release
Management
Strategy


“If
releases
are
like
giving
birth,
then

you
must
be
doing
something
wrong.”

-‐
Robert
Beneﬁeld


Case
Study:
Enterprise
Agile
AdopMon
180+
person
“Web
2.0”
product
organiza:on
Waterfall
SDLC
that
development
uses
to
deliver
in
6
month
release

cycles
Want
to
use
Agile
methods
to
be
more
responsive
to
users
and
keep
up

with
other
“Web
2.0”
companies
Transi:oned
to
Agile
methods
on
15
teams
in
3
months
Changed
release
management
strategy,
added
XP
technical
prac:ces,

and
implemented
Scrum
product
development
framework
for
scaled

coordina:on
Able
to
release
every
week
to
users
within
4
months
Used
streamlined
deployment
environment
process
to
validate
product

changes
daily
using
Con:nuous
Integra:on
and
automated
promo:ons

29

The
Power
of
2
Scripts:
Deploy
&
Rollback

30

Scaling
ConMnuous
IntegraMon

End-‐to-‐End
&
Load/Stress

Integrated

Component
ValidaHon

Component
ValidaHon

31

Automated
PromoMon
to
Environments

32

The
value
of
technical
aspects
in
an

applica:on
or
its
surrounding
infrastructure

is
the
cost
of
not
addressing
them.

29

Describe
as
Abuse
User
Stories

Implement Security
for User Information

*
From
“User
Stories
Applied”
presented
by
Mike
Cohn
Agile
2006

30


Describe
as
Abuse
User
Stories

Implement Security As a Malicious Hacker I
want to steal credit card
for User Information
information so that I can
make fraudulent charges

*
From
“User
Stories
Applied”
presented
by
Mike
Cohn
Agile
2006

30


Some
PotenMal
Abusers
• Malicious
Hacker
• Mass
of
users
• SQL
injector
• Disgruntled
employee
• Naïve
API
user
• ImpaBent
clicker
• Denial-‐of-‐service
(DoS)
aFacker
• Sleazy
user

31


SoIware
Quality
A0ributes
Deﬁned

32


SoIware
Quality
A0ributes
Ra:ng
Tool

33


Put
SoIware
Debt
on
Product
Roadmap

*
Image
from
Dean
Leﬃngwell’s
blog
-‐
h0p://scalingsoIwareagility.wordpress.com/

34 38

Exercise:
So+ware
Debt
Management

Strategy


Thank
you!
QuesHons
&
Answers


Come
see
us
at
AgileAdvantage.com

41

Recognizing Software Debt - Beyond Agile Puget Sound

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Recognizing Software Debt - Beyond Agile Puget Sound

Similaire à Recognizing Software Debt - Beyond Agile Puget Sound (20)

Plus de Chris Sterling

Plus de Chris Sterling (16)

Dernier

Dernier (20)

Recognizing Software Debt - Beyond Agile Puget Sound