# Xtreme Programming (XP)

## what is it?

* methodology for teams that face of vague or rapidly changing requirements.
* only do what you need to do to create value for the customer.
* A way to: Stay aware. Adapt. Change.
* To help in improving the ability to cope with change
* Distinguished by
  * short development cycles.
  * incremental planning approach.
  * ability to be flexible when the business needs change.
  * reliance on automated tests.
  * reliance on oral communication.
  * reliance on an evolutionary design process.
  * reliance on the close collaboration.
  * reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project.

### Values of XP

* Communication
  * problems within a tema can be caused by lack of Communication.
    * this should be the first place to look at when problems occurs
  * How can your team now communicate in order to solve the problem and ensure that the same issue doesn't arise?
  * helps your team to bond and is a key component to effective cooperation
* Simplicity
  * Focus on working on the simplest thing that could possibly work
  * Eliminate unnecessary complexity
* Feedback
  * Shorten the feedback cycle as best as you can.
  * Too much feedback is counter productive
    * look to find the sweet point
  * Range of forms
    * Getting opinions from colleagues, books, internet
    * Evaluating code produced by yourself, others
    * How did testing feel
    * Did the code pass the tests
    * Does the code work
* Courage
  * Effective action in the face of fear.
  * Courage may manifest itself
    * in a bias to action
    * to be patient to wait for a problem to reveal itself when you feel one approaching
    * to wait for a problem to reveal itself when you feel one approaching
    * to change a course of action can lend itself to finding simpler solutions.
* Respect
  * contributions of each person on a team has to be respected
  * Needed for XP to work

### Principles

* Principles guide behaviour
* Principles give you a better idea of what a practice is intended to accomplish
* Main principles
  * Humanity
    * Creating software
      * should meet human needs, maslov
      * acknowledge human fallibility
      * leverage human strength
  * Economics
    * everything you do has business value and serves business needs
    * Think about the 'time value of money' and the 'option value of systems and teams'
    * What you're building is more valuable the more it earns money sooner and spends money later
    * How flexible is your software for being used beyondoriginally intended purpose
    * balance enhancing the option value of the software and the team whilst not wasting money investing in speculative flexibility
  * Mutual benefits
    * Every activity should benefit all concerned
  * Self-Similarity
    * Try copying the structure of one solution into a new context, even at different scales
  * Improvement
    * Aim for excellence through constant improvement
  * Diversity
    * need to bring together a variety of skills, attitudes, and perspectives
  * Reflection
    * to expose mistakes and learn from them
    * How is your team working and why are they doing what they are doing?
    * Why did you suceed?
    * Why did you fail?
  * Flow
    * delivering a steady flow of valuable software by engaging in all activities of development simultaneously
  * Opportunity
    * View problems as opportunities to learn, improve, and change
  * Redundancy
    * Keep redundancy where it serves a valid purpose, that is, uncovering defects. You may have many practices that catch the same defects, but the defect problem in general cannot be solved with a single practice
    * Defects corrode trust and trust is the great waste eliminator
  * Failure
    * use it to learn from
    * When you don't know what approach to take, risking failure can be the shortest route to success.
  * Quality
    * Sacrificing quality is not an effective means of control. Aiming for higher quality often results in faster delivery; lowering quality standards results in less predictably delivery later on
  * Baby Steps
    * What's the least you could do that is recognizably in the right direction?
    * ou want to avoid 'wastefully \[recoiling] from aborted big changes'.
  * Accepted Responsibility
    * With responsibility comes authority.

### Practices

* Practices need to be underpinned by values, otherwise they become rote.
* Practices are also situation dependent.

## Primary Practices

### Sit together

* sit with client
* allow to communicate fully
* physical proximity enhances communication
* open spaces helps with ease of communication

### Whole team

* The team needs the skills and perspectives necessary for the project to succeed
* cross functional
* People need a sense of team
  * belonging, shared purpose, support
* The team is dynamic, should change members depending on needs

### Informative workspace

* Make workspace about your work

### Energized Work

* Only work for as long as you can be productive
* prepared, rested, relaxed mind.

### Pair Programming

* PingPong
* Roles
  * Navigator and driver
  * Experienced or junior dev
  * Experienced or junior domain wise
  * These can be any combination. Need to adjust depending on what you are.
* It's a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.
  * Keep each other on task.
  * Brainstorm refinements to the system.
  * Clarify ideas.
  * Take initiative when their partner is stuck, thus lowering frustration.
  * Hold each other accountable to the team's practices.
* Rotate pairs can be a good idea,
* tiring but satisfying.
* Pairing and personal space
  * Different individuals and cultures are comfortable with different amounts of body space.
  * Personal hygiene and health are important issues when pairing.
  * Ideally, emotions at work will be about work.
  * It is important to respect individual differences when pairing.
  * If you aren't comfortable, the team isn't doing as well as it could.

