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.