Un voeu pour la période des Fêtes

La 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.

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.

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.

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.

Je nous souhaite tous une Belle Année AGILE.

Comment 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.

Je vais plutôt vous aider à apporter une réflexion sur besoin spécifique d’un Coach Agile.

À 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ».

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.

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.

Comme toujours, soyez Agile dans votre réflexion et votre démarche.

Agile, 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.

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.

Tout passage Agile, même au sein d’une petite équipe de développement aura un impact sur l’organisation tout entier.

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.

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 !

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.

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.

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.

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.

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.

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.

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 !

Agile, mais pourquoi ?

Agile, mais pourquoi ?

L’autre jour, un client m’a posé la question « Pourquoi, je m’étais tourné vers les méthodologies agiles? »

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 !"

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.

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.

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.

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.

Les méthodologies agiles, ce n'est peut-être pas pour tout le monde, mais moi, je m'y s'en alaise.

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.

Reconnaître l’autre ce n’est pas un crime

Je ne vous parlerais pas aujourd’hui des grands criminels et encore moins défendre les grands principes de l’agile d’un plan technique.

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.

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.

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.

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.

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.

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.

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.. !

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.

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 !

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.

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.

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. »

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.

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.

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.

Et si on pensait différemment, aussi dans notre relation avec les autres.

L’honnêteté de le dire

Trop 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.

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.

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.

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 !

J’ai préféré de loin, et c’est que j’ai fait, de lui souhaitant bonne chance en déclinant son invitation.

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.

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.

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.

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.

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.

Rappelons nous, et honnêtement bien sûr! Comment on réagit dans ce genre d’expérience.

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.

Après tout, penser, différemment, c’est aussi pensé avec honnêteté !

Afin Québec sur la map Agile Tour

Merci mon Ami Dominique Asselin, qui me rappelle d'annoncer la conférécence Agile Tour arrive à Québec.

Je me promets de faire tout mon possible pour y assister ..! et peut-être participé à titre conférencier.

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.

Au plaisir de vous voir nombreux !

On documente, quoi, quand et comment ?

On documente, quoi, quand et comment ?

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 ! »

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.

Mais, ce n’est pas tout de dire qu’il faut documenter. Comme dans toutes choses il faut savoir comment, quand et surtout quoi !

D'abord, revenons à la base, c’est quoi la fin ultime d’une bonne documentation.

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.

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.

Maintenant qu’on sait à quoi va servir la documentation. Donc, on peut se pencher sur le quoi !

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.)

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.

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.

Bien sûr, en plus de documenter la partie « fonctionnelle » de l’application. Il faut aussi documenter le code, la base de données.

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.

On peut utiliser Word, mais ce n’est pas le seul outil à notre disposition. Il en existe plein d’autres.

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 !

Allez documenter ..!

Construire l’équipe c’est important aussi !

En agile, construire l’équipe c’est important !

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).

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!

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.

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.

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.

Comment faire donc ?

La recette :

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.

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 !)

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.

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.

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.

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.

En agile, tant l’individu que sa participation au sein de l’équipe.

La motivation des ressources !

La motivation des ressources, une parte importante du travail en méthodologies agiles

Mon grand-père disait, si on veut tuer un homme, il suffit de le payer à rien faire.

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é.

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.

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.

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.

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.

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.

Je ne suis pas en train de dire mettre la faute non plus sur le syndicat et encore moins, le mettre dehors nos gouvernements.

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.

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.

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.

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.
Ç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 ».

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.

On m’a toujours appris que pour produire un bon logiciel, on avait besoin des gens créatifs.

Quand je me retrouve avec la charge de ressources, je m’amuse à leur poser à chacun les 3 questions suivantes :

Qu’est-ce que tu aimes faire, qu’est-ce qui te fait vraiment plaisir, à la limite jouir dans ton travail ?
Par exemple. Moi, je tripe à faire de l’architecture et modélisation de données.
Qu’est que tu n’aimes pas faire, une chose que tu vas repousser à la dernière minute tout le temps ?
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 ».
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.
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.

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.

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.

Autrement, ils sont payé, oui pour travailler, payer pour descendre des heures en produit la sortie de leur entrés s’est tout.

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é.

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.
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 !

Agile et l’intégration de ressources dites « particulières ».

Les méthodologies agiles donnent une place importante aux différentes personnes impliquées dans un projet, qu’il soit client, pilote, membres de l’équipe de développement où autres participants.

Les méthodologies agiles, et bien sur votre humble serviteur, préconisent de mettre la bonne personne à la bonne place en exploitant ses forces et ses compétences plutôt que se s’acharné sur ses faiblesses.

Ce n’est pas vrai de dire qu’on est bon dans tout, qu’on peut tout faire. Chaque individu à des forces et des faiblesses. Qu’elle soit causée par un manque d’intérêts ou par une limitation quelconque.

