tag:blogger.com,1999:blog-59403595475543169602024-02-20T08:28:45.118-05:00Génération Agile BlogueBlogue qui cherche à promouvoir et à expliquer les méthodologies Agiles.Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.comBlogger37125tag:blogger.com,1999:blog-5940359547554316960.post-10970435348190800262010-07-13T11:25:00.000-04:002011-12-06T10:07:01.639-05:00Lancement du site corporatif<meta equiv="refresh" content="0;url=http://nouvelleaddressedublog.com/"></meta>
Nous avons lancé un nouveau site corporatif à l’adresse suivante : http://www.generationagile.com et par ce fait, nous avons aussi déplacé notre blogue à http://generationagile.com/blogue-de-generation-agile/ et son flux RSS : http://generationagile.com/feed/<br />
<br />
Nous vous invitons à le changer dans vos lecteurs de flux et bien surs, continuer à nous suivre. Mais, surtout, continuer à nous apporter vos lumières avec tous vos commentaires judicieux.<br />
<br />
MERCI de votre compréhension et au plaisir, de continuer à échanger avec nous.<br />
<br />
<br />
L’équipe de Génération Agile.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-87944741265830896562010-07-05T12:20:00.002-04:002010-07-05T12:20:40.595-04:00Les comités d'architectures, pour ou contre.Les comités d'architectures, pour ou contre.<br />
<br />
On dit en méthodologies Agiles qu'on doit prioriser le travail d'équipes. Mais, à quel prix ? Surtout quand et comment, on parle d'architecture logicielle.<br />
<br />
Un architecte logiciel au sien d'une équipe traditionnelle est le maitre après Dieu. Il est surtout le maitre désign logiciel. C'est lui, éminence grise, sur ce domaine. Les autres membres de l'équipe n'ont qu'à appliquer ce que ce « Dieu » a décidé.<br />
<br />
En plus, de son travail s'effectue en début de projets. Où il met les grandes lignes de l'architecture (L'ARCHITECTURE LGOCIEL) et puis s'en va du projet. Et dans de très rares cas, lorsqu'on est vraiment chanceux et que le projet est long (conséquemment très gros). Et parfois, il reviendra en cours de projet, pour faire une revue d'architecture.<br />
<br />
Mais, disons que cette stratégie n'est pas vraiment « Agile ». Mais, certaines organisations pour aider (ou favoriser) le travail d'équipe. Mais aussi la compréhension des membres des équipes de développement. Elle forme de ce qu'on appelle des comités d'architecture.<br />
<br />
Un comité où les membres, indépendamment de leurs niveaux de compétences, s'assoient ensemble pour construire l'architecture du logiciel et bien sûr la mettre en œuvre. Arriver à un consensus sur les différents choix d’architectures nécessaire aux projets.<br />
<br />
J'avoue que dans certains contextes et lorsque l'équipe est restreinte, cela peut fonctionner. Par contre, si l'équipe est trop grande, que la disparité des compétences (surtout en architecture logiciel) ne s'égale pas. On peut tomber dans le piège de la réunitivite. La maladie des réunions qui s'étire pour n'arriver à aucun consensus.<br />
<br />
Donc, c’est quoi le compromis qu'il faut faire. Je sais, vous voulez une solution toute faite. Mais, si vous êtes lecteurs réguliers de mon blogue, vous savez que je ne donne jamais de solutions toutes faites. Je propose généralement une approche plutôt qu'une solution.<br />
<br />
Mais, c'est quoi le rôle de l'architecte logiciel au sein d'une équipe Agile. D'abord concevoir cette architecture logiciel, je sais c’est évident. Mais, c'est bien de se le rappeler. Mais, contrairement aux environnements traditionnels. Il n'est pas le « DIEU » de l'architecture. Mais, l'expert aux SERVICES, oui aux SERVICES des autres membres de l'équipe.<br />
<br />
De plus, son intervention aux projets de ne doit pas se limiter à une p'tite vite en début de projet. Mais, tout au long du projet. Il est au service de l’équipe et de ses membres<br />
<br />
Donc, l'approche que j’utilise (oui je suis aussi Architecte logiciel « Agile ») et qui fonctionne avec les équipes dans lesquelles je l'ai appliqué. C'est que je conçois seul une première version de l'Architecture. Une fois conçu, je la présente oui, à un comité d'architecte « RESTREINT ». Il est généralement composé de 2 à 3 autres personnes (membre de l'équipe bien sur), ceux qui sont les plus expérimentés ou qui peuvent apporter quelque chose aux discussions.<br />
<br />
Je présente toujours le concept d’architecture, en disant que je leur présente ma vision pour leur faire valider. Je suis à leur service et non l'inverse. Le but de cette première rencontre, c’est d'établir les bases de « NOTRE » vision de l'architecture logicielle. Lorsqu'il est nécessaire, nous pouvons ensemble la raffiner.<br />
Une fois que cette petite équipe est arrivée à un consensus. Je dis bien un consensus, peut-être pas à la véritable architecture. Mais, les premières bases qui doivent être mises en début de projet. Elles seront et devront être raffinées en cours de projet. J'utilise cette approche à chaque phase importante d'architecture. <br />
<br />
Tout faire en équipe, c'est philosophiquement bien. Mais, impossible à appliquer correctement dans le monde réel. Si nous sommes trop nombreux à discuter ensemble pour des choses simples. Il risque fort qu'on consomme du temps inutilement. Prendre de faire la sélection d'un groupe de composantes ou des grandes lignes d'architectures. Nous n'avons pas besoin d'avoir l'opinion de chacun des membres. Au besoin, leur poser individuellement la question, pourra très bien suffire <br />
<br />
Il faut prendre le temps d'évaluer la rentabilité des efforts et le temps consommé aux projets. N'oublions pas, notre « ULTIME » but c'est de produire un logiciel. Ne pas faire, des réunions justes pour faire réunion.<br />
<br />
En résumé, faire des comités d'architectures logiciels, oui, seulement lorsque c'est nécessaire. Rappelez-vous de vous poser les questions suivantes.<br />
<br />
Pourquoi je fais quelque chose ?<br />
<br />
Pour qui je le fais ce quelque chose?<br />
<br />
Et surtout comment on doit fait la chose ?<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-65282204314590566832010-06-14T15:21:00.000-04:002010-06-14T15:21:42.178-04:00Un chef et son buffet de services, un buffet de services AgileUn chef et son buffet de services, un buffet de services Agile <br />
<br />
Ce petit concept pour parler d’Agile, commence à faire du bruit sans que vous sachiez qui en est l’auteur! <br />
<br />
Donc, comme je suis à l’origine de cette analogie, j’ai le devoir de vous expliquer ce qu’elle soutient. <br />
<br />
Qui d’entre vous est déjà allé au restaurant ! Et une fois arrivé dans ce restant, vous vous trouvez devant 2 problématiques. Soit vous vous retrouvez dans un restaurant qui ne sert pas ce que vous pensiez y manger ou ne savez pas quoi manger. Mais encore, le serveur ne vous apporte pas le plat commandé! <br />
<br />
Trop souvent en informatique et malheureusement en méthodologie Agile, vous vivez (vous les clients) ce genre de situations désagréables. Vous voulez vous lancer en dans cette aventure. Mais, vous ne savez pas comment et encore moins quelles implémentations prendre.<br />
<br />
Donc, c’est pour cela que j’ai réfléchie à comment apporter une solution à ce problème et bien entendu , d'une manière Agile. <br />
<br />
Premier constat, nous ne pouvons pas savoir ce dont vous avez besoin sans que nous vous l’ayons demandé. Mais, il ne suffit pas de demander, il faut aussi beaucoup écouter. <br />
<br />
Deuxième constat, votre besoin peut et va changer ! Donc, pour être en concordance avec le principe de la réactivité aux changes (en référence au Manifeste Agile) que je dois donc vous offrir une solution qui suivra cette évolution. <br />
<br />
En reprenant l’exemple du restaurant, je peux préparer un excellent menu, d’excellent mets. Mais, lorsqu'arrive le temps de choisir , il peut arriver que ce que j’ai préparé ne vous convienne pas exactement. Là sera mon vrai rôle de conseiller, de chef Agile en vous orientant vers de combinaisons qui pourraient répondre à votre besoin. Et si nécessaire; après tout, j’ai de très bons fournisseurs de produits alimentaires; je pourrai vous concocter une recette bien à vous. Une combinaison de méthodologies agiles (ou juste une seule) qui permettra d’adresse votre problème. <br />
<br />
En Agile, il existe plusieurs méthodologies (Scrum, Leam, Kanban, XP, etc.) qui répondent chacune à différents besoins. Peut-être, l’une d’entre elle correspondra à votre besoin à certains moments. Et plus tard, dans le projet, se sera le tour d’une autre.<br />
<br />
Mais choisir la bonne méthodologie Agile, c’est comme arrivé devant un buffet lorsqu’on est affamé ! On veut tout avoir, tout gouter, de l'entrée au dessert, en passant la petite soupe là-bas ! <br />
<br />
Si nous mangeons, nous goutons à toutes les choses comme des enfants, nous allons nous rendre malades. Et le problème (notre faim) que nous voulions résoudre pourrait être la cause de beaucoup d’autres. Dans ce cas-ci, potentiellement des maux de ventre pour avoir trop mangé. <br />
<br />
Vouloir essayer toutes les méthodes, de demander à Pierre, Jean, Jacques n’est pas la solution. Mais, si vous arrivez aux buffets et que vous demandez, conseille à un chef d’expériences. Il vous fera surement découvrir des nouvelles choses, des nouvelles combinaisons que vous n’auriez jamais pensé d’essayer. <br />
<br />
Si vous avez encore faim après la première, la deuxième assiette, vous pourrez en reprendre ou changer selon votre goût. Même chose, pour les méthodologies Agiles. <br />
<br />
Imaginer, 10, 100 personnes qui arrive au buffet, croirez-vous sincèrement quelle prendront exactement la même chose devant l'éventail choix qui sont mis à leur disposition. Chacun de vos projets est unique. Donc, il faut appliquer de manière unique les méthodologies Agiles.<br />
<br />
Donc, Agile et ses implémentations méthodologiques (SCRUM, XP, LEAN,Kanban, Crystal Clear et autres) doivent s'adapter à votre besoin au moment de votre commande. Au besoin, on pourra changer de chef, changer d’ingrédients, inventer, mixer avec l’aide d’experts pour trouver la recette! La recette qui vous permettra d’atteindre l’objectif de créer un logiciel qui correspond à vos besoins. <br />
<br />
Je m'engage à vous concocter la recette dont vous aurez besoin au moment. <br />
<br />
Aujourd’hui, vous avez le goût de manger quoi, vous avez besoin de combler quelle problématique ?<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-83436039326421799252010-05-23T12:10:00.003-04:002010-05-23T12:14:15.976-04:00Quelle est le meilleur outil pour construire le Web ?Quelle est le meilleur outil pour construire le Web ?<br />
<br />
Lors du dernier #WEBCAMP #QC, cette question a été lancée. Il y a eu un débat intéressant !<br />
<br />
Mais, j'aimerais si vous me permettez, d'y réponde en plus de 140 caractères.<br />
<br />
Toujours lorsque me pose ce genre de question, je réponds à peu près la même réponse. « un petit calepin, un crayon, mes deux (2) oreilles et mon équipe ».<br />
<br />
Car, avant toute de choses, l'origine de l'application web que nous voulons construire est un « CLIENT ». Sans lui, il n'y aurait pas de projet !<br />
<br />
Mes 2 oreilles me permettent l'écouter, mon calepin et mon crayon prendre des notes sur son besoin. C'est seulement après pris conscience de son besoin que je puisse enfin choisir qu'elle sera le meilleur outil pour répondre à son besoin.<br />
<br />
Peut-être parfois, je prendrai des plates-formes #OpenSource ! D'autres du .Net ou même du Java (J2EE). Mais, peu importe vers quoi se tournera mon choix, il devra absolument répondre à ces critères.<br />
<br />
1-Techniquement et efficacement rentable pour mon Client ! Si pour arriver à construire l'application qui rempli son besoin ! Que parce que j'ai choisi le langage « X » dans l'environnement « Y », le projet me prend 6 mois de plus avec des « Gourous » qui seront seules à comprendre ce qu'ils font. À mes yeux, je me tire dans le pied.<br />
<br />
2-Une fois le projet terminé ! Est-ce que le client ou encore une équipe réduire, sera capable de supporter et d'entretenir l'application et son environnement ! J'ai trop vu souvent ! De belles applications, qui faisait pour quelque chose de simple (informatiquement parlant) et qui demandait une armée pour la supporter. Et là, je ne parle pas d'une plate forme de gestion de grandes entreprises. !<br />
<br />
3-Mes choix technologiques sont-ils compatibles avec l'environnement de mon Client. Exemple, si mon client est ORACLE-JAVA-LINUX-Progress mur à mur, et que je lui arrive avec une application construire en ASP.NET sur une base de données SQL SERVER. Comme on dit l'application a besoin d'être belle ..!<br />
<br />
4-L'expertise, l'expertise (les ressources humaines) nécessaire pour la mettre en œuvre existe-t-elle sur le marché local ou régional de MON CLIENT. Si mon client est perdu dans le Grand Nord et les seuls programmeurs qui peuvent l'aider et qui habite sa région, ne connaît que le PHP. Je n'irais pas l'écrire en JSF parce que tout simplement moi j'aime ça. On attache nos clients par la qualité des services qu'on lui rend et non par notre expertise technique qu'on possède.<br />
<br />
5-Le web existe depuis longtemps, il a vu passé plus d'un langage ! C Pour faire les CGI-BIN, de l'ASP standard, Java pour faire des applets et tout le reste. La question n'est pas de répondre qui est le meilleur ! Mais, qui est le meilleur aujourd'hui ! Si refaisons le projet dans un an, dans 2 ans nos choix seront peut-être différents.<br />
<br />
Je fais du Web depuis presque ses débuts ..! Et malgré toutes ces années, je n'ai pas trouvé le LANGAGE DE PROGRAMMATION meilleur que tous les autres. J'en ai juste trouve certain mieux adapter pour répondre à un besoin ou à contexte donné.<br />
Rappelez-vous, le langage de programmation est un outil et non un moyen. L'outil est remplaçable par un autre. Quant au moyen, c'est la seule manière de faire la chose.<br />
<br />
En résumé, ayez un bon coffre à outils !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com2tag:blogger.com,1999:blog-5940359547554316960.post-80758206467352961422010-05-23T11:29:00.016-04:002010-05-24T13:16:50.401-04:00Invitation aux blogueurs participants aux #WEBCAMP #QCJ'invite tous les blogueurs qui étaient présents aux dernières #WEBCAMP #QC de faire ressortir la connaissance et ce qu'ils ont retenu de leurs expériences de cette belle aventure.<br />
<br />
Nous étions 400 chanceux en salle, plusieurs autres en ligne. Mais, tout cela ne doit pas s'arrête là !<br />
<br />
Le Web continue à vivre et à évoluer ! Donc, servons-nous de cette belle réflexion collective qu'est le #WEBCAMP #QC et rédigeons ensemble des billets à la garder active et pour la prospérité !<br />
<br />
Je vous invite aussi à utiliser les tags suivant #WEBCAMP #QC #after et m'envoyer un lien vers vos billets. Il me fera le plus grand plaisir de les ajouter en référence aux bas de ce billet.<br />
<br />
Allez procréer, faisons-nous ensemble d'excellents billets sur cette journée épique !<br />
<br />
<br />
<table boder="1"><tbody>
<tr><td><a href="http://twitter.com/PRESENTability">Denis F. Gravel</a></td><td><a href="http://bit.ly/8ZJuwf">WebCamp Québec Live – 19 mai 2010</a></td></tr>
<tr><td><a href="http://twitter.com/Generationagile">Bruno Larouche</a></td><td><a href="http://bit.ly/91E4J7">Quelle est le meilleur outil pour construire le Web ?</a></td></tr>
<tr><td><a href="http://twitter.com/jparent">Jonathan Parent</a></td><td><a href="http://bit.ly/9Npn94">Entrevue de Jonathan Parent suite aux #webcamp</a></td></tr>
<tr><td><a href="http://twitter.com/MarioAsselin">Mario Asselin</a></td><td><a href="http://bit.ly/df7ium">D'un WebCamp à l'autre...</a></td></tr>
<tr><td><a href="http://www.synchro-blogue.com/synchro/author/sandrabellefoy">Sandra Bellefoy</a></td><td><a href="http://www.synchro-blogue.com/synchro/2010/05/twitter-le-webcamp-de-quebec.html">« Twitter » le WebCamp de Québec…</a></td></tr>
<tr><td><a href="http://www.synchro-blogue.com/synchro/author/sandrabellefoy">Sandra Bellefoy</a></td><td><a href="http://www.synchro-blogue.com/synchro/2010/05/autour-dun-webcamp-quebecois.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Synchro-blogue+(Synchro-blogue)">Autour d’un WebCamp québécois…</a></td></tr>
<tr><td><a href="http://twitter.com/jfvrville">@jfvrville</a></td><td><a href="http://jfverville.com/2010/05/2eme-edition-du-webcamp-quebec-reussie/">2ème édition du Webcamp Québec réussie</a></td></tr>
<tr><td><a href="http://lejournaldequebec.canoe.ca/">journal de Québec</a></td><td><a href="http://lejournaldequebec.canoe.ca/journaldequebec/actualites/quebec/archives/2010/05/20100519-122703.html">WebCamp 2010: le happening web de Québec</a></td></tr>
<tr><td><a href="http://www.Cyberpresse.ca/">Cyberpresse</a></td><td><a href="http://www.quebechebdo.com/article-457859-Les-professionnels-du-web-campent-au-G.html">La politique a encore peur des médias sociaux</a></td></tr>
<tr><td><a href="http://www.quebectaime.com">Billet de Québec t’aime</a></td><td><a href="http://www.quebectaime.com/2010/05/20/all-your-%C2%AB-webcamp-%C2%BB-are-belong-to-us/">All your "WebCamp" are belong to us</a></td></tr>
<tr><td><a href="http://twitter.com/pgregoire">Patrick Grégoire</a></td><td><a href="http://www.patrickgregoire.com/index.php/2010/05/retour-sur-mon-webcamp-quebec-400-passionnes-de-web-se-rencontrent/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+PatrickGregoire+(Patrick+Gr%C3%A9goire+-+RSS+-+Abonnez+vous+aux+nouvelles)">Retour sur mon Webcamp Québec : 400 passionnés de Web se rencontrent</a></td></tr>
</tbody></table><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-60673650139893443352010-05-10T21:32:00.001-04:002010-05-23T11:39:02.690-04:00Mutatis mutandis, une réflexion sur le WebCamp de Québec<div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Le 19 mai prochain, environ 400 professionnels de tous acabits de l’industrie du Web se réuniront dans une conférence participative de type BarCamp, ce sera donc une belle occasion pour tous de discuter. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">L’objectif de ce genre de conférence est souvent partagé sur un domaine donné. Dans le cas qui nous intéresse, ils échangeront sur le Web. Mais si, aujourd’hui nous amorcions ensemble une réflexion le WebCamp, n’on pas pour le changer, mais juste pour poser un nouveau regard. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Un regarde de ce qui devrait être changé. C’est là l’essence de cette expression latine. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">« En change ce qui doit être changé, </span>et d’apprendre<span lang="RU"> la différence de ce qu’il ne l’est pas ». Le changement </span>c’est <span lang="RU">bien, pourtant il ne faut le faire sans réflexion à prime à bord. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Le Web arrivera bientôt à son âge adulte. Longtemps, il a été un monde réservé aux Geeks tant </span>pour <span lang="RU">son utilisation que son exploitation. Progressivement, il s’est démocratisé à tous les niveaux. Il passa du programmeur jusqu’à l’artiste pour se rendre jusqu’à l’utilisateur. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">La science de jadis devient un art ! Les techniques inaccessibles qu’aux professionnels devient facile</span>ment<span lang="RU"> utilisable par nos utilisateurs. Donc, aujourd’hui, demain, et pourquoi pas le 19 mai prochain. Nous devons apporter une réflexion sur ce qu’il serait intéressant pour l’aider à devenir grand. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">De venir en grand, en mettant en place des outils, des stratégies de développement et différentes actions pour enfin qu’on puisse dirent : « Adulte, tu es maintenant ! » au sujet du Web. Et je crois que c’est une belle occasion, ce WebCamp de Québec. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Avec les années plus</span>ieurs<span lang="RU"> outils ont été mise à la disposition de toute personne qui s’intéressait aux technologies Internet. Du simple </span>« vi »<span lang="RU"> (éditeur en mode ligne d’Unix) pour écrire le HTML jusqu’au CMS le plus sophistiqué par exemple WordPress ou Drupal. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Des langages de programmation pour les types de programmeurs, avec Framework pour faire à peu près tout ce qu’on voudrait faire dans ce merveilleux monde du Web. En passant de l’open source </span>jusqu<span lang="RU">’aux distributions commerciales. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Je ne crois pas qu’il y a un meilleur langage qu’une autre, il n’y a qu’un meilleur pour combler le besoin dans l’environnement technologique et organisationnel qu’il doit être livré. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Avec l’ensemble des outils qui sont mis à notre disposition, nous devons passer du travail de l’artisan à un travail plus professionnel. Cependant, il plus que le temps de mettre en place des stratégies, surtout des stratégies de développements. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Des stratégies qui ramèneront les principaux intéressés à leur place respective. Bien sûr, l’utilisateur final, c’est lui qui utilisera ce que nous allons construire. Sans oublie, les différents membres de l’équipe ou des équipes qui construiront le site Web ou l’application</span> et bien sur le client qui payera le projet.<o:p></o:p></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Bien sûr les méthodologies Agiles font partie de ces stratégies sans pour autant en être la seule. Le choix d’une stratégie doit être basé le partage. Le partage entre les individus, le partage d’information de données, le partage entre les organisations. L’échange et la communication doivent être au cœur même de cette stratégie. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Il faut aussi profiter des acquis qui se sont faits aux files des années. Aujourd’hui, nous ne devons pas toujours réinventer la roue. Plusieurs </span>des <span lang="RU">choses, </span>des <span lang="RU">bonnes et </span>des <span lang="RU">mauvaises</span>. Mais, il faut<span lang="RU"> pren</span>dre <span lang="RU">le temps de valider leur utilisation. En prenant conscience que nous ne sommes p</span>lus<span lang="RU"> seules. Que peut-être quelqu’un à déjà résolu le même problème que nous</span> avons<span lang="RU">. Ou encore, qu</span>e notre solution<span lang="RU"> pourrait aussi servir à quelqu’un d’autre. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">De l’open source aux formats ouverts, en passant architectures orientées services (incluant les environnements « clouds computing ») jusqu’aux différents réseaux sociaux. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Plus d’un changement cogne à nos portes, nous ne pouvons pas (ou plus) faire la sourde oreille. Les gouvernements, les grandes entreprises comme la petite doivent prendre le temps d’évaluer toutes les solutions. Même les solutions qu’il n’y pas si longtemps, ne semblaient pas acceptable. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">N’oublions pas, le Web n’est plus seulement dans nos ordinateurs bien assis à nos bureaux (au travail ou à la maison). Aujourd’hui, avec un ordinateur portable et un accès WIFI</span> on peut avoir accès presque partout<span lang="RU">. Et ce n’est plus seulement l’ordinateur qui nous donne accès ce merveilleux monde ! <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Du petit téléphone intelligent, en passant les tablettes PC ou le fameux IPAD. </span>Et même, la télévision qui servira bientôt comme terminal pour naviguer sur Internet. En plus, programme télévisé qui sont webdiffusé. <o:p></o:p></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">La TÉLÉVISION qui s’annonce de se présenter dans le WEB et bien sûr le présenter aussi ! </span>Nous n’avons qu’à penser ToutTv.com démontré ce point.<span lang="RU"><o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Mais, il ne faut pas oublier notre ami Google que presque chaque jour, repousse les limites. Une vraie « vague » d’évolution que nous ne sommes pas les seules à utiliser. Il n’est pas loin, le jour où un client va nous demander une application comme Google Earth. Car, lui aussi l’utilise maintenant. <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU"> <o:p></o:p></span></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><span lang="RU">Je ne sais pas ce comment</span> demain<span lang="RU"> sera fait. Mais, une chose est sûre ! C</span>e<span lang="RU"> sera au moins Web. Donc, c’est important de tenir des activités comme le WebCamp</span> et d’y apporter une réflexion sur le changement en cours.<o:p></o:p></div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;"><br />
</div><div class="MsoNormal" style="mso-margin-bottom-alt: auto;">Au plaisir de discuter avec vous au WebCamp. <span lang="RU"><o:p></o:p></span></div><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-89967820062495422202010-04-24T18:44:00.000-04:002010-04-24T18:44:30.076-04:00Si vous me racontiez une petite histoire ?C’est souvent comment, j’aborde mes séances d’ « User Storie » avec des usagers. <br />
Au cours des prochaines lignes de ce billet, je vais essayer d’apporter mes lumières sur l’utilisation de cette méthodologie d’identifications de besoins et des fonctions de l’application des utilisateurs. <br />
Beaucoup de gens plus traditionnels on peur de s’y impliquer trop à font ou encore ne savent pas comment le faire, sans embarqué dans dans une spirale de besoins. Ou encore pire, en utilisant un langage trop compliquer pour l’utilisateur. <br />
L’utilisateur moyen comprend souvent mieux son son travail que le pense ! Pourquoi pas, de lui proposer une technique simple pour nous l’expliquer. Si on leur permet de nous parler, sans qu’ils sentent moins compétant ou inférieur à nous. Généralement, ils vont nous faire de belles surprises. Nous connaissons l’informatique, mais eux connaisse leur domaine. Notre logiciel doit s’adapter à leur besoin et aussi à leur domaine d’affaires. Laissons-les-nous en parler ! <br />
Les histoires utilisateurs (ou en anglais « User Stories ») permet de créer cet environnement facilitateur, et ce, sans l’utilisation d’outils complexes. Il est rare de trouver une personne qui est incapable de parler ce qu’il fait à tous les jours. <br />
Qui ne sait pas dessiner grossièrement un écran juste pour donner un premier ébauche de ce quoi il pourrait ressembler. Mais, surtout prendre le temps d’écouter l’utilisateur sur ce qu’ils voudraient en faire. <br />
<br />
Car, n’oublions pas, notre quête ultime dans cet exercice, c’est de livrer en fin de projet la meilleure application. La meilleure application qui correspond tant aux besoins de notre utilisateur. Mais, aussi selon contexte organisationnel (incluant sa capacité de payer aussi). <br />
Trop souvent pour atteindre cet objectif, on utilisait un jargon trop technique; peut-être pour nous monter un peu trop savant ! Mais en restreignant notre langage à celui que tout le monde peut comprendre et surtout l’utilisateur. Il sera vite à l’aise de nous parle de toutes ses préoccupations. Il sera toujours temps d’écrire une belle documentation pour conserver ou officialiser ce besoin. <br />
Nous en méthodologies Agiles, nous acceptons le changement. C’est vrai. Mais, plus rapidement ce changement arrive. Mais, aussi sa compréhension devient claire plus vite nous adapter dans le projet. Plus, nous aurons la capacité de l’adresser et d’y faire face. Plus auront la facilité d’atteindre notre objectif final.<br />
Cette belle histoire que l’usager va nous raconter. Elle ne doit pas être laissée à tous les vents. Mais, accompagner tant dans son traitement que dans son discours. On peut bien raconter, les contes des mille et une nuits. Si cela n’apporte rien à la compréhension, cela ne sert à rien. <br />
Il aussi intéressant, de permet à l’occasion de parler de sont travail d’une manière plus générale. Car, en racontant ces petits à côtés. À une oreille, bien à viser, on peut découvrir bien choses qui vont nous aider dans notre quête. <br />
J’aime bien entendre raconter mon utilisateur ce qu’il fait en prenant son café en arrivant le matin. J’y ai découvert de vraies petites perles. Souvent même, sans que l’utilisateur se rendre compte de ce qu’il m’avait raconté, de l’importance de son histoire. <br />
<br />
Raconter une histoire, c’est bien beau. Mais, comment faut-il le faire. Comme dit l’expression, nous avons deux oreilles et une bouche. C’est qu’il faut écoute 2 fois plus qu’on parle. Prendre des notes au besoin, des petits schémas, de petits dessins et l’utilisateur n’y voit pas d’inconvénient, enregistrer les conversations. <br />
Il faut aussi, bien sûr, prendre des notes de ce que l’utilisateur nous explique. La manière le plus simplement, c’est par l’utilisation de grand Post-it ou d’un tableau. Si vous utiliser un tableau, d’apporter une caméra pour prendre une photo de ce qui a été écrit au tableau. C’est important de garder ces grands Post-it ou photos pour conserver une trace de ce qu’il a été discuté avec les utilisateurs. <br />
Il est très conseillé de limiter à 4 ou 5 points de formes par fiche. On se croit toujours avoir une mémoire très supérieur à la réalité. Mais, il est facile de se rappeler de l’information comprise dans 4-5 items. Plus que ça, il sera difficile de combler l’information des points formes. <br />
Et quand on dit, des points de forme. On ne dit pas de romans. Il faut se limiter à une ou deux phrases courtes. Une phrase d’actions et surtout affirmative. Nous voulons décrire ce qu’on veut faire et non l’inverse. <br />
Restons simples, restons Agile tant notre approche que dans nos actes. Et faisons- le ensemble, en impliquant l’utilisateur, nous atteindrons notre objectif. De créer la meilleure application pour notre utilisateur. Et j’en suis sur, il en sera d’autant satisfait. Car, il se sentira impliqué dès le début et jusqu’à la fin. <br />
Lors de ces séances d’ « user stories » vous ne devez pas diriger la conversation ou la rencontre. Mais, vous devez l’animer, idéalement nous en voulons toujours plus, avoir toute l’information d’un seule coup. Mais, parfois, il sera nécessaire, tant pour compréhension du système système ou domaine d’affaires. Ou parce que l’utilisateur avait plus d’information à nous donner. <br />
Il sera toujours le temps, d’en refaire une autre pour compléter ou même améliorer la compréhension du besoin. Parler, s’assoir avec notre utilisateur, lui donner l’occasion de nous parler de son besoin, c’est aussi ça d’être Agile. <br />
Avez-vous une petite histoire à me raconter ?<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-71189904867374653842010-03-16T18:55:00.001-04:002010-03-30T16:05:50.081-04:00L’intégralité de l’équipe de développements.L’un des principes à la base de SCRUM, est l’intégralité de l’équipe de développements pour la durée du cycle (l’itération).<br />
<br />
Mais, pour plusieurs organisations qui sont habituées d’avoir une mobilité des ressources en cas d’urgence. Cette impossibilité de bouger des individus durant la période du cycle pourrait être problématique. Beaucoup d’organisation ajuste leurs équipes selon les besoins du moment, surtout selon les urgences de l’organisation.<br />
<br />
Donc, demander à de telle organisation de respecter l’intégralité de l’équipe durant le cycle de développement. Ce n’est pas une chose facile.<br />
<br />
Je travaille comme consultant en informatique depuis plusieurs années, dans différentes organisations du Québec (province de Québec). Et il m’est arrivé de voir ou d’entendre parler des équipes qui évoluaient selon le besoin et les urgences de l’organisation.<br />
« L’expression on sait comme l’équipe est construite, au moment la regarde. La seconde d’après, elle peut changer. »<br />
<br />
Ce n’est pas mal en soi, mais toutes décisions organisationnelles à des conséquences positives et négatives. Comme on dit, je ne veux pas faire un procès à ces organisations. Mais, si elles veulent faire le passage à Agile. Ils devront effectuer une bonne réflexion sur les impacts que cela aura sur leur gestion des ressources et des impacts organisationnels.<br />
<br />
N’oublions pas que l’engagement est individuel, mais aussi en d’équipe. Donc, si nous brisons cette équipe, l’engagement ne risque de plus tenir. En agile, les individus qui composent l’équipe ne sont pas juste un numéro remplaçable. Mais, une personne importante au sein du projet et que les autres membres compte sur ces efforts pour mener à bien le projet, ou le cycle. Une équipe SCRUM qui s’engage sur la livraison d’une série de taches. Elle fait sur la base de la confiance que chacun à envers les autres.<br />
<br />
Donc, lorsqu’on me parle, qu’on me demande de briser cette intégralité. Je demande toujours. Si tu t’engages à livrer quelque chose avec une personne, et le lendemain, je la changerais. Est-ce que cela affecterait ta capacité à livrer, mais surtout la confiance de le faire ?<br />
<br />
Je n’ai jamais eu personne qui n’avait pas d’impact sur son travail ou sa vision du projet. Par conséquent, j’accompagne toujours mes clients afin qu’ils comprennent et acceptent les inconvénients et les avantages, avant de lancer dans un premier projet Agile.<br />
<br />
Et de notre coté, nous devons prendre aussi conscience que pour certaine organisation, souvent pour les petites, c’est difficile voir impossible de respecter cette intégrité de l’équipe.<br />
<br />
En conclusion, il n’a pas de solutions parfaites pour gérer cette intégralité. Il faut juste trouver votre solution à vous. Tout en cherchant, à viser l’intégralité complète de l’équipe de développement.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-88658551236035295992010-03-16T18:24:00.001-04:002010-03-30T16:08:10.457-04:00L’intégralité organique, fonctionnelle, une petite définition.<div class="MsoNormal">Suite à la rédaction d’un billet sur la <a href="http://generationagile.blogspot.com/2010/03/la-revue-de-code-ce-nest-pas-l.html">revue de code</a> et dans laquelle je parlais d’intégralité organique et fonctionne du code. Et j’ai reçu un commentaire judicieux d’une personne qui me demandait d’expliquer ces concepts.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Donc, voici ma vision (une définition qui n’en est pas une) sur ces deux concepts.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Commençons par l’intégralité fonctionnelle. Lorsque nous écrivons du code. Nous ne le faisons pas parce que cela fait joli. Pour démontrer, que nous capable de faire des algorithmes complexes, du code qui ne sert à rien, juste écrire du code. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Une fonction, une classe ou simplement quelques lignes doivent avoir un objectif à remplir. Si j’écris la fonction SupprimerLesEspacesDansUneChaine (la fameuse fonction « TRIM »). Son objectif est de supprimer les espaces dans une chaine et la retourner à la fin, une fois le traitement terminé.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Dans notre exemple, on ne devrait jamais trouver du code pour le calcul de Pi dans cette fonction. Par contre, elle doit contenir le traitement de validations des entrées et une gestion d’erreurs adéquates.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">On doit aussi avoir les outils qui démontrent l’atteinte d’objectif. Ce n’est pas juste la parole de son programmeur qui le valide. Souvent, je conseille d’avoir de petits programmes de tests (Unit Test and Fonctionnal Test). Mais, une série d’exemples d’utilisation, lorsque c’est une classe ou fonction d’utilités (la fonction « Trim », ne fait rien de spécifique dans l’application. Mais, elle aide d’autre traitement à atteindre leur objectif à eux.) </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Cette intégralité fonctionnelle devrait être couverte par les tests unitaires bien sûr. Mais aussi, par des tests fonctionnels; automatiser si possible. Il est intéressant, de conserver une copie des tests et de leurs résultats aux fins d’archives.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">L’intégration organique (ou logiciel), couvre plusieurs aspects. Bien entendu, le respect de la nomenclature de l’écrire du code (Nom de la classe, des fonctions et méthodes, des variables, etc).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Mais, il faut aussi vérifier que le code produit, ne compile pas juste le poste du développeur qui l’a écrit. Il doit aussi compiler dans les environnements continus ou sur les « Build Machines ». J’ai déjà vu du code qui compilait sur tous les postes des développeurs. Mais, lorsque nous avions voulu, faire une version officielle avec la Build Machine. Ça avait fait « Boom », le code ne compilait pas du tout.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Pourtant, ce code avait révisé par toute l’équipe. Il respectait les standards de programmations. Mais, il n’avait jamais été compilé entièrement avec les sources de la version officielle qui était pour la livraison chez les clients.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">L’autre aspect souvent oublié, c’est la manière de faire les choses. Beaucoup, d’organisation on des librairies de composantes utilitaires. Et il faut les utiliser, lorsque nous travaillons.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Par exemple, on a beau avoir construit la meilleure fonction de validation d’un NAS (Numéro d’Assurance sociale). Si nous n’avons pas utilisé, la fonction standard de l’organisation. A mes yeux, nous avons un problème d’intégrité organique (ou logiciel).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Il faut chercher à ne jamais réinventer la roue. Il faut l’utilisé au besoin, encore plus en orientés objets avec les principes de la surcharge et de l’héritage.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">L’autre aspect, les fameux algorithmes géniaux. Mais, donc le nom du programmeur est marqué en dessous. A moins, que nous lancions une fusée sur Mars. Je n’aime pas voir, du code que seul le programmeur qui l’a écrit comprend. Que pour toutes corrections ou modifications, nous avons besoin de lui.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Nous devons toujours écrire, du code pour les 10 programmeurs qui vont faire la maintenance de celui-ci. Il existe encore du code qui a été écrit avec des cartes perforées. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">La continuité du désigne est aussi une autre chose importante. Les architectes ou les concepteurs des modèles organiques de l’application. Ne sont pas toujours à côté des programmeurs, lorsqu’ils ont besoins d’ajouter une classe ou une fonction dans cet ensemble.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Dans un mode idéal, je sais que c’est la responsabilité du concepteur de prendre cette décision. Mais, nous savons tous qu’en tant programmeur ou analyste qu’il arrive parfois de prendre cette décision sans l’approbation immédiate du concepteur.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Il faut voir l’intégralité comme une gestion des impacts du code produit dans le reste de l’application ou de la solution logiciel.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Et je me répète, encore et encore, les programmes de tests avec leurs résultats sont aussi importants.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Donc, l’intégralité fonctionnelle et organique d’un code est bien plus que le regarde de la qualité d’écriture du code lui-même. C’est une vue d’ensemble dans la validation du code produit.</div><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-5036882418019435752010-03-13T21:52:00.008-05:002010-03-16T18:27:12.394-04:00<div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">La revue de code, ce n’est pas l’Inquisition !</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">L’une des bonnes pratiques des méthodologies Agiles et de l’Extrem Programming, est la révision de code.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Mais, souvent la révision de code est utilisée comme une forme d’Inquisition, une forme de dictature par certains membres de l’équipe.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Les principes qui sont derrière la révision de code ont le but de vérifier le respect des standards de programmations, de la simplicité des algorithmes et ainsi que de la compréhension générale de l’ensemble du code produit par l’équipe.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Elle permet aussi d’augmenter les compétences générales des membres de l’équipe. On peut s’en servir pour aider et former des membres qui ont moins d’expériences.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Mais, malheureusement, dans certaine équipe, certains coéquipiers qui ont un égo trop grand, se serve de cette technique comme une forme d’Inquisition en vers les gens moins expérimentés ou moins forts techniquement qu'eux.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">J’ai même vu que certains l’utilisaient pour régler des conflits personnels. Quelle horreur !</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">La révision de code doit suivre aux minimums ces règles.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Le réviseur doit avoir une compétence égale ou supérieure de celui dont il révise le code. C’est aussi un exercice de formations.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">La révision est une recommandation, n’est pas un acte de dieux. Encore moins une condamnation par les pairs. La personne révisée peut, et a le droit de discuter toutes les corrections demandées par le réviseur. Il est même recommandé que cette discussion s’effectue en équipe.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Le réviseur NE DOIT JAMAIS modifier lui-même le code révisé. S’il y a des modifications ou des améliorations à faire sur une partie ou l’intégralité du code, c’est la responsabilité de l’auteur du code. Je répète, le réviseur NE DOIT PAS CORRIGER lui-même le code révisé. Si on veut que l’auteur s’améliore, il doit lui-même faire les corrections.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">La révision de code ne doit pas se limité au fichier de code (le support) mais aussi sont<a href="http://generationagile.blogspot.com/2010/03/lintegralite-organique-fonctionnelle.html">intégration</a>, tant organique que fonctionnel dans le reste du projet. L’intégration organique est respect de la culture technique du projet. L’intégration fonctionnelle est le respect de l’objectif de la fonction, de la classe révisée.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">On doit aussi inclure dans la révision de la qualité de la documentation. Pas la révision du français ou de l’anglais, oui, la documentation doit être bien écrite. Mais, elle doit aussi aider la compréhension du code qu’elle documente. C’est souvent la partie que les gens oublient. Pourtant, elle est aussi importante que le code lui-même. Car, elle servira à la maintenance de celui-ci.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">La recommandation de révision doit toujours être faite par écrit. Premièrement, un texte écrit permet de réduire l’émotivité que les paroles directes ne permettent pas toujours. Et deuxièmement, le texte pourra servir pour le suivi, l’augmentation de la connaissance générale et bien sûr la maintenance du code.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Mais le plus IMPORTANT, toute transmission de révision à une autre personne doit se faire dans le plus GRAND RESPECT. Je dis toujours à mes réviseurs, imaginer que c’est pour vous que vous recevez cette recommandation que vous avez écrite. Donc, comment aimeriez-vous la recevoir ?</span></li>
</ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">En utilisant, cette technique dans un profond respect de tous les membres de l’équipe. Nous allons t’en renforcer la compétence moyenne de l’équipe que de l’esprit d’équipe.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">Car, lorsqu’il y a confiance mutuelle au sein de l’équipe, les membres de celle-ci n’ont plus peur de demander de l’aide. Cette demande s’effectue tout naturellement. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><o:p><span style="font-family: 'Times New Roman';"></span></o:p></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; text-align: justify;"><span style="font-family: 'Times New Roman';">De plus, la qualité va aussi augment progressivement. Ce qui va réduire tant le temps de révision que le temps de corrections subséquentes. L’expérience m’a démontré que si on prend le temps de bien le faire et surtout dans le fait dans un profond RESPECT, cette technique est plus que profitable.</span></div><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com2tag:blogger.com,1999:blog-5940359547554316960.post-88712055317906474422010-03-11T13:21:00.007-05:002010-03-30T16:11:59.602-04:00Le “Pair Programming” revu et visité !<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">L’une des grandes forces de la méthodologie « Extrem Programming (XP) », est bien sont “Pair Programming” ou d’une mauvaise traduction, la programmation en duo.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Pour avoir travaillé en ce monde, je suis conscience tant de sa puissance que de ses forces. Un bon duo pourra rapidement acquérir un rendement de 2.5 à 3 fois, et peut-être plus, leur cumul du travail individuel. <span style="mso-spacerun: yes;"></span>Mais, il faut une bonne complémentarité dans l’équipe.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Dans nos grandes organisations avec leurs grands projets, il est facile de trouver les individus qui fonctionneront bien sur ce principe. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Mais, lorsque nous intervenons dans de plus petites organisations, avec les effectifs réduits et aussi le budget d’autant réduit. Il est difficile d’immobiliser, 2 ressources sur une même tâche. Même, si à moyen terme, serait plus efficace.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Prenons par exemple un projet de 700-800 jours/personnes, environ 1 an avec 4-5 ressources. Il est difficile de doubler le nombre de ressources pour faire du « Pair Programming ».<span style="mso-spacerun: yes;"> </span>Et le temps total du projet (d’autant si c’est la première expérience ensemble des pairs), elle risquerait de ne pas trouver leur vitesse de croisière <span style="mso-spacerun: yes;"></span>tant recherchée.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Donc, comment tirer parti de cette force, sans pour autant immobiliser les 2 ressources en même temps.<span style="mso-spacerun: yes;"> </span>C’est une question que je vais tenter de répondre avec vous.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Faisons ensemble les constats des forces de cette paire, et essayons d’en tirer parti au mieux.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">On dit qu’il y a<span style="mso-spacerun: yes;"> </span>plus<span style="mso-spacerun: yes;"> </span>dans 2 têtes que dans une. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">Qu’en travaillant à 2 sur un même ordinateur, la qualité intrinsèque du code et des algorithmes augmente</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;"><span style="mso-spacerun: yes;"></span>Si une personne est absente, surtout lors d’une absence prolongée. L’autre personne peut continuer où l’équipe avait laissé.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l2 level1 lfo1; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">L’Augmentation du rendement, augmentation de l’efficacité. </span></li>
</ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Révisons ensemble cette liste. Essayons d’en exploiter les forces, sans passer à l’absolue du « Pair Programming »</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt; tab-stops: 353.25pt;"></div><span style="font-family: Times New Roman;"></span><br />
<ol style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">« On dit qu’il y a<span style="mso-spacerun: yes;"> </span>plus<span style="mso-spacerun: yes;"> </span>dans 2 têtes que dans une. »<span style="mso-spacerun: yes;"> </span>Par cette expression, on parle souvent du cumul de connaissance, du cumul d’expérience.</span></li>
<ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Même si les gens ne travaillent pas en pair, il n’est pas interdit de faciliter le travail collectif.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Il est recommandé de mettre en place une structure, ou des structures qui permettent l’échange d’information comme les Wikis, les forums à l’interne de votre organisation. Ne paniquez pas, il existe de bonnes solutions opens sources qui pourront vous aider à les mettre en place</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">lorsqu’il y a un problème, qu’une personne ne réussis pas à résoudre toute seule, il n’est pas interdit (même recommander) de demander l’aider.<span style="mso-spacerun: yes;"> </span>Utiliser momentanément le travail par pair pour résoudre le problème.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Après tout, nous n’avons pas besoin du « pair programming » pour travailler en équipe, ensemble !</span></li>
</ul></ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<ol start="2" style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">La qualité du code et des algorithmes.</span></li>
<ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">La qualité du code, et des algorithmes est souvent 2 choses qui sont problématiques dans le développement logiciel. </span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Les programmeurs ont souvent le syndrome de « DIEU », en croyant que leur code et leurs algorithmes sont les meilleurs. Mais, c’est FAUX. Le code fait par une personne n’est pas la solution ultime. L’équipe de doit avoir une connaissance générale du travail de tous ces membres !</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Une autre technique que contient XP (Extrem Programming), c’est la revue de code.<span style="mso-spacerun: yes;"> </span>Elle permet en groupe ou par un autre membre de l’équipe une revue du code.</span></li>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Une bonne revue de code devrait compter au minimum ces critères.</span></li>
</ul></ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: Times New Roman;">i.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Revue des standards de codification</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">ii.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Le respect de la nomenclature de l’application.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">iii.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">La simplicité de compréhension et la qualité des algorithmes.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">iv.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">La documentation intrinsèque du code et autre documentation nécessaire à sa compréhension.</span></div><ol start="2" style="margin-top: 0cm;" type="1"><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Ce que ce n’est pas une revue de code</span></li>
</ul></ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">i.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Un exercice pour démontrer l’incompétence d’un individu</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">ii.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Un procès, une vengeance entre individus.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 108pt; mso-list: l0 level3 lfo2; mso-text-indent-alt: -9.0pt; tab-stops: list 108.0pt; text-indent: -108pt;"><span style="mso-list: Ignore;"><span style="font-family: 'Times New Roman';"></span><span style="font-family: Times New Roman;">iii.<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Une amélioration du code par le réviseur. Le réviseur doit remettre ses recommandations de corrections à l’auteur. Il n’est jamais recommandé d’effectuer soi-même (Réviseur) les corrections à faire</span></div><ol start="2" style="margin-top: 0cm;" type="1"><ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level2 lfo2; tab-stops: list 72.0pt;"><span style="font-family: Times New Roman;">Les recommandations<span style="mso-spacerun: yes;"> </span>de corrections ou d’amélioration ne sont pas actes de Dieux. Elles doivent être considérées comme une « RECOMMANDATION », une « OBSERVATION » et surtout laisser la place à la discuter tant en équipe que dans la relation Révisé-Reviseur.</span></li>
</ul>
<li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">L’absence ou l’indisponibilité d’une ressource. Le calvaire de tout chargé de projets. Le pair programming nous aide, dans la gestion de cette non-disponibilité d’une ressource. Mais, lorsqu’on ne peut pas avoir 2 personnes qui font le travail, surtout en simultanées. Il est difficile de trouver de la remplacer aux pieds levés.</span></li>
</ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt 53.4pt; mso-list: l1 level1 lfo3; tab-stops: list 53.4pt; text-indent: -18pt;"><span style="font-family: Symbol; mso-fareast-font-family: Symbolfont-family:Symbol;"><span style="mso-list: Ignore;">·<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Une solution que j’applique dans ces cas là est le principe de la ressource et demi. Une ressource qui a la responsabilité première d’une tache. Généralement, la personne plus expérimentée du groupe.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 53.4pt; mso-list: l1 level1 lfo3; tab-stops: list 53.4pt; text-indent: -18pt;"><span style="font-family: Symbol; mso-fareast-font-family: Symbolfont-family:Symbol;"><span style="mso-list: Ignore;">·<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">A laquelle, s’ajoute une demi-ressource. Généralement, une personne moins expérimentée que la première. Mais, qui a toute la capacité de faire et surtout l’intérêt de le faire.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 53.4pt; mso-list: l1 level1 lfo3; tab-stops: list 53.4pt; text-indent: -18pt;"><span style="font-family: Symbol; mso-fareast-font-family: Symbolfont-family:Symbol;"><span style="mso-list: Ignore;">·<span style="font-family: 'Times New Roman';"> </span></span></span><span style="font-family: Times New Roman;">Le secret de la sauce, c’est la communication entre les 2. La demi-ressource doit avoir la capacité. Donc, la connaissance nécessaire du «quoi » et du « comment » des travaux.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 53.4pt; mso-list: l1 level1 lfo3; tab-stops: list 53.4pt; text-indent: -18pt;"></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 53.4pt; mso-list: l1 level1 lfo3; tab-stops: list 53.4pt; text-indent: -18pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<ol start="4" style="margin-top: 0cm;" type="1"><li class="MsoNormal" style="margin: 0cm 0cm 0pt; mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;"><span style="font-family: Times New Roman;">La fameuse augmentation de la capacité de travail. C’est plus que vrai, qu’il y a de possibilités d’un bon gain de performance. Mais, pour arriver au fameux gain tant attendu, il aura une transition, une adaptation. Car, il ne sera pas immédiat. Les 2 personnes devront apprendre à travailler ensemble. <span style="mso-spacerun: yes;"></span>Donc, si on inclut ce délai dans le calcul du gain de productivité. Je ne suis sûr qu’une petite organisation soit capable d’absorber les coûts durant cette transition afin d’atteindre la productivité attendue. </span></li>
</ol><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"><span style="font-family: Times New Roman;">Pour avoir mis en pratique le principe de la ressource et demi, à plusieurs reprises. C’est le<span style="mso-spacerun: yes;"> </span>meilleur compromis sur plusieurs aspects pour les petites organisations.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"><span style="font-family: Times New Roman;">Donc, en résumé, le « pair programming » c’est une excellente technique. Je vous la recommande, mais, tout comme application des principes Agiles. Il faut prendre le temps de bien évaluer nos besoins et d’aller chercher les outils dont on a besoin.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt 35.4pt;"><span style="font-family: Times New Roman;">Le « pair programming » n’est pas une religion ! Mais, une bonne pratique de développement !</span></div><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-28156490669911325302010-02-26T11:00:00.003-05:002010-02-26T11:55:00.266-05:00Une petite Game de poker ..! ça vous tente..!<p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Une petite Game de poker ..! ça vous tente..!<o:p></o:p></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Je vous rassure tout de suite, je n’ai pas l’intention de suggérer de jouer au poker au travail et tous autres jeux de ce genre.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Je parle plus tôt d’une technique d’évaluation de la complexité d’un projet appelée « Planning Poker ». C’est un exercice est basé sur une série de cartes, généralement base de 0, ½ , 1, 2,3,4,5,8,13,20, 40, ? (point d’interrogation) , Infini, pause café (carte joker). Certains jeux de cartes peuvent avoir une variance, mais l'idée reste la même. <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Les cartes permets aux différents membres de l’équipe d’évaluer l’ampleur ou la complexité d’une tâche donnée qui devrait normale être exécuté dans le sprint. Le but de cette activée n’est pas de faire planifier le projet et son ordonnancement par l’équipe de développement.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Comme on dit, plus il y a de têtes, plus on a de chance d’identifier les problèmes qui pourraient survenir, conséquemment les adresser rapidement. En utilisant une carte, pour émettre son évaluation, le membre de l’équipe ne subira pas l’influence des autres. Comme tout le monde retourne en même temps, ça carte, personne ne peut influencer l'autre.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Normalement, tous les membres de l’équipe de développement, le client (Product Owner), le chargé de projet et toutes personnes qui pourraient apporter un éclairage sur la problématique, qu’on doit résoudre, peuvent participer à cette séance. Mais, généralement on se limite à l’équipe élargie (Développement, plus product owner).<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Le déroulement de cet exercice est simple. Bien sûr, tous les participants doivent avoir son jeu de cartes. Le responsable du projet (ou le product owner) doit expliquer la tâche (histoire ou story) qu’on doit évaluer. Chacun, choisit une carte, qu’il garde cachée jusqu’au moment du dévoilement. Le choix doit corresponde tant à leur évaluation individuelle. Je dis souvent : « Comment, tu penses que c’est long à faire ? » Ce n'est pas juste une question de temps ! Mais, d'effort à consacrer pour le faire. <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><o:p> </o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">N'oubliez pas, que parfois, même si une tâche prend, exemple 6h. Il arrive parfois qu'elle demande un temps de préparation avant son accomplissement. Et aussi, un temps de déploiement pour l'équipe de tests. Il faut aussi prévoir ces tâches, soit en l'incluant dans l'évaluation de son parent ou encore en définissant une ou des tâches spécifiques.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Tout à l’heure, je vous ai énuméré la série. Mais, il y a quelque carte qui demande une certaine explication. Chacune des cartes représente une valeur en heures ou en unités, de zéro jusqu’à 40, parfois 100 sur certain jeux, avec des cartes spéciales, la carte infinie ou illimitée, la carte pause café, point d’interrogation. La notion d'unités est importante, tant pour des fins de planifications, que pour des comparaisons entrent les différents morceaux.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Les valeurs ½, 1, 2, 3, 5, 8, 13, 20, 40 ne demandent pas d’explications supplémentaires. Elle représente l’effort dans l’unité définie par l’équipe.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">La carte zéro possède quant à elle, une double signification ou peut-être plus selon les contextes. Elle peut signifier que je l’ai déjà fait, que j’ai déjà une librairie ou module dont on pourrait se servir, et surtout le temps d’intégration du projet est très court. La deuxième signification, c’est que la tâche en question est tellement simple qu’il n’est pas nécessaire de la planifier. <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Mais, par expérience, je ne recommande jamais son utilisation. Car, je ne connais très peux de tâches qui ont un temps d’intégration de zéro. Il m’arrive parfois de supprimer cette carte des jeux. Lorsque, j’organise une séance de « Planning Poker », je préviens tous les participants du coté légèrement pervers de la carte Zéro. Elle peut nous apporte une sur évaluation de nos compétences et de nos capacités. Je leurs suggère gentiment. Qu’il serait peut-être préférable lorsqu’il pense que la tâche est trop simple, de plus tôt utilisé la carte de ½ aux fins de sécurités.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">De l’autre côté, un peu par opposition, il existe la carte de l’infini. Généralement, selon l’expérience vécue, les gens l’utilisent quant ils n’ont qu’une vague idée ou qu'ils sont incapable d'estime la complexité.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Si lors du dévoilement, il y a plusieurs cartes infinies, cela indique généralement deux grands problèmes, la « story » est très mal compris par l’équipe, elle doit être précisée davantage. De plus, il semble que la complexité de tâche demande un raffinement, un découpage plus précis. Cette tâche est en problème, il serait conseillé de la reporter à cycle subséquent. Tout report d’une tâche doit accepter par le Product owner, et justifier en conséquence.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><o:p> </o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Ce jeu aide aussi à identifier les incompréhensions, tant des membres de l'équipe que des fonctionnalités intrinsèques et extrinsèques. Malgré, qu'il est recommandé de faire la séance sous un mode détendu. Le responsable du jeu doit avoir l'oeil ouvert pour détecter tous problèmes éventuels.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Une autre source d'indicateur de problème, est la carte point d’interrogation, signifie bien sûr que la personne n’a aucune idée de la complexité de la tâche ou encore quelque refuse de se commettre sur une évaluation. Lorsque qu’une ressource utilise cette carte, je la voix comme une lumière rouge, une alerte.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">J’interviens rapidement, pour identifier la nature de l’incompréhension. Car, s’il y a une personne qui choisit cette carte. A mes yeux, il ne doit pas être la seule personne qui n’a pas compris. Il faut immédiatement éclaircir la situation en interrogeant la personne.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Ce semblant de jeux aide souvent à voir la compréhension du projet que l’équipe possède. Il faut donc le faire, avec beaucoup de soin.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">La dernière et non la moindre, cette de la pause café.. ! La carte Joker par excellent ! L’évaluation de la complexité est une tâche complexe pour n’importe qui ! Encore plus, pour des programmeurs et analystes qui n’ont jamais eu à évaluer leurs travaux.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Donc, c’est important de permettre à tous les membres de l’équipe d’avoir, la possibilité de prendre une pause. L’esprit clair, il est plus facile d’avoir bon jugement. Il ne faut pas oublier que le travail d’équipe est important. Et les pauses aussi le sont autant.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">La définition de la valeur en heure ou en unité, à mon avis ce la n’a pas grande importance. Tant que vous convenez ensemble ce que veux dire tous ces cartes. Les deux choix, à mes yeux s’équivalant. Le plus important, s’est d’avoir une base de comparaison, un étalon.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Il faut établir une base de référence, trouver ensemble les bases que l’équipe pourra utiliser, pour comparer et mieux évaluer. Il est très recommandé qu’une fois établie cette référence, elle ne doit plus changer en cours de projets. Cette phrase n'est pas une loi, mais une forte recommandation. Cette charte de référence doit être comprise de tous et surtout être disponible à tous pour consultation. L’expérience des cycles aidera à mieux comprendre, tant la technique que sont application.<o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Mais, si après quelque cycle, ça ne fonctionne pas ! N’ayez pas peur d’arrêter ou de redonner les explications. Il faut que chacun comprenne que malgré les apparences, ce n’est pas jeux. C’est un exercice très important. Il existe d’autres méthodes pour l’évaluation de l’effort et de la compréhension de l’équipe. Bien utiliser, elle vous permettra tant l'appropriation de l'équipe des tâches à accomplir. Mais, aussi détecter des problèmes plus rapidement. <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"> <o:p></o:p></span></p> <p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;"><br /></span></p><p style="margin:0cm;margin-bottom:.0001pt;background:white"><span style="color:black;">Souvenez-vous que les méthodologies Agiles proposent plusieurs outils, il suffit de trouver le bon. Le Poker Planning est une bonne technique, mais elle ne convient pas à toutes les équipes et tous les projets. Trouvez-la bonne pour vous !</span></p><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-37629826716267052010-02-18T11:20:00.007-05:002010-03-30T16:15:38.535-04:00Agile et la modélisation, une première réflexion !<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Traditionnellement dans les projets, construire ou non, l’architecture (donc la modélisation) ne se posait pas comme question. Dès que le projet était assez gros, on lui affectait un architecte (ou une équipe d’architecte et de modélisateur) pour construire l’architecture logicielle. Leur responsabilité était d’effectuer la modélisation du logiciel et de la base de données pour tout le système. (L’architecte, bien entendu je ne parle pas de la personne, mais du ou des rôles au sein du projet).</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Durant cet exercice classique, l’architecte ou le modalisateur effectuait la conception du logiciel et de sa base de données. Un travail qui pouvait prendre beaucoup de temps. Un beau travail qui n’apporte rien au client, et ce, tant que le travail de programmation n’était pas commencé.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Mais en Agile, comme nous livrons des petits morceaux d’applications fonctionnelles par cycles. Il est difficile de penser qu’on peut faire toute la modélisation en début de projet. D’autant plus que de cycle en cycle, le besoin peut changer. Donc, ce qu’on aura modélisé au début (selon les approches classiques) risque de plus correspondent au besoin ou tout simplement être invalidé en cours de route.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Cette réflexion, pourrait <span style="mso-spacerun: yes;"></span>faire conclure plusieurs personnes qu’il n’est pas nécessaire d’effectuer la modélisation ou de créer une architecture logicielle. <span style="mso-spacerun: yes;"></span>Pourtant, même si nous sommes en Agile, elle demeure aussi importante. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Maintenant que nous sommes d’accord avec ce principe. Vous me direz comment, il faut le faire ? Je n’ai pas de techniques infaillibles. Mais, quelques principes que j’utilise selon le besoin. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Il y a plusieurs façons de faire cette modélisation, cette architecture logicielle. Mais, ce qui est généralement reconnu est de le faire selon le principe du juste à temps. C’est donc de faire ce qui est nécessaire pour le cycle. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Pour ma part, je conseille la règle du 110-120% nécessaire pour le cycle. L’excédentaire est une prévision pour le cycle suivant. 100% du besoin de ce que nous devons construire et 10-20% de mise en place des pièces qui seront nécessaires pour l’interconnexion des cycles suivants. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Par exemple, si nous travaillons sur la facette de la fiche Client. Il serait intéressant de prévoir les orientations des facettes commandes et facturations. Sans pour autant compléter le travail de ces dernières facettes.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Il arrive parfois pour le besoin du projet, nous avons besoin de mettre en place les bases ou les orientations d’architecture. Dans ce cas, n’ayez pas peur de faire un premier cycle consacré qui couvrira ces orientations. <span style="mso-spacerun: yes;"></span>Mais, surtout faire une modélisation qui pourra évoluer selon les besoins durant le déroulement du projet. Il sera toujours le temps de le faire dans le cycle qui touchera la facette concernée.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"><span style="font-family: 'Times New Roman'; font-size: 12pt; mso-ansi-language: FR-CA; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: FR-CA;">Construiriez-vous une application, s’en savoir où en aller ? S’en avoir une vision de l’architecture sur quoi baser votre développement. Bien sûr que non. Donc, faire de la modélisation va de soit. Pour ce faire, voici quelques techniques qui </span>peuvent vous aidez à faire cette modélisation. J’aime bien utiliser la modélisation par domaine pour la partie plus organique et les « <a href="http://en.wikipedia.org/wiki/User_story">User Story</a></span><span style="font-family: Times New Roman;"> » pour la partie plus fonctionnelle.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Une bonne référence qui vous permettra de mieux faire la lumière sur le comment de la modélisation en contexte Agile, je vous suggère cette référence en Anglais : <a href="http://www.agilemodeling.com/">Agile Modeling</a></span><span style="font-family: Times New Roman;">. Elle couvre beaucoup de techniques relatifs à cette approche.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Mais, surtout voyez cette référence, commune une autre boite d’outils, et non le moyen comment faire la modélisation. Être Agile, faire un projet en Agile, ce n’est pas d’abandonner vos bonnes pratiques. C’est simplement, parfois, de les utiliser différemment ! </span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">En autres mots, il ne faut pas chercher à tout réinventer toute la modélisation. Il suffit de restreinte sa pensée au besoin du cycle. Rappeler-le souvent à vos architectes classiques.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"></div><span style="font-family: Times New Roman;"></span><br />
<div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;"></span></div><div class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span style="font-family: Times New Roman;">Rappelez-vous la règle du rhinocéros. Il est difficile de le manger d’une seule bouchée, mais en toutes petites bouchées, c’est plus facile.</span></div><div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-38798458001836500142010-01-25T16:10:00.010-05:002010-03-30T16:16:52.842-04:00Agile, est-ce pour moi ?Il y a toujours beaucoup de préjugés auprès des gens lorsqu'on veut leur parler de se lancer ou simplement adopter les méthodologies Agiles. Souvent leur premier réflexe est de répondre que les méthodologies Agiles ce n'est pas pour eux.<br />
<br />
Combien de fois, un programmeur ou un analyste, m'a faites cette affirmation! Je ne le compte plus. <br />
<br />
Donc, essayons de réfléchir à qui s'adresse ces approches Agiles. <br />
<br />
Est-ce qu'ils ont raison ? Dans les faits, leur analyse n'est pas tout à fait fausse. Car, leur affirmation est souvent relatif à la dérivation SCRUM des approches Agiles.<br />
<br />
Donc, affirmer que SCRUM n'est pas pour soi. Cette affirmation n'est pas fausse. Il existe plusieurs méthodes qui dérivent des principes du manifeste Agile. Chacune d'entre elles adresse à une série de problèmes. Certaine sont plus adapté à la gestion projet (la gestion des livraisons), ex : SCRUM. Mais, il en existe plusieurs autres. <br />
<br />
Il faut choisir selon le contexte de notre environnement ou tout simplement de son travail à effectuer ! Par exemple, si nous sommes une ou deux personnes, sur un projet. Il n'est pas nécessaire d'utiliser Scrum (Scrum demande une équipe de 5 à 9 personnes) . Cette équipe n'a pas besoin d'une gestion complète de projet. L'utilisation d'une approche qui lui permettrait de produire une meilleure qualité du code et qui automatiserait certaines tâches routinières. Je crois, serait plus approprié. Il pourrait utiliser des approches comme Test Driven Developpement (TDD) et BDD (Behavior Driven Developpement) pour définir les différents besoins qu'ils doivent couvrir dans l'application développement.<br />
<br />
Prenons, un autre exemple. Une petite équipe (5 à 9 personnes) de développement qui cherche à construire une application commerciale (Software in boxe). Cette fois-ci, le besoin est différent. La simple utilisation des 2 méthodes précédemment citées (TDD et BDD), ne suffit pas. L'ajout d'une méthode de gestion de projets ou des livraisons comme SCRUM ou SCRUMBAN pourrait intéressant.<br />
<br />
L'utilisation des méthodologies Agiles, dans ses projets, est accessible à tout le monde. Que nous soyons chargés de projet, Analystes ou même programmeurs. Il suffit de prendre la méthode qui correspond à notre besoin.<br />
<br />
Donc, lorsqu'on m'affirme que les méthodologies Agiles ne sont pas pour eux. Ils ne peuvent pas utiliser ou appliquer, les méthodologies Agiles. Il faut (et au besoin se faire aider) prendre le temps de trouver la méthode qui nous convient. Et si on ne trouve pas, dans une seule méthode, ce qui nous convient. Il ne faut jamais hésiter d'en prendre une comme base, ex scrum (si nous sommes une équipe) et la complémenter avec une autre selon le besoin qu'on veut couvrir.<br />
<br />
Donc, affirmées que les méthodologies Agiles ne sont pas pour nous, signifie seulement que la connaissance ou l'analyse des approches Agiles qu'on a faites sont insuffisantes. Comme dans toutes choses, il faut prendre le temps d'analyser, de se documenter. <br />
<br />
Aujourd'hui, demain et dans l'avenir, les méthodologies Agiles sont là pour rester. Donc, nous devons s'y préparer ! Chacune sa méthodologie et les projets agiles iront encore mieux !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com2tag:blogger.com,1999:blog-5940359547554316960.post-47958843217660842522010-01-06T12:57:00.000-05:002010-01-06T12:58:08.819-05:00Mes petites résolutions Agiles pour l’an 2010.Quelle belle tradition que sont les résolutions du Nouvel An. J’ai eu donc l’idée de vous partager aujourd’hui quelque une de mes résolutions pour ce Nouvel An. Mais, surtout un pour une année que j’espère où les méthodologies agiles prendront encore plus la place qui lui revient.<br /><br />La première, nous (Moi, mon organisation, vous, tout le monde) à parler avec le plus de justesse possible des méthodologies Agiles. Quand nous voulons être une référence, il faut toujours vérifier ses affirmations et les baser sur la vérité, une vérité vérifiable.<br /><br />La deuxième, dépassé plus que la simple formation. Travailler avec les gens pour les accompagner à s’accaparer les méthodologies. Je crois que pour les méthodologies Agiles, prend la place qu’elles méritent. Les gens doivent s’accaparer un peu comme leur langue maternelle.<br /><br />La troisième, accompagner les gens ainsi que leur organisation, dans leurs choix et leurs transitions vers les méthodologies Agiles. Si vous le ne savez pas encore, choisir d’effectuer ce virage n’est pas une chose facile. Donc, les gens ont besoin de notre aide, mais surtout de notre accompagnement.<br /><br />La quatrième, continué, continué à expliquer, mais surtout à ÉCOUTER les gens qui s’intéresse aux méthodologies agiles. Comme dit le bon vieux proverbe, on a deux (2) oreilles et une bouche. Donc, on doit écouter deux (2) fois plus !<br /><br />Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.<br /><br />En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com2tag:blogger.com,1999:blog-5940359547554316960.post-1688503256878177742009-12-17T11:37:00.001-05:002009-12-17T11:41:59.382-05:00Un voeu pour la période des FêtesLa période des réjouissances de Noël et du Nouvel An arrive à grands pas. Ce matin même l’hiver nous le rappelle avec un -20C qu’on bel et bien dans cette période-là pour rester.<br /><br />Moi, Bruno Larouche, l’homme derrière Génération Agile et bien sur ce blogue, veut prendre quelque minute de votre temps pour vous souhaiter la plus joyeuse période de Noël et une année 2010 remplie de beaux projets Agile.<br /><br />Espérons tous ensemble que cette nouvelle arrive à grand soit une année où les différentes approches Agiles auront encore une plus grande progression. Mais, aussi acquerra une maturité tant dans les pratiques que pour les gens qui les utilisent.<br /><br />Je quitte aujourd'hui, pour une période de vacance qui je crois bien mérité. Je serais de retour le 4 janvier 2010 pour vous accompagner dans tous vos projets.<br /><br />Je nous souhaite tous une Belle Année AGILE.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com3tag:blogger.com,1999:blog-5940359547554316960.post-41814967153378318172009-12-07T13:40:00.003-05:002010-01-29T16:33:36.937-05:00Comment choisir son Coach Agile ?Je sais avec titre comme celui-là, beaucoup d’entre vous, vous attendez que je vais vous fournir une recette de cuisine ou encore une fiche à remplir pour aider à bien choisir votre Coach Agile. C’est bien mal me connaître. Je ne crois tout simplement pas aux procédures définies. Encore plus dans les différents processus de sélections des ressources humaines.<br /><br />Je vais plutôt vous aider à apporter une réflexion sur besoin spécifique d’un Coach Agile.<br /><br />À la base, les coachs agiles proviennent de différents profils. Souvent, ils proviennent de 2 grands profilés. La gestion de projets bien, mais aussi des architectes intégrateurs.<br /><br />Il faut prendre le temps d’évaluer vos besoins. Par exemple, si vous avez un problème de gestion de projets. Cherchez-en un, qui a été chargé de projet.<br /><br />Il faut aussi qu’il ait joué les différents rôles dans une équipe Agile. Il doit comprendre ce que chacun des rôles on fait. S’il n’a jamais été programmeur, comment, il pourra expliquer au programmeur l’impacte sur leur travail.<br /><br />Tout comme un chargé de projets devra avoir géré des projets dans un contexte agile ainsi hors des méthodologies agiles. Comme dit si bien, l’expression anglaise « a Jack work trail ». Plus, il aura occupé différents postes aux files de sa carrière, plus il sera en mesure d’expliquer les impacts dans le passage aux méthodologies agiles.<br /><br />La formation apporte beaucoup, mais elle ne remplacera jamais, l’expérience terrain. Tout comme, une certification Scrum Master ou autre certification du genre, à laquelle ne s’ajoute aucune expérience pratique, ne sont pas plus performant que si vous commander un livre chez Amazone.<br /><br />Un vieux proverbe disait : « Il y a des choses qui s’apprennent. Mais, qui ne se montre pas ! » C’est le cas, du coaching agile. Les meilleures formations, certifications, ne remplaceront jamais l’expérience.<br /><br />N’oubliez pas, que les méthodologies agiles, sont basées des approches de gestions et de bonnes pratiques. Donc, pas de règles rigides qu’on applique sans réfléchir. Par exemple, le Guide vert, donnent beaucoup d’exemples comment faire les choses, on peut s’y référer pour résoudre nos problèmes. Cette approche n’est pas prônée en Agile.<br /><br />Il est vrai aussi de dire que les méthodologies agiles possèdent beaucoup de documentations (livres, site web, blogue (comme le mien)). Mais, le rôle principal du Coach Agile, n’est pas d’appliquer les règles écrites. C’est d’apporter la lumière des interlignes, des problèmes que vous vivrez durant le projet.<br /><br />Je ne crois pas non plus au « GOUROU AGILE » qui arrive avec livre de recettes agiles. Comment on peut appliquer une recette magique, avec une équipe, une organisation, une technologie, etc. Applique une recette comme celles-là, va en l’en compte même des principes d’agiles. Chaque individus, organisation, projets sont différents les uns des autres. Donc, comment pourraient ton avoir un tel livre de recettes.<br /><br />S.V.P., n’applique une fiche des sélections pour recruter votre Coach Agile. C’est un non-sens à mes yeux. Rappelez-vous du principe numéro 1 du manifeste Agile : « L’interaction avec les personnes que les processus et les outils ».<br /><br />Rencontrez les ressources, discutées avec eux de leur vision et de leur philosophie. N’oubliez pas, cette personne aura un impact important dans votre organisation. Laisseriez-vous, votre concierge prendre la direction de votre compagnie sans vérifier ces compétences ? Le meilleur sera toujours celui avec qui vous pourrez vous assoir pour discuter du ou des problèmes. L'humain a la place #1 en agile. Donc, il faut que la communication passe entre vous et votre Coach Agile.<br /><br />En terminant, trouver un Coach Agile qui vous conviendra, ce n’est pas un processus facile. Il n’y pas de mauvais Coach Agile. Il y a un qui vous convient mieux que d’autres. Aussi, pourquoi pas, au lieu d’une seule personne, de faire intervenir une équipe avec diversifié et spécialité pour vous accompagner dans ce virage important pour votre organisation. Chacun des membres de cette équipe pourrait vous apporter une lumière sur différents axes.<br /><br />Comme toujours, soyez Agile dans votre réflexion et votre démarche.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-4220716413449213522009-11-20T19:17:00.004-05:002010-03-30T16:18:12.712-04:00Agile, de Haut jusqu’en bas, et Droite à Gauche.Beaucoup d’organisation qui se lance dans les méthodologies Agiles, oublie un facteur important dans leur adaptation de ces nouvelles approches.<br />
<br />
Beaucoup d’organisations qui démarrent un petit projet pilotent en Agile dans une équipe de développement. Oublie souvent, trop souvent, l’impact que cela peut avoir sur leur organisation.<br />
<br />
Tout passage Agile, même au sein d’une petite équipe de développement aura un impact sur l’organisation tout entier. <br />
<br />
Traditionnellement, les équipes de développement étaient dynamiques. C'est-à-dire qu’à tout moment, et souvent selon besoin momentané de l’organisation, être totalement réorganisés ou restructurés. Aux files du besoin ou des changements de l’organisation, les membres de l’équipe peuvent changer ou être remplacés durant la vie du projet. Mais, l’une des règles importantes en Agile, c’est justement l’intégrité de l’équipe. Normalement, il est très souhaitable que l’équipe reste intègre du début jusqu’à la du projet.<br />
<br />
Donc, cela a un impacte direct sur la gestion des ressources disponibles. Chaque membre s’engage en tant qu’individu et aussi à titre de membres de l’équipe à livrer une série de composantes. Donc, s’il manque une ou plusieurs personnes dans l'équipe, l’engagement ne peut plus tenir !<br />
<br />
Le second impact, est la disponibilité de la personne qui joue le rôle de product owner (méthodologie Scrum). Cette personne est aussi importante que tous autres membres de l’équipe. Il n’est jamais facile de libérer cette personne à cause de son expertise et sa connaissance du domaine d’affaires de l’entreprise.<br />
<br />
Mais pour acquérir cette expertise, ça veut dire aussi qu’il occupe une place importante au sein de l’organisation. Donc, il occupe une fonction qui peut-être difficile à redistribuer ou à replacer.<br />
<br />
Le dernier problème qu’il est difficile de réaliser avant sa mise en place. C’est la livraison fréquence et surtout beaucoup plus rapide de morceaux d’applications fonctionnelles. C’est bien beau sur le papier, mais en pratique, il apprendre à le gérer ces livraisons fréquentes. Avoir une application à tester tous les 6 à 12 mois, les organisations sont habituées. Mais, en avoir a testé, tous les 2, 4 ou 6 semaines, ce n’est pas la même chose.<br />
<br />
Comme vous le voyez, se lancer dans un processus de mise en place des méthodes Agiles, impacte bien de haut et bas, et de droite à gauche l’organisation.<br />
<br />
Bien entendu, l’impact pourra varier d’une organisation à une autre, mais l’expérience m’a démontré qu’elle dépassera l’équipe qui l’implémentera dans son projet de développement. Mais, une chose est sûre, il y aura un impact plus grand que seulement que dans l’équipe de développement. <br />
<br />
Je sais vous aller dire que je prêche pour ma paroisse. Mais, je vous recommande de vous joindre une personne d’expériences, une personne qui a tant de l’expertise technique en méthodologie Agile. Mais, qui a aussi de l’expérience en contexte organisationnel. Autrement dit-on bon mélange entre l’expertise organisationnelle (monde des affaires) et l’expertise en implémentation des approches Agiles.<br />
<br />
En terminant, rappelez-vous que vous faisiez des affaires avant l’implémentation des méthodologies Agiles et que vous devriez en faire encore après !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-61805258836202464032009-09-14T18:50:00.002-04:002010-01-29T16:41:31.168-05:00Agile, mais pourquoi ?Agile, mais pourquoi ?<br /><br />L’autre jour, un client m’a posé la question « Pourquoi, je m’étais tourné vers les méthodologies agiles? »<br /><br />Mais, c’est en lisant le billet de Nicolas Roberge sur son implication dans le Twestival. Que j’ai pensé d’écrire, moi aussi, pourquoi moi, je me suis intéressé aux méthodologies agiles. Lancer au point de l'inclure une partie dans mon nom de compagnie, la partie Agile, de Génération Agile, c'est bien pour les méthodologies agiles.<br /><br />Il y a de milliers de raisons pour effectuer ce virage. Mais, pour ma part, lorsque je l’ai fait (il y a maintenant plus de 8 ans), était un peu réactionnel. En réaction à différentes expériences que j'ai vécues, tant bonnes que mauvaises.<br /><br />J’ai vu plusieurs projets que pour livrer, nous avions du faire des heures de fous, plus 60 heures par semaines. Ou à l’inverse, être en attendre de quelque chose parce qu’il y avait eu un problème de planification.<br /><br />J’ai vécu plusieurs projets, où on était des numéros, des numéros remplaçables. Je me souviens au début quand j’ai choisi de faire carrière en informatique, je voulais avoir un « fun ». Être un acteur important dans les différents processus de création, pas simplement avoir l’impression de rentrer faire un travail à la chaine, être une machine qui produit quelque chose.<br /><br />Encore pire, j’ai vu un projet dans lequel, il fut construit une belle application, mais qui fut tabletté parce qu’elle ne répondait pas aux besoins finaux du client. A juger le nombre de personnes, qui ont travaillé sur le projet, c'était surement plus que le salaire moyen d'une ressource.<br /><br />Donc, c’est en réaction à ces divers problèmes, et encore bien d’autres, que j'ai voulu chercher une solution nouvelle. Cherchez à penser différemment le problème afin de lui apporter une nouvelle lumière.<br /><br />J’ai toujours cru, et je le crois encore qu’on doit mettre le client au centre du développement. Mais aussi, remettre l’humain dans les grands processus informatiques. Dès l’université, je cherchais toujours la meilleure façon de faire les choses, mais surtout en prenants soins mettre l’humain en tout haut de la liste des choses importantes dans un projet.<br /><br />Donc, c’est vraiment en réaction aux constats des problèmes, de mon inconfort à n’être qu’un numéro parmi tant d’autres. Comme je dis souvent, je suis capable de réfléchir, et je veux le faire.<br /><br />D’abord, j’ai fait mes devoirs en étudiant plus à fond les méthodes existantes pour savoir, comment on pourrait ramener l’être humain au centre du projet, tant le client et les ressources impliqués. Mais, la seule réponse que j’ai découverte c’était comment construire des documents pour gérer la communication. Mais, il suffit d’enfermer 2 personnes dans un local, tôt ou tard, ils se mettront à parler ensemble. Donc, laisse le naturel de l’humain aller. Je ne dis pas qu'il ne faut parfois structure la communication, mais là est un autre sujet.<br /><br />En partant, de ces principes tout simples, je suis parti à la quête d’une ou des nouvelles approches. Me souvenant, aussi de mon passage vers l’orienté objet, qu’il y avait surement quelqu’un quelle part qui avait fait la même réflexion. C’est ainsi que je suis tombé d'abord sur l’Extrem Programming (XP), puis quelqu’un temps après Scrum et les autres. Mais, c’est le jour que je suis tombé sur le manifeste agile que j’ai compris la base que je cherchais.<br /><br />Ce n’était pas la solution miracle, une réponse à toutes les questions que j’avais. Mais, une réflexion qui était basée sur les principes que je cherchais tant. J'ai continué ou je continue toujours à explorer et étudier les différentes méthodologies. Plus j'en apprends, et encore très régulièrement, je vous l'assure sur les méthodologies agiles, plus je deviens une personne qui croit qu'il faut s'en inspirer.<br /><br />L’expérience m’a démontré, et ce que je préconise toujours, de ne pas appliquer « by the book » l'une ou l'autre méthodologie, qu’elle soit agile ou non. Il ne faut jamais prendre tout argent comptant. Il faut rester l’esprit ouvert. Je citerais, en exemple mon prof d'université lorsqu'il parlait de modélisation, " la pureté est conceptuelle. Dès, qu'on descend au physique en perd !"<br /><br />C'est la même chose, pour une méthodologie, a pureté se trouve dans les livres, dès qu'on la descend, on doit réfléchir comment l'appliquer.<br /><br />Je ne considère pas que tant les méthodologies agiles que mes pensées sont parfaites. Mais, jusqu'à maintenant, selon mes critères, elle se rapproche le plus de ce que je recherche.<br /><br />Mais, afin d'entre sur, je présente ma vision, mes idées à qui veut bien m'écouter, je les écrits sur ce blogue dans la mer Internet jusqu'au jour, où je trouverais une meilleure solution ou encore qu'on m'en apportera une.<br /><br />En résumé, je me suis tourné vers les méthodologies agiles, n'ont pas pour faire différent. Mais, pour remettre le client et les ressources impliqués dans les projets aux premiers rangs. Et aussi, mettre en à côté, la qualité du travail et l'honneur du travail bien fait.<br /><br />Les méthodologies agiles, ce n'est peut-être pas pour tout le monde, mais moi, je m'y s'en alaise.<br /><br />Qui m'aime (aime les méthodologies agiles) , ... vient marcher à mes côtés..! Je ne suis pas, et je ne serais jamais un évangéliste et encore moins un prôneur de la vérité divine, surtout dans notre merveilleux monde de l'informatique.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-24362995418268348422009-08-11T12:36:00.009-04:002010-01-29T16:44:15.256-05:00Reconnaître l’autre ce n’est pas un crimeJe ne vous parlerais pas aujourd’hui des grands criminels et encore moins défendre les grands principes de l’agile d’un plan technique.<br /><br />Bien au contraire, c’est un peu l’autre côté de la médaille de l’honnête de le dire. Dans ce dernier article, je parlais qu’il faut dire la vérité sur nos connaissances et sur nos compétences.<br /><br />Il est vrai d’affirme la vérité sur soi-même. Mais, il est d’autant de l’affirmer sur l’autre. Comme dit si bien l’expression, rendons à César, ce qui appartient à César.<br /><br />Combien de héros inconnus dans nos projets jouent au sauveur, créé de petits miracles sans qu’on reconnaisse leurs talents et leurs acharnements à l’excellence. Pourtant beaucoup d'entre eux, vous dira qu’ils n’ont fait que leur travail.<br /><br />Mais, trop souvent, ils passent dans l’ombre. L’ombre d’un beau parleur, d’une forte tête ou tout simplement d’une personne qui était là (parfois malgré elle) au bon moment pour récolter les fleurs.<br /><br />Combien j’ai rencontré des personnes hyper compétentes, qui passaient pour des individus très moyens parce qu’ils n’ont une personnalité assez extravertie pour faire reconnaître leur talent.<br /><br />Je pense à ancien confrère de travail, qui est devenu par la suite mon ami (D. Vézina). A l’écouter parler, il est un programmeur bien moyen. Il me parle souvent de l’un et de l’autre qui sont de super programmeur.<br /><br />Et pourtant, lui et un autre programmeur du même gabarit, M. Falco, prônent tous deux en têtes de la liste de mon Dream Team. Avec ces 2-là, emmenez les projets.. !<br /><br />Vous avez aussi surement rencontré une personne, qui se tient debout devant les autres pour recevoir les coups, pour protéger les siens. Et quand, les honneurs arrivent (et s’ils arrivent) .. Elle est déjà partie mener un autre combat quelque part.<br /><br />Trop souvent, pour ne pas dire presque tout le temps, ce genre d’individus qui jouent au super héros de l’ombre, n’est et ne sera jamais reconnu. Personne ne prend le temps de leur dire simplement un petit merci. Un vrai merci de reconnaissance !<br /><br />Reconnaître ce que l’autre a ou fait, de la petite chose toute simple à aux grands exploits, devrait être naturel. Non seulement, naturel, mais être un devoir de chacun.<br /><br />Dire que l’autre, dans une situation donnée, dans un contexte donné est meilleur ou a mieux réussi que moi. Qu’il ou elle a des talents, des compétences que je n’ai pas. Cela ne m’enlève rien. Bien au contraire.<br /><br />Tout le monde aimerait avoir tous les talents de la terre, moi le premier. Mais, appliquons le principe d’Archimède. « Donnez-moi un levier assez long, et je soulèverai la terre. »<br /><br />Notre levier, ce n’est pas un bout bois, mais notre équipe, les membres de notre équipe. Et si chacun des individus reçoit avec honnêteté la reconnaissance qui lui revient, et ce, tout à fait gratuitement. Nous pourrons aussi accomplir le miracle de soulever la terre.<br /><br />Certain apporteront la force, d’autre le courage, certain l’intelligence, et peu importe l’apport. Si tout le monde le fait avec cœur, nous réussirons.<br /><br />Et terminant, je permets de préciser, si vous de l’avez pas déjà compris. Qu’il n’a jamais été questions ici, d’argent ou quelques choses de valeurs monétaires. Mais, du respect de l'autre.<br /><br />Et si on pensait différemment, aussi dans notre relation avec les autres.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com4tag:blogger.com,1999:blog-5940359547554316960.post-65473448274917125942009-08-11T12:25:00.004-04:002010-01-29T16:48:21.968-05:00L’honnêteté de le direTrop souvent on entant les programmeurs dirent, "on est capable de faire ça !" Même si on, fond d’eux, ils le savent très bien ! Ils n’ont aucune idée de qu’on on parle.<br /><br />Encore la semaine passée, une cliente m’a téléphoné, pour me demander si j’avais les connaissances dans un domaine très rare. Je savais très bien que si mon téléphone sonnait pour ce poste, c’est qu’elle était mal prise. Qu’elle n’avait pas trouvé de ressources pour combler le mandat.<br /><br />Je savais aussi que c’était un mandat dès plus payant, potentielle le double et plus de mon tarif habituel. Mais, parfois, il faut primer l’honnête aux mauvais argents.<br /><br />Elle le savait, et je le sais aussi, je connais beaucoup de choses. Mais, j’ai des spécialités. Mais aussi des incompétences. Elle est tombée dans un domaine que je ne connaissais pas. J’aurais pu faire comme bon nombre, accepter, lui charger le gros et me débrouiller !<br /><br />J’ai préféré de loin, et c’est que j’ai fait, de lui souhaitant bonne chance en déclinant son invitation.<br /><br />Longtemps, j’ai cru comme plusieurs, je tétais capable de tout faire. En travaillant assez fort, en mettant les heures qu’ils frauderaient, que j’y arriverais. C’est vrai, avec les années par contre. J’ai appris et surtout compris que j’avais des forces et des faiblesses. Même en cumulant les heures, les heures de fous. Ce serait inutile, cela ne suffirait pas.<br /><br />Et que si j’étais honnête avec moi-même, encore plus avec mes clients. Donc, lorsque je suis compétent pour faire « un job », je le dis. Et inversement aussi.<br /><br />La meilleure façon d’aider un client, ce n’est pas d’accepter tout ce qu’il propose, sans penser à nos incompétences. C’est d’être honnête avec lui, au besoin l’orienter vers une autre personne ou encore tout simplement, lui dire que vous n’êtes pas la bonne personne.<br /><br />C’est comme quand on va à la quincaillerie ou le centre de rénovation, et qu’on demande une information au premier commis rencontrer. Et qu’il commence par nous faire une litanie du rien et du complexe, au lieu de nous dire simplement. Qu’il ne comprend pas ou ne sait pas quoi répondre à notre question.<br /><br />J’essaie d’être le plus patient possible. Mais, comme tout le monde. Je finis par perdre patience et partir. C’est la même chose pour nos clients. Ils nous engagent pour nos connaissances, et non pour notre ignorance.<br /><br />Rappelons nous, et honnêtement bien sûr! Comment on réagit dans ce genre d’expérience.<br /><br />Il semble toujours plus facile, en apparence, de dire « oui boss, présent boss » à toutes demandes. Mais, je prends le pari qu’à long terme, si on est honnête avec nous même et surtout avec nos clients, nos affaires et l’informatique iront encore mieux. Soyons les vieux messieurs aux cheveux gris des centres de rénovations, qui prennent le temps de répondre et de trouver chez l’autre la réponse.<br /><br />Après tout, penser, différemment, c’est aussi pensé avec honnêteté !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com4tag:blogger.com,1999:blog-5940359547554316960.post-91427711432003293002009-07-29T17:27:00.002-04:002009-07-29T17:40:32.692-04:00Afin Québec sur la map Agile TourMerci mon Ami <a href="http://repensersondeveloppement.blogspot.com/2009/07/conference-agiletour-quebec-en-octobre.html">Dominique Asselin</a>, qui me rappelle d'annoncer la conférécence Agile Tour arrive à <a href="http://www.agiletour.org/en/quebec.html">Québec</a>.<br /><br />Je me promets de faire tout mon possible pour y assister ..! et peut-être participé à titre conférencier.<br /><br />Je fais donc appel, à vous mes lecteurs de ce blogue et je sais qu'ils font aussi l'appel de conférencier. Si vous voulez me voir débattre de ma vision des méthodologies Agiles, n'hésitez pas à me laisser un commentaire sur le sujet que vous voudriez me voir proposer et présenter.<br /><br />Au plaisir de vous voir nombreux !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-77239167774563397762009-07-28T18:54:00.018-04:002010-06-01T09:13:21.622-04:00On documente, quoi, quand et comment ?On documente, quoi, quand et comment ?<br />
<br />
Je ne compte plus le nombre de fois que j’ai attendu l’horreur suivante : « On est en agile, donc on ne fait pas de documentation ! »<br />
<br />
Mais, pourtant c’est justement en agile qu’il faut bien documenter. C’est un oxymoron, tant en agile qu’autrement de dire qu’on ne fait pas de documentation.<br />
<br />
Mais, ce n’est pas tout de dire qu’il faut documenter. Comme dans toutes choses il faut savoir comment, quand et surtout quoi !<br />
<br />
D'abord, revenons à la base, c’est quoi la fin ultime d’une bonne documentation.<br />
<br />
Généralement, une bonne documentation a deux fins. La première, c’est de créer un terrain d’entente, un langage commun entre les parties. On pourrait dire une forme de contrat sur qu’est ce qu’on va faire.<br />
<br />
La deuxième fin qu’on oublie souvent dans la documentation, c’est la maintenance de l’application ou du logiciel qu’on développe. Plusieurs statistiques démontrées que l’effort (le temps consacré à cet exercice) de la maintenance sera la phase la plus importante durant sa vie utile. Il y aura plus d’heures consacrées à la maintenance qu’au développement propre.<br />
<br />
Maintenant qu’on sait à quoi va servir la documentation. Donc, on peut se pencher sur le quoi !<br />
<br />
Prenons un petit exemple. Une petite application qui permet de saisir la fiche d’une employée. L’information nominative de l’employer. (Nom, prénom, coordonnées, etc.)<br />
<br />
Je ne suis pas sur qu’il est intéressant de document dans un long document, l’interface graphique en décrivant chacun des champs, une image de l'interface pourrait-être suffisant.<br />
<br />
Mais, à l’inverse, s’il y a une règle de validation de l’information entre elle. A titre d’exemple, une règle qui oblige la confirmation de l’information saisir par un directeur. Là c’est important de la documenter.<br />
<br />
Bien sûr, en plus de documenter la partie « fonctionnelle » de l’application. Il faut aussi documenter le code, la base de données.<br />
<br />
C’est intéressant et surtout nécessaire, de produire de la documentation. Mais, cela ne veut pas dire pour autant de tout décrire ou d’écrire dans un beau document produit avec Microsoft Word. On est des informaticiens pas des auteurs de romans savons.<br />
<br />
On peut utiliser Word, mais ce n’est pas le seul outil à notre disposition. Il en existe plein d’autres.<br />
<br />
Il faut là aussi être « agile » dans la production de la documentation. Il existe plusieurs outils qui sont capables de produire une base de documentation organique à partir des commentaires dans le code (oui, oui, il faut inscrire des commentaires. Rappelez-vous toujours qu’il y aura de la maintenance sur votre travail.)<br />
<br />
Les différents diagrammes UML bien produit peuvent aussi servir à cette base de documentation. Et il n’est pas nécessaire, de « TRADUIRE » en français un « cas d’utilisation » à 4 bulles (Création, Modification, Suppression, Recherche (CRUD)) d’un employé. Ne devons pas stupide à l’inverse.<br />
<br />
Une présentation PowerPoint pourrait aussi servir pour présenter un scénario (défilement des écrans) de navigations ou encore un arbre hiérarchique ou décisionnel. On dit bien qu’une image vaut mille mots. Rappelez-vous-en quand vous faites de la documentation.<br />
<br />
Et pour répondre, à la dernière question posée. Après tout, elle est aussi importante que les autres. Le fameux « QUAND ». Je me souviens, à l'université on la faisait toujours en dernier. Juste avant de partir pour aller porter notre travail au professeur.<br />
<br />
Beaucoup trop de gens, moi, aussi j’en étais un de ceux-là. Produise la documentation en catastrophe à la fin du projet et du bien livrable. Mais, est-ce que vous êtes relus les commentaires ou la documentation que vous aviez produite en catastrophe à la fin du bien livrable. Versus celle que vous aviez prise le temps de faire en produisant le code. N’oubliez pas, la mémoire est une faculté qui oublie. C’est beaucoup plus facile de documenter un algorithme quand elle fraiche à la mémoire.<br />
<br />
Le constat est facile à faire. La documentation produite en catastrophe reste toujours une documentation produite en catastrophe. Et celle que vous avez pris le temps de le faire, est souvent de qualité bien supérieure.<br />
<br />
Donc, la réponse est toute simple. La documentation n’est pas une punition, ce n’est pas un passage obligé. Mais, une chose aussi importante que le code en lui-même. Ce qui veut dire, on n’a pas besoin de répondre quand il faut produire la documentation.<br />
<br />
Car, elle doit être le faire tout le temps. Une règle forte simple qu’on m’a apprise et que je transmets encore aujourd’hui. Si tu regardes une ligne de code, une interface, un procédé et que ça prend plus de temps à le comprendre que ça t’a pris à le lire. Documente-les.<br />
<br />
Et surtout, ce n’est pas le temps d’écrire des romans, et encore moins des encyclopédies. Écrire simplement ce qui est nécessaire à la compréhension, de ce que tu dois documenter. En utilisant des points de formes, un tableau synthèse au besoin.<br />
<br />
En résumé, on document ce qui est important pour la compréhension du travail qui est à faire et de sa maintenance. Quand, tout le temps bien sûr.<br />
<br />
Et le comment, en se servant de l’outil qui rendra le mieux l’information qu’on doit transmettre. Laisser les figures de style shakespeariennes à Shakespeare lui-même !<br />
<br />
Allez documenter ..!<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-38141716117639201682009-07-27T17:16:00.002-04:002010-01-29T16:55:56.710-05:00Construire l’équipe c’est important aussi !En agile, construire l’équipe c’est important !<br /><br />Ce n’est plus un secret que de dire l’importance de bien construire une équipe, tant l’équipe de développement que l’équipe au tour (client, pilote, expert du domaine).<br /><br />Ce que je vais vous expliquer, ce n’est pas une manière de construire le « dream team Agile ». Mais, des choses qui vous aideront, je l’espère, à éviter des erreurs!<br /><br />Traditionnellement, une fois qu’on a identifié les compétences techniques, on recherchait les spécialistes qui possèdent ces compétences. On cherchait le meilleur qui était disponible.<br /><br />Souvent cette quête de compétence s’effectuait en parcourant les CV, les porte-folios. Une fois dénichée la perle rare, on passe au suivant, sans vérifier tant l’intérêt de l’individu. Et surtout, vérifiez la capacité interpersonnelle de l’individu. On n’avait vu que du papier, donc c’était difficile.<br /><br />Certain diront, que les individus suite à un mandat, leurs capacités interpersonnelles sont « ÉVALUÉ ». Mais, là encore on utilise des formulaires et du papier. En plus, la grille qui pourrait « Matcher » l’équipe n’existe pas.<br /><br />Comment faire donc ?<br /><br />La recette :<br /><br />Il faut continuer a faire la recherche technique. On ne demandera pas à un programmeur Cobol MVS d’aller faire du C++ pour construire un moteur 3D. Le projet a besoin des gens techniques pour réaliser ce qui doit être fait.<br /><br />Mais, au lieu de partir en quête du super meilleur spécialiste avec l’égo aussi gros que sa compétence technique. Recherchons, une compétence peut-être plus moyenne (mais qui est capable de faire la job !)<br /><br />Je préfère de loin une compétence moyenne techniquement, mais qui est toujours prêt à aider les autres. Et surtout, qu’il effectue un travail que tout le monde peut comprendre.<br /><br />Les spécialistes font souvent un excellent travail. Mais, ils sont souvent le seul à comprendre ce qu’ils font. Je m’amuse souvent à dire qu’ils signent leur travail et en indiquant le taux horaire pour effectuer la modification.<br /><br />Je préfère de loin un travail moyen que tout le monde peut corriger, à la superbe passe de code que seul son auteur comprend.<br /><br />Aux files de l’expérience, j’ai connu trop souvent ces supermans du code que par leur supériorité technique, les rendaient de très mauvais travailleurs d’équipes.<br /><br />En agile, tant l’individu que sa participation au sein de l’équipe.<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0tag:blogger.com,1999:blog-5940359547554316960.post-84808934368083372712009-07-27T17:13:00.000-04:002009-07-27T17:14:20.506-04:00La motivation des ressources !La motivation des ressources, une parte importante du travail en méthodologies agiles<br /><br />Mon grand-père disait, si on veut tuer un homme, il suffit de le payer à rien faire.<br /><br />Si on adapte son discours dans notre contexte. Il suffirait de payer une personne, et ce, peut importe la qualité ou le type de travail qu’il fait, son salaire est assuré.<br /><br />C’est un peu ce que vivent les fonctionnaires, ils ont acquis une telle sécurité d’emploi, qu’à la limite, ils ne peuvent rien faire et ils recevront leur chèque de paie.<br /><br />En plus de cela, le travail est surnormalisé, je suis sur que la tâche « réalimenter l’imprimante en papier » qui doit être inscrite dans le profile de quelqu’un.<br /><br />La conséquence négative d’une telle structure, s’est qu’elle ne laisse plus la place à l’initiative individuelle. Ils sont payés pour faire une « job » très définie. Et, lorsqu’il identifie un problème. Ils doivent transmettre l’information à leurs hiérarchies.<br /><br />Et plus la hiérarchie est complexée, et elle est aux gouvernements, plus l’information est difficile à circuler. Donc, le retour en est autant difficile.<br /><br />Le problème ne provient pas seulement du côté employeur, mais aussi de la parti syndical. Je crois que tout syndicat chercher avoir de bons soldats conforme les uns et les autres. Mais, très peu de généraux.<br /><br />Je ne suis pas en train de dire mettre la faute non plus sur le syndicat et encore moins, le mettre dehors nos gouvernements.<br /><br />Il faut chercher à briser ce cercle vicieux qui empêche les individus de faire, d’être des individus à part entières en laissant leurs libertés tant de manière individuelle que de groupe.<br /><br />Dans toutes choses, je le crois sincèrement, qu’il faut un équilibre. Selon le constat que j’ai vu trop souvent nous sommes rendus avec une trop grosse structure qui est impossible à bouger rapidement. L’une de qualités d’une équipe dite « agile » est juste cette liberté de mouvement.<br /><br />Comment y arriver, d’abord il faut améliorer les voies de communications. Pour ma part, je trouve très démotivant d’attendre des jours, parfois des semaines l’autorisation de pouvoir corriger ou encore la réponse à mon problème. Ma crainte, souvent fondée, de subir les foudres de mon gestionnaire de projet parce que j’ai pris du retard. Même si je ne suis pas responsable.<br /><br />Donc, dans ce genre de situation, au lieu de résoudre ou simplement le soulever, de peur de se faire reprocher. Il le laisse passer au suivant. Un peu disant c’est bien comme ça.<br />Ça revient à dire deux choses aux individus ne fait pas vagues et ne cherchent pas les problèmes. Fait uniquement, le travail qu’on t’a demandé. Autrement dit, un ordinateur-humain qui effectue un travail sans réfléchir. Il reçoit un intrant qui explique ce qu’il doit produit en extrant. Et tout ce qui sépare entre les deux, il ne doit qu’appliquer de recettes prédéfinies, et surtout prédéfinis par d’autres « supérieurs ».<br /><br />Une belle application de la méthode Ford, du travail à la chaine. Pourtant, la plupart des informaticiens (programmeur, analyste, DBA, architecte, etc) que je connais, sont des gens très créatifs.<br /><br />On m’a toujours appris que pour produire un bon logiciel, on avait besoin des gens créatifs.<br /><br />Quand je me retrouve avec la charge de ressources, je m’amuse à leur poser à chacun les 3 questions suivantes :<br /><br />Qu’est-ce que tu aimes faire, qu’est-ce qui te fait vraiment plaisir, à la limite jouir dans ton travail ?<br />Par exemple. Moi, je tripe à faire de l’architecture et modélisation de données.<br />Qu’est que tu n’aimes pas faire, une chose que tu vas repousser à la dernière minute tout le temps ?<br />Répéter des tests unitaires « Manuellement », une fois le programme fini. Je les fais toujours, mais cela ne veut pas dire que j’aime ça. Communément, appelez-la job de « plombier ».<br />Es-tu conscience, que je ne pourrais pas toujours te donner juste du fun. Il faut répartir de manière équitable ce travail moins intéressant.<br />Il y aussi des gens qui croient que leur donnent des choses plates c’est pour les punir. Mais, qu’elle soit fun ou non, tout travail mérite d’être bien fait.<br /><br />Trois petites questions en apparence qui sont anodines. Mais, parfois on peut découvrir que quelqu’un aime justement ce que les autres détestent par-dessus tout. L’expérience m’a démontré qu’on mais toujours plus de cœur à l’ouvrage pour les choses qu’on aime.<br /><br />Mais, dans nos gouvernements, ils ne s’intéressent pas à savoir ce que les gens aiment ou pas. Ils sont payés à produire ce qu’ils ont reçu en entrée. C’est tout.<br /><br />Autrement, ils sont payé, oui pour travailler, payer pour descendre des heures en produit la sortie de leur entrés s’est tout.<br /><br />J’ai cœur à croire, qu’il y a encore de gens qui ne sont pas trop tard. Que si on leur donnait la chance, il serait encore plus productif et créatif. Si seulement, ils avaient l’opportunité de faire quelque chose qui aime avec un peu de créativité.<br /><br />Je vous entant déjà crier, lever les barricades. Ici, je ne fais pas le procès de personnes. Je cherche simplement une voie de solution à problème que moi, j’ai vue après des fonctionnaires de nos différents paliers de gouvernements.<br />Comme toujours, vous avez une meilleure idée que moi, venez, nous en discuterons ensemble. Et, je réponds souvent, mon père sait tout.. Mais, il est aussi mort !<div class="blogger-post-footer">Bonne lecture à tous. L'équipe de Génération Agile !</div>Génération Agilehttp://www.blogger.com/profile/14093439757788825944noreply@blogger.com0