tag:jacques.witte.usineweb.fr,2011:mephisto/architecture-logicielle Mephisto Noh-Varr 2009-07-01T08:59:43Z jacques tag:jacques.witte.usineweb.fr,2009-07-01:29 2009-07-01T08:58:00Z 2009-07-01T08:59:43Z

<p>La chaîne de déploiement décrit dans le cadre du <strong>développement logiciel</strong> les logiques opérationnelles liées au <strong>développement par version</strong> d’une application</p>

<p>La chaîne de déploiement décrit dans le cadre du <strong>développement logiciel</strong> les logiques opérationnelles liées au <strong>développement par version</strong> d’une application</p> <p>La chaîne de déploiement décrit dans le cadre du <strong>développement logiciel</strong> les logiques opérationnelles liées au <strong>développement par version</strong> d’une application</p> <h2>les 3 maillons indispensables de la chaîne</h2> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/7/1/chaine-deploiement-1.jpg" alt="" /></p> <p>Votre chaine de déploiement est constituée à minima de:</p> <ul> <li>l’environnement de réalisation, le domaine de travail de vos développeurs & graphistes,...</li> <li>l’environnement de démo, le domaine de travail de vos chefs de projets</li> <li>l’environnement d’exploitation, le domaine de travail de vos intégrateurs de contenu et de votre client</li> </ul> <h2>la logique de passage d’un environnement à l’autre</h2> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/7/1/chaine-deploiement-2.jpg" alt="" /></p> <p>Il est important de comprendre que la logique de passage d’un environnement au suivant est sous la responsabilité des personnes de l’environnement en cours:</p> <ul> <li>Décisionnel =&gt; Réalisation <ul> <li>la décision de mettre en réalisation un <strong>Pool de fonctionnalités</strong> est le choix <strong>tactique ou stratégique</strong> des décideurs</li> </ul> </li> <li>Réalisation =&gt; Démo <ul> <li>la décision de mettre une version de <strong>developpement</strong> de l’application en démo dépend des <strong>Développeurs</strong> et est basé sur leur connaissance de la <strong>version stable</strong> du code de l’application</li> </ul> </li> <li>Démo =&gt; Exploitation <ul> <li>la décision de mettre une version de <strong>démonstration</strong> de l’application en exploitation dépend des <strong>Chef de projet</strong> est basé sur leur analyse de la <strong>maturité avérée</strong> (recettage) du <strong>Pool de fonctionnalités</strong> de l’application</li> </ul></li> </ul> <h2>La chaîne de production ne s’arrête pas avant que le Pool soit vide</h2> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/7/1/chaine-deploiement-3.jpg" alt="" /></p> <p>Il est important de comprendre que la logique de passage d’un environnement à l’autre ne doit <span class="caps">JAMAIS</span> être court-circuité sous peine de désorganisation de l’ensemble (phénomène d’aller retour en contresens entre les maillons de la chaîne)</p> <p>Ceci est particulièrement vrai suite à la phase de Démo et d’Exploitation où apparaît la <strong>phase d’affinage</strong>:</p> <ol> <li>qui boucle sur l’environnement de Réalisation autant de fois que nécessaire</li> <li>qui est constitué: <ol> <li>de correctifs</li> <li>mais aussi <strong>d’adaptation ergonomique et fonctionnel</strong> du Pool de fonctionnalités initial.</li> </ol></li> </ol> <p>La <strong>phase d’affinage</strong>:</p> <ol> <li>Exclut que <strong>l’environnement Décisionnel</strong> lance un nouveau Pool de fonctionnalités dans <strong>l’environnement de Réalisation</strong> sous peine de court-circuitage</li> <li>Permet au Décisionnel de repenser le prochain Pool de fonctionnalités au regard des résultats du précédent affinage</li> </ol> <p><strong>En résumé</strong>:</p> <ul> <li>Une bonne phase d’affinage détermine la qualité finale de la réalisation</li> <li>D’un point de vue pratique un <strong>système de ticketing</strong> et de <strong>tableaux de bord</strong> ainsi qu’un système de <strong>versionning du code</strong> et de <strong>déploiement</strong> bien organisés sont essentiels pour correctement piloter la phase d’affinage</li> </ul> <h2>Pour aller plus loin</h2> <p>Voici, vu par un <strong>architecte logiciel</strong>, le sypnosys de la suite de la reflexion sur <strong>comment mettre en oeuvre</strong> la chaine de déploiement d’une application au sein de votre entreprise:</p> <ol> <li>les <strong>poncifs classiques</strong> du développement d’une application: <ol> <li>le système de Milestones pour le contrôle décisionnel & l’affinage</li> <li>le test continu en appui feu de la phase de réalisation et du respect des normes</li> <li>L’homogénéité des environnements pour diminuer le risque d’exploitation</li> <li>Faire éclore à maturité les fonctionnalités de l’application sur l’environnement démo</li> <li>Déployer automatiquement un environnement sinon rien</li> <li>Corriger en cas réel: I want my data back !</li> </ol> </li> <li>l’application de ces poncifs sur les <strong>outils opérationnels</strong> de votre infrastructure: <ol> <li>de système de ticketing</li> <li>de versionning du code</li> <li>de système de déploiement</li> <li>de tableaux de bord</li> </ol></li> </ol> <strong>Article connexes:</strong> <ul> <li><a href="http://jacques.witte.usineweb.fr/2009/6/24/la-chaine-de-production">la chaine de production</a></li> </ul> jacques tag:jacques.witte.usineweb.fr,2009-06-24:28 2009-06-24T15:30:00Z 2009-06-25T07:49:47Z

