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

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming

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 402 - eXtreme programming