### Stories

* Write stories around the framework of customer-visible functionality
* As soon as a story is written, try to estimate the development effort necessary to implement it.

### Weekly Cycle

* Plan work a week at a time
* Have a meeting at the beginning of the week where you review progress to date and have your client prioritise a week's worth of stories

### Slack

* Always leave room for tasks to be dropped if you get behind
* You can also structure slack, e.g. hack days

### Ten-Minute Builds

### Continuous Integration

* Integrate and test changes after no more than a couple of hours

### TDD

* It addresses many problems.
  * Scope creep: if you really want to put that other code in, write another test after you've made this one work.
  * Coupling and cohesion: if it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
  * Trust: writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
  * Rhythm: it's clearer what to do next: either write another test or make the broken test work. Code, refactor, test, code, refactor.

### Incremental Design

* Make the design of the system an excellent fit for the needs of the system that day
* design done close to when it is used is more efficient.

## Corollory Practices

* Primary practices should be done first before attempting this.

### Real customer involvement

* Make people whose lives/businesses are affected by your system be part of the team
* Aim to reduce wasted effort
* Increase trust with customer -> increased productivity

### Incremental deployment

* Big deployments have a high risk and high human and economic costs.
* Find a little piece of functionality or a limited data set you can handle right away. Deploy it.
* Legacy: Implementing scaffolding between the two systems is the price you pay for insurance against big changes going wrong

### Team Continuity

* Keep effective teams together
* Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy

### Shrinking teams

* As a team grows in capability, keep its workload constant, but gradually reduce the number of team members
  * Strive to improve efficiency until some of the team members are idle — shrink the team and continue
* This frees people to form more teams.
* When the team has too few members, merge it with another too-small team.

### Root-cause analysis

* When a defect is found or a mistake occurs, eliminate its cause such that the team will never make the same mistake again
* Write an automated system-level test and unit test that demonstrates the defect, including the desired behaviour
* Fix the system so the unit test works. This should cause the system test to pass also. If not, return to the previous point.
* Once the defect is resolved, figure out why the defect was created and wasn't caught. Initiate the necessary changes to prevent this kind of defect in the future.
* Use the technique of the 'Five Whys'
* The root cause is almost always a people problem

### Shared Code

* Anyone on the team can improve any part of the system at any time
* Until the team has developed a sense of collective responsibility, no one is responsible and quality will deteriorate.
* People will make changes without regard for the team-wide consequences.
* pair programming and continuous integration are interesting to try to avoid selfish conducts.

### Code and tests

* Maintain only the code and the tests as permanent artifacts.
* Generate other documents from the code and tests
* Rely on social mechanisms to keep alive important history of the project.
* The valuable decisions in software development are:
  * What are we going to do?
  * What aren't we going to do?
  * How are we going to do what we do?

### Single Code Base

* Temporary branches should be short lived
* Multiple code streams are a huge source of waste
* Rather than add more code bases, fix the underlying design problem that is preventing you from running from a single code base.

### Daily Deployment

* Put new software into production every night
* If you are out of sync with what is in production you risk making decisions without accurate feedback. It is a risk
* Prereqs for this:
  * Defect rate is down to a handful per year
  * Build environment is smoothly automated
  * Deployment tools are automated
  * Ability to roll out incrementally and roll back in case of failure
  * Highly developed trust within the team and with customers

### Negotiated Scope Contract

* Write contracts that fix time, costs, and quality, but call of an ongoing negotiation of precise scope of the system
* Sign a series of short contracts instead of one long one
* Negotiated scope contracts are a mechanism for aligning the interests of suppliers and customers to encourage communication and feedback

### Pay-per-use

* Money is the ultimate feedback.
* Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.
* If you can't implement pay-per-use, you might be able to go to a subscription model. Then the team can focus on retention rates
* Pay-per-release isn't a good option: the supplier is motivated to keep shipping releases with new functionality, whilst the customer wants fewer releases with more functionality, in order to avoid the pain of upgrades

## The whole XP team

* The roles and responsibilities of different team members
  * Members can have multiple roles