<p>Dès lors qu’un projet nécessite la taille d’une équipe une organisation s’impose pour atteindre l’objectif. C’est là qu’intervient ce vieux concept industriel de la <strong>chaîne de production</strong>. Revisitons donc ce concept …</p>

<p>Dès lors qu’un projet nécessite la taille d’une équipe une organisation s’impose pour atteindre l’objectif. C’est là qu’intervient ce vieux concept industriel de la <strong>chaîne de production</strong>. Revisitons donc ce concept …</p> <p>Dès lors qu’un projet nécessite la taille d’une équipe une organisation s’impose pour atteindre l’objectif. C’est là qu’intervient ce vieux concept industriel de la <strong>chaîne de production</strong>. Revisitons donc ce concept…</p> <h2>la chaîne de production pour quels objectifs ?</h2> <pre> Décision -&gt; Action -&gt; Résultat </pre> La chaîne une fois démarrée doit mettre sous tension les différents intervenants afin que : <ul> <li>objectif 1: le résultat: prenne moins de temps</li> <li>objectif 2: le résultat: soit plus qualitatif</li> <li>objectif 3: cible les responsabilités en cas d’urgence</li> </ul> <h2>La chaîne de production est transversale</h2> Votre entreprise est constituée de différents intervenants (ou maillons): <ul> <li>décideurs</li> <li>développeurs</li> <li>graphiste</li> <li>administrateurs</li> <li>commerciaux</li> </ul> Naturellement, chacun se greffe sur la chaîne de production en tant que <strong>maillon</strong> avec plusieurs objectifs: <ul> <li>pour y apporter un <strong>savoir-faire</strong> complémentaire (responsabilité de l’intervenant)</li> <li>mais aussi pour <strong>tirer la chaine à soi</strong> selon le point de vue métier du maillon (désir/frustration de l’intervenant)</li> </ul> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/6/24/chaine1.jpg" alt="" /></p> <p>Ceci peut devenir problématique car dans une chaine chaque maillon a une <strong>responsabilité cloisonné</strong> et a une tendance naturelle à ne s’intéresser qu’à lui-même (<strong>égocentrisme</strong> du maillon)</p> Il faut donc trouver un moyen de <strong>faire communiquer</strong> les différents intervenants de la chaîne, sous peine d’un blocage (cf Goldratt), lié à la: <ul> <li>sous-production d’un maillon (pas assez de rapidité de développement, pas assez de tests fonctionnels et qualitatifs, ....)</li> <li>sur-production d’un maillon (trop de fonctions nouvelles ,trop de vente, trop d’incidents)</li> </ul> <h2>La chaîne de production doit être transparente</h2> Le meilleur moyen d’y arriver est de permettre, à tout à chacun dans l’équipe, de savoir à l’instant T: <ul> <li>qu’est ce qu’a donné le résultat du travail de l’intervenant X sur le projet Z ?</li> <li>où en est on dans la chaîne de production vis-à-vis de tel ou tel projet ? (quels vont être les nouveautés ?, combien on en a vendu ?, nombre d’incidents ?, ...)</li> </ul> <p>Il faut donc une sorte de <strong>tableau de bord</strong> qui décloisonne les intervenants de leur responsabilité principale:</p> <ul> <li>en leur donnant une <strong>vue grand angle</strong> des conséquences de leur travail (notion d’utilité de l’intervenant d’un point de vue global)</li> <li>ce qui permet à chaque intervenant <strong>d’anticiper les actions futures</strong> et d’y apporter son concours</li> </ul> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/6/24/chaine2.jpg" alt="" /></p> Cela permet a chacun d’appuyer sur le frein ou l’accélérateur en prenant en compte: <ul> <li>l’état amont /aval des autres maillons pour agir </li> <li>et non pas seulement son propre domaine de compétences (désir/frustration du maillon)</li> </ul> <h2>La chaîne de production est circulaire !</h2> <p>Ainsi par la transparence de l’information (notion de feedback), l’attitude de la moyenne des intervenants <strong>s’auto-police</strong> sur les projets, permettant à la ligne hiérarchique de se <strong>concentrer</strong> uniquement sur les cas réellement <strong>urgents & importants</strong> (table d’Einsenhover).</p> <p>On en revient, au travers du tableau de bord, à la vision de la <strong>roue de l’ingénieur</strong> appliquée à <strong>tous les intervenants</strong> de l’entreprise:</p> <p><img src="http://jacques.witte.usineweb.fr/assets/2009/6/24/chaine3.jpg" alt="" /></p> <h2>En conclusion</h2> <p>Comme le conclut Goldratt, l’élément critique qui pilote la chaîne de production est la <strong>qualité du feedback</strong> et de ses critères. Il faut donc construire scrupuleusement, avec <strong>l’architecte logiciel</strong>, ses tableaux de bord en se basant sur les <strong>indicateurs réels de fonctionnement</strong> de votre entreprise.</p> <p>C’est ici que <strong>le monde du Web</strong> peut faire la différence dans les développements de tableaux de bord. Cette technologie étant aujourd’hui accessible par un simple navigateur et compréhensible par tous les intervenants d’une entreprise. Elle permet qui plus est <strong>d’agréger facilement</strong> les différentes sources d’informations de l’entreprise (SAP, Base de données, fichiers excels, téléphonie …)</p> jacques tag:jacques.witte.usineweb.fr,2009-02-23:24 2009-02-23T14:25:00Z 2009-03-02T13:52:21Z

