Extreme CMMI

1
Extreme CMMI

• Patrick Emery
• pemery_at_cox.net

2
Topics

• 4 Points To Highlight
• XP - The 12 Steps
• Minimum XP
• CMMI Version
• Specific Examples
• Almost XP
• XP Documentation
• More Than Minimal
• Conclusions

3
4 Points to Highlight

• Project Restrictions
• Process versus Process Improvements
• Local Optimization
• Magic

4
XP - The 12 Steps

• Planning game. Customers decide the scope and
  timing of releases based on estimates provided by
  programmers. Programmers implement only the
  functionality demanded by the stories in this
  iteration.
• Small releases. The system is put into production
  in a few months, before solving the whole
  problem. New releases are made often anywhere
  from daily to monthly.
• Metaphor. The shape of the system is defined by a
  metaphor or set of metaphors shared between the
  customer and programmers.
• Simple design. At every moment, the design runs
  all the tests, communicates everything the
  programmers want to communicate, contains no
  duplicate code, and has the fewest possible
  classes and methods. This rule can be summarized
  as, "Say everything once and only once."
• Tests. Programmers write unit tests minute by
  minute. These tests are collected and they must
  all run correctly. Customers write functional
  tests for the stories in an iteration. These
  tests should also all run, although practically
  speaking, sometimes a business decision must be
  made comparing the cost of shipping a known
  defect and the cost of delay.
• Refactoring. The design of the system is evolved
  through transformations of the existing design
  that keep all the tests running.

5
XP - The 12 Steps Cont.

• Pair programming. All production code is written
  by two people at one screen/keyboard/mouse.
• Continuous integration. New code is integrated
  with the current system after no more than a few
  hours. When integrating, the system is built from
  scratch and all tests must pass or the changes
  are discarded.
• Collective ownership. Every programmer improves
  any code anywhere in the system at any time if
  they see the opportunity.
• On-site customer. A customer sits with the team
  full-time.
• 40-hour weeks. No one can work a second
  consecutive week of overtime. Even isolated
  overtime used too frequently is a sign of deeper
  problems that must be addressed.
• Open workspace. The team works in a large room
  with small cubicles around the periphery. Pair
  programmers work on computers set up in the
  center.
• Just rules. By being part of an Extreme team, you
  sign up to follow the rules. But they're just the
  rules. The team can change the rules at any time
  as long as they agree on how they will assess the
  effects of the change

6
Minimum XP process Requirements

• Extreme Programming (a la C3 project) requires 4
  things
• You do pair programming.
• You deliver an increment every three weeks.
• You have a user on the team full time.
• You have regression unit tests that pass 100
  of the time.

7
Minimum XP process Rewards

• As a reward for doing those,
• You don't put comments in the code.
• You don't write any requirements or design
  documentation.
• -- Alistair Cockburn, http//www.c2.com/cgi/wiki?
  AlmostExtremeProgramming

8
CMMI Version

• Pick CMMI-SE/SW version 1.02 to look at as
  opposed to
• CMM SW
• CMMI-SE/SW/IPPD(Integrated Product and Process
  Development )
• CMMI-SE/SW/IPPD/A( Acquisition )
• Other Quality Frameworks
• Take a pessimistic attitude that when it doesn't
  work with SE/SW it won't work with the others.

9
CMMI Version (continued)

• Continuous versus staged representation.
• Continuous indicates improvements in a single
  process area( detail )
• Staged gives a single number indicating only
  overall improvements in organizational maturity(
  rollup )
• Use Continuous because staged is a view of
  continuous.

10
Specific Examples

• Non-compliance with documenting requirements,
  design and code

11
Almost XP

• Discussion of XP as specific process instance
  versus CMMI is a process model.
• The Software CMM tells what to do in general
  terms, but does not say how to do it, while XP is
  a set of best practices that contain fairly
  specific how-to information an implementation
  model for a particular kind of environment.
  Mark C Paulk, http//www.sei.cmu.edu/cmm/papers/xp
  -cmm-paper.pdf
• XP claims to be a lightweight discipline of
  software development.
• CMMI allows and recommends tailoring.
• XP warns of "almost XP" syndrome.

