| <?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="-pA6XLJKgRiwDTEp_qMlQ9g" name="xp_values,1.076140803519123E-306" guid="-pA6XLJKgRiwDTEp_qMlQ9g" changeDate="2005-12-06T02:48:47.737-0800"> |
| <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> |