| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T09:23:18.328+0100" version="1.0.0"> |
| <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations> |
| <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,_HQEP8ILXEduLd8CaF_IcMA.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> |
| <purpose><p> |
| Elaborer la planification initiale de la release permettant de lancer la série de sprints. |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |