| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:DeliverableDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-Lo_rjBFuf6JDjdUw5nJjYw" name="new_deliverable,_EopWMPddEeCG79QDqBlPXg" guid="-Lo_rjBFuf6JDjdUw5nJjYw" changeDate="2012-05-30T14:26:25.810-0700" version="7.5.1"> |
| <mainDescription><p>
 |
| A release consists of integrated, compiled code that runs cleanly, independently, and in its entirety. This is an
 |
| important rule because in order to be released or even "potentially shippable," a release increment must be able to
 |
| stand on its own, otherwise it is not shippable. Releases&nbsp;can be created at either the program or team level.
 |
| </p>
 |
| <p>
 |
| There are three potential uses for a release:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>It is not used outside of the program:</strong> It has been produced to minimize risks linked to technology
 |
| and a program's capability to integrate components and to produce a Build. This situation usually happens at the
 |
| beginning of a new product lifecycle.
 |
| </li>
 |
| <li>
 |
| <strong>It is used by beta customers and the program manager:</strong> It allows end users to test it in a Beta
 |
| test environment, which provides immediate feedback and reduces risks associated with user interface ergonomics.
 |
| customer feedback will influence the program backlog for later consideration.
 |
| </li>
 |
| <li>
 |
| <strong>It is deployed or shipped and used by end users:</strong> This result provides immediate value to the end
 |
| users.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In many organizations, a program release typically is timeboxed to 2 to 3 months of development effort and 2 to 4 weeks
 |
| of hardening which results in a scheduled release approximately every 90 days. Releases for individual development
 |
| teams usually occur more often than those for programs, but there are no hard and fast rules regarding how often
 |
| releases should be scheduled. The only requirement is that working software should be delivered "frequently" by both
 |
| development teams and programs. Although the example timeframe described above is arbitrary, empirical evidence
 |
| suggests it is about right for most companies and fits nicely into quarterly planning cycles.
 |
| </p>
 |
| <p>
 |
| Each release has a set of release objectives and a projected delivery date; it also has a planned number of
 |
| sprint/iterations. For example, a brief description of a release might be: "The goal of Release 2 is to provide B2B
 |
| scheduling capability for the Ordering and Logistics Department. The release is targeted for June 31 and will consist
 |
| of five 2-week feature development sprint/iterations and&nbsp;one 2-week release sprint/iteration."
 |
| </p></mainDescription> |
| <purpose><p>
 |
| The purpose of this work product is to:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| At the team level, bring closure to a sprint/iteration or series of sprint/iterations by delivering working, tested
 |
| software that can be potentially used by the end user community for whom the system was (or is being) developed
 |
| </li>
 |
| <li>
 |
| At the program level, deliver an integrated, value-added product increment to customers that was developed in
 |
| parallel by multiple, coordinated, and synchronized development team members
 |
| </li>
 |
| </ul></purpose> |
| </org.eclipse.epf.uma:DeliverableDescription> |
