| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\xp\guidances\concepts\motivation.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: motivation.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,1.6390805262958034E-306 CRC: 3764417517 -->motivation<!-- END:presentationName,1.6390805262958034E-306 --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-nIpFvBhY9WogqrEQv4NknQ CRC: 42062863 --><p> |
| The goal of a software process is to guide the software development organization to: |
| </p> |
| <ol> |
| <li> |
| Get the right software done. |
| </li> |
| <li> |
| Get the software done right. |
| </li> |
| <li> |
| Get the software done quickly. |
| </li> |
| <li> |
| Get the software done frugally. |
| </li> |
| </ol> |
| <p> |
| There are many approaches to this problem. Some software processes are high in ceremony. They guide the developers to |
| create many artifacts. They punctuate the project with phases and sign-offs. They release infrequently, sometimes |
| solely upon project completion. There is a time and place for such processes. |
| </p> |
| <p> |
| On the other hand, the most important and scarce resource in any project is the time of the developers. High ceremony |
| processes fill that time with work activities that center around artifacts and reviews instead of around the core |
| artifacts of code and tests. For many projects this is an exorbitant expense. |
| </p> |
| <p> |
| To manage this expense, many projects need a process that uses a minimum of ceremony and concentrates on the core |
| artifacts. They need a feedback-driven process that delivers working software rapidly in quick releases. |
| </p> |
| <p> |
| XP is just such a low ceremony process. It is used by those teams and for those projects where ceremony is of little |
| value, but rapid feedback is of high value. Such projects tend to be small to medium sized - fewer than one or two |
| million lines of code - and involve fewer than one or two dozen developers. They tend to exist in environments of |
| intense business and or technical change. They are, of course, exceedingly common. |
| </p> |
| <p> |
| A lack of ceremony does not imply a lack of management. XP places a lot of emphasis on techniques for planning, |
| estimation, and schedule management. Creating, maintaining, and managing a project plan is a very big part of XP. |
| </p> |
| <p> |
| A lack of ceremony also does not imply a lack of discipline. XP espouses discipline for every facet of the project. |
| There is discipline for testing, integration, planning, reviewing, and for producing software with a high quality |
| internal structure. The goal is to keep the project moving and the software easy to modify, easy to extend, and easy to |
| develop. |
| </p> |
| <p> |
| In short, XP puts the emphasis on ensuring that the team is working on the minimum set of activities and artifacts that |
| will produce the right software, built right, built quickly and built frugally.<br /> |
| <br /> |
| </p><!-- END:mainDescription,-nIpFvBhY9WogqrEQv4NknQ --> |
| </body> |
| </html> |