| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" name="what_is_xp,9.251272550276345E-306" guid="-nO38_JQ9G3FQvNlAT5Agqg" changeDate="2006-11-08T15:33:57.947-0800" 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,6.191633934532389E-306.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,1.076140803519123E-306.html" |
| guid="1.076140803519123E-306">values</a>, <a class="elementLinkWithUserText" |
| href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html" guid="3.036332011267074E-306">rights,</a> |
| and best <a class="elementLinkWithUserText" |
| href="./../../../xp/customcategories/xp_best_practices,4.315031901943112E-306.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> |