Extreme programming practices: Difference between revisions

Content deleted Content added
Uncapitalized "extreme programming" where not used in a title (WP:MOSCAPS); punctuation to before <ref>s
Line 1:
'''[[Extreme Programmingprogramming]]''' (XP) is a popular [[agile software development]] methodology used to implement [[software]] projects. This article details the practices used in this methodology. Extreme Programmingprogramming has 12 practices, grouped into four areas, derived from the [[best practices]] of [[software engineering]].<ref name="XPExplained">Beck, K. <u>''Extreme Programming Explained: Embrace Change</u>'' 2nd. ed. Addison-Wesley, 2000 pp. 54</ref>
 
==Fine scale feedback==
Line 6:
 
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).
=== Planning game ===<!-- This section is linked from [[Extreme Programmingprogramming]] -->
The main planning process within Extremeextreme Programmingprogramming 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:
 
*Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
Line 115:
[[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 condition on which the code may fail.
 
=== Whole team ===<!-- This section is linked from [[Extreme Programmingprogramming]] -->
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.
 
Line 148:
Also, included in this concept is that people perform best and most creatively if they are 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
The intense collaborative way of working within the team drives
a need to recharge over weekends.
 
Line 155 ⟶ 154:
 
== See also ==
* [[Extreme Programmingprogramming]]
* [[Continuous integration]]
* [[Multi-stage continuous integration]]