Souvent, beaucoup d’organisations ont peur d’engager des ressources qui en apparence a une certaine limitation. Et j’entends parlas pas seulement les personnes « dites handicapés » mais toutes personnes qui a une limite fonctionnelle, physique ou mentale.

Pourtant, malgré leurs limitations « en apparence » certaines de ces personnes cachent des habilités extraordinaires. Donnons par exemple, M. Albert Einstein, l’un des plus grands physiciens du dernier siècle avec son fameux E=mc2. Qu’est-ce que serait la physique moderne sans son apport. Pourtant, il était dyslexique. Ce qui aux yeux de biens des gens serait encore aujourd’hui un handicap majeur.

Je pense aussi à un ami, du secondaire, qui était paraplégique. Mais, en l’absence de jambes fonctionnelles, avait développé une force exceptionnelle au niveau des bras. Il était imbattable aux bras de fer.

La comparaison que je donne souvent, c’est l’achat d’une voiture. Si on met un gros budget pour acheter le super moteur, des roues de courses. Il risque d’en maquer pour le reste. Mais, cela ne veut pas dire que notre voiture ne correspondra pas à nos besoins, quelle ne sera pas fonctionnelle.

L’apparence de limitation d’un individu, peut-être une force dans un autre contexte. L’autre jour en discutant avec une amie, elle me racontait qu’un des amis avait problème de rendement avec ses employés (construction). Elle lui a suggéré d’engager de hyperactif, ils ont tellement d’énergie. Qu’ils pourront travailler comme 2. Je trouvais l’image belle.

L’hyperactivité qui causait problème en classe, sur un chantier de construction pourrait être un avantage.

Si on regardait notre contexte, l’informatique. Certaines limitations aux yeux de certains pourraient causer des problèmes. Par le passé, j’ai eu un employé qui était du syndrome d'Asperger, limitation qui causait de problème dans interaction personne à personne, le point négatif.

Mais, l’autre côté positif, c’est qu’il avait une passion démesurée (à la limite de la folie) pour le développement Web (javascript, asp.net, XML et compagnie). Une vraie encyclopédie sur ces technologies. Bien entendu, on ne l’a pas mis aux services à la clientèle. Il était notre développeur pour tout ce qui touchait le javascript, le XML, XSLT, CSS et compagnie. Il avait aussi la responsabilité de tester tous les frameworks ou librairies touchant ces technologies. Dieu merci Google, ne l’avait pas découvert, je n’imagine pas, ce que Google sortirait comme technologie s’il avait accès à ces services.

Je ne vous cacherai pas la première fois, que je l’ai rencontré. Je n’étais pas sur de vouloir l’engagé. Mais, je remercie le ciel d’avoir eu la sagesse d’aller plus loin.

Une autre personne que je connais, il est dyslexique. Beaucoup de gens auraient peur de le mettre en dans un contexte, il devrait faire de la formation et de l’animation de groupes. Et pourtant, cette personne le fait de plus de 20 ans.

Bien sûr, pour y arriver, il fait corriger ses textes et ses présentations. Ou semblait un problème, sa dyslexie, il s’en est servi pour apporter une compréhension nouvelle de la formation. Il a du pour surmonter, surpasser sa dyslexie trouver des solutions à l’apprentissage que d’autre n’aurait pas trouvés. Il se sert de ces techniques qu’il a développées pour lui, pour enseigner, former les autres. Il utilise une forme d’enseignement qui utilise plusieurs axes simultanément. Donc, tous trouvent son compte, n’oublions pas que chacun apprend de manière différente.

Comme, il me faisait remarquer tout le monde n’est pas visuel ou auditif. Des gens pour apprendre, doivent faire des exercices à répétitions par exemple, et bien d’autre manière d’apprendre.

En utilisant, leurs forces que plutôt qu’en s’acharnant sur leur faiblesse. On arrive à produire des meilleurs travaux.

En agile et avec le gros bon sens, si on place la bonne personne, avec les bonnes compétences, aux bons endroits. Que plutôt s’acharner à leurs faires réussir des tâches que toute manière, ils seront incapables de réussir, on réussirera de miracles . Ne demandons pas à un aveugle de voir, mais ce qu’il peut faire pour nous aider. Nous saurions peut-être surpris de sa réponse.

Le classement d’individus, les préjugés et toutes actions négatives envers les personnes. Quand on croit qu’il y a un problème et qu'on le résoudre en appliquant des idées préconçues, on se trompe souvent. Il faut rester ouvert, rechercher des solutions. On ne peut pas tout connaître, parfois demander, se documenter sur des limitations en apparence, on pourrait être surpris du résultat. Ces quelques efforts nous aideront à intégrer aux mieux des ressources qu’on aurait délaissées sans ces efforts.

