EEEGEF 492'07 RAD, Agile Methods, and XP

1
EEE/GEF 492.07RAD, Agile Methods, and XP
Royal Military College of Canada Electrical and
Computer Engineering

• Professor Colin Wortley
• wortley_at_rmc.ca
• 613-541-6000 ext. 6493

Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
2
Development Process Models

• Different approaches to sequencing the
  engineering activities
• Waterfall
• Incremental/Prototyping
• Evolutionary Prototyping
• Spiral
• Rapid Application Development (RAD)
• precursor to agile methods
• Rational Unified Process (RUP)
• unification of previous models
• Agile eg. XP, Scrum, Crystal, Feature Driven,
  Adaptive

1st five are in van Vliet (Ch. 3). Last 2 are too
new.
3
RAD Rapid Application Development

• evolutionary development, with time boxes fixed
  time frames within which activities are done
• time frame is decided upon first, then one tries
  to realize as much as possible within that time
  frame
• other elements Joint Requirements Planning (JRD)
  and Joint Application Design (JAD), workshops in
  which users participate
• requirements prioritization through a triage
• development in a SWAT team Skilled Workers with
  Advanced Tools

4
Development Process Models

• Different approaches to sequencing the
  engineering activities
• Waterfall
• Incremental/Prototyping
• Evolutionary Prototyping
• Spiral
• Rapid Application Development (RAD)
• precursor to agile methods
• Rational Unified Process (RUP)
• unification of previous models
• Agile eg. XP, Scrum, Crystal, Feature Driven,
  Adaptive

1st five are in van Vliet (Ch. 3). Last 2 are too
new.
5
http//agilemanifesto.org
- written in 2001
6
Principes sous-tendus par l'Agile Manifesto Nous
suivons ces principes 1 Satisfaire le
consommateur est notre priorité principale grâce
à la livraison précoce ? et continue d'un
logiciel de qualité ?. Faire bon accueil aux
modifications d'exigences, même lorsqu'elles sont
tardives dans le développement. Les processus
agiles exploitent le changement pour en faire un
avantage compétitif pour le consommateur. Livrer
un logiciel fonctionnel fréquemment, tous les
quinze jours à deux mois en privilégiant
l'intervalle le plus court. Commanditaires
business people et développeurs doivent
travailler ensemble quotidiennement pendant toute
la durée du projet.
7

• Principes sous-tendus par l'Agile Manifesto
• Nous suivons ces principes 2
• Construire des projets autour de personnes
  motivées. Leur procurer l'environnement et les
  moyens dont ils ont besoin, et leur faire
  confiance pour mener le travail à son terme.
• La façon la plus efficace de transmettre une
  information à une équipe ou au sein d'une équipe
  de développement c'est de converser en
  face-à-face.
• Le logiciel fonctionnel ? est la mesure
  principale de progression.
• Les processus agiles promeuvent le développement
  durable. Commanditaires, développeurs, et
  utilisateurs doivent pouvoir être capables de
  soutenir une allure constante indéfiniment.

8
Principes sous-tendus par l'Agile Manifesto Nous
suivons ces principes 3 Prêter une attention
constante à l'excellence technique et à la bonne
conception améliore l'agilité. La simplicité --
l'art de maximiser la quantité de travail à ne
pas faire -- est essentielle. Les meilleures
architectures, spécifications, et conceptions
émergent d'équipes qui s'auto-organisent. À
intervalles réguliers, l'équipe est appelée à
réfléchir sur la façon de devenir plus efficace,
puis règle et ajuste son comportement en
conséquence.
9
http//agilemanifesto.org/principles.html
10
(No Transcript)
11
Original signatories included representatives
from Extreme Programming, SCRUM, DSDM, Adaptive
Software Development, Crystal, Feature- Driven
Development, Pragmatic Programming, and others.
For a brief history on the manifesto go
to http//agilemanifest
o.org/history.html
12
La Programmation Extrême
13
Extreme Programming
14
A Brisk Stroll ThroughExtreme Programming
15
Where the stroll is going

• a bit of introduction
• projects are made of releases
• releases have lots of iterations
• iterations unfold day by day
• every day we do development
• some XP issues
• design
• documentation
• when cant you XP?

16
What is XP?

• a light-weight methodology
• designed for moderate-sized software projects
  with vague or changing requirements
• an interlocking set of practices
• for planning, designing, programming and testing
• a set of values
• communication, simplicity, feedback, courage
• a relationship
• the customer defines business value the
  developers deliver business value
• an evil, mind-destroying cult
• all your development processes belong to us!
• well, you decide

17
What do you mean by extreme?

• take well-known software engineering best
  practices and push them to the extreme
• if code reviews are good, review code all the
  time
• if testing is good, test all the time
• if design is good, design all the time
• if simplicity is good, keep the system as simple
  as possible all the time
• if architecture is good, define and refine the
  architecture all the time
• if integration testing is good, integrate and
  test all the time
• if short iterations are good, make the iterations
  really, really short
• if plans and measurements are good, plan and
  measure all the time

18
Where did XP come from?

