| <?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="-pA6XLJKgRiwDTEp_qMlQ9g" |
| name="xp_values,1.076140803519123E-306" guid="-pA6XLJKgRiwDTEp_qMlQ9g" changeDate="2005-12-06T05:48:47.737-0500"> |
| <mainDescription><a id="XE_xp__core_values" name="XE_xp__core_values"></a> 
 |
| <h2>
 |
| <a id="Communication" name="Communication">Communication</a>
 |
| </h2>
 |
| <p>
 |
| XP emphasizes face-to-face communication over other types of communication, such as documents. XP values documents but
 |
| values personal communication even more. In order to facilitate communication, XP teams:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Use a common system metaphor or vocabulary.
 |
| </li>
 |
| <li>
 |
| Work closely with one another in an open workspace.
 |
| </li>
 |
| <li>
 |
| Continuously integrate the code.
 |
| </li>
 |
| <li>
 |
| Work closely with the business people, preferably having them in the same room.
 |
| </li>
 |
| <li>
 |
| Program in pairs.
 |
| </li>
 |
| <li>
 |
| Collectively own the code.
 |
| </li>
 |
| <li>
 |
| Frequently plan and report status to the customer.
 |
| </li>
 |
| </ul>
 |
| <h2>
 |
| <a id="Simplicity" name="Simplicity">Simplicity</a>
 |
| </h2>
 |
| <p>
 |
| XP presumes that it is better to do the simple thing today and pay a little more tomorrow if more is really needed than
 |
| to do a more complicated thing today that may never be used. This is a fundamental philosophy that permeates everything
 |
| in an XP project. If something isn't needed today, we don't do it today.
 |
| </p>
 |
| <p>
 |
| For example:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| We will write no document unless there is an immediate and significant need.
 |
| </li>
 |
| <li>
 |
| We will adopt no tool unless there is a tangible and verifiable benefit.
 |
| </li>
 |
| <li>
 |
| We will avoid writing infrastructure until it is needed by existing code.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In order to maintain the simplicity of their software and their team structure, XP teams:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Ask themselves: What is the simplest thing that can possibly work?
 |
| </li>
 |
| <li>
 |
| Continuously simplify and improve the design through refactoring.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Some time ago, Kent Beck offered the following rules for simple design. In priority order, the code must:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Run all the tests.
 |
| </li>
 |
| <li>
 |
| Contain no duplicate code.
 |
| </li>
 |
| <li>
 |
| Express all the ideas the author wants to express.
 |
| </li>
 |
| <li>
 |
| Minimize classes and methods.
 |
| </li>
 |
| </ol>
 |
| <h2>
 |
| <a id="Feedback" name="Feedback">Feedback</a>
 |
| </h2>
 |
| <p>
 |
| Feedback works at different scales in XP.
 |
| </p>
 |
| <p>
 |
| At the highest level, the customer can see the progress of the team through the working software delivered every two
 |
| weeks. This continuous feedback allows the customer to steer the project to success. We get concrete feedback on the
 |
| state of the system in the form of executable pieces of functionality that pass repeatable, automated acceptance tests.
 |
| These tests prevent the system from backsliding. No new release of the system can fail acceptance tests that used to
 |
| work.
 |
| </p>
 |
| <p>
 |
| At the programming level, programmers write unit tests for all the logic in the system to get immediate and concrete
 |
| feedback telling them if the code they just wrote is doing what they expected.
 |
| </p>
 |
| <p>
 |
| XP teams:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Develop in small releases.
 |
| </li>
 |
| <li>
 |
| Develop in smaller iterations.
 |
| </li>
 |
| <li>
 |
| Break features and requirements into stories that fit in an iteration.
 |
| </li>
 |
| <li>
 |
| Break stories into even smaller tasks.
 |
| </li>
 |
| <li>
 |
| Write small unit tests to ensure that tasks work properly.
 |
| </li>
 |
| <li>
 |
| Write acceptance tests to ensure that stories work properly.
 |
| </li>
 |
| <li>
 |
| Track progress and communicate it to the customer frequently.
 |
| </li>
 |
| </ul>
 |
| <h2>
 |
| <a id="Courage" name="Courage">Courage</a>
 |
| </h2>
 |
| <p>
 |
| Perhaps a better name for this value is trust. In order to function, the members of an XP team have to have the courage
 |
| to trust each other, trust their customer, trust their practices, and trust themselves.
 |
| </p>
 |
| <p>
 |
| XP team members trust that they can:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Stop when they are tired.
 |
| </li>
 |
| <li>
 |
| Let every business decision be made by the customer.
 |
| </li>
 |
| <li>
 |
| Ask customers to reduce the scope of a release.
 |
| </li>
 |
| <li>
 |
| Ask their peers or customers for help.
 |
| </li>
 |
| <li>
 |
| Design and implement only what is needed for today and add tomorrow what will be needed tomorrow.
 |
| </li>
 |
| <li>
 |
| Make changes that improve the functions or structure of the code.
 |
| </li>
 |
| <li>
 |
| Fix the design and retrofit existing code when the design is shown to be inadequate.
 |
| </li>
 |
| <li>
 |
| Throw away code.
 |
| </li>
 |
| <li>
 |
| Change code they did not write.
 |
| </li>
 |
| <li>
 |
| Change the process when it is not working.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <br />
 |
| <br />
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