Il ne faut pas oublier, qu’on a tous à notre manière des limitations qui aux yeux des autres, sont des handicapes majeurs. Pour moi, quelqu’un avec l’esprit fermé est plus problématique que un aveugle, un Aperger ou un dyslexique.

Il faut aussi trouver de nouvelles façons d’intégrer ses ressources, et ils pourront nous apporter des lumières dans notre nuit.

Restons ouverts d’esprit, restons agiles.. ! Même avec ces ressources qu’on éliminait par simples préjugés.

WebCamp, une façon de participer aux changements des TI

Les méthodologies apportent un courant de changements. Mais, pour effectuer ce changement, il faut travailler plusieurs aspects.

Mais surtout s’assoir les gens de l'industrie concernée ensemble pour discuter ce qu'on peut améliorer ou non dans notre industrie.

C'est ainsi qu'a l'initiative, des gens que je respecte, MM Nicolas Roberge, Jonathan Parent, Luc Vaillancourt, Jean-Philippe Bonneau et le tout supporté par la Vetiq, on eu l’idée de lancer le premier WebCamp de Québec.

C’est une belle occasion d’échanger, de discuter, de voir comment on va les grands changements que l’industrie des TI doit faire, qu’il soit agile, web ou autrement.
La seule chose qui est sure avec les TI, c’est que ça évolue.. ! Et quand on veut voir, savoir et même participer à ce changement, il faut s’impliquer. C’est pourquoi, je serai présent, et je serais prêt à répondre aussi « présent » si les gens veulent m’entendre parler de ma vision des méthodologies agiles.

Participons aux changements, participons à ce WebCamp.. ! C’est une manière.. De s’impliquer aux changements.. ! Derrière le Web, derrière les technologies, il y a des gens qui réfléchissent!

En terminant, je vous invite aussi à laisser des commentaires sur ces billets, si voulez orienter ma possible présentation.

P.-S. Je vous invite à vous inscrire.. Rapidement, les places s’envolent.

Les méthodologies agiles, au gouvernement est-ce possible?

Les méthodologies agiles au gouvernement est ce possible, je réponds à cette question Oui, avec beaucoup de travail par contre.

L'informatique évoluée, les expertises changes, le manque de ressource, la spécialisation des ressources, et encore bien d'autre élément vos finir à faire changer l'approche que nos gouvernements.

Je ne sais pas s'ils iront vers les méthodologies agiles ou autres choses, mais le modèle, dois, et va changer, j'en suis sûr.

En me fiant à mon expérience, à ce que j'ai vu jusqu'ici, le gouvernement va prendre la tendance la plus forte. À titre d'exemple, la technologie qui a pris émergence pour faire du web dans les ministères de la région de Québec, c'est du .net de Microsoft.

En plus, une nouvelle génération (« Y » et ses suivantes) arrive à grands pas, ils ne veulent plus les anciennes méthodes. Mon ami Nicolas Roberge a bien décrit la problématique dans son billet : Le choc des générations dans les technologies de l’information».

On vit, le gouvernement vit un changement majeur dans la manière qu’il doit faire et l’informatique. Récemment, on pouvait apprendre que de grands chantiers avaient défoncé les temps et les budgets, pour le pas dire qu’ils avaient perdu le contrôle.

C’est peut-être en ne faisant plus ces grands chantiers qui sont presque impossibles à contrôler.

On ne peut pas manger un rhinocéros en une seule bouché, mais si on le découpe en petit morceau, c’est plus facile à manger.

C’est la même chose pour un projet informatique. Il faut le prendre en plus partie, c’est beaucoup plus facile à gérer, et ce, dans le contexte du manque de ressources et de changement technologies.

Mais, pour les méthodologies agiles soient abordés dans nos ministères, il y a plus d’un changement à faire. Je ne veux pas couvrir tous les éléments dans ce billet. Je vais essayer d’explorer chacune des problématiques dans les billets suivants.

L’agilité au gouvernement, c’est possible. Mais on va avoir besoin de bon cuisinier pour aider à manger notre rhinocéros. Moi, je suis partant pour trouver la bonne sauce et vous.. ?

Seul, je n’y arriverais pas .. Je vais faire mon petit bout de chemin, aider certain à le faire.. Mais, tous nous devront en faire un aussi.

Là, et seulement là, les méthodologies agiles pourront être adoptées aux gouvernements.

Plan de travail, Les méthodoloties agiles et le gouvernement du québec

Mon ami Nicolas Roberge, m’a suggéré sur les méthodologies Agile et le gouvernement québécois.

Comme je crois, que je ne peux pas, qu'il est plus simple d'écrire une série de billets qu'un seul. Je vous propose donc un premier plan de travail.

