Transcript Extreme Programming and Systems Engineering Similarities

Extreme Programming and
Systems Engineering
Similarities and Synergy
(based on talk given to INCOSE New England Chapter)
Joseph (Yossi) Weihs
Sept 10th, 2004
Abstract
XP is one of the popular ‘Agile’ software
development disciplines
Systems engineers may have to deal
with software teams practicing XP
What should you look out for, and what
can you exploit when working with an
XP oriented team?
2
Contents






Overview – what is XP
Why use XP
Overlap with SE
Key differences
Integrated methods
Summary / Take Home
3
Agile Methods
Formality - from lightweight to ‘heavy’:
Scrum
XP
Crystal Orange
DSDM
4
Overview



Extreme Programming is a software
development methodology that
originated about seven years ago
XP is winning recognition in large
organizations
XP is bunched together with Lean
development and Agile processes
5
Must have a flow chart
6
History of XP


Started out as a
one man’s quest
Kent Beck
Defined four values
in 1996:
–
–
–
–
Communication
Simplicity
Feedback
Courage
7
History of XP (continued)


Since 1999 it has been publicly
evangelized. Numerous publications have
sprung up
2004 – XP is in use in many organizations,
large and small
8
Why XP?
The approach works best when:
 Project has numerous requirement changes
 High risk development
 Applied to small (30<) teams
 Testability is a requirement (V&V!)
Use XP only with whole software team buy-in!
9
XP Cost of Change
Cost of change
Traditional Development
eXtreme Programming
Maintenance
Coding
Design
Analysis
0
Development phase
10
Steve Hayes ([email protected])
XP and Risk
11
Core XP Principles





Incremental change
Assume simplicity
Rapid feedback
Embracing the change
Quality work
12
Core XP Practices
Broken down to four domains:
Planning
Designing
Coding
Testing
13
Planning
–
–
–
–
–
–
–
–
–
User stories
Release planning / release plan
Make frequent small releases
Project velocity
Iterative development
Iteration planning
Move people around
Daily stand up meeting
Fix XP when it breaks
14
Designing
– Simplicity is the key
– Choose a system metaphor
– CRC cards
– Spike solution
– Never add functionality early
– Re-factor mercilessly
– YAGNI = You Ain’t Gonna Need It
15
Coding
–
–
–
–
–
–
–
–
–
On site customer
Coding standard
Code unit then test
Pair programming
Sequential integration
Integrate often
Collective code ownership
Optimize last
40 hours a week
16
Testing
– Unit tests
– When a bug is found…
– Acceptance tests
17
XP Life Cycle





Exploration phase
Planning phase
Iterations to release
Productionizing
Death phase
18
XP Team Members







Programmers
Customers
Testers
Trackers
Coach
Consultants
Manager
19
XP roles an SE plays





Customer – the SE is requirements
advocate and validation tester
Tracker – SE may act as project
manager, including risk mitigation
Tester – SE may facilitate some tests
Coach – SE’s as discipline leader
Manager – SE as boss in large project
20
XP & SE – Overlap
XP
Systems Engineering
Planning
Testing
Development plan, risk
management
Validation & verification
Coach
Systems engineer
Collective System integration
ownership
21
XP Iterations and SE
XP: Assume customer
does not have clear
definition of system at
any point
SE: Maximize
planning, scenario
building risk
assessment before
starting work
Collision? Sometimes, but SE can still manage
process: trickle feed XP’rs requirements
disguised as customer stories, according to SE
requirement rankings
22
XP Customer and SE
XP: Customer Rep
available at all times
for iterations:
Requirements, risks,
priorities, validation
SE: Customer signs off
on SOW, gets briefed
on progress and
accepts product at
milestones
Collision? Sometimes – when working with XP
teams, use their power throughout project
initiation, and transition more structured
disciplines as project matures
23
Additional XP & SE issues



XP’s short iterations and local focus fit
concept exploration phase
XP is the least formalistic of the Agile
methods : On-Site Customer
Pair Programming can cause cultural
problems
24
Integrated Approaches




Small XP teams within larger projects
Software – part heavyweight, part XP
Extreme / Agile Project Management
Extreme applied to other engineering
disciplines
25
Summary / Take Home




Works well for smaller software
projects / proof of concept
Works with CMMI / UML (to a point)
No fixed cookbook – tailor it to your
project
Spill over to project management and
general engineering management
26
References



Extreme Programming Explained, Kent
Beck, Addison Wesley 1999
Re-factoring: Improving the Design of
Existing Code, Martin Fowler, Addison
Wesley 1999
Many web sites
27
Links








http://www.extremeprogramming.org
http://www.xp2001.org
http://www.iturls.com/English/SoftwareEngineering
/xpm_apm.asp
http://www.balagan.org.uk/work/
http://collaboration.csc.ncsu.edu/laurie/Papers/XPS
ardinia.PDF
http://www.xprogramming.com/
http://www.dsmweb.org/
http://www.martinfowler.com/articles/newMethodol
ogy.html
28
Extra Slides
29
XP - The Four Core Values




Communication.
Simplicity.
Feedback.
Courage.
30
Communication



Often problem that arise in SW project can
be tracked back to lack of communication.
XP enforces the Communication Value by
employing many practice that could not be
carried without communicating (e.g. pair
programming, unit testing etc.).
XP employs a Coach whose job is that of
noticing when people are not
communicating and reintroduce them.
31
Simplicity



XP embrace the principle of “Make it Simple”
XP is betting that it is better to do a simple
thing today and pay a little more tomorrow
to change it, if it needs to be changed, than
building a more complicate system that has
feature that will never be used.
Simplicity and Communication support each
other mutually.
32
Feedback




Feedback works in XP at different time
scales.
Programmers have feedback on a minutes
time scale on the status of the system
thanks to unit tests.
When customers write new stories the
programmers estimate those immediately to
give prompt feedback to the customer about
the quality of the stories.
The customer review the scheduler every 23 weeks and provide prompt feedback to
the developer.
33
Courage



XP team should have the courage of
throwing code away.
XP team should have the courage of mainly
refactor the architecture of the system, if
architectural flaw are detected.
Courage has in XP the same role that
mutation has in genetic algorithms. Takes
you out of local maximum/minimum.
34