Content deleted Content added
BurkHufnagel (talk | contribs) |
Adding local short description: "Software development methodology", overriding Wikidata description "agile software development methodology" |
||
| (37 intermediate revisions by 28 users not shown) | |||
Line 1:
{{Short description|Software development methodology}}
'''[[Extreme programming]]''' ('''XP''') is an [[agile software development]] methodology used to implement [[software]]
==Fine
=== 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]]
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
|
|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
}}</ref> The Planning Game approach has also been adopted by non-software projects and 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>▼
|citeseerx=10.1.1.296.4732
▲}}</ref> The Planning Game approach
==== ''Release planning'' ====
Line 49 ⟶ 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
*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 83 ⟶ 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
Considering team velocity storypoints to be planned. Iteration duration can be 1 to 3 weeks.
Line 108 ⟶ 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
* Design the task: If needed, the programmers will design the functionality of the task.
* Implement the task using [[
* Run
=== Test driven development ===
Line 119 ⟶ 124:
* 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
* 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
=== 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 135 ⟶ 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
=== Small releases ===
Line 143 ⟶ 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
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
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.
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
=== System metaphor ===
Line 163 ⟶ 171:
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.
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
Line 171 ⟶ 179:
== See also ==
* [[Continuous integration]]
* [[Multi-stage continuous integration]]
Line 178 ⟶ 185:
== References ==
{{reflist}}
{{
== External links ==
*[http://www.extremeprogramming.org/ 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]
{{DEFAULTSORT:Extreme Programming Practices}}
| |||