1. Les méthodologies agile, au gouvernement est-ce possible ?
2. Les appels d'offres et les méthodologies agiles.
3. La motivation des ressources, une part importante du travail en méthodologies Agiles.
4. La gestion d'équipe mixte, consultant et fonctionnaire, est-ce possible ?
5. La gestion des demandes de changements dans le contexte gouvernemental.
6. La gestion de la livraison et de la facturation en contexte agile
7. Y-a-t-il une meilleure méthode, qui serait plus facile à adapter pour le gouvernement ?

Avez-vous d’autres suggestions et laissez-moi un commentaire.

Agile plus qu’un Buzzword et comment faire des affaires en agiles

On attendant parler partout des méthodologies agiles, comme étant le nouveau buzzword à la mode.

Et quand, quelque chose devient la saveur du mois, beaucoup de gens, très souvent avec les meilleures intensions du monde (et je le dis sans ironie), voie surgie des occasions d’affaires.

L’occasion d’offrir de nouveaux services à leurs clients. Car, beaucoup de gens, veulent se lancer à cette nouvelle approche, mais ne savent pas trop comment. Donc, le premier réflexe qu’ils ont, c’est engager un consultant.

Pour faire carrière en consultation, je sais que nous sommes vites à dire présent. Même si on n’a pas toujours la compétence. Ce billet n’est pas une critique sur le travail de consultant, étant moi-même consultant et propriétaire d’une petite firme de consultant, se serait me tirer dans le pied avec un fusil à lunette.

Mais, il faut avoir la sagesse de se former, et aussi d’intervenir dans notre spécialité et au besoin de faire partenariat. Je dirais même parfois, réinventer ou créer un nouveau modèle d’affaires.

Car, tant dans le contexte des méthodologies agiles, que d’autres secteurs de l’industrie, il est impossible de tout connaître.

A titre, d’exemple, j’effectue du conseil en méthodologies agiles depuis plusieurs années, depuis 2002, et je pratique régulièrement. Et, il m’arrive encore d’apprendre de nouvelles choses à ce sujet.

Je sais qu’il existe d’excellente formation théorique, par exemple la certification Scrum Master, certaines formations Lean et surement du côté Crystal Clear. Tout comme, il existe de nombreux livres aussi excellents, les uns que les autres.

Mais, dans beaucoup de choses, la pratique et l’expérience de terrain valent de l’or. En suivant la formation, Certification Scrum master, vous apprendrez à animer le « Scrum matinal ». Je l’espère, que votre formateur vous donnera des exemples, et surtout comment s’en sortir, quand le Scrum n’atteint pas son objectif.

Je me souviens de professeurs de base de données à l’université, qui disait vous allez comprendre aujourd’hui, ou dans 10 ans, la modélisation de données. J'avais compris à lors, la modélisation de données. Mais, ça m’a pris 10 ans (manière de parler) pour comprendre ce voulait dire son expression. Si tu as le cerveau, les habilités, un bon professeur, etc. Tu pourras apprendre facilement la théorie. Mais, il faut plus que la théorie pour la mettre en pratique.


15 Ans, plus tard, la différence maintenant en modélisation de données, je pense que je suis meilleur. Mais, surtout je peux trouver plus rapidement une solution aux cas nos théoriques.

C’est la même, vous pourriez lire, des tonnes de livres sur le « pair programming », seule l’expérience pourra vous dire qu’en mettant 2 individus ensemble, pourquoi ça fonctionne tout suite. Et en changeant, l’un des partenaires l’efficacité du pair sera réduite à zéro.

Quand on veut se lancer dans les méthodologies agiles. Il faut aller chercher les formations, lire les livres, les blogues comme celui-ci. Mais, ce qu’il ne faut jamais oublié. Que malgré parfois, un grand nombre d’années d’expériences en informatiques. Que lorsqu’on commence, dans une nouvelle technologie, comme les méthodologies agiles, nous redevenons des juniors pour un temps. Le temps, que l’expérience rentre. C’est d’une question de temps et d’effort.

Rappelons-nous, quand nous avons commencé, quand nous étions juniors, la plus grosse erreur qu’on a tous faite. C’était de ne demander de l’aide, que souvent trop tard. Et maintenant, que l’expérience de la vie, que l’expérience professionnelle a rentrée, oui, dans d’autres secteurs. Il serait sage de demander cette aide dès le départ.

Et pourquoi, en utilisant le bon vieux principe qui a fait sait preuve. Le bon vieux compagnonnage. Faire du compagnonnage, c’est d’être agile avec les méthodologies agiles.

Il y a de la place pour tout le monde, pour faire de la consultation en méthodologies agiles, Mais S.V.P. arrêtons d’improviser, arrêtons de vendre de l’air. Revenons aux 4 principes agiles, au manifeste, afin d’offrir une véritable offre agile.

Macroscope versus Agiles, combat à finir

Pour beaucoup de gens, dont les puristes des 2 côtés, affirme haut et fort que ces 2 méthodologies s’opposent.

Mais, est-ce vraiment le cas ?