<p>Le pourquoi et le comment du <strong>plateau de compétences</strong> notamment dans la mise en oeuvre de vos besoins informatiques dans une relation business-to-business</p>

<p>Le pourquoi et le comment du <strong>plateau de compétences</strong> notamment dans la mise en oeuvre de vos besoins informatiques dans une relation business-to-business</p> <p>Le pourquoi et le comment du <strong>plateau de compétences</strong> notamment dans la mise en oeuvre de vos besoins informatiques dans une relation business-to-business</p> <h2>De l’exigence du monde moderne</h2> <p>Aujourd’hui, le client en général, et l’internaute en particulier à une attente en terme de qualité de produit & service sans précédent:</p> <ul> <li><strong>Internet mondialise</strong> de facto la mise en concurrence des applications logicielles, les prestataires du métier se retrouve a réaliser un cahier des charges identique dans une concurrence dissymétrique de moyens & de tailles ce qui nécessite des choix de mise en oeuvre technique de plus en plus pertinants…</li> </ul> <ul> <li><strong>L’accélération du temps</strong> impose à l’industrie informatique de réaliser en quelques mois ce que le secteur industriel réalise en quelques années, les prestataires du métier informatique font face à des problématiques de croissance/décroissance de productivité de leur équipes qui impose de la recherche & développement pour améliorer leur outils en interne de façon constante…</li> </ul> <p>Du fait que l’informatique est présente dans tous les métiers, les prestataires se retrouvent face à des exigences en terme d’écoute, de <strong>respect des normes</strong>, et de création de valeur ajoutée qui enterre l’informatique pour les informaticiens et impose le montage d’équipes métiers <strong>pluridisciplinaires</strong> de manière <strong>ad’hoc</strong>...</p> <h2>De l’obligation de travailler en réseaux</h2> <p>Tout cela nous pousse à une ouverture sur des équipes composés <strong>d’experts</strong> (marketing, commercial, logistique, informatique,...) dans leur domaine mais capables de se fédérer afin de:</p> <ul> <li><strong>solutionner les problématiques projets</strong> grâce aux différentes approches</li> <li><strong>innover fonctionnellement par la transposition des savoirs-faire métiers</strong>: un expert est plus pertinent pour discerner le besoin fonctionnel propre à son corps de métier qui est manquant dans une solution logicielle: c’est donc lui qui apporte l’innovation logicielle</li> <li><strong>créer de la valeur ajouté par un résultat qualitatif</strong> c’est le fruit de l’expérience de travail du cocktail interdisciplinaire: “le bon gout pour le client final provient de la qualité des ingrédients mélangés”</li> </ul> <p>Ces concepts correspondent à ce que l’on appel communément un <strong>plateau de compétence</strong> dans le monde de l’industrie (qui rejoint les conditions énumérés dans l’article sur <a href="http://jacques.witte.usineweb.fr/2008/2/11/methodes-agiles-en-entreprise">les équipes agiles</a>)</p> <h2>De la problématique de la structuration</h2> <p>Nous voyons donc que la difficultée du <strong>plateau de compétence</strong> pour l’entreprise n’est pas de comprendre son intérêt fonctionnel mais bien de pouvoir en effectuer le montage (en particulier pour les <span class="caps">PME</span>/PMI)...</p> <p>Pour le service des ressources humaines:</p> <ul> <li>Comment regrouper des experts sur un plateau de compétence pour une entreprise au vue de l’effort de type “chasseur de tête” à consentir ?</li> <li>Comment gérer le rapport interne/externe vis à vis des salariés de l’entreprise ?</li> </ul> <p>Pour le chef de projet:</p> <ul> <li>Comment les faire intervenir, et dans quel ordre ?</li> </ul> <p>Pour le budget de l’entreprise:</p> <ul> <li>Comment supporter le coût qu’un groupe d’expert engendre pour une entreprise une fois sortie de la phase de création de projet ?</li> </ul> <h2>Vers une solution ?</h2> <p>La réponse peut paraître naive: </p> <ol> <li>louez un plateau de compétences déjà formé en “tête de pont” de vos projets (avant projet, mise en oeuvre de la version 1 du produit,...) comprenant un coordinateur (et référant auprès du client)</li> <li>puis éventuellement transférez la compétence à une équipe en interne entre la fin de la “phase tête de pont” et le début de la “phase d’exploitation” de votre solution informatique</li> </ol> <p>Car elle soulève une vraie problématique commerciale: comment et chez qui trouver ces services ad-hoc ?</p> <ul> <li>les <strong>agences d’interim</strong> se bornent dans leur grande majoritée à louer des compétences individuelles… Elles se restreignent trop “au produit RH / intérimaire” mais pas forcément au “plus service” qu’elles peuvent offrir.</li> <li>les <strong>ssii</strong> louent dans certain cas des groupes de compétences mais dans la plupart des cas ne disposent dans leur réserves que de ressources “juniors” du fait de la dyssimétrie offre/demande…</li> <li>les <strong>freelancers</strong> qui offrent l’avantage de l’expérience métier sont, du fait de leur statut d’indépendants, difficiles à regrouper de manière ad’hoc au sein d’un plateau…</li> </ul> <h2>Synthèse</h2> <p>Il manque donc sur le marché des offres fournissant aux entreprises des “plateaux de compétences” composés d’experts habitués à travailler ensemble en “marque blanche”.</p> <p>Cela rejoint l’idée d’une vision opérationnelle des cabinets de think-tank anglo-saxons (groupes de réflexions) composés de consultants.</p> <p>Les <strong>plateaux de compétences</strong> sont donc à redécouvrir particulièrement pour le marché actuel où l’on distingue de plus en plus les prestataires qui exécutent:</p> <ol> <li>la phase <strong>décisionnel</strong> réalisé par les cabinets conseils: <ul> <li>les chambres professionnelle du conseil labelisés</li> <li>ceux spécialisés en Architecture des Systèmes (APE: 6202A)</li> </ul> </li> <li>la phase <strong>d’architecture et de création</strong> du produit pilote </li> <li>la phase <strong>d’exploitation/évolution</strong> du produit .</li> </ol> jacques tag:jacques.witte.usineweb.fr,2008-05-23:13 2008-05-23T11:29:00Z 2009-05-09T22:43:35Z

