<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription 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="-6aCUL_kawJFNBtfH_sRXkw" name="Product increment,_tCmYEP-xEdqLnajTSLeAsA" guid="-6aCUL_kawJFNBtfH_sRXkw" changeDate="2006-12-03T10:04:18.218+0100" version="1.0.0">
  <mainDescription>&lt;p&gt;
    Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
    sprint,&amp;nbsp;les exigences supplémentaires réalisées pendant ce sprint.
&lt;/p&gt;
&lt;p&gt;
    On peut&amp;nbsp;trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
    fin d'itération&amp;nbsp;:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
        technologie et à la capacité de l'équipe à intégrer pour produire un &lt;q&gt;build&lt;/q&gt;. Cela arrive surtout au début
        d'un nouveau produit.
    &lt;/li&gt;
    &lt;li&gt;
        il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
        avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
        Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
    &lt;/li&gt;
    &lt;li&gt;
        il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
        viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
        disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
        temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
        écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
        particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
        temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;br /&gt;</mainDescription>
  <keyConsiderations>&lt;p&gt;
    Le produit évolue pendant toute sa vie jusqu'à son retrait.
&lt;/p&gt;</keyConsiderations>
  <briefOutline>Le produit partiel peut être déployé dans l'environnement de production&amp;nbsp;ou simplement mis à disposition des
utilisateurs.</briefOutline>
</org.eclipse.epf.uma:ArtifactDescription>