1. CMPUT 402 - eXtreme programming
Paul Sorenson
1/11/2019
CMPUT eXtreme programming

2. What is Extreme Programming?
It is a deliberate and disciplined approach to software development.
Stresses customer satisfaction
Special Development Cycle
Rules and Practices of Extreme Programming:
Planning
Coding
Designing
Testing
1/11/2019
CMPUT eXtreme programming

3. Special Development Cycle
Pairs of programmers program together
Development is driven by tests. Testing is done before coding. You are finished adding functionality to a program when all tests that you can think would “break” a program run correctly.
Pairs don’t just make test cases run. They also evolve the design of the system. Pairs add value to the analysis, design, implementation, and testing to the system.
Integration immediately follows development, including integration testing (i.e. when programmers are coding independently, at the end of the day, they integrated their work before they quit).
1/11/2019
CMPUT eXtreme programming

4. Heavy Emphasis on Planning
User stories
Release Planning
Focus on small releases
Project velocity
Iterative planning and development
Moving people around
Daily standup meeting
Adjusting XP (fixing it when it breaks)
1/11/2019
CMPUT eXtreme programming

5. CMPUT 402 - eXtreme programming
User Stories
Serve the same purpose as use cases, but may be used to create time estimates for the release planning meeting
Written by customers as things that the system needs to do for them (desirable/required features)
Similar to usage scenarios, except they are not limited to describing a user interface
Format: written by users, without technical syntax.
User stories drive creation of acceptance tests
Biggest difference from traditional requirements specifications is level of detail. User story uses only a reasonably low risk estimate of how long the story will take to implement
1/11/2019
CMPUT eXtreme programming

6. User Stories (continued)
Each story will get a 1, 2, or 3 week estimate in “ideal development time” (This is the time it would take to implement the story if no distractions. If the period is longer than three weeks, break the story down further. If the period is less than one week, then you should consider combining stories, because the existing ones are too detailed).
Approximately 80 user stories plus or minus 20 create a release plan during release planning.
The difference between user stories and requirements documents is focus on user needs and not on specific technology, or algorithms.
1/11/2019
CMPUT eXtreme programming

7. CMPUT 402 - eXtreme programming
Release Planning
Release plan lays out the overall project. It is used to create plans for each iteration.
Tech people make tech decisions and business people make business decisions. Development team estimates each user story in terms of ideal programming weeks.
A useable, testable system delivered early is desirable.
The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope).
1/11/2019
CMPUT eXtreme programming

8. CMPUT 402 - eXtreme programming
Project Velocity
How fast work is getting done
Project velocity => # user stories during the iteration. Total up the # estimates that these stories or tasks received to get effort/time-to-complete estimates.
Project velocity in stories completed can be used to estimate how many stories will get done.
Tracking the total amount of work done during each iteration is key to keep project on pace.
If project velocity changes dramatically for more than one iteration, re-estimate and re-negotiate the release plan
1/11/2019
CMPUT eXtreme programming

9. CMPUT 402 - eXtreme programming
Release Planning ... more
Planning by time => #iteration x project velocity = # stories completed. (eg. 6 iter x 2.5 stories/iter = 15 stories)
Planning by scope => estimated user stories / project velocity = #iterations until release is ready. (eg. 8 stories/2.5 stories/iter = 3.2 iterations)
Release plan meeting called “Planning Game”
Estimates must not be changed for the user stories because they will be required “as is” during iteration planning meetings
1/11/2019
CMPUT eXtreme programming

10. Philosophy of Release Planning
Philosophy of release planning => a project may be quantified by four variables:
Scope = how much is to be done
Resources = how many people are available
Time = when the project or release will be done
Quality = how good the software will be and how good it will be tested.
Management chooses three out of four variables to dictate; development team dictates remaining variable.
1/11/2019
CMPUT eXtreme programming

