1. XP – Extreme Programming

2. XP in general
XP is an agile discipline of software develop-ment. It emphasis high customer satisfaction and customer involvement. When working with XP everybody works as a hole team, but the customers and the manager as well. XP aims at short iterations, and to provide working code, at the end of each iteration.

3. XP Values
Communication (communication among team members and between the team and the customer must be maximized).
Simplicity (do the simplest thing that could possibly work). Simplicity favors communication, reduces the amount of code and improves the quality.
Feedback
Courage (communication, simplicity and feedback allow to tackle with courage even big changes in requirements……)
Respect (if members of a team don’t care about each other and their work, no methodology can work).

4. Extreme Programming Practices
Fine scale feedback
- Pair Programming
- Planning game
- Test Driven development
- Whole team
Continous process
- Continuous integration
- design involvement
- small releases

5. Shared understanding
- coding standard
- collective code ownweship
- Simple design
- System Metaphor
Programmer welfare
- Sustainable Pace

6. Coding standard
An agreed upon set of rules that the entire development team agree to adhere to throughout the project
A consistent style and format for source code

7. Collective code ownership
Everybody is responsible for all the code
Every programmer has the right to change the code

8. Continous Integration
The development team should always be working on the latest version of the software
Upload current version to the code repository every few hours

9. Design improvement Implement as simple as possible
Refactor the code when needed
- refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior.

10. Simple design a shared understanding practice
Programmers should take a ”simple is best” approach to software design

11. Small Releases a continous rocess practice
The delivery of the software is done in predetermined releases (sometimes called ”Builds”)
Ther small releases provides the customer to gain confidence over the progress of the project.

12. Sustainable Pace a programmer welfare practice
Programmers or software developers should not work more than 40 hours weeks.
People perform best and most creatively if they are rested.

13. System Methaphor
A naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system mat create loan_records(class) for borrowers (class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue (class). For each class or operation the functionality is transparent to the entire team

14. Pair Programming a fine scale feedback practice
All code is produced by two people programming on one task on one workstation.
One programmer has control over the workstation and is thinking mostly about the code in detail.
The other programmer is more focused on the big picture, ans is continually reviewing the code that is being produced by the first programmer.
Programmers trade roles regularly

15. Planning game a fine scale feedback practice
Release Planning
- focused on determining whar requirements are included in which
release and when it’s going to be delivered.
- the customers and developers are both part of this.
Iteration planning
- plans the activities and task of the developers. In this process the customer is not involved.

16. Planning game Release planning
3 phases:
- Exploration Phase: in this phase the custo- mer will give all his requirements for the system. These bwill be written down on user story cards-
- Commitment phase: within the commitment phase business and development will commit themselves to the functionality that will be included and the date of the next release.
- Steering Phase: in the steering phase the plan can be ajusted, new requirements can be added and or existing requirements can be changed or removed.

17. Planning game Iteration planning
3 phases:
Exploration phase: within this phase the requirement will be translated to different tasks. The task are recorded on task cards.
Commitment phase: the tasks will be assigned to the programmers and the time it takes to complete will be estimated.
Steering phase: the tasks are performed and the end result is matched with the original user story.

18. Test driven development a fine scale feedback practice
Unit test are written before the eventual code is coded.
Intended to stimulate the programmer to think about conditions in which his or her code could fail

19. Whole team a fine scale feedback practice
The ”customer” is not the one who pays the bill, but one who will really uses the system
The customer should be at hand at all times and available for questions.