blob: 6c78f3b903816750c262b43d734a422714b2e7b6 [file] [log] [blame]
<?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>&lt;p&gt;
Il existe 2 types de releases&amp;nbsp; :
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
une date fixée.
&lt;/li&gt;
&lt;li&gt;
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.
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
Les conditions de succès sont définies en fonction de ce type de release.
&lt;/p&gt;
&lt;br /&gt;</sectionDescription>
</sections>
<sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" guid="_BuXEQAPKEdubhrgDuRb4fA">
<sectionDescription>&lt;p&gt;
L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
&lt;/p&gt;
&lt;p&gt;
L'estimation est réalisée en équipe.
&lt;/p&gt;
&lt;p&gt;
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).
&lt;/p&gt;
&lt;p&gt;
Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
de pratiquer le &quot;planning poker&quot; et de travailler par analogie en comparant les éléments estimés.&amp;nbsp;
&lt;/p&gt;</sectionDescription>
</sections>
<sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA">
<sectionDescription>&lt;p&gt;
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.&lt;br /&gt;
&lt;/p&gt;</sectionDescription>
</sections>
<sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA">
<sectionDescription>&lt;p&gt;
L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa &lt;a class=&quot;elementLink&quot;
href=&quot;./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html&quot;
guid=&quot;_HQEP8ILXEduLd8CaF_IcMA&quot;&gt;Vélocité&lt;/a&gt;&amp;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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;</sectionDescription>
</sections>
<sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" guid="_I71XkAPKEdubhrgDuRb4fA">
<sectionDescription>&lt;p&gt;
En fonction des paramètres suivants :
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
les estimations de chaque item,
&lt;/li&gt;
&lt;li&gt;
l'ordre dans lesquels les items sont classés (la priorité),
&lt;/li&gt;
&lt;li&gt;
la vélocité estimée pour la release,
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
on affecte les items aux sprints de la release.
&lt;/p&gt;
&lt;p&gt;
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 &quot;rond&quot;).
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;</sectionDescription>
</sections>
<purpose>&lt;p&gt;
Elaborer la planification initiale de la release permettant de lancer la série de sprints.
&lt;/p&gt;</purpose>
</org.eclipse.epf.uma:TaskDescription>