11. CMPUT 402 - eXtreme programming
Small Releases
Development team needs to release iterative versions of the system to the customer frequently.
Small frequent releases are critical to getting valuable feedback in time to have an impact on the system’s development.
1/11/2019
CMPUT eXtreme programming

12. Iteration and Iteration Planning
Iterations are 1-3 weeks long.
Plan what will be done at the beginning of each iteration and not before.
By not adding functionality in advance and practicing “just-in-time” planning, it is easy to adapted to changing user requirement.
1/11/2019
CMPUT eXtreme programming

13. CMPUT 402 - eXtreme programming
Moving people around
Avoids serious knowledge and coding bottlenecks
Cross-training is an important consideration in companies to avoid “islands of knowledge” which are susceptible to loss. Instead of one person knowing everything about a specific part of code, everyone knows a lot about many sections of the code. (flexibility of the team increases)
Pair programming exposes all team members to all parts of code without losing thought or productivity.
1/11/2019
CMPUT eXtreme programming

14. Daily Stand-Up Meetings
Communication among the entire team is facilitated (problems/solutions that have simple answers allowed, promoting team focus; standing in circle and discussing in turn)
Long discussions are avoided. One short meeting with everyone (developers), rather than many meetings with only a few developers attending.
In 15 minutes (or less) you can get a sense of the trouble spots, identify who might be able to help, communicate surprises to exploit or prepare for, and make sure you are starting the day right
1/11/2019
CMPUT eXtreme programming

15. CMPUT 402 - eXtreme programming
Design
Yes there is design in XP!
Simplicity
System Metaphor
CRC cards
Spike solution
No fat functionality added early
Refactoring
1/11/2019
CMPUT eXtreme programming

16. Simplicity and the System Metaphor
Simplicity is the key (takes less time to finish)
It is always faster and cheaper to “replace” complex code before wasting time on it.
Never add functionality before it is scheduled.
System Metaphor:
Choose a system metaphor - it keeps the team on the same page by naming classes and methods consistently.
Good for overall design of system and code reuse.
Choose names that are easy to relate to for objects
1/11/2019
CMPUT eXtreme programming

17. CMPUT 402 - eXtreme programming
CRC Cards
Class, Responsibilities, Collaboration (CRC) cards to design system as a team.
Allow entire project teams to help with the design (the more people involved => the greater the number of ideas).
Individual CRC cards used to represent objects.
CRC session => someone simulates system by talking about which objects sends messages to other objects.
Criticisms: lack of written design.
1/11/2019
CMPUT eXtreme programming

18. CMPUT 402 - eXtreme programming
Spike Solution
Create spike solutions to figure out answers to tough technical or design problems.
Spike Solution: very simple program to explore potential solutions.
Build system that only examines specific problem
Goal: Reduce the risk of a technical problem
1/11/2019
CMPUT eXtreme programming

19. No “fat” functionality added early
Keep system clear of functionality you think will be needed later (chances are, you will not need it).
Extra functionality allows process down and squanders resources.
1/11/2019
CMPUT eXtreme programming

20. CMPUT 402 - eXtreme programming
Refactoring
Remove redundancy, eliminates unused functionality and rejuvenates obsolete designs.
Refactoring throughout project lifecycle generally saves time, increases quality and keeps system and code simple.
Let go of notions of “you thought the system should or should not be” and try to see the new design as it emerges before you.
1/11/2019
CMPUT eXtreme programming

21. CMPUT 402 - eXtreme programming
TESTING
Primary emphasis in on...
Unit testing
Acceptance testing
1/11/2019
CMPUT eXtreme programming

22. CMPUT 402 - eXtreme programming
Unit testing
Create a unit test framework to support the creation of automated unit test suites.
Test all classes in the system
Create your tests before writing the code.
Biggest obstacle in spending so much time creating unit tests is fast approaching deadlines; however, this method will end up being more cost efficient and protect against bugs in releases.
Automated unit tests offer a far greater pay back than the apparent cost of creation
1/11/2019
CMPUT eXtreme programming

