Extreme Programming Practices

From Wikipedia, the free encyclopedia

Extreme Programming (XP) is a popular agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme Programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Contents 1 Fine scale feedback 1.1 Pair programming 1.2 Planning game 1.2.1 Release planning 1.2.1.1 Exploration phase 1.2.1.2 Commitment phase 1.2.1.2.1 Sort by value 1.2.1.2.2 Sort by risk 1.2.1.3 Steering phase 1.2.2 Iteration planning 1.2.2.1 Exploration phase 1.2.2.2 Commitment phase 1.2.2.3 Steering phase 1.3 Test driven development 1.4 Whole team 2 Continuous process 2.1 Continuous integration 2.2 Design improvement 2.3 Small releases 3 Shared understanding 3.1 Coding standard 3.2 Collective code ownership 3.3 Simple design 3.4 System metaphor 4 Programmer welfare 4.1 Sustainable pace 5 See also 6 Notes 7 References 8 External links

[edit] Fine scale feedback

[edit] Pair programming

Pair programming means that 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 coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers trade roles regularly.

The pairs are not fixed: it's recommended that programmers try to mix as much as possible, so that everyone knows what everyone is doing, and everybody can become familiar with the whole system. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership).

[edit] Planning game

The main planning process within Extreme Programming is called the planning game. The planning process is divided into two parts:

• Release Planning: This is focused on determining what requirements are included in which release and when it’s going to be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
  • Exploration Phase: In this phase the customer will give all his requirements for the system. These will 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 adjusted, new requirements can be added and/or existing requirements can be changed or removed.

• Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases:
  • Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks 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.

[edit] Release planning

[edit] Exploration phase

This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.

• Get Requirement from Customer: Business has come with a problem; during a meeting, development will try to define this problem and get requirements.
• Write a Story: Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story. The story is written on a user story card.
• Split a Story: Every design critical complextiy has to be addressed before stating the iteration planning. If development isn't able to estimate the story (next item), it needs to be split up and written again. Development can also create spike solutions to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements.
• Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.

When business cannot come up with any more requirements, one proceeds to the commitment phase.

[edit] Commitment phase

This phase involves the determination of costs, benefits, and schedule impact. It has four components:

• Sort by Value: Business sorts the user stories by Business Value.
• Sort by Risk: Development sorts the stories by risk.
• Set Velocity: Development determines at what speed they can perform the project.
• Choose scope: The user stories that will be finished in the next release will be picked. Based on the user stories the release date is determined.

[edit] Sort by value

The business side sorts the user stories by business value. They will arrange them into three piles:

• Critical: stories without which the system cannot function or has no meaning.
• Significant Business Value: Non-critical user stories that have significant business value.
• Nice to have: User stories that do not have significant business value; an example can be an improvement in usability or presentation.

[edit] Sort by risk

The developers sort the user stories by risk. They also categorize into three piles: low, medium and high risk user stories. The following is an example of an approach to this:

• Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
  • Completeness (do we know all of the story details?)
    • Complete (0)
    • Incomplete (1)
    • Unknown (2)
  • Volatility (is it likely to change?)
    • low (0)
    • medium (1)
    • high (2)
  • Complexity (how hard is it to build?)
    • simple (0)
    • standard (1)
    • complex (2)

All indexes for a user story are added, assigning the user stories a risk index of low (0–1), medium (2–4), or high (5–6).

[edit] Steering phase

Within the steering phase the programmers and business people can "steer" the process. That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong. This is the chance to adjust the plan accordingly.

[edit] Iteration planning

[edit] Exploration phase

The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.

• Gather User Stories: Gather and write all user stories for the next release
• Combine/Split task: If the programmer cannot estimate the task because it is too big or too small, the programmer will need to combine or split the task.
• Estimate task: Estimate the time it will take to implement the task.

[edit] Commitment phase

Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.

• A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
• Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
• Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
• Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.

[edit] Steering phase

The implementation of the tasks is done during the steering phase of the iteration planning.

• Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
• Find a Partner: The programmer will implement this task along with another programmer. This is further discussed in the practice Pair Programming.
• Design the task: If needed, the programmers will design the functionality of the task.
• Write unit test: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.
• Write code: The programmers start to code.
• Run test: The unit tests are run to test the code.
• Refactor: Remove any code smells from the code.
• Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.

[edit] Test driven development

Unit tests are automated tests that test the functionality of pieces of the code (e.g. classes, methods). Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further condition on which the code may fail.

[edit] Whole team

Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be at hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.

[edit] Continuous process

[edit] Continuous integration

The development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.

[edit] Design improvement

Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck. One of the symptoms of this is the need for dual (or multiple) maintenance: functional changes start requiring changes to multiple copies of the same (or similar) code. Another symptom is that changes in one part of the code affect lots of other parts. XP doctrine says that when this occurs, the system is telling you to refactor your code by changing the architecture, making it simpler and more generic.

[edit] Small releases

The delivery of the software is done in predetermined releases (sometimes called 'Builds'). The release plan is determined when initiating the project. Usually each release will carry a small segment of the total software, which can run without depending on components that will be built in the future. The small releases provides the customer to gain confidence over the progress of the project.

[edit] Shared understanding

[edit] Coding standard

Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard will specify a consistent style and format for source code, within the chosen programming language. The coding standard may be a standard conventions specified by the language vendor (e.g The Code Conventions for the Java Programming Language, recommended by Sun), or custom defined by the development team.

[edit] Collective code ownership

Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

[edit] Simple design

Programmers should take a "simple is best" approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler.

[edit] System metaphor

System Metaphor is 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 may 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.

[edit] Programmer welfare

[edit] Sustainable pace

The concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime. Since the development cycles are short cycles of continuous integration, and full development (release) cycles are more frequent, the projects in XP do not follow the typical crunch time that other projects require (requiring overtime).

Also, included in this concept is that people perform best and most creatively if they are rested.

[edit] See also

• Extreme Programming

[edit] Notes

[edit] References

[edit] External links

SCRUM - http://www.controlchaos.com/

XP Practices - http://www.extremeprogramming.org/index.html

Kent Beck XP Practices - http://ootips.org/xp.html

Ron Jeffries XP Practices - http://www.xprogramming.com/xpmag/whatisxp.htm