• in-house development efforts
• initial development, continuous evolution after
  first production release
• has also been used for shrink-wrapped, contracted
  systems
• business-oriented systems
• changing requirements, partial releases possible
• has also been used for embedded systems, etc.
• small programming teams
• less than ten people
• have been reported successes at 50 or more
• flexible programming technologies
• started in the Smalltalk world
• has also been used for Java, C, Lisp, Python,
  etc.
• a deep sense of frustration

19
Who are the players?

• customer
• chooses what will deliver business value, what to
  do first and what to defer
• defines tests to show that the system does what
  it needs to
• may be one or more people, must speak with one
  voice
• developer
• analyzes, designs, tests, programs and integrates
  the system
• estimates the difficulty of each story
• tracks the pace of story delivery
• manager
• brings the customer and the programmer together
  and helps them meld into a smoothly operating
  team
• runs interference, provides snack food
• ensures victories are celebrated
• may also have dedicated tester, tracker, coach

20
Whats the work environment?

• ideally, single, large, open work room
• lots of white boards, walls to stick things on
• development machines on tables in center of the
  room
• small personal spaces at edges of the room (small
  desk, telephone, whatever)
• aim is to promote fluid communication within the
  group
• everyone works here manager, customer,
  developers, specialists

21
Projects are made of releases
The team plans one release at a time. Releases
are short not more than three to six months.
22
Architectural spike, metaphor

• before beginning work on the system, need a
  common understanding of high-level structure
• XP doesnt do Big Design Up Front, doesnt have
  an Architecture Phase
• based on initial understanding of system from
  customer, do an architectural spike
• running code to clarify understanding of system
  structure
• result of architectural spike is a metaphor
• a way of thinking about the system
• the employee compensation process is like bins
  going down a conveyor belt or a computer is
  like a desk
• if the metaphor is well chosen, it leads
  automatically to design approaches, class names,
  communication

23
User stories

• the customer writes requirements in terms of
  user-visible functionality, as short stories
  written on index cards

• stories must be clear enough that
• developers can make estimates from them
• the customer can write acceptance tests from them

24
Why index cards?

• XP uses index cards for documenting stories,
  tasks, classes in designs, everything
• why?
• cheap
• easy to write on, sort, shuffle, organize,
  manipulate, annotate, lay on tables, stick to
  walls
• and tear up
• people dont get emotionally attached to index
  cards the way they do to long requirements
  documents, CASE tool drawings,MS project
  schedules, etc.
• provide physical evidence of whats been done,
  whats to be done
• really sophisticated projects use pre-formatted
  index cards for different purposes

25
Estimating stories

• developers estimate stories in terms of ideal
  development weeks
• I could implement that in two weeks if everyone
  would just leave me alone
• if estimate is greater than a week or so, ask
  customer to split the story
• then developers re-estimate
• if estimates are uncertain, do a spike solution
• a small, throw-away prototype, intended to get a
  better feel for how much effort will be required
  to implement the story
• result of a spike is a confident estimate

26
The release planning game

• customer prioritizes stories
• developers declare project velocity
• ideal programmer weeks per calendar week
• based on actual observation, not wishful thinking
• customer declares release scope
• meaningful package of business value
• release milestone is computed based on story
  estimates, project velocity, chosen scope
• result should be in the 3-6 month range
• may be constrained by external factors
• customer may add or remove stories until a
  satisfactory release plan (scope, milestone) is
  found

27
What if

• youre in the first release and dont know your
  velocity?
• make an educated guess guess low accept that
  its a guess
• your measured velocity last release was
  unacceptably low?
• use it for your plan anyway, then hustle to beat
  the plan
• better to beat a conservative plan than lose to
  an optimistic one

can we really double productivity?
XP approved estimate!
28
Acceptance tests

• the customer writes the acceptance tests based on
  the agreed stories
• essentially black-box testing
• aim is to provide the customer with confidence
  that the system does what is required
• if the system passes these tests, Id believe it
  does what I asked for
• the development group may provide dedicated
  testers who help the customer implement the
  acceptance tests
• ideally, acceptance tests will be automated for
  ease of execution if theyre easy to run,
  theyll be run

29
Releases have lots of iterations
Iterations are really short not more than one to
three weeks. Expect a dozen iterations in a
release.
30
Iteration planning game

• developers set an iteration milestone (1-3 weeks)
• customer selects prioritized stories
• to fill iteration, based on story estimates and
  project velocity
• normally includes failed acceptance tests and
  unfinished tasks from last iteration
• developers divide stories into tasks
• discuss intent of stories with customer
• split into detailed programming tasks, write on
  cards
• developers declare personal velocity
• individually, in ideal programmer days per
  calendar day
• based on observation, not wishful thinking
• personal target personal velocity iteration
  duration
• developers sign up for tasks (take cards)
• individually estimate task (ideal programmer
  days)
• if task lt 1 day or gt 3 days, group or split as
  necessary
• take tasks up to personal target

31
What if

• the customer has selected more stories than will
  fit in the iteration
• indicates a disconnect between story-level
  estimation and task-level estimation