D’abord, posons un regard sur Macroscope de DMR.

Voici le texte d’introduction trouvé le site de DMR. http://tinyurl.com/Macrosope

« Grâce à ses méthodes, processus et outils, Macroscope aide les entreprises à planifier, à mettre en œuvre et à gérer leur transformation organisationnelle par des initiatives clés :

• planification stratégique
• architecture de l'entreprise et de ses technologies de l'information
• développement, déploiement et maintenance de systèmes d'information et d'autres solutions technologiques
• gestion de projet
• gestion de la valeur et de la réalisation des bénéfices

À la manière d'une feuille de route, Macroscope guide les acteurs dans la réalisation de leurs activités, et ce, à toutes les étapes d'un changement organisationnel. »

Regardons de l’autre côté le manifeste agile : http://tinyurl.com/AgileManifesto

• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide

Allez affirmer que Macroscope implémente les méthodologies agiles. Quand même, affirmer ceci serait une stupidité.

À la lumière de ces 2 courts textes, je crois que me permet par contre dire qu’il ne s’oppose pas. Macroscope est une méthodologie qui décrit et définit les processus qu’on devrait faire pour le changement organisationnel, y compris ceux qui touchent le développement d’applications. Pour se faire, il fournit une série de gabarits qui permet de documenter les processus de développement logiciels. Beaucoup d’excellents exemples de référence comme base pour les construire.

Vous pensez sans que j’aille citer le 2e principe, celui de la documentation exhaustive pour m’attaquer de front à Macroscope pour la tuer. Eh bien non, détromper vous trompez, c’est tout le contraire.

Oui, je m’en sers de ce principe. Mais, je ne me s’en pas partir en guerre rangée contre DMR et sa méthodologie. Je reconnais certaines applications de son approche de gestion et surtout quand les gens font de la sur documente ce n’est pas très agile.

Ce n’est pas une grande nouvelle. Mais, je pense qu’on devait réfléchir le problème différemment. Tout le monde qui me connaisse, et encore plus, ceux qui ont lu mes articles précédents savent que je prône la documentation, lorsque nécessaire bien sûr.

Il faut documenter ce qui doit être documenté. C’est ce que dit ce principe. Et de l’autre coté, Macroscope nous explique comment le faire cette documentation, comment documenter les différentes choses avec l’aide de ses gabarits

Donc, si nous voulons être agiles tout en utilisant Macroscope. C’est possible. Il suffit de gérer le projet en utilisant une approche agile. Et pourquoi pas SCRUM. SCRUM était une méthode du coté agile aussi structurée et structurante. Elle est très rassurante pour les clients.

Et utilisez Macroscope pour documenter les processus. Je travaille dans le marché de Québec, essentiellement gouvernementale et grosse compagnie d’assurances, pour savoir qu’elles sont habituées de lire ces documents.

Ce n’est pas un vrai passage à agile. Mais, une belle transition qui pourra aider à mieux faire l’informatique. Et surtout d’aider à démocratiser l’utilisation des méthodologies agiles dans notre belle région de Québec.

S.V.P. par contre, ARRÊTEZ de sur documenter et de faire du copier-coller de chose qui est déjà documentée. Combien de fois, j’ai vu qu’on a répété le texte, parfois écrit différemment, pour expliquer la même chose dans une même série de documents.

Il n’est pas nécessaire de réécrire un algorithme de validation générique dans tous les dossiers fonctionnels qui l’utilise. Documentez-la dans un seul document et fais-y référence, dans les autres.

Un document utilisant des références aurait du faire de 20-25 pages, mais parce qu’on n’avait pas recopié le texte. Il pourrait en contenir plus de 100 pages sinon. Qui aime lire des documents de 100 pages. Pas moi en tout cas.

Et en plus, pensons eu un peu à l’environnement.. ! Utilisons une documentation électronique, wiki, blogue et compagnie.

En utilisant, les bons côtés de chacune de ces méthodologies, nous serons agiles dans notre gestion de projets.

Et si vous croyez que cela ne peut pas fonctionner. Oui, j’en suis sur ça fonctionne. C’est d’ailleurs la technique, j’ai suggéré à une amie, une spécialiste Macroscope et ancienne membre de l’équipe de rédaction de Québec. Car, elle voulait passer à agile, mais sans pour autant délaisser ses bases.

A ce que je sais et selon que j’ai discuté avec elle, la dernière fois qu’on s’est vue. Elle l’a appliqué avec succès dans un de ses mandats dans un ministère.
Être agile, ce n’est pas tout changé, c’est aussi savoir manier l’ancien avec le nouveau. C’est de réfléchir le problème, pour trouver ou retrouver des solutions.

Et ceux, qui ne me croient pas .. Communiquer avec moi, on le fera ensemble, cette implémentation d’Agile et Macroscope dans votre organisation. generationagile@gmail.com

