Extreme programming practices: Difference between revisions

Revision as of 10:58, 17 September 2019

Latest revision as of 17:04, 19 June 2025

(24 intermediate revisions by 17 users not shown)

Line 1:

{{Short description|Software development methodology}}

'''[[Extreme programming]]''' ('''XP''') is an [[agile software development]] methodology used to implement [[software]] projectssystems. 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==

=== 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]] meansis a method of programming thatin allwhich code is produced by two people programming on one tasktogether on one workstationtask. 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; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains 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).

Line 23 ⟶ 25:

|first1=Grigori|last1=Melnik

|first2=Frank|last2=Maurer

|title=Proceedings. 30th Euromicro Conference, 2004

|titlechapter=Introducing Agile Methods: Three Years of Experience

|series=Proceedings of the 30th Euromicro Conference

|pages=334–341

Line 29 ⟶ 32:

|publisher=IEEE

|doi=10.1109/EURMIC.2004.1333388

|isbn=0-7695-2199-1

|citeseerx=10.1.1.296.4732

}}</ref> The Planning Game approach hasis alsoused beenin adopteddevelopment byframeworks beyond just non-software projectssystems. andFor 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'' ====

Line 50 ⟶ 54:

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

Line 84 ⟶ 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.

Line 109 ⟶ 113:

* 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 [[Testtest-driven development]] (TDD) (see below)

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

=== Test driven development ===

Line 125 ⟶ 129:

* [[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==

Line 136 ⟶ 140:

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

Line 144 ⟶ 148:

=== 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 specifies 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 | ___location =| 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 (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 webbook|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.

Collective code ownership may accelerate development because a developer who spots an error can fix it immediately, which can reduce bugs overall. However, programmers may also introduce bugs when changing code that they do not understand well. Sufficiently well-defined unit tests should mitigate this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

Line 174 ⟶ 179:

== See also ==

* [[Extreme programming]]

* [[Continuous integration]]

* [[Multi-stage continuous integration]]

Line 181 ⟶ 185:

== References ==

{{reflist}}

{{RefimproveMore citations needed|date=December 2008}}

== External links ==