« Itération Agile. Train de Release Agile. Fractale Agile » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Aucun résumé des modifications
 
Ligne 10 : Ligne 10 :
Traduction :<br />
Traduction :<br />
<br />
<br />
<span style="display: block; text-align: justify"><span class="hps">Comme je l'ai longuement décrit dans </span>[http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841/ref=sr_1_7?s=books&ie=UTF8&qid=1283881266&sr=1-7 Agile Software Requirements], [http://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192/ref=pd_sim_b5 Scaling Software Agility]<span class="hps"> et ce [http://scalingsoftwareagility.wordpress.com/category/agile-release-train/ blog], le Train de Release Agile peut offrir des avantages considérables pour les grandes Entreprises logicielles agiles. Moi, et beaucoup d'autres</span>, l'utilisons <span class="hps">régulièrement pour : 1) Aligner les équipes agiles sur une mission commune et 2) Organiser l'entreprise autour de des concepts de programme et de </span>flux de <span class="hps">développement de produits.</span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span class="hps">Toutefois, étant un homme économe en</span> <span class="hps atn">mots</span>, j'ai <span class="hps">parfois un peu de mal à décrire le Train</span> de <span class="hps">Release Agile dans</span> des termes <span class="hps">les plus simples possibles</span>. <span class="hps">Il y a quelque temps</span>, j'ai comparé <span class="hps">le train de release à une fractale au-dessus du sprint / itération. </span>Une fractale <span class="hps">est une forme géométrique qui peut être divisée en différentes parties, chacune de ces parties étant une copie en taille réduite de l'ensemble</span>. <span class="hps">Peut-être est-ce la meilleure façon de penser au train de release. Essayons</span>.<br /> <br /> <span class="hps">Il n'y a pas de débat</span> sur le fait <span class="hps">qu'une itération / sprint agile suit un schéma général simple </span>: 1. <span class="hps">Plan 2. Engagement 3. Exécution 4. Démonstration 5. Adaptation </span><span class="hps atn">(</span>Rétroaction). <span class="hps">Cela ressemble à ça </span>:<br /> <br /> [[Image:screen-shot-2011-09-27-at-12-44-35-pm.png|screen-shot-2011-09-27-at-12-44-35-pm.png]]<br /> <br /> <span class="hps">Le train de release met en jeu plus d'équipes et des</span> <span class="hps atn">itérations plus longues (super </span>sprint) <span class="hps">mais le schéma est exactement le même</span>, <span class="hps">c'est juste qu'il s'applique au niveau au-dessus, au niveau du programme. Cela ressemble à ça </span>:<br /> [[Image:screen-shot-2011-09-27-at-12-44-46-pm.png|screen-shot-2011-09-27-at-12-44-46-pm.png]]<br /> </span><br />  Est-ce que c'est plus simple à comprendre ?<br /> <br />
<span style="display: block; text-align: justify"><span class="hps">Comme je l'ai longuement décrit dans </span>[http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841/ref=sr_1_7?s=books&ie=UTF8&qid=1283881266&sr=1-7 Agile Software Requirements], [http://www.amazon.com/Scaling-Software-Agility-Practices-Enterprises/dp/0321458192/ref=pd_sim_b5 Scaling Software Agility]<span class="hps"> et ce [http://scalingsoftwareagility.wordpress.com/category/agile-release-train/ blog], le Train de Release Agile peut offrir des avantages considérables pour les grandes Entreprises logicielles agiles. Moi, et beaucoup d'autres</span>, l'utilisons <span class="hps">régulièrement pour : 1) Aligner les équipes agiles sur une mission commune et 2) Organiser l'entreprise autour de des concepts de programme et de </span>flux de <span class="hps">développement de produits.</span></span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><span class="hps">Toutefois, étant un homme économe en</span> <span class="hps atn">mots</span>, j'ai <span class="hps">parfois un peu de mal à décrire le Train</span> de <span class="hps">Release Agile dans</span> des termes <span class="hps">les plus simples possibles</span>. <span class="hps">Il y a quelque temps</span>, j'ai comparé <span class="hps">le train de release à une fractale au-dessus du sprint / itération. </span>Une fractale <span class="hps">est une forme géométrique qui peut être divisée en différentes parties, chacune de ces parties étant une copie en taille réduite de l'ensemble</span>. <span class="hps">Peut-être est-ce la meilleure façon de penser au train de release. Essayons</span>.<br /> <br /> <span class="hps">Il n'y a pas de débat</span> sur le fait <span class="hps">qu'une itération / sprint agile suit un schéma général simple </span>: 1. <span class="hps">Plan 2. Engagement 3. Exécution 4. Démonstration 5. Adaptation </span><span class="hps atn">(</span>Rétroaction). <span class="hps">Cela ressemble à ça </span>:<br /> <br /> [[Image:screen-shot-2011-09-27-at-12-44-35-pm.png|screen-shot-2011-09-27-at-12-44-35-pm.png|link=]]<br /> <br /> <span class="hps">Le train de release met en jeu plus d'équipes et des</span> <span class="hps atn">itérations plus longues (super </span>sprint) <span class="hps">mais le schéma est exactement le même</span>, <span class="hps">c'est juste qu'il s'applique au niveau au-dessus, au niveau du programme. Cela ressemble à ça </span>:<br /> [[Image:screen-shot-2011-09-27-at-12-44-46-pm.png|screen-shot-2011-09-27-at-12-44-46-pm.png|link=]]<br /> </span><br />  Est-ce que c'est plus simple à comprendre ?<br /> <br />