123 Go je me lance en agile.. !

Un nouveau courant d’idées méthodologiques qui commence à émerger, c’est bien les méthodologies agiles. C’est bien beau, mais par où commencer! Voici notre réponse à cette question importante que nous allons essayer de vous donner des pistes des solutions durant cet article.

Nous aimerions bien vous proposer une recette magique. Une recette que vous pourriez, appliquer sans qui crainte de l’échec et qui va réussir à tous les coups. Mais, l’expérience de plusieurs années en informatique et en méthodologies de développement. Dont, avec les méthodologies agiles, nous a permis de comprendre qu’il faut faire attention avec ces soit disent « recette toute faite ».

Il faut repartir à la base des méthodologies agiles, les quatre principes :

• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide

Si une organisation, (une compagnie, une équipe de développement, etc.) décide de se tourner ou du moins regarde la possibilité de le faire. C’est qu’elle a identifié qu’elle a un problème quelque part. Et potentiellement, l’un qui touche c’est quatre grands principes.

Bravo, vous avez fait le premier pas. Car, en se lançant en agile, ou toutes autres nouvelles méthodes. Il faut gérer le changement. Il faut faire un constat.
Agile ne signifie qu’il faut tout changer dans votre organisation. Encore moins, que tout ce que vous faites déjà est en erreur. Agile chercher simplement à améliorer vos processus en apportant une nouvelle vision, une nouvelle approche dans la manière d’aborder un problème.

Lorsque nous implémentons agiles dans une organisation, il ne faut pas arriver avec un bulldozer qui détruira tout sur son passage. Il faut arriver avec de la minutie, du doigté, de la sagesse et surtout beaucoup de respect.
Nous disons toujours regardons ce que vous faites de biens, ce qui peut être amélioré, ce qui doit être changé et ce qui ne doit pas l’être.

Il y a une école de pensée dans les méthodologies agiles, qui veulent la mort des méthodes « wather falls » ou des approches mérisiennes (Mérise, P+, Macroscope). Nous pensons le contraire. Si certains éléments de ces méthodes en cascade fonctionnent chez vous. Continuez à les utiliser (ne changeons pas ce qui fonctionne.) Ajustons seulement la manière de les utiliser dans un contexte agile. Exemple, si vos clients sont confortable avec un dossier fonctionnel selon les la définition de P+. Continuer à les écrire sur cette base. L’adaptation agile qu’on peut faire, c’est de réduire son volume (le nombre de pages) et le média de production. Au lieu de l’écrire sur beau document imprimé sur 8 ½ - 11. Utiliser une version électronique qui contient des références web (pointeurs) vers des processus déjà documentés ou pourquoi pas un Wiki.

A l’inverse, si aucun de vos clients ne lit le plus petit dossier fonctionnel, à quoi sert donc à s’acharner des les produire. Utiliser peut-être un « cas d’utilisation UML » ou les « Story de Scrum ».

Il apporter des solutions aux problèmes, et surtout ne pas en créer de nouveau.
Après avoir fait le constat dans votre organisation, vous nous poserez sans doute les questions suivantes :

• Il doit exister une ou plusieurs méthodes structurées qui implémentent ces principes ?
• La quelle de ses méthodes, dois-je choisir ?

Il existe plusieurs méthodes, certaines plus structurées que d’autre.
• Scrum
• Extrême programming
• Lean
• RAD (Rapid Application Developpement)
• Et plusieurs autres.

Laquelle prendre dans cette liste, en prendre une ou toutes les prendre, me diriez-vous. Nous répondons toujours, la même chose. Un bon mélange de tout ça. Un petit soupçon de SCRUM pour sa structure et sa gestion d’équipe. La gestion des story pour documenter les processus d’affaires. Le « SCRUM matinal » pour assurer un bon suivi. Et le plus important, le cycle d’itération très court avec son fameux backlog.

Quelque graine d’extrême programming, avec son « pair programming » adapté à la bonne saveur de votre organisation. Peut-être pas 2 personnes assises devant l’écran. Mais, une redondance des expertises par exemple. Par l’approche, spécialiste et son assistant. Une personne possède une personne précise. Et en cas de son absence (ou non-disponibilité), le second peut intervenir à la place du principale.

Lean la gestion de la qualité des processus et des livrables. On veut livrer quelque chose, mais surtout quelque chose de qualité. Ainsi que son principe de juste d’attends.

N’oubliez pas, ce n’est pas une recette de cuisine. Une recette générique qu’on peut appliquer tous les organisations. Si on veut respecter les valeurs mêmes d’agrile, il faut trouver le moyen d’adapter cette recette, d’ajuster les saveurs pour réponse à notre besoin. Une méthode qui nous (nous et vous) à produire de meilleurs logiciels tant qualité du produit, en coût de développement qu’en temps de développement.