* The goal is to have everyone contribute the best he has to offer to the team's success
* Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.
* Roles:
  * Testers
    * catching trivial mistakes is accepted by the programmers
    * Test-first programming results in a suite of tests that help keep the project stable.
    * help defining and specifying what will constitute acceptable functioning of the system before the functionality has been implemented.
    * coach programmers on testing techniques
    * Testers amplify communication by looking at 'happy paths' and asking about scenarios where things go wrong
  * Interaction designers
    * choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories.
  * Architects
    * look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories.
    * help choose the most appropriate fracture lines and then follow the system as a whole
    * keep the big picture in mind as the groups focus on their smaller section.
  * Project managers
    * facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organization.
    * keeping plans synchronized with reality.
    * facilitate communication within the team, increasing cohesiveness and confidence.
  * Product managers
    * help the team decide priorities by analyzing the differences between actual and assumed requirements
    * adapt the story and theme to what is really happening now.
    * Stories should be sequenced for business, not technical, reasons.
    * goal is a working system from the first week.
    * encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team.
  * Executives
    * provide an XP team with courage, confidence, and accountability.
    * articulate and maintain large-scale goals.
    * look for good software coming from the team and continuing improvement as well
    * free to ask for explanations about any aspect that dont makes sense.
    * Two metrics to measure the health of XP teams
      * Number of defects found after development. Each is an opportunity for the team to learn and improve.
      * The time lag between the beginning of investment in an idea and when the idea first generates revenue
  * Technical writers
    * provide early feedback about features and to create closer relationships with users
    * create closer relationships with users.
    * help them learn about the product, listening to their feedback, and addressing confusion with further publications or new stories.
  * Users
    * help write and pick stories and make domain decisions during development.
    * have a good relationships with a large potential user community
    * have knowledge and experience with systems similar to the one being built
  * Programmers
    * estimate stories and tasks, break stories into tasks, write tests, write code to implement features, automate tedious development process, and gradually improve the design of the system.
    * Have good social and relationship skills
  * Human resources
    * reviews
    * Hirings
    * XP teams put much more emphasis on teamwork and social skills.
    * best interviewing technique is to have the candidate work with the team for a day
    * Pair programming provides an excellent test of technical and social skills.

## The theory of Constraints

* The Theory of Constraints says that in any system there is one constraint at a time
* To improve throughput in a system you need to first identify the constraint
  * then think about how you can increase its capacity,
  * offload some of the work to non-constraints,
  * or eliminate the constraint altogether.
* How do I identify a constraint? Work piles up in front of one
* when you eliminate one constraint you create another
* avoid micro-optimization and look at the whole situation before starting to make changes.
* Software development is a human process not a factory.

## Planning: managing scope

* starts with putting the current goals, assumptions, and facts on the table
  * With current, explicit information, you can work toward agreement about what's in scope, what's out of scope, and what to do next.
* Planning is complicated because the estimates of the cost and value of stories are uncertain.
* There is a limit to how much work can be done in a day
  * More time at the desk does not equal increased productivity for creative work.
* Planning also involves deciding what to do next out of all of the possibilities. Plans are not predictions of the future. Rather, they provide you with a starting point and help you to coordinate with other teams.
* Everyone on the team should be involved in planning.
* Be prepared for the plan not to match reality.

## Testing: early, often, and automated

* Defects destroy the trust required for effective software development.
  * Without trust, people spend much of their time defending themselves against the possibility that someone else may have made a mistake.
* Defects are expensive when they occur
  * The direct costs of fixing the defects.
  * The indirect costs because of damaged relationships, lost business, and lost development time
* Acceptable level is to reduce the occurrence of defects to an economically sustainable level.
  * eliminating software defects is also expensive.
  * There will always be defects. The key is to learn from them so there are no repeats.
  * The sooner you find a defect, the cheaper it is to fix it.
* Software testing is double-checking
* Beta testing is a symptom of weak testing practices and poor communication with customers.
* Tests provide a measure of confidence and a measure of progress.

## Designing: the value of time

* If you can generate value without feedback, designing sooner makes more sense
* If experience creates most of the value, designing just enough today to get going and then designing mostly in the light of experience makes more sense.
* Design is deferred until it can be made in the light of experience and the decisions can be used immediately
  * Deploy software sooner.
  * Make decisions with certainty.
  * Avoid living with bad decisions.
  * Maintain the pace of development as the original design assumptions are superseded.
* Design always
* Once and Only Once: DRY
* Simplicity
  * Is it appropriate for the intended audience? The people who need to work with it have to understand it.
  * Is it communicative? Every idea that needs to be communicated should be represented in the system.
  * Is it factored? Duplication of logic and structure make code hard to understand and change.
  * Is it minimal? The system should have the fewest elements possible.

## User stories

## Iteration planning

## Spiking

## Coding standards

## Collective ownerships

* All commits have both pairs name on it
* Any issue with this code, either one of the pair is responsibile for any issues

## Bugs

* New tests are writing for this
  * to expose the bug (red)
  * make sure bug is fixed (green)

## Practises

https://basusourav.wordpress.com/2015/05/18/12-core-practices-of-xp/

## links

* https://en.wikipedia.org/wiki/Extreme\_programming
* http://www.extremeprogramming.org/
* https://martinfowler.com/bliki/ExtremeProgramming.html
* https://ronjeffries.com/xprog/what-is-extreme-programming/
* http://www.extremeprogramming.org/rules.html
* https://www.tutorialspoint.com/extreme\_programming/extreme\_programming\_introduction.htm
* https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/
