Extreme programming practices: Difference between revisions

Revision as of 08:31, 26 June 2007

Latest revision as of 17:04, 19 June 2025

(162 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Software development methodology}}

'''[[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]].

'''[[Extreme programming]]''' ('''XP''') is an [[agile software development]] methodology used to implement [[software]] systems. 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]].<ref name="XPExplained">Beck, K. ''Extreme Programming Explained: Embrace Change'' 2nd. ed. Addison-Wesley, 2000 pp. 54</ref>

==Fine-scale feedback==

==Fine scale feedback==

=== Pair programming ===

{{Confusing|date=June 2023|reason=the first sentence of the following paragraph seems to be an incomplete sentence. Where is the verb phrase?}}

[[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.

[[Pair programming]] is a method of programming in which code is produced by two people programming together on one task. 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 after minute to hour periods.

The pairs are not fixed: it's recommended that; programmers try to mix as muchswitch aspartners possiblefrequently, so that everyone knows what everyone is doing, and everybody can becomeremains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership).

=== Planning game ===<!-- This section is linked from [[Extreme Programming]] -->

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

=== Planning game ===<!-- This section is linked from [[Extreme programming]] -->

*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:

The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:

**Exploration Phase: In this phase the customer will give all his requirements for the system. These will be written down on [[user story|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''Release Planning'': This plansis focused on determining what requirements are included in which thenear-term activitiesreleases, and taskswhen ofthey theshould developersbe delivered. InThe thiscustomers processand thedevelopers customerare isboth notpart involvedof this. IterationRelease Planning also consists of three phases:

**Exploration Phase: In this phase the customer will provide a shortlist of high-value requirements for the system. These will be written down on [[user story]] cards.

**Commitment Phase: Within the commitment phase business and developers 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]].

The purpose of the Planning Game is to guide the product into delivery. Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery using a straightforward approach.<ref>{{cite conference

|first1=Grigori|last1=Melnik

|first2=Frank|last2=Maurer

|title=Proceedings. 30th Euromicro Conference, 2004

|chapter=Introducing Agile Methods: Three Years of Experience

|series=Proceedings of the 30th Euromicro Conference

|pages=334–341

|year=2004

|publisher=IEEE

|doi=10.1109/EURMIC.2004.1333388

|isbn=0-7695-2199-1

|citeseerx=10.1.1.296.4732

}}</ref> The Planning Game approach is used in development frameworks beyond just software systems. For example, it is used by teams in the context of [[business agility]].<ref>Leybourn, E. (2013). Directing the Agile Organisation: A Lean Approach to Business Management. London: IT Governance Publishing: 146–150.</ref>

==== ''Release planning'' ====

==== Release planning ====

===== Exploration phase =====

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

*GetWrite Requirement froma CustomerStory: Business has come with a problem; during a meeting, development will try to define this problem and get requirements. Based on the business problem, a story ([[user 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.

*Estimate a Story: Development estimates how long it will take to implement the work implied by the story card. 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.

*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|user story card]].

*Split a Story: Every design critical complexity has to be addressed before statingstarting 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.

Line 35 ⟶ 52:

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

*Sort by Value: Business sorts the [[user story|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.

====== Sort by value ======

The business side sorts the [[user story|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.

====== Sort by risk ======

The developers sort the [[user story|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)

Line 71 ⟶ 88:

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.

==== ''Iteration planningPlanning'' ====

Considering team velocity storypoints to be planned. Iteration duration can be 1 to 3 weeks.

===== Exploration phase =====

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

*Translate the requirement to tasks: Place on task cards.

*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 bigsmall or too smallbig, the programmer will need to combine or split the task.

*Estimate task: Estimate the time it will take to implement the task.

Line 87 ⟶ 106:

*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.

===== 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 Partnerpartner: The programmer will implement this task along with another programmer. This is further discussed in the practice of [[Pairpair Programmingprogramming]].

* Design the task: If needed, the programmers will design the functionality of the task.

* Implement the task using [[test-driven development]] (TDD) (see below)

* Write [[unit test]]: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.

* Run functional test: Functional tests (based on the requirements in the associated user story and task card) are run.

* 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.

=== Test driven development ===

[[Unit testing|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 conditionconditions onunder which the code may fail.

Test driven development proceeds by quickly cycling through the following steps, with each step taking minutes at most, preferably much less. Since each user story will usually require one to two days of work, a very large number of such cycles will be necessary per story.

=== 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 on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.

* Write [[unit test]]: The programmers write a minimal test that should fail because the functionality hasn't been fully implemented in the production code.

* Watch the new test fail: The programmers verify the test does indeed fail. While it may seem like a waste of time, this step is critical because it verifies that your belief about the state of the production code is correct. If the test does not fail, the programmers should determine whether there is a bug in the test code, or that the production code does support the functionality described by the new test.

* Write code: The programmers write just enough production code so the new test will pass.

* Run test: The unit tests are executed to verify that the new production code passes the new test, and that no other tests are failing.

* [[Code refactoring|Refactor]]: Remove any [[code smells]] from both the production and test code.

For a more intense version of the above process, see Uncle Bob's Three Rules of TDD.<ref>{{cite web|last1=Martin|first1=Robert|title=Three Rules of TDD|url=http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd}}</ref>

=== Whole team ===<!-- This section is linked from [[Extreme programming]] -->

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 on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator. All the skills necessary to deliver the software product should be present on the team.

==Continuous process==

=== 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.

=== 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 ofmany other parts. XP doctrine says that when this occurs, the system is telling you to [[refactoring|refactor]] your code by changing the architecture, making it simpler and more generic.

=== Small releases ===

The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project. This helps maintain the concept of the whole team as the customer can now come up with his suggestions on the project based on real experience.

{{Expand-section|date=January 2007}}

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.

==Shared understanding==

=== Coding standard ===

[[Coding conventions|Coding standard]] is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard will specifyspecifies a consistent style and format for source code, within the chosen programming language, as well as various programming constructs and patterns that should be avoided in order to reduce the probability of defects.<ref>{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=75| isbn = 978-0-470-04212-0 }}</ref> 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.

Extreme Programming backers advocate code that is [[self-documenting]] to the furthest degree possible. This reduces the need for [[Comment (computer programming)|code comments]], which can get out of sync with the code itself.<ref>{{Cite web |url=http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt |title=XP-eXtreme Programming | format=PPT| access-date=2015-01-31 |archive-date=2021-12-17 |archive-url=https://web.archive.org/web/20211217175200/http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt |url-status=dead }}</ref>

=== Collective code ownership ===

{{main|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.

Collective code ownership (also known as "team [[code ownership]]" and "shared code") means that everyone is responsible for all the code; therefore, everybody is allowed to change any part of the code. Collective code ownership is not only an organizational policy but also a feeling. "Developers feel team code ownership more when they understand the system context, have contributed to the code in question, perceive code quality as high, believe the product will satisfy the user needs, and perceive high team cohesion."<ref>{{cite book|last1=Sedano|first1=Todd|last2=Ralph|first2=Paul|last3=Péraire|first3=Cécile|title=Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering|chapter=Practice and Perception of Team Code Ownership|year=2016|pages=1–6|chapter-url=http://dl.acm.org/citation.cfm?doid=2915970.2916002|publisher=ACM|doi=10.1145/2915970.2916002|isbn=9781450336918|s2cid=10016345}}</ref> Pair programming, especially overlapping pair rotation, contributes to this practice: by working in different pairs, programmers better understand the system context and contribute to more areas of the code base.

ByCollective givingcode everyownership programmermay theaccelerate rightdevelopment tobecause changea thedeveloper code,who therespots isan riskerror ofcan errorsfix beingit introducedimmediately, bywhich can reduce bugs overall. However, programmers whomay thinkalso theyintroduce knowbugs whatwhen theychanging arecode doing,that butthey do not foreseeunderstand certain dependencieswell. Sufficiently well -defined unit tests addressshould mitigate this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

Collective code ownership may lead to better member backup, greater distribution of knowledge and learning, shared responsibility of the code, greater code quality, and reduced rework. But it may as well lead to increased member conflict, increase of bugs, changes of developers mental flow and breaks of their reasoning, increased development time, or less understanding of the code.<ref>Ribeiro, Danilo & Silva, Fabio & Valença, Diana & Freitas, Elyda & França, César. (2016). Advantages and Disadvantages of using Shared code from the Developers Perspective: A qualitative study.</ref>

=== 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.

=== System metaphor ===

[[SystemThe Metaphor]]system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's 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 <code>loan_records(class)</code> for <code>borrowers(class)</code>, and if the item were to become overdue it may perform a make_overdue operation on a <code>catalogue (class)</code>. For each class or operation the functionality is transparentobvious to the entire team.

==Programmer welfare==

=== 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 well rested.

{{Expand-section|date=January 2007}}

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).

A key enabler to achieve sustainable pace is frequent code-merge and always executable & test covered high quality code. The constant refactoring way of working enforces team members with fresh and alert minds. The intense collaborative way of working within the team drives

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

a need to recharge over weekends.

Well-tested, continuously integrated, frequently deployed code and environments also minimize the frequency of unexpected production problems and outages, and the associated after-hours nights and weekends work that is required.

== See also ==

* [[Continuous integration]]

* [[Multi-stage continuous integration]]

* [[Extreme Programming]]

* [[Class-responsibility-collaboration card]]

== Notes ==

{{Expand-section|date=January 2007}}

== References ==

{{reflist}}

{{Expand-sectionMore citations needed|date=JanuaryDecember 20072008}}

== External links ==

SCRUM - *[http://www.controlchaosextremeprogramming.comorg/ XP Practices]

*[http://ootips.org/xp.html Kent Beck XP Practices]

*[https://web.archive.org/web/20061215120657/http://www.xprogramming.com/xpmag/whatisxp.htm Ron Jeffries XP Practices]

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

{{Expand-section|date=January 2007}}

{{DEFAULTSORT:Extreme Programming Practices}}

[[Category:Software development process]]

[[Category:Extreme Programmingprogramming]]