mardi 13 juillet 2010
Lancement du site corporatif
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.
MERCI de votre compréhension et au plaisir, de continuer à échanger avec nous.
L’équipe de Génération Agile.
lundi 5 juillet 2010
Les comités d'architectures, pour ou contre.
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.
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é.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
Pourquoi je fais quelque chose ?
Pour qui je le fais ce quelque chose?
Et surtout comment on doit fait la chose ?
lundi 14 juin 2010
Un chef et son buffet de services, un buffet de services Agile
Ce petit concept pour parler d’Agile, commence à faire du bruit sans que vous sachiez qui en est l’auteur!
Donc, comme je suis à l’origine de cette analogie, j’ai le devoir de vous expliquer ce qu’elle soutient.
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é!
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.
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.
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.
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.
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.
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.
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 !
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é.
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.
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.
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.
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.
Je m'engage à vous concocter la recette dont vous aurez besoin au moment.
Aujourd’hui, vous avez le goût de manger quoi, vous avez besoin de combler quelle problématique ?
dimanche 23 mai 2010
Quelle est le meilleur outil pour construire le Web ?
Lors du dernier #WEBCAMP #QC, cette question a été lancée. Il y a eu un débat intéressant !
Mais, j'aimerais si vous me permettez, d'y réponde en plus de 140 caractères.
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 ».
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 !
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.
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.
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.
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. !
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 ..!
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.
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.
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é.
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.
En résumé, ayez un bon coffre à outils !
Invitation aux blogueurs participants aux #WEBCAMP #QC
Nous étions 400 chanceux en salle, plusieurs autres en ligne. Mais, tout cela ne doit pas s'arrête là !
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é !
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.
Allez procréer, faisons-nous ensemble d'excellents billets sur cette journée épique !
lundi 10 mai 2010
Mutatis mutandis, une réflexion sur le WebCamp de Québec
samedi 24 avril 2010
Si vous me racontiez une petite histoire ?
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.
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.
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 !
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Avez-vous une petite histoire à me raconter ?
mardi 16 mars 2010
L’intégralité de l’équipe de développements.
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.
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.
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.
« L’expression on sait comme l’équipe est construite, au moment la regarde. La seconde d’après, elle peut changer. »
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.
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.
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 ?
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.
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.
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.
L’intégralité organique, fonctionnelle, une petite définition.
samedi 13 mars 2010
- 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.
- 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.
- 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.
- La révision de code ne doit pas se limité au fichier de code (le support) mais aussi sontintégration, 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.
- 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.
- 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.
- 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 ?
jeudi 11 mars 2010
Le “Pair Programming” revu et visité !
- On dit qu’il y a plus dans 2 têtes que dans une.
- Qu’en travaillant à 2 sur un même ordinateur, la qualité intrinsèque du code et des algorithmes augmente
- Si une personne est absente, surtout lors d’une absence prolongée. L’autre personne peut continuer où l’équipe avait laissé.
- L’Augmentation du rendement, augmentation de l’efficacité.
- « On dit qu’il y a plus dans 2 têtes que dans une. » Par cette expression, on parle souvent du cumul de connaissance, du cumul d’expérience.
- Même si les gens ne travaillent pas en pair, il n’est pas interdit de faciliter le travail collectif.
- 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
- 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. Utiliser momentanément le travail par pair pour résoudre le problème.
- Après tout, nous n’avons pas besoin du « pair programming » pour travailler en équipe, ensemble !
- La qualité du code et des algorithmes.
- La qualité du code, et des algorithmes est souvent 2 choses qui sont problématiques dans le développement logiciel.
- 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 !
- Une autre technique que contient XP (Extrem Programming), c’est la revue de code. Elle permet en groupe ou par un autre membre de l’équipe une revue du code.
- Une bonne revue de code devrait compter au minimum ces critères.
- Ce que ce n’est pas une revue de code
- Les recommandations 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.
- 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.
- 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. 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.
vendredi 26 février 2010
Une petite Game de poker ..! ça vous tente..!
Une petite Game de poker ..! ça vous tente..!
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 !
jeudi 18 février 2010
Agile et la modélisation, une première réflexion !
lundi 25 janvier 2010
Agile, est-ce pour moi ?
Combien de fois, un programmeur ou un analyste, m'a faites cette affirmation! Je ne le compte plus.
Donc, essayons de réfléchir à qui s'adresse ces approches Agiles.
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.
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.
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.
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.
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.
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.
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.
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 !
mercredi 6 janvier 2010
Mes petites résolutions Agiles pour l’an 2010.
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.
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.
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.
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 !
Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.
En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.