12
XP Documentation

• XP is designed to use face to face human
  communication in place of written documentation
  wherever possible. Ron Jeffries,
  http//www.xprogramming.com/xpmag/expDocumentation
  InXP.htm
• You may ask how we later know what the design
  is, since the cards are gone. Our answer is that
  the design is represented in the code. Ron
  Jeffries, http//www.xprogramming.com/Practices/Pr
  acDocumentation.html

13
More Than Minimal

• Planning Game
• Metaphor, Simple Design, Coding Standards, and
  Refactoring
• Collective Ownership
• 40-hour week, Open Workspace

14
Conclusions

• If rewards can be ignored and the process still
  considered XP then a CMMI compliant XP process
  can be constructed.
• XP does in fact recommend doing some
  documentation as needed. Ronald E Jeffries,
  http//www.xprogramming.com/Practices/PracDocument
  ation.html
• However, the impact on XP's productivity gain
  when eliminating those rewards should be examined.

15
References

• Kent Beck, Extreme Programming, Proceedings of
  the Technology of Object-Oriented Languages and
  Systems conference in June 1999, Nancy, France,
  IEE, http//www.computer.org/proceedings/tools/027
  5/02750411abs.htm
• Kent Beck, XP practices, eXtreme Programming Pros
  and Cons What Questions Remain?, IEEE Computer
  Society Dynabook (September 2001),
  http//www.computer.org/SEweb/Dynabook/XPPracSdb.h
  tm
• Jawed Siddiqi, "An Exposition of XP But No
  Position on XP", eXtreme Programming Pros and
  Cons What Questions Remain?, IEEE Computer
  Society Dynabook (September 2001),
  http//www.computer.org/SEweb/Dynabook/Index.htm
• T. Scott Ankrum, What's Written Down?, eXtreme
  Programming Pros and Cons What Questions
  Remain?, IEEE Computer Society Dynabook
  (September 2001), http//www.computer.org/SEweb/Dy
  nabook/AnkrumComments.htm

16
References Continued

• Ian Alexander, "The Limits of eXtreme
  Programming", eXtreme Programming Pros and Cons
  What Questions Remain?, IEEE Computer Society
  Dynabook (September 2001), http//www.computer.or
  g/SEweb/Dynabook/AlexanderCom.htm
• Stephen J Mellor, Metaphors, Magic, War Numbers,
  and The Elite, eXtreme Programming Pros and Cons
  What Questions Remain? IEEE Computer Society
  Dynabook (September 2001), http//www.computer.org
  /SEweb/Dynabook/MellorCom.htm
• Cockburn, Alistair, "Almost Extreme Programming",
  http//www.c2.com/cgi/wiki?AlmostExtremeProgrammin
  g
• Richard Bechtold, Ph.D., Essentials of Software
  Project Management, (Vienna, Virginia Management
  Concepts, Inc., 1999), 218.
• US AirForce Software Technology Support Center,
  http//www.stsc.hill.af.mil/cmmi/index.asp

17
References Continued Again

• Paulk, Mark C., "Extreme Programmming From a CMM
  Perspective", XP Universe Conference Papers,
  Raleigh, NC, 23-25 July 2001, http//www.sei.cmu.e
  du/cmm/papers/xp-cmm-paper.pdf
• Merriam-Webster, "definition of document",
  Collegiate Dictionary ,(2001), http//www.m-w.com/
  cgi-bin/dictionary?document
• Jeffries,Ronald E., "Essential XP
  Documentation", 09/01/2001, http//www.xprogrammin
  g.com/xpmag/expDocumentationInXP.htm
• Jeffreis,Ronald E., "Software Documentation",
  http//www.xprogramming.com/Practices/PracDocument
  ation.html
• Jerzy Nawrocki, Bartosz Walter, Adam
  Wojciechowski, Toward Maturity Model for extreme
  Programming, Proceedings of 27th EUROMICRO
  Conference (September 4-6, 2001, Warsaw, Poland),
  IEEE Computer Press, Los Alamitos, 233-239,
  http//www.cs.put.poznan.pl/jnawrocki/publica/euro
  micro2001.doc