23. CMPUT 402 - eXtreme programming
Unit testing ... more on
Unit tests enable collective code ownership and refactoring
Ensures all functionality always works
Building a single universal unit test suite for validation and regression testing enables frequent integration.
Creating tests independent of code (before the code), sets up check and balances and greatly improves the chances of getting code correct the first time.
All code must pass all unit tests before it is released (checked in).
1/11/2019
CMPUT eXtreme programming

24. CMPUT 402 - eXtreme programming
Acceptance Testing
Creating Acceptance Tests first before debugging helps the customer define the problem and relate it to programmers
Given a failed acceptance test, developers can create unit tests to show the defect from a source code point of view.
Acceptance Tests are created from user stories selected during the iteration planning meeting
Acceptance Tests are black box system tests where each test represents some expected result of the system
1/11/2019
CMPUT eXtreme programming

25. Acceptance Testing... more
Customers may need or seek assistance in creating acceptance tests (one per user story)
Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which of failed tests are of highest priority
A user story is not complete unless it passes all acceptance tests.
Test scores are published for the team to review
Acceptance tests should be automated for frequent running
1/11/2019
CMPUT eXtreme programming

26. CMPUT 402 - eXtreme programming
CODING
Customer is always available
Coding standards
Code unit test first
Pair programming
Sequential integration
Collective code ownership
Optimization
No overtime
1/11/2019
CMPUT eXtreme programming

27. Customer always available
Customer is available and a part of the development team
On-site, face-to-face communication is key
Customers and designers create user stories and they assign priorities
Small incremental releases for functionality to be released to the customer
Customer is needed for help with functional testing
1/11/2019
CMPUT eXtreme programming

28. CMPUT 402 - eXtreme programming
Coding Standards
Code must be formatted to agreed upon coding standards
Coding standards – keep code easy to write, consistent, readable, and refactorable
1/11/2019
CMPUT eXtreme programming

29. CMPUT 402 - eXtreme programming
Code Unit Tests First
Creating unit tests first helps in creating code with less bugs.
By creating tests first, your design will be influenced by a desire to test everything of value to your customer.
Implement only the feature you want (concise and simple)
1/11/2019
CMPUT eXtreme programming

30. CMPUT 402 - eXtreme programming
Pair Programming
Two people working together at a single computer, release all code in a production (tested) release
Increases software quality without impacting time to deliver
“Two people working at a single computer will add as much functionality as two working separately.” However, the quality of the finished product will be higher (This may seem counter-intuitive).
One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class.
1/11/2019
CMPUT eXtreme programming

31. Sequential Integration
Appoint an integrator, or integration team to manage
Developers work with obsolete versions which are reintegrated into the code base
Strict sequential (or single-threaded) integration by the developers in combination with collective code ownership is recommended
Only one development pair integrates, tests, and releases changes to the source code repository at any given time
Sequential integration allows latest version to be consistently identified
1/11/2019
CMPUT eXtreme programming

32. Collective code ownership
Allows everyone to contribute new ideas to all aspects of the project. Everyone can add code, fix bugs, and refactor
This approach is supported by the creation of unit tests for code as it is developed
Before any code is released, it must pass all unit and functional tests 100%. Then anyone can make changes to any method of any class; => frequent integration.
Collective code ownership is more reliable because if there is a single person in charge, he may leave the project at any time
1/11/2019
CMPUT eXtreme programming

33. Optimization and Fixing XP
Do not optimize system or process until the end
Make system work => make it correct, then make it fast
Fix XP when it breaks:
Follow XP rules to start with
Make minor changes if necessary (discuss; devise ways to improve XP).
1/11/2019
CMPUT eXtreme programming

34. CMPUT 402 - eXtreme programming
No Overtime
Working overtime causes decreased motivation and spirit and usually results in bugs that have to be found and corrected later.
Instead of overtime, use a release planning meeting to change the scope or timing.
Adding people to the project when it is running late is bad idea.
1/11/2019
CMPUT eXtreme programming