| <?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="-vcCn_ksJo5Jw27aNZb1Cvw" name="small_releases,5.762953011420275E-306" guid="-vcCn_ksJo5Jw27aNZb1Cvw" changeDate="2006-11-09T15:03:57.390-0800" version="1.0.0"> |
| <mainDescription><a id="XE_xp__small_releases" name="XE_xp__small_releases"></a><a id="XE_small_releases__practice_of" |
| name="XE_small_releases__practice_of"></a><a id="XE_engineering_practices__small_releases" |
| name="XE_engineering_practices__small_releases"></a> |
| <h3> |
| Description |
| </h3> |
| <p> |
| There are many developers who have spent years developing software and yet never had any of it released into use. |
| Fortunately, this situation is becoming rarer, but it still happens. There are many reasons why some software never |
| gets put into production, but often a key factor is the size of releases. Releasing software is much like integrating |
| source code changes in a project: the longer you delay it, the tougher it becomes. Releasing software into production |
| frequently is a good way of getting feedback. Users will often think of issues that they would not have without actual |
| experience using the software. Getting that feedback early enhances the overall quality of the product. |
| </p> |
| <p> |
| In XP, we recommend release cycles of three to four months at most. |
| </p> |
| <h3> |
| Benefits |
| </h3> |
| <ul> |
| <li> |
| <b>Small releases increase feedback</b>. Discrepancies between the system that is needed and the system being |
| developed are found early. |
| </li> |
| <li> |
| Putting pieces of a system into production frequently raises the quality consciousness of the project. The |
| <b>system must consistently be good enough to ship</b>. |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |