| <?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-DKbcEDMwu7S4GWFkH-TTkg" name="how_to_adopt_production_release,_IADPYeB-EeC1y_NExchKwQ" guid="-DKbcEDMwu7S4GWFkH-TTkg" changeDate="2011-10-13T06:52:57.041-0700" version="7.2.0"> |
| <mainDescription><h3>
 |
| Getting started
 |
| </h3>
 |
| <p>
 |
| The goal of the Production Release practice is to transform the business value developed in Feature Development
 |
| Sprint/Iterations into a finished product that can be released into production along with other products as part of a
 |
| coordinated Release.
 |
| </p>
 |
| <p>
 |
| If a development team has never practiced Production Release before, the best way to think of this special type of
 |
| Sprint/Iteration is to consider a past project in which your team spent a week of 16-hour days doing all the things
 |
| necessary to prepare for a deployment based on an arbitrary release date. Then realize that you do not have to operate
 |
| like that any more, and that a Production Release Sprint/Iteration is your opportunity to calmly deal with all the
 |
| preparatory activities that accompany a well-managed, coordinated release while other development team members are doing the
 |
| same. In short, the Production Release practice represents the way you always wished you could prepare for a release
 |
| but did not have the opportunity.
 |
| </p>
 |
| <h3>
 |
| Common pitfalls
 |
| </h3>
 |
| <p>
 |
| Because production release provides a development team the opportunity to "fine tune" a product and tighten up
 |
| problematic areas of the code, it is good practice not to squander that Sprint/Iteration.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>A Release Sprint/Iteration is not a time to rest:</strong> Some development team members think that when they get
 |
| to Production Release they can relax and not work too hard. However, when practicing the Agile value of Sustainable
 |
| Pace, teams should <em>not need to</em> rest, and team members should maintain the tempo that they established
 |
| during previous Feature Development Sprint/Iterations.
 |
| </li>
 |
| <li>
 |
| <strong>Testing is not more important than documentation and training:</strong> While the various types of testing
 |
| that are conducted in a Release Sprint/Iteration (integration, system, UAT) are important, documentation and
 |
| training are just as important because how well end users can actually use the product to do their work is critical
 |
| to a successful delivery.
 |
| </li>
 |
| <li>
 |
| <strong>Successful hardening is more important than squeezing in marginally tested features:</strong> Do not think
 |
| that more features delivered is necessarily better. While there is always a temptation to deliver more
 |
| functionality in a Release, resist that desire and deliver only features that are mature and have been well tested
 |
| and integrated.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |