Extreme programming practices: Difference between revisions

Revision as of 13:41, 12 May 2015

Revision as of 05:55, 20 May 2015

Line 21:

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

Line 30:

|publisher=IEEE

|doi=10.1109/EURMIC.2004.1333388

}}</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>.

==== Release planning ====

Line 86:

==== Iteration planning ====

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

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

Line 105 ⟶ 106:

===== Steering phase =====

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

* Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.

Line 159 ⟶ 160:

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

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

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.