• since task-level estimation more detailed,
  believe it
• after first few iterations, will know if release
  re-plan needed
• the developers have room for more tasks
• customer adds more stories
• the customer wants remove a story from the
  release, or add one, or change one
• go for it but dont forget to update the
  release plan!
• the customer has run out of stories
• success! but dont worry, theres more where
  those came from

32
Iterations unfold day by day
33
Stand-up meeting

• each morning, entire team (including customer,
  manager, specialists) gathers for a stand-up
  meeting
• called stand-up because everyone stands in a
  circle for the whole meeting
• goal is for each team member to communicate
  problems and solutions
• promotes team focus, takes the place of many
  smaller meetings

34
Every day we do development
35
CRC modeling

• simple form of object-oriented design
• Class, Responsibility, Collaboration
• done on (you guessed it) index cards
• or whiteboards, in a pinch
• do just enough design to understand the code you
  need to write
• typically, models are kept around just long
  enough to complete the implementation, then
  discarded
• make the design just enough to implement the task
  at hand
• Do the Simplest Thing That Could Possibly Work
• resist the urge to design for tomorrow
• You Aint Gonna Need It

36
Programming in XP

• incrementally
• programming is done in very tight cycles, a few
  lines of code or a method (not even a class)
• test-first
• automated unit tests are created before the code
  that makes them run
• execute the test and watch it fail!
• write just enough code to pass the test
• write just enough tests that youre sure the code
  works
• test-code-refactor
• repeat this process adding small bits of
  functionality, always test-first and
• refactor the design (and tests) as necessary,
  then test again

37
Refactoring

• refactoring improving the design of existing
  code
• based on recognition of code smells or
  anti-patterns
• classes or methods too long, too much or too
  little functionality, poor use or lack of use of
  inheritance, duplicate code, near duplicate code,
  
• XP separates new development from refactoring
• refactoring should result in no functional change
• can be done before or after adding functionality
• without automated unit tests, continual
  refactoring is dangerous or impossible
• refactoring browsers now available

38
Pair-Programming

• two people share one computer during a session
• one types/designs tactically
• the other thinks strategically
• will this work? what next? do we need to
  refactor?
• switch roles frequently
• switch partners frequently
• claimed benefits
• increased quality (continuous inspection)
• increased productivity (counter-intuitive but
  demonstrated)
• continual cross-training
• it takes some getting used to!
• liberal use of breath mints recommended

39
We complete our tasks
40
the day ends
41
an iteration completes
42
we make a release
43
and we start the next one.
44
Summary A set of interlocking practices

• Process
• on-site customer
• small releases
• planning game

• Programming
• test-first programming
• coding standards
• simple design
• refactoring
• Team
• pair programming
• collective ownership
• continuous integration
• no overtime
• metaphor

The practices are designed to mutually support
one another. Each, in isolation, couldnt
possibly work.
45
Where did design go?

• common perception that XP doesnt do design
• certainly doesnt do Big Design Up Front
• design happens
• in the establishment of a system metaphor
• in the division of stories into tasks
• in decisions about task implementation
• in refactoring

46
And documentation?

• XP is a code-centric process, since
• you need the code anyway, and
• code is the ultimate reflection of software
  design
• by itself, XP doesnt tend to produce non-code
  documentation
• except acceptance tests, and those should be code
  anyway!
• if the customer requires any other documentation,
  it will be produced
• and the documentation story must be estimated,
  planned and resourced just like any other

47
When shouldnt you do XP?

• when you cant automate unit testing
• with Extreme Cleverness you can automate pretty
  much anything whether or not you should is a
  business decision
• when the system really does demand Big Design Up
  Front
• perhaps do the BDUF as an XP mini-project?
• when you cant get a full-time customer
• so theyre not serious anyway, right? well, how
  about a substitute?
• when you really do understand all the
  requirements up front
• yeah, right

48
What to do, when you cant do XP?

• be subversive, do parts of it
• plan the XP way, within constraints
• pair program/design
• practice test-first
• look for refactoring opportunities
• do something else
• XP simply may not be right for your situation
• recognize that, and do something else intelligent

49
What do we actually know?

• little experimental evidence regarding
  effectiveness of XP
• much like the rest of software engineering
• some solid experimental results regarding pair
  programming pairs are almost twice as productive
  as individuals and produce higher quality code
• significant body of anecdotal evidence
• most positive, some reported failures
• appears obviously unsuitable for some domains,
  obviously suitable for others
• distrust both obviouslys

50
For more information

• Web sites
• www.extremeprogramming.org
• www.xprogramming.com
• c2.com/cgi/wiki?ExtremeProgrammingRoadmap
• www.xp123.com/
• www.refactoring.com
• www.adaptivesd.com
• alistair.cockburn.us
• crystalmethodologies.org
• agilemanifesto.org
• Books
• Beck. Extreme Programming Explained Embrace
  Change
• Jeffries et. al. Extreme Programming Installed
• Beck and Fowler. Planning Extreme Programming
• Fowler. Refactoring Improving the Design of
  Existing Code