En conclusion, se lancer en agile, ce n’est pas une chose simple sans pour autant être complexe. Il faut prendre le temps de bien poser l’analyse. Ne pas avoir peur de se remettre en questions et surtout avec l’agilité de s’adapter en cours de routes.

Mais, surtout trouver une personne d’expériences (en méthodologie agile) avec la chimie passera .. ! et avec laquelle vous n’aurez pas peur de tout remettre en question. Y compris de ne rien changer .. !

Je sais, il semble que nous vous laissons sur votre faim, sans avoir bien répondu à la question. Et pourtant, oui nous y avons répondu .. ! Car, la seule solution à savoir comment on se lance en agile, c’est avec vous .. que seulement nous pouvons la trouver.. !

Agile c’est de pensée différemment, et parfois de donner des réponses qui ne semblent pas en être une.

L’expérience et la compétence

Ces deux termes sont souvent confondus. Pour ma part, elles sont différentes sans pour autant s’opposer.

L’expérience s’acquière aux files des années, aucune formation, pilule magique peut données l’expérience. Comme disait mon défunt père, l’expérience s’acquiert : « au pic et la pioche » .

Quant à la compétence, elle peut s’acquérir par de la formation, par le travail, l’étude. Mais, à la base il faut avoir la structure d’esprit, de pensée, nécessaire pour arriver acquérir cette compétence.

Par exemple, j’ai un profond respect pour les programmeurs Cobol. J’ai eu de très bons professeurs, mais malgré cela je reste profondément incompétent dans ce langage. Par contre, fais-te moi parler d’architecture orientée objet et orientée Service, la je crois que je sais de quoi je parle.

Suis-je plus incompétent pour autant, non, c’est juste que mon cerveau est construit d’une certaine manière, qui m’aide dans mon travail. Et j’aurais beau travailler 10 ans, (j’espère que non) en Cobol, je resterai toujours un mauvais programmeur Cobol. Dieu merci, il y a des gens qui l’ont.

Combien de fois, j’ai entendu quelqu’un, et souvent des patrons pour justifier une promotion d’une personne. Il a acquis assez d’années expériences pour ce poste, sans pour autant regarder si la personne avait la compétence nécessaire pour ce poste.

Aux files des années, j’ai connu beaucoup de personnes qui avaient gravi les échelons par expérience sans pour autant en avoir les compétences. Un peu à l’image de principe de Peters.

À l’inverse, j’ai aussi connu beaucoup de gens, qui avaient toutes les compétences pour occuper un poste supérieur. Mais, qui n’avait pas toute « L’EXPÉRIENCE » pour l’obtenir.

Je ne veux pas dire qu’il faut donner à des gens sans expérience, des postes qui en demande. Mais, en plus de regarder l’expérience, qu’il faut regarder d’autre chose. Donc, les compétences, mais aussi l’intérêt. Je n’ai pas les compétences pour le Cobol, mais surtout aucun intérêt pour ce genre de langage.

Il faut donc, arrêter de voir l’informatique comme étant hiérarchique, mais étant compartimenté. Un bon programmeur ne fait pas automatiquement un bon architecte. C’est peut-être notre programmeur moyen qui sera notre meilleur architecte ou analyste. Je pense à coéquipier d’université, l’un pour des meilleurs programmeurs que j’ai connu. Ferais un mauvais architecte ou même pire, un analyste pitoyable. Car, il a de la difficulté à interagir et communiquer avec les autres. Mais, il écrit du code plus vite que sont ombre. Et surtout du code d’une très grande qualité.

Aujourd’hui, il doit cumuler près de 20 ans d’expérience, et aux dernières nouvelles que j’en ai eues, il est toujours programmeur. Et j’en suis sur, un programmeur redoutable. Il aurait l’expérience pour devenir Architecte ou Analyste. Mais, il n’a pas les compétences pour le devenir. Et je ne pense pas l’intérêt non plus.

Beaucoup trop, d’architecte, d’analyste ou chargé de projet qui pense, encore comme quand il était programmeur. Comme, j’ai connu beaucoup de monde, j’ai connu aussi un analyste fonctionnel, qui écrivait des dossiers fonctionnels, de vrai roman, excessivement facile à lire et comprendre. Par contre, il n’était incapable de le programmer ce dossier. A chacun son métier et les vaches seront bien gardé.

Avec les méthodologies agiles, nous offre un environnement assez sur les compétences et l’intérêt des individus plus tôt que par la reconnaissance de l’expérience. Un programmeur de 20 ans d’expérience, au lieu de lui donner un poste d’architecte dans laquelle, il n’aura pas l’expertise nécessaire. Lui donner la chance de continuer à faire ce qui fait de mieux, c'est-à-dire programmer, mais aussi transmettre toutes ces expériences (pas les années, mais la somme des projets et des lignes de codes) qu’il a fait aux autres.

