| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" |
| name="what_is_xp,9.251272550276345E-306" guid="-nO38_JQ9G3FQvNlAT5Agqg" changeDate="2006-11-08T18:33:57.947-0500" |
| version="1.0.0"> |
| <mainDescription><a id="XE_xp__what_is_it" name="XE_xp__what_is_it"></a><a id="XE_what_is__xp" name="XE_what_is__xp"></a> 
 |
| <p>
 |
| Kent Beck, author of <i>Extreme Programming Explained</i> [<a class="elementLinkWithUserText" href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references.html#BEC00" guid="6.191633934532389E-306">BEC00</a>], says, "XP is a light-weight methodology for small-to-medium-sized teams
 |
| developing software in the face of vague or rapidly changing requirements." Simply stated, XP is a set of <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values.html" guid="1.076140803519123E-306">values</a>, <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_rights.html" guid="3.036332011267074E-306">rights,</a>
 |
| and best <a class="elementLinkWithUserText" href="./../../../xp/customcategories/xp_best_practices.html" guid="4.315031901943112E-306">practices</a> that support each other in incrementally developing software.
 |
| </p>
 |
| <p>
 |
| When a team is developing software with XP, the customer creates stories that describe the functionality of the
 |
| software. These stories are very lightweight use-cases. They are small units of functionality that require less than
 |
| one or two weeks to implement. Programmers estimate the stories, and, based upon those estimates, the customer decides
 |
| which stories to do first.
 |
| </p>
 |
| <p>
 |
| Development is done iteratively and incrementally. Every two weeks, the programming team delivers working stories to
 |
| the customer. Then the customer chooses another two weeks worth of work. The system grows in functionality, piece by
 |
| piece, steered by the customer. Progress is measured and tracked based on the observable behavior of the team.
 |
| </p>
 |
| <p>
 |
| XP relies on evolutionary design and testing techniques that maintain a high quality design while new functionality is
 |
| being added. These techniques avoid the mess of unmaintainable code through continuous review, an emphasis on
 |
| simplicity, and the backstop of nearly universal test coverage.
 |
| </p>
 |
| <p>
 |
| Programmers work on their programming tasks in pairs. The pair share a single workstation and work together to write a
 |
| single piece of code. Both partners are equally engaged in the writing. The keyboard moves back and forth between them
 |
| frequently.
 |
| </p>
 |
| <p>
 |
| XP programmers practice Test-Driven Development. In short, they write unit tests prior to writing production code.
 |
| However, this is done in very tiny increments. Tiny portions of a test are written first, and then just enough
 |
| production code is written to make those portions pass. This continues iteratively until everything that can be
 |
| practically tested has been tested.
 |
| </p>
 |
| <p>
 |
| XP focuses on continuous delivery of tested, running software from the first day of the project to the last. Delivery
 |
| of real software, combined with simple but frequent planning, provides stakeholders with a clear view of what is done
 |
| and what will be done. This enables the business to steer the project to an on-time shipment of the best possible
 |
| software that can be completed in the time available.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
