Inherent
complexity
and
uncertainty
• Machines
are
complex
• Machines
are
faster
and
can
process
more
data
than
human
brain
(consciously)
• Although
Machines
are
predictable
(based
on
math
and
logic),
the
level
of
parallelism,
speed
and
volume
of
data
and
instrucHons
processed
per
second
makes
dealing
with
machines
a
complex
and
uncertain
task
• Modern
mathemaHcal/logical
formulas
=
so,ware
programs
needs
TesHng
to
make
sure
we
have
instructed
the
machine
properly.
Can
not
be
predicted
upfront
• Uncertain
and
Changing
Requirements,
FuncHonal,
non
FuncHonal
created
by
Machines
and
the
Problem
to
solve
Accidental
complexity
and
uncertainty
created
by
Humans
So,ware
Development
depends
on
humans
creaHvity,
knowledge,
passion,
talent
desires
…
but
also
in
their
collaboraHons
and
interacHons
So,ware
is
“so,”
or
flexible,
it
is
possible
to
express
almost
any
kind
of
abstracHon
That
is
based
on
human
creaHvity,
talent
and
knowledge
that
is
acquired
along
the
synthesis
process
knowledge
Time
Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Learning
by
doing
Deliberate
pracHce
Till
the
Desired
Working
So#ware
Emerges
Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Inten%on' Realiza%on' Feedback' Synthesis' Compile
Failed
Run
Failed
Test
Failed
Test
Passed
Enhance
Idea/Design
Test
Failed
Inten%on' Realiza%on' Feedback' Synthesis' Test
Passed
Emergence
is
the
key
characterisHc
of
complex
systems.
WORKING
SOFTWARE
IntenHonal
Emergent
Requires
MulHple
Disciplines
in
a
Team
CollaboraHng
together
Domain
Experts
Ux
Designers
Business
Analysts
Product
Managers
So#ware
Developers
Testers
System
Engineers
Deployment
Engineers
So,ware
Architects
Human
Factors
Users
Project
Managers
Agile
So,ware
Development
is
just
a
set
of
Principles,
Values,
and
PracHces
for
dealing
with
so,ware
complexity
and
uncertainty
The
purpose
:
Effec3ve
So6ware
Development
Our
highest
priority
is
to
saLsfy
the
customer
through
early
and
conLnuous
delivery
of
valuable
so#ware.
Welcome
changing
requirements,
even
late
in
development.
Agile
processes
harness
change
for
the
customer’s
compeHHve
advantage.
Deliver
working
so#ware
frequently,
from
a
couple
of
weeks
to
a
couple
of
months,
with
a
preference
to
the
shorter
Hmescale.
Business
people
and
developers
must
work
together
daily
throughout
the
project.
Build
projects
around
moLvated
individuals.
Give
them
the
environment
and
support
they
need,
and
trust
them
to
get
the
job
done.
The
most
efficient
and
effecHve
method
of
conveying
informaHon
to
and
within
a
development
team
is
face-‐to-‐face
conversaLon.
1 2 3 4 5 6 7 8 9 10 11 12 Working
so#ware
is
the
primary
measure
of
progress.
Agile
processes
promote
sustainable
development.
The
sponsors,
developers,
and
users
should
be
able
to
maintain
a
constant
pace
indefinitely.
ConHnuous
amenHon
to
technical
excellence
and
good
design
enhances
agility.
Simplicity—the
art
of
maximizing
the
amount
of
work
not
done—is
essenHal.
The
best
architectures,
requirements,
and
designs
emerge
from
self-‐organizing
teams.
At
regular
intervals,
the
team
reflects
on
how
to
become
more
effecHve,
then
tunes
and
adjusts
its
behaviour
accordingly.
12
Agile
Principles
Copyright 2007 Dean Leffingwell What
Paradigms
Is
Agile
Breaking?
Culture
Measure
of
Success
Waterfall
Development
IteraLve
Development
IteraLve
and
Incremental
Development
Parallel
Development
Acceptance
Test
Driven
Development
Command-‐and-‐Control
Leadership
/CollaboraLve
Conformance
to
Plan
Response
to
Change
Design
QA
Process
Big
Design
Up
Front
ConLnuous/Emergent
Big
Test
on
Backend
ConLnuous
Agile
Development
Tool
Support
Highly
specific
Fully
Integrated
IteraHve
vs
Waterfall
Development
So,-‐NOT-‐aware
So,ware
Waterfall
Requirements
Analysis&Design
ImplementaHon
TesHng
Deployment
SpecificsHons
Architecture
So,ware
So,ware
Paperware
Itera3on1
Itera3on2
Itera3on3
Release1
Working
So,ware
Release2
Release3
Focus In Executable Software You
can't
know
everything
at
the
beginning
You
learn
as
you
work
Why
IteraHve
• It
accommodates
changing
requirements
• IntegraHon
is
not
one
"big
bang"
at
the
end
of
a
project
• Risks
are
usually
discovered
or
addressed
during
early
integraHons
• Reuse
is
facilitated
• Management
has
a
means
of
making
tacHcal
changes
to
the
product
• Defects
can
be
found
and
corrected
over
several
iteraHons,
• It
is
a
bemer
use
of
project
personnel.
• Team
members
learn
along
the
way.
• The
development
process
itself
is
improved
and
refined
along
the
way
IteraHon
a
la
mini-‐waterfall
Requirements
Analysis&Design
ImplementaHon
TesHng
Deployment
PLANNING
REVIEW
ITERATION
N
Product
Backlog
Working
So,ware
Requirements
Analysis&Design
ImplementaHon
TesHng
Deployment
IteraHon
a
la
agile
PLANNING
REVIEW
ITERATION
N
Product
Backlog
Working
So,ware
Concurrent
&
Blended
around
people
collaboraHon
2-‐4
weeks
User
Story1
UserStory2
UserStory3
Feature1
Feature2
…
define
build
test
define
build
test
define
build
test
ITERATION
DBT
user
story
1
DBT
component
2
DBT
Feature1
Backlog
n
UserStory2
UserStory3
NewUserStory4
Feature2
NewFeature3
…
Backlog
n+1
PLANNING
REVIEW
Working
So,ware
D/B/T
:
• User
story
• Feature
• Technical/Architecture
• Bug
“iteraHng”
builds
a
rough
version,
validates
it,
then
slowly
builds
up
quality
1 2 3 IteraHng
allows
you
to
move
from
vague
idea
to
realizaHon
From
Jeff
Pamon
:
hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Value
Driven
SOURCE
:
DSDM
Based
on
Dean
Leffingwell
scaling
agile
blog
Fixed
Scope
Time
Resources
Time
Scope
Plan
Driven
Value
Driven
The
Plan
creates
cost/ schedule
es1mates
feature
intent
&
commitment
to
deliver
the
max
value
Resources
Fixed
EsLmated
IntenLonal
&
Max
Possible
The
happy
IteraHve
project
• User
Stories
• Features
• Architecture
Stories
• Issues/Bugs
ITERATION1
ITERATION2
ITERATION3
ITERATION4
Final
RELEASE
Backlog
Fixed
Time
The
unhappy
IteraHve
project
• User
Stories
• Features
• Architecture
Stories
• Issues/Bugs
ITERATION1
ITERATION2
ITERATION3
ITERATION4
Final
RELEASE
Backlog
New
Req
“Embracing
the
Change”
Fixed
Time
Value
Driven
Strategies
• PrioriLze
and
reduce
goals
to
hit
the
release
date
– Less
goals
=>
less
So,ware
• Do
not
commit
to
early:
– Decide
what
to
deliver
by
experimenHng
in
the
iteraHons.
– Remember
that
both
Specs
and
Architecture
emerge
• Avoid
Big
UpFront
Designs
and
Specs
(BUFDS)
• Grow
Features
quality
iteraHon
by
iteraHon
– Start
with
simplest,
minimal
feature
soluHon
and
add
more
quality
iteraHon
by
iteraHon
Based
on
Jeff
Pamon:
hmp://www.agileproductdesign.com
Embrace
Uncertainty
presentaHon
RUP
Process
Framework
Overview
of
Processes/Methods
Low
Ceremony
Limle
documentaHon
Light
process
High
Ceremony
Well
documented
Traceability
CCB
CMM-‐I
CMM
IteraHve
Risk
Driven
ConHnuous
integraHon
and
tesHng
Waterfall
SequenHal,
Few
risks
Late
IntegraHon
and
tesHng
Open
UP
DSDM
XP
SCRUM
Agile
Source:
Per
Kroll/
Philippe
Krutchen
The
Agile
Methods
• Each
IteraLon
delivers
working
so#ware:
Ready
to
be
demonstrated
to
Business
Customer
and
deployed
in
producHon
environment
• All
development
disciplines
(requirements,
analysis
and
design,
implementaHon,
test…)
are
nearly
concurrent
:
FiDng
all
ac3vi3es
in
a
short
3me
itera3on
• Teams
are
self
managing
:
Bomom-‐up
vs
Top-‐down
management
• Use
of
specific
pracLces
that
keep
the
code
base
fresh
and
flexible:
Pair
programming,
code
refactoring,
test
driven
development,
conHnuous
integraHon
• Lean
principles
and
techniques
eliminate
waste
whenever
possible
Books: Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell Agile Estimating and Planning, Mike Cohn Agile Project Management with Scrum, Ken Schwaber The Enterprise and Scrum, Ken Schwaber Scrum And XP from the trenches, Henrik Kniberg Succeeding with Agile. Software Development using Scrum. Mike Cohn Specification by Example. Gojko Adzic Agile References (II)
Kanban
in
a
nusthell
• Visualize
the
workflow
– Split
the
work
into
pieces,
write
each
item
on
a
card
and
put
on
the
wall
– Use
named
columns
to
illustrate
where
each
item
is
in
the
workflow.
• Limit
WIP
(work
in
progress)
–
assign
explicit
limits
to
how
many
items
may
be
in
progress
at
each
workflow
state.
• Measure
the
lead
Hme
(average
Hme
to
complete
one
item,
someHmes
called
“cycle”),
opHmize
the
process
to
make
lead
Lme
as
small
and
predictable
as
possible.
Cra,smanship
Manifesto
As
aspiring
So,ware
Cra,smen
we
are
raising
the
bar
of
professional
so,ware
development
by
pracHcing
it
and
helping
others
learn
the
cra,.
Through
this
work
we
have
come
to
value:
That
is,
in
pursuit
of
the
items
on
the
le,
we
have
found
the
items
on
the
right
to
be
indispensable.
Not
only
working
so,ware,
but
also
well-‐cra#ed
so#ware
Not
only
responding
to
change,
but
also
steadily
adding
value
Not
only
individuals
and
interacHons,
but
also
a
community
of
professionals
Not
only
customer
collaboraHon,
but
also
producLve
partnerships
hmp://manifesto.so,warecra,smanship.org/
_rubengb
nktamago
ramimac
miyakemito
datarian
ikezoemakoto
ogugu9
yurihondo
adavis
dsa28s
takuyay0ne
line_developers
minorun365
jensimmons
skipperchong
aleyda
zakiyama
jasonvnalue
jonyablonski
carmenintech
kneath
keithpitt
addyosmani
quramy
edds