1. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 1 eXtreme Programming – one of the Agile Software Development Methodologies T-76.650 21.1.2002 Jari Vanhanen

2. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 2 Agile Methodologies  eXtreme Programming  SCRUM  Dynamic Systems Development Method  Feature Driven Development  Crystal Methodologies / Adaptive Systems Development  Iterative and incremental in nature  Package existing software engineering practices  Some starting points for the interested:  www.agilealliance.org/  www.martinfowler.com/arti cles/newMethodology.html www.martinfowler.com/arti cles/newMethodology.html

3. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 3 From Waterfall to XP Time Analysis Design Implementation Test WaterfallIterativeXP Reference: Beck Kent, “Embracing Change with Extreme Programming”, IEEE Computer, Vol. 32, No. 10, 1999, pp. 70-77.

4. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 4 Introduction to eXtreme Programming (XP)  XP is an extreme attempt to dramatically simplify the software development process  XP focuses on what delivers value  requirements and working code  minimize the intermediate work products  tacit knowledge, face-to-face communication  Most famous of the agile processes  Kent Beck, C3 project at Chrysler 1996  A set of common sense principles and practices taken to extreme levels  testing, reviews, simplicity,...

5. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 5 Focus  When to use XP  small (2-10), co-located teams  however, well-structured 10 person team can solve a larger problem than much bigger team with heavier methodology  vague or rapidly changing requirements  aiming to high productivity  When not to use XP  large team  long time is needed to gain feedback of the system  slow builds, infrequent releases, lack of customer collaboration  automated, quick testing of the software is impossible  technology with an inherently exponential cost curve

6. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 6 Characteristics  Incremental planning  feedback from short cycles  flexible scheduling  Evolutionary design process lasts as long as the system lasts  Automated tests  unit tests  acceptance tests  Oral communication, tests, and code to communicate system structure and intent  Close collaboration of programmers  High-discipline  activity intensive  coach required

7. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 7 Focus on Controlling the Scope  Four variables in a project  cost, time, quality and scope  all can’t be fixed  cost is the most constrained  quality must usually be good  more time means lack of feedback  being able to adjust the scope gives best control

8. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 8 Flattened Change Cost Curve  What does cost of change actually mean?  detection, implementation, deployment?  during an iteration, release, project, the whole life-cycle?  Technical premise of XP  steep change cost curve makes XP impossible  What makes flattening possible  object technology  simple design  automated tests  lots of practice in modifying the design  Or is it still there?  XP’s practices just provide feedback early time cost of change time cost of change

9. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 9

10. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 10 Values, Principles and Practices  Values  short-term individual goals vs. long-term social goals  common values required  Principles  more concrete  considered when making decisions  Practices  concrete ways of work

11. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 11 Values (1/2)  Communication  lack of it is the reason for most problems  punishment from bad news kills it  XP employs practices that keep programmers, customers and managers communicating  Simplicity  What is the simplest thing that could possibly work?  general vs. simple design  anticipatory design assumes more work today saves later  YAGNI  low rate of changes  anticipatory design  high rate of changes  refactoring and continuous design  helps understanding

12. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 12 Values (2/2)  Feedback  concrete feedback about the state of the system  scale of minutes or days  unit tests, quality of stories (requirements), progress of tasks  scale of weeks or months  func. tests, schedule, system in production  Courage  changing the system  throwing code away  pair programming

13. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 13 Principles  Fundamental principles  rapid feedback  critical for learning  assume simplicity  treat every problem as if it can be solved with simplicity  incremental change  series of smallest changes that make a difference  embracing change  best strategy preserves most options while actually solving your most pressing problem  quality work  excellent quality  nobody likes doing a bad job  Secondary principles  teach learning  small initial investment  play to win  concrete experiments  open, honest communication  work with people’s instincts, not against them  accepted responsibility  local adaptation  travel light  honest measurement

14. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 14 Practices - Overview  Simple, well-known practices  How could XP work?  practices support each other’s weaknesses  exponential change cost is collapsed (simple design, tests, refactoring)  Practices  Planning game  Small releases  Testing  Continuous integration  Metaphor  Simple design  Refactoring  Pair programming  Collective ownership  Coding standard  On-site customer  40-hour week

15. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 15 Practices - Process  On-site customer  sitting with the team  customer and user views  Testing  functional (acceptance) tests for stories  criteria for readiness  unit tests for all methods that could possibly break  100% must pass all the time  write tests before code  Small releases  as small as possible  most valuable business requirements  Planning game  release planning  iteration planning

16. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 16 Practices – Process - Planning Game  Release planning  customer decides  scope, priority and dates  programmer team decides  estimates, consequences, process, detailed scheduling  exploration phase  customer writes stories  team estimates stories  planning phase  team estimates velocity  customer selects and prioritizes stories   Iteration planning  exploration phase  team brainstorms tasks  commitment phase  programmers accept and estimate a set of tasks  personal speed  steering phase  implement a task  record progress  recovery (if needed)  verify story

17. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 17

18. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 18 Practices – Team Practices  Pair programming  for all production code  dynamic pairing  Collective ownership  everyone responsible of the whole system  a pair should immediately revise any overly complex code they see  Continuous integration  several times a day  unit tests must run 100%  Coding standard  improved communication  Metaphor  high-level architecture  common language between business and technical folks  40-hour week  overtime is a symptom of a serious problem

19. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 19 Practices - Programming  Simple design  best design for today  runs the tests  no duplicated logic  code states intention to programmers  Refactoring  make design simpler, while still running all of the tests  Testing  Coding standard

20. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 20 Roles and Responsibilities  Customer  write and select stories  continuous discussion with programmers  write functional tests  Manager  form the team  resources  interface to outside parties  Coach  keep discipline in place  indirect intervention preferred  Programmer  test, code, refactor  Tester  help the customer specify functional tests  run the tests regularly  Tracker  collect effort data  face-to-face  give programmers feedback on accuracy of estimates

21. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 21 Critique  Architecture design?  spikes, metaphor  first iteration should contain stories that force to create a skeleton of the whole architecture  if requirements are predictable discarding them in the design throws away valuable information  refactoring  works better with small systems and local optimizations  architectural discontinuities (performance, security) cause large costs with big systems

22. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 22 Critique  Making documents?  team practices  shared knowledge  minimal documents  document more, if customer is willing to pay for it  What if the team must be replaced?  Documents?  requirements, functional spec.  user stories, acceptance tests  architecture spec.  short technical overview  technical specification  code, unit tests  project plan  release plans, iteration plans

23. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 23 Critique  On-site customer?  is the project important, if the customer is not willing to assign one person to it  still difficult in practice  Flattened change cost curve  What does this really mean?  When is it valid?  XP requires highly skilled, motivated, and disciplined developers. The number of such developers is limited.

24. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 24 References  Beck. Embracing Change with Extreme Programming, IEEE Computer, Vol. 32, No. 10, 1999, pp. 70-77.  Beck. Extreme Programming Explained. Boston, Addison- Wesley, 2000.  Beck, Fowler. Planning Extreme Programming. Boston, Addison-Wesley, 2000.  Wake. Extreme Programming Explored. Boston, Addison- Wesley, 2001.  www.extremeprogramming.org  www.xp2001.org