<p>La bonne formulation d’un <strong>contrat</strong> reste la pierre angulaire du commencement d’un projet et surtout <strong>la réussite de sa finalisation</strong>...</p> <p>Dans le cadre d’équipes fonctionnant en <a href="http://www.jacques.witte.usineweb.fr/2008/2/11/methodes-agiles-en-entreprise">méthodes agiles</a>, comment faire pour que ces documents soient en accord avec la real politik de la <strong>mise en oeuvre “agile”</strong> notamment le <strong>développement itératif</strong> du produit ?</p>

<p>La bonne formulation d’un <strong>contrat</strong> reste la pierre angulaire du commencement d’un projet et surtout <strong>la réussite de sa finalisation</strong>...</p> <p>Dans le cadre d’équipes fonctionnant en <a href="http://www.jacques.witte.usineweb.fr/2008/2/11/methodes-agiles-en-entreprise">méthodes agiles</a>, comment faire pour que ces documents soient en accord avec la real politik de la <strong>mise en oeuvre “agile”</strong> notamment le <strong>développement itératif</strong> du produit ?</p> <p>La bonne formulation d’un <strong>contrat</strong> reste la pierre angulaire du commencement d’un projet et surtout <strong>la réussite de sa finalisation</strong>...</p> <p>Dans le cadre d’équipes fonctionnant en <a href="http://www.jacques.witte.usineweb.fr/2008/2/11/methodes-agiles-en-entreprise">méthodes agiles</a>, comment faire pour que ces document soient en accord avec la real politik de la <strong>mise en oeuvre “agile”</strong> notamment le <strong>développement itératif</strong> du produit ?</p> <h2>Le background</h2> <p>Tout d’abord, rappelons brièvement deux concepts:</p> <ul> <li><strong>le développement itératif</strong> <ol> <li>Consiste en un développement “par version” d’un produit, </li> <li>Chaque itération (version) est courte (se compte en jours tout au plus) et livre un produit fonctionnel (exploitable par le client). </li> <li>A la suite de chaque livraison, le client peut définir ou re-définir le cahier des charges de la nouvelle itération jusqu’à atteindre le <strong>produit fini</strong></li> </ol></li> </ul> <ul> <li><strong>le contrat au forfait</strong> <ol> <li>Consiste en un contrat qui détermine une liste exhaustive de fonctionnalités de la <strong>version finale</strong> d’un produit à réaliser dans des échéances données</li> </ol></li> </ul> <h2>Les points de vues</h2> <p>Il est clair que ces deux concepts s’affrontent: on ne peut pas signer un contrat au forfait d’un produit et en assurer un développement agile sans payer le prix de la contradiction….</p> <p>Quelles sont les marges de manoeuvre existantes ? Il faut d’abord confronter les deux points de vues:</p> <ul> <li><strong>point de vue client</strong> <ol> <li>le client veut se rassurer sur <strong>combien il va payer au total</strong> (sachant qu’il prévoit souvent pour les finitions une marge de X % de dérapage)</li> <li>le client veut définir <strong>l’ensemble des fonctionnalités</strong> du produit, même si celles-ci peuvent être floues (de peur de se retrouver à la livraison de celui-ci sans marge de négociation possible)</li> <li>le client veut que le produit soient <strong>réalisé dans une échéance temps</strong> (date de début, date de fin) pour respecter ses impératifs stratégiques propres (commercial, de communication, d’organisation…)</li> </ol></li> </ul> <ul> <li><strong>point de vue de l’équipe de mise en oeuvre</strong> <ol> <li>l’interprétation et donc le <strong>chiffrage</strong> d’un gros contrat au forfait (liste exhaustive de fonctionnalités) est un <strong>exercice vaudou difficile</strong> qui, sous-estimé, impacte la rentabilité du contrat (alors que celui-ci n’a pas démarré)</li> <li>l’équipe de mise en oeuvre va donc souvent <strong>surestimer les temps de production</strong> (le plus souvent en facteur multiplicatif) sur chaque <strong>fonctionnalité floue ou susceptible de changer</strong></li> <li>le client par nature lorsqu’il reçoit le produit s’aperçoit que <strong>l’interprétation de la mise en oeuvre</strong> de telle fonctionnalité était erroné (c’est <strong>l’effet surprise</strong>) et demande (avec raison) des <strong>correctifs</strong> qui deviennent une charge de travail non chiffrée pour l’équipe</li> </ol></li> </ul> <h2>Vers une solution</h2> <p>Il faut donc trouver une solution contractuelle qui: </p> <ol> <li>satisfasse le client sur la vision <strong>macro-planning</strong> du projet sur lequel <strong>les deux parties s’engagent</strong></li> <li>apporte de la <strong>flexibilité</strong> sur les <strong>phases charnières</strong> du projet pour l’équipe de mise en oeuvre (afin de réduire “l’effet surprise”)</li> <li>permette <strong>d’éviter les engagements contractuels</strong> basés sur des fonctionnalités ou chiffrages <strong>flous ou susceptibles de changer</strong> (sur lesquelles on ne peut malheureusement pas revenir une fois signé…)</li> </ol> <h2>Une méthode contractuelle</h2> <p>La recette, consisterait à ne pas confondre <strong>cahier des charges</strong> et <strong>contrat</strong> :</p> <ol> <li>Le client fournit un cahier des charges de son produit</li> <li>L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit ce cahier des charges en le découpant en milestones (groupe de fonctionnalités) chiffrés en jours/hommes</li> <li>L’ensemble des milestones (cad le chiffrage du cahier des charge) détermine un nombre de jours/hommes total du projet</li> <li>Le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet (25%, 50%, 75%, 100%...), ce qui signifie la réservation du planning de l’équipe de mise en oeuvre</li> <li>Le client signe la mise en oeuvre de la milestone 1, ce qui signifie l’engagement de début de travaux</li> <li>Ce nombre de jours total est ensuite affecté dynamiquement aux milestones suivants la milestone1:</li> </ol> <ul> <li><strong>dans un ordre qui peut être revisité de façon “agile”</strong> par le client & l’architecte</li> <li><strong>dans un contenu</strong> (cad le détail des fonctionnalités de chaque milestones) <strong>qui peut être revu de façon “agile”</strong> par le client & l’architecte en fonction du recettage de la précédente milestone et de l’évolution du projet</li> </ul> <p>Le tout constitue une <strong>formulation agile</strong> d’un <strong>contrat au forfait</strong>...</p> <h2> Synthèse</h2> <p>Par le biais de sa <strong>formulation agile</strong>, le <strong>contrat + le cahier des charges</strong> offrent au client la capacité d’établir une vraie <strong>stratégie de mise en oeuvre</strong> de son produit:</p> <ul> <li> flexible dans le temps </li> <li> flexible dans les moyens (humain, financier, d’infrastructure) engagés</li> <li> flexible dans sa finalité (ce que fait le produit)</li> </ul> <h2>Références</h2> <ul> <li><a href="http://fr.wikipedia.org/wiki/M%C3%A9thode_agile">les méthodes agiles</a></li> <li><a href="http://www.aubryconseil.com/dotclear/index.php/2008/04/14/401-contrat-au-forfait-et-demarche-agile">avantage d’un contrat au forfait et démarche agile</a></li> <li><a href="http://www.aubryconseil.com/dotclear/index.php/2006/07/12/58-agilite-pour-un-contrat-au-forfait">agilité pour un contrat au forfait</a></li> </ul> <h2>Citations</h2> <ul> <li><a href="http://www.lemagit.fr/article/developpement-contrats-projets/3029/1/methodes-agiles-comment-donner-agilite-contrat-forfait-partie">article dans Le Mag IT</a></li> </ul> jacques tag:jacques.witte.usineweb.fr,2008-02-11:9 2008-02-11T08:05:00Z 2009-02-03T18:58:13Z