Un bon programmeur, nous permet d’augmenter la qualité de notre logiciel. On veut un logiciel qui fonctionne, mais surtout un logiciel de qualité.

Mettons les bonnes aux bons endroits, tant d’un point de vue des compétences, de l’expérience que des intérêts. On est venu en informatique pour se faire du fun.. ! Pour avoir du Fun ! Donc, c’est en passant, en repassant ce modèle que nous pour arriver à cet objectif ultime, de livrer une application de qualité et surtout qui corresponds aux différents besoins de notre client.

Associons compétence, expérience et intérêt, et je crois sincèrement que nous de meilleurs ressources pour tous nos projets.

Si tout le monde change un seul individu, que cet individu en fait autant. La terre informatique se portera mieux !

Qu’est-ce que sait d’être Agile .. ! Partie 4 (L’ouverture au changement .. !)

Qu’est-ce que sait d’être Agile .. ! Partie 4 (L’ouverture au changement .. !)
Une petite phrase qui décrit bien les méthodologies Agiles, c’est l’ouverture au changement !

Beaucoup de projet, la première étape est de définir un plan de travail. Le fameux « chemin critique ». Il y a donc des gens qui ont de très bonnes boules de Crystal. Ils sont capables de définir tous les étapes, surtout en sans en oublié une seule d’un projet.
Moi, j’y arrive pour un projet « Hello world », plus gros que cela, j’en suis incapable.

Un instant, je ne dis pas de ne pas faire de plan de travail, d’y aller « free for all ». Oui, il faut faire un plan de travail. Il faut organiser la structure du projet

Ce que dit l’expression « L’ouverture au changement doit primer sur le suivi d’un plan rigide. » c’est qu’avoir fait le plan de travail, il ne faut pas le figer dans le béton.

Si on prend par exemple, la construction d’une maison, il est intéressant de savoir qu’il faut construire les fondations avant de construire les murs.
Mais, à l’étape de construire de les fondations, on n’a pas besoin de savoir la couleur des rideaux, jusqu’il faudra prévoir les services d’un décorateur à certain moment du projet.

Il faut avoir la capacité de s’adapter, le plan de travail est notre cadre, c’est lui qui nous donne les grandes directions qu’on doit prendre ou qu’on devra prendre
La planification devrait mettre en place les grandes actions du projet. Et de chacune de ses grandes actions, redéfinir les différentes sous-étapes.

Si on reprend notre maison, si on avait prévu dans notre grande planification de faire venir notre décorateur à la 8e semaine. Mais, il pourrait arriver que lorsqu’on appelle notre décorateur, qu’il n’est pas de disponibilité pour la 8e semaine. Dès qu’il nous propose de venir la 6e pour première rencontre et une seconde à la 9e semaine.

Si nous avons plan trop rigide, il sera difficile de s’adapter aux nouvelles
contraintes. C’est vrai que si nous n’avons pas les couleurs qu’il faut mettre sur les murs, il sera difficile de commandes la peinture.

Ou encore, un autre exemple, le client quand on construit la chambre des maitres, nous demande d’ajouter une porte communicante avec la chambre voisine. Il est vrai que cette demande n’était pas prévue initialement. Mais, si on reste ouvert, il sera facile de s’adapter.

En informatique, ça pourrait dire de changer le comportement d’une fonction en cours de développement, et ce, même si on s’était entendu sur un traitement différent.
Il ne faut pas oublier, ce que notre travail c’est une fournir une application fonctionnelle et surtout, qui correspond aux besoins de notre client.

Mais, c’est aussi de faire comprendre que si le besoin original était une Renaud 5 (petite voiture économique des années 1980) et qu’en cours de projets, il s’aperçoit qu’en fin de compte, c’est un camion F150 qu’il va avoir besoin qu’il aura conséquemment un changement de coups.

L’ouverture aux changements, doit venir tant de nous l’équipe de projet que de la part du client. Vous avez surement vécu des projets, qu’il avait été entendu avec le client qu’on implémenterait une fonction de telles manières. Mais d’en-cours de travaux, on s’apercevait que c’était beaucoup plus compliqué de ce qu’on aurait pu penser. Et c’est normal Je ne dit pas de réduire la fonctionnalité, mais d’essayer en collaboration avec de trouver une nouvelle manière de résoudre le problème.

Travaillons ensemble et nous pourrons changer le monde, trouvé des solutions nouvelles à divers problèmes qu’on peut vivre dans le projet. Et très souvent, on trouve la solution ou on ne pensait jamais la trouver. Il faut simplement rester ouvert et accepter de se remettre en question.

Il ne faut chercher à changer les choses pour changer les choses. Il faut prendre le temps d’apprendre à découvrir les choses qu’on doit et qu’on peut changer, et celles qu’on ne peut pas. C’est aussi ça d’être agile .!