<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MOA on Shigaepouyen</title><link>https://blog.shigaepouyen.net/tags/moa/</link><description>Recent content in MOA on Shigaepouyen</description><generator>Hugo -- gohugo.io</generator><language>fr</language><lastBuildDate>Fri, 03 Apr 2009 08:30:33 +0000</lastBuildDate><atom:link href="https://blog.shigaepouyen.net/tags/moa/index.xml" rel="self" type="application/rss+xml"/><item><title>Travaillez votre AGILE IT!</title><link>https://blog.shigaepouyen.net/travaillez-votre-agile-it/</link><pubDate>Fri, 03 Apr 2009 08:30:33 +0000</pubDate><guid>https://blog.shigaepouyen.net/travaillez-votre-agile-it/</guid><description>&lt;h3 id="kesako-"&gt;Kesako ?
&lt;/h3&gt;&lt;p&gt;&lt;a class="link" href="http://fr.wikipedia.org/wiki/M%c3%a9thode_agile" target="_blank" rel="noopener"
&gt;Agile&lt;/a&gt; englobe un ensemble de méthode de gestion de projet et de conception logicielle qui se veulent plus impliquantes et plus réactives vis-à-vis du client que les méthodes traditionnelles. Le but est d&amp;rsquo;obtenir un produit focalisé sur la satisfaction du client plutôt qu&amp;rsquo;un produit focalisé sur des engagements contractuels.&lt;/p&gt;
&lt;p&gt;Les 4 valeurs fondamentales d&amp;rsquo;agile sont &lt;strong&gt;l&amp;rsquo;équipe&lt;/strong&gt; (« Personnes et interaction plutôt que processus et outils »), l &lt;strong&gt;&amp;lsquo;application&lt;/strong&gt; (« Logiciel fonctionnel plutôt que documentation complète »), l&lt;strong&gt;a collaboration&lt;/strong&gt; (« Collaboration avec le client plutôt que négociation de contrat ») et &lt;strong&gt;l&amp;rsquo;acceptation du changement&lt;/strong&gt; (« Réagir au changement plutôt que suivre un plan »).&lt;/p&gt;
&lt;p&gt;La méthode la plus répendu en France est &lt;a class="link" href="http://fr.wikipedia.org/wiki/Scrum" target="_blank" rel="noopener"
&gt;SCRUM&lt;/a&gt;, souvent couplée avec &lt;a class="link" href="http://fr.wikipedia.org/wiki/Extreme_programming" target="_blank" rel="noopener"
&gt;XP&lt;/a&gt; (eXtrem Programming)&lt;/p&gt;
&lt;h6 id="huile-sur-toile-c-olivier-morin"&gt;Huile sur toile (c) &lt;a class="link" href="http://www.flickr.com/photos/oliviermorin/" target="_blank" rel="noopener"
&gt;Olivier Morin&lt;/a&gt;
&lt;/h6&gt;&lt;h3 id="méthodes-agiles-versus-méthodes-classiques"&gt;Méthodes agiles versus méthodes classiques
&lt;/h3&gt;&lt;p&gt;Je ne vous fais pas l&amp;rsquo;affront de vous présenter le &lt;a class="link" href="http://fr.wikipedia.org/wiki/Cycle_en_V" target="_blank" rel="noopener"
&gt;cycle en V&lt;/a&gt; ou en &lt;a class="link" href="http://pascal.roques.googlepages.com/cycleeny" target="_blank" rel="noopener"
&gt;Y (2TUP)&lt;/a&gt;. Ces méthodes sont aujourd&amp;rsquo;hui bien connues par les chef de projets, des indicateurs de ROI et de performances sont intégrés, les projets maitrisés. De plus ces dernières années nous avons vu fleurir de &amp;ldquo;nouvelles méthodes&amp;rdquo; de gestion de projet bien adaptées à ces cycles (&lt;a class="link" href="http://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library" target="_blank" rel="noopener"
&gt;ITIL&lt;/a&gt;, &lt;a class="link" href="http://fr.wikipedia.org/wiki/CMMI" target="_blank" rel="noopener"
&gt;CMMI&lt;/a&gt;, &lt;a class="link" href="http://fr.wikipedia.org/wiki/COBIT" target="_blank" rel="noopener"
&gt;COBIT&lt;/a&gt;, &amp;hellip;) et qui permettent de maîtriser aussi les projets dans la durée.&lt;/p&gt;
&lt;p&gt;Le problème est que dans ce cycle, on implique le métier et la MOA en début et en fin uniquement. Du coup, plus le projet est long, plus l&amp;rsquo;effet de tunnelisation est important.
De plus les équipes sont cloisonnées : &lt;strong&gt;Métier &amp;lt;-&amp;gt; MOA &amp;lt;-&amp;gt; MOE ( &amp;lt;-&amp;gt; prestataires ).&lt;/strong&gt;
Du coup, le métier désigne un responsable pour dialoguer avec la MOA, qui va mettre quelqu&amp;rsquo;un en face et va à son tour désigner un responsable pour dialoguer avec la MOE, &amp;hellip; et ainsi de suite. Autant d&amp;rsquo;interfaces qui peuvent déformer l&amp;rsquo;information, faire goulet d&amp;rsquo;étranglement, &amp;hellip; Et si on saute une étape, on crée des tentions et des frustrations.
&lt;img src="https://blog.shigaepouyen.net/uploads/ilovemiage/uploads/2009/04/projet-241x300.jpg"
loading="lazy"
alt="projet"
&gt;&lt;/p&gt;
&lt;p&gt;Agile propose au contraire d&amp;rsquo;impliquer tous les acteurs ensembles et tout au long du projet. Dans Scrum, par exemple, &lt;strong&gt;on découpe le projet en sprint de 1 à 4 semaines&lt;/strong&gt;. Lors de chaque sprint MOA et MOE décident ensemble de ce qui sera développer pendant le prochain sprint. Chaque jour du sprint, le chef de projet anime un &amp;ldquo;stand up meeting&amp;rdquo; avec ses équipes et chacun décide des tâches qu&amp;rsquo;il prend à sa charge. L&amp;rsquo;information est donc sensé remonter, dans le pire des cas chaque jour en interne MOE et à chaque sprint entre MOA et MOE. C&amp;rsquo;est aussi un process fortement impliquant pour les équipes de développement. Enfin, pour des projets avec &amp;ldquo;deadline&amp;rdquo; cela garantie que c&amp;rsquo;est bien les fonctionnalités les plus importantes qui seront développées.
&lt;img src="https://blog.shigaepouyen.net/uploads/ilovemiage/uploads/2009/04/vueglobalescrum-300x116.png"
loading="lazy"
alt="vueglobalescrum"
&gt;&lt;/p&gt;
&lt;p&gt;Le problème est que cela demande &lt;strong&gt;une disponibilité beaucoup plus importante des MOA&lt;/strong&gt;, il s&amp;rsquo;agit d&amp;rsquo;un pré-requis indispensable. Si la MOA attend un développement exhaustif du périmètre les risques de dérivent sont important. Enfin on peut se retrouve à casser et refaire souvent.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;AGILITE = VITESSE + CAPITALISATION&lt;/strong&gt; : il faut continuer à documenter ses projets sinon passé quelques runs ou un renouvellement partiel de l&amp;rsquo;équipe, le projets n&amp;rsquo;est plus viable.&lt;/p&gt;
&lt;h3 id="pourquoi-attendre"&gt;Pourquoi attendre?
&lt;/h3&gt;&lt;p&gt;On se rend assez vite compte que les méthodes agiles ne sont pas des méthodes miracles. Finalement, si elles sont intéressante pour des projets innovants, elles le sont assez peu pour des projets très long ou des projets en exploitation.&lt;/p&gt;
&lt;p&gt;De plus, les freins existent : les chef de projets ne peuvent plus appliquer leurs indicateurs traditionnels, du coup la comparaison entre un projet agile et un autre n&amp;rsquo;est pas aisée, pourtant les décideurs souhaitent toujours pouvoir mesurer leur ROI (pourquoi pas avec un indicateur gain/satisfaction utilisateur?)&lt;/p&gt;
&lt;p&gt;Enfin pour les sociétés de services doivent mettre en face de ces projets un nouveau modèle commerciale : il serait suicidaire de vendre un projet agile comme un forfait classique et leur apport est moindre si elles se contentent de fournir des ressources agiles en régie.&lt;/p&gt;
&lt;p&gt;Cependant, crise aidant, les sociétés qui ont du cash ont tout intérêt à investir dans l&amp;rsquo;innovation maintenant pour être leader en période de reprise. Je prends le paris qu&amp;rsquo;elles seront de plus en plus demandeuses de ce type de méthodes. Dans le même temps, on devrait voir un regain d&amp;rsquo;intérêt pour le &lt;a class="link" href="http://fr.wikipedia.org/wiki/Model_driven_architecture" target="_blank" rel="noopener"
&gt;MDA&lt;/a&gt; qui permet de contourner le problème du &amp;ldquo;faire et refaire&amp;rdquo;.&lt;/p&gt;
&lt;h6 id="patate"&gt;&lt;a class="link" href="http://www.martinvidberg.com/blog/" target="_blank" rel="noopener"
&gt;patate&lt;/a&gt;
&lt;/h6&gt;&lt;p&gt;Everland (c) &lt;a class="link" href="http://www.martinvidberg.com/blog/" target="_blank" rel="noopener"
&gt;Martin Vidberg&lt;/a&gt;&lt;/p&gt;
&lt;h3 id="la-souplesse-du-chef-de-projet"&gt;La souplesse du chef de projet
&lt;/h3&gt;&lt;p&gt;Le chef de projet doit maintenant connaître différent mode de projet pour offrir le meilleur service possible à son client&amp;hellip;
Et si la vraie agilité c&amp;rsquo;était l&amp;rsquo;adaptabilité, plutôt que l&amp;rsquo;évangélisation théorique?&lt;/p&gt;</description></item></channel></rss>