| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" |
| name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T00:23:18.328-0800" |
| version="1.0.0"> |
| <sections xmi:id="_8qN08APJEdubhrgDuRb4fA" name="Définir les conditions de succès de la release" |
| guid="_8qN08APJEdubhrgDuRb4fA"> |
| <sectionDescription><p>
 |
| Il existe 2 types de releases&nbsp; :
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
 |
| une date fixée.
 |
| </li>
 |
| <li>
 |
| une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
 |
| toutes les exigences seront réalisées.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Les conditions de succès sont définies en fonction de ce type de release.
 |
| </p><br /></sectionDescription> |
| </sections> |
| <sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" |
| guid="_BuXEQAPKEdubhrgDuRb4fA"> |
| <sectionDescription><p>
 |
| L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
 |
| </p>
 |
| <p>
 |
| L'estimation est réalisée en équipe.
 |
| </p>
 |
| <p>
 |
| La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
 |
| estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
 |
| </p>
 |
| <p>
 |
| Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
 |
| de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.&nbsp;
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA"> |
| <sectionDescription><p>
 |
| Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
 |
| des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA"> |
| <sectionDescription><p>
 |
| L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
 |
| href="./../../Scrum/guidances/termdefinitions/Velocity_410B5A1F.html"
 |
| guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;réelle. Elle sera alors utilisée pour cette release, éventuellement
 |
| ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
 |
| projets différents.
 |
| </p>
 |
| <p>
 |
| Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
 |
| premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
 |
| une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
 |
| sur la vélocité mesurée dans les sprints précédents.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" |
| guid="_I71XkAPKEdubhrgDuRb4fA"> |
| <sectionDescription><p>
 |
| En fonction des paramètres suivants :
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| les estimations de chaque item,
 |
| </li>
 |
| <li>
 |
| l'ordre dans lesquels les items sont classés (la priorité),
 |
| </li>
 |
| <li>
 |
| la vélocité estimée pour la release,
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| on affecte les items aux sprints de la release.
 |
| </p>
 |
| <p>
 |
| Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
 |
| plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
 |
| </p>
 |
| <p>
 |
| Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
 |
| tous les sprints de la release.
 |
| </p></sectionDescription> |
| </sections> |
| <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations> |
| <purpose><p>
 |
| Elaborer la planification initiale de la release permettant de lancer la série de sprints.
 |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