<p>Les méthodes agiles (extreme programing, et autres) sont en vogue, elles ont le vent en poupe et une tempête d’articles et de livres voit le jour, et rafraîchit, synthétise, améliore nos façons de travailler au sein d’une équipe… Mais, à la vérité, on oublie souvent de citer les conditions nécessaires à la mise en place de l’agilité dans une entreprise:</p>

<p>Les méthodes agiles (extreme programing, et autres) sont en vogue, elles ont le vent en poupe et une tempête d’articles et de livres voit le jour, et rafraîchit, synthétise, améliore nos façons de travailler au sein d’une équipe… Mais, à la vérité, on oublie souvent de citer les conditions nécessaires à la mise en place de l’agilité dans une entreprise:</p> <p>Les méthodes agiles (extreme programing, et autres) sont en vogue, elles ont le vent en poupe et une tempête d’articles et de livres voit le jour, et rafraîchit, synthétise, améliore nos façons de travailler au sein d’une équipe… Mais, à la vérité, on oublie souvent de citer les conditions nécessaires à la mise en place de l’agilité dans une entreprise:</p> <ul> <li>une équipe réduite: 6-7 personnes, c’est à dire le nombre limite jusqu’où l’information peut être diffusé sans réunion formelle. Ceci évite le travail perdu (mauvaise interprétation de l’objectif) ou en double (par défaut de communication entre les collègues)</li> </ul> <ul> <li>une équipe transversale: maitrisant verticalement le produit, de sa conception à son déploiement. Car l’agilité se brise très facilement sur les temps de latence inter-service (pour les entreprise dont la masse critique les pousse à opérer un cloisonnement par service système, réseau, développement, design,...)</li> </ul> <ul> <li> une équipe expérimenté: composé de moitié de seniors, car seul l’experience n’est pas transmissible… et nombre des méthodes agiles nécéssite une pratique consommé du principe d’utilisation des outils de travail (agl, source versionning, ticketing système), de la compréhension du rythme (roadmap produit) , du cycle de vie d’un produit (R&D, dévelopement, exploitation, support) et d’une maitrise de son infrastructure (poste de travail, serveurs d’intégration continue, de recettage, de production,...)</li> </ul> <p>Enfin, d’un point de vue ressources humaines, sauf cas exceptionnel, les équipes existantes d’un service (d’une entreprise) ne deviennent jamais agiles parce qu’on le décrète, mais elles nécéssitent d’être:</p> <ul> <li> (re) structuré, dès le départ dans cette philosophie de travail, chacun des membre travaillant en addition l’un de l’autre et non en concurrence</li> </ul> <ul> <li> stable dans le temps du projet</li> </ul> <ul> <li>impermeable aux autres problématiques de l’entreprise</li> </ul> <p>En conclusion, le ticket d’entrée pour mettre en place les méthodes agiles semble assez cher mais offre pour le décideur une version plus palpable de la tryptique: “une équipe” &lt;=&gt; “un produit” &lt;=&gt; “un budget”, et ses avantages inhérants:</p> <ul> <li> renforce le sentiment des collaborateurs d’appartenance à un projet commun, dont le résultat de chacun est visible (culture du résultat)</li> </ul> <ul> <li>permet plus de marge de manoeuvre pour motiver les équipes lors des phases critiques du projet (décision stratégique, livraison, urgence, ...) un peu comme on le fait le monde du btp (mécanisme incitatif au respect des dates de livraison)</li> </ul> <ul> <li> permet de maîtriser les dérapages financiers (budget maximum pour une durée donnée)</li> </ul> <ul> <li> évite une ligne hierachique trop longue nuisible aux remontés d’informations (feedback) indispensable aux comités de pilotages</li> </ul>