blob: 9147ccc340f63a97f69693a974ddaf60184dedcc [file] [log] [blame]
<?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>&lt;a id=&quot;XE_xp__what_is_it&quot; name=&quot;XE_xp__what_is_it&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_what_is__xp&quot; name=&quot;XE_what_is__xp&quot;&gt;&lt;/a&gt;
&lt;p&gt;
Kent Beck, author of &lt;i&gt;Extreme Programming Explained&lt;/i&gt; [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#BEC00&quot;
guid=&quot;6.191633934532389E-306&quot;&gt;BEC00&lt;/a&gt;], says, &quot;XP is a light-weight methodology for small-to-medium-sized teams
developing software in the face of vague or rapidly changing requirements.&quot; Simply stated, XP is a set of &lt;a
class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html&quot;
guid=&quot;1.076140803519123E-306&quot;&gt;values&lt;/a&gt;, &lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html&quot; guid=&quot;3.036332011267074E-306&quot;&gt;rights,&lt;/a&gt;
and best &lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../xp/customcategories/xp_best_practices,4.315031901943112E-306.html&quot;
guid=&quot;4.315031901943112E-306&quot;&gt;practices&lt;/a&gt; that support each other in incrementally developing software.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>