L’intégralité de l’équipe de développements.

L’un des principes à la base de SCRUM, est l’intégralité de l’équipe de développements pour la durée du cycle (l’itération).

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.

Suite à la rédaction d’un billet sur la revue de code   et dans laquelle je parlais d’intégralité organique et fonctionne du code. Et j’ai reçu un commentaire judicieux d’une personne qui me demandait d’expliquer ces concepts.

Donc, voici ma vision (une définition qui n’en est pas une) sur ces deux concepts.

Commençons par l’intégralité fonctionnelle. Lorsque nous écrivons du code. Nous ne le faisons pas parce que cela fait joli. Pour démontrer, que nous capable de faire des algorithmes complexes, du code qui ne sert à rien, juste écrire du code.

Une fonction, une classe ou simplement quelques lignes doivent avoir un objectif à remplir. Si j’écris la fonction SupprimerLesEspacesDansUneChaine (la fameuse fonction « TRIM »). Son objectif est de supprimer les espaces dans une chaine et la retourner à la fin, une fois le traitement terminé.

Dans notre exemple, on ne devrait jamais trouver du code pour le calcul de Pi dans cette fonction. Par contre, elle doit contenir le traitement de validations des entrées et une gestion d’erreurs adéquates.

On doit aussi avoir les outils qui démontrent l’atteinte d’objectif. Ce n’est pas juste la parole de son programmeur qui le valide. Souvent, je conseille d’avoir de petits programmes de tests (Unit Test and Fonctionnal Test). Mais, une série d’exemples d’utilisation, lorsque c’est une classe ou fonction d’utilités (la fonction « Trim », ne fait rien de spécifique dans l’application. Mais, elle aide d’autre traitement à atteindre leur objectif à eux.)

Cette intégralité fonctionnelle devrait être couverte par les tests unitaires bien sûr. Mais aussi, par des tests fonctionnels; automatiser si possible. Il est intéressant, de conserver une copie des tests et de leurs résultats aux fins d’archives.

L’intégration organique (ou logiciel),  couvre plusieurs aspects. Bien entendu, le respect de la nomenclature de l’écrire du code (Nom de la classe, des fonctions et méthodes, des variables, etc).

Mais, il faut aussi vérifier que le code produit, ne compile pas juste le poste du développeur qui l’a écrit. Il doit aussi compiler dans les environnements continus ou sur les « Build Machines ».  J’ai déjà vu du code qui compilait sur tous les postes des développeurs. Mais, lorsque nous avions voulu, faire une version officielle avec la Build Machine. Ça avait fait « Boom », le code ne compilait pas du tout.

Pourtant, ce code avait révisé par toute l’équipe. Il respectait les standards de programmations. Mais,  il n’avait jamais été compilé entièrement avec les sources de la version officielle qui était pour la livraison chez les clients.

L’autre aspect souvent oublié, c’est la manière de faire les choses. Beaucoup, d’organisation on des librairies de composantes utilitaires. Et il faut les utiliser, lorsque nous travaillons.

Par exemple, on a beau avoir construit la meilleure fonction de validation d’un NAS (Numéro d’Assurance sociale). Si nous n’avons pas utilisé, la fonction standard de l’organisation. A mes yeux, nous avons un problème d’intégrité organique (ou logiciel).

Il faut chercher à ne jamais réinventer la roue. Il faut l’utilisé au besoin, encore plus en orientés objets avec les principes de la surcharge et de l’héritage.

L’autre aspect, les fameux algorithmes géniaux. Mais, donc le nom du programmeur est marqué en dessous. A moins, que nous lancions une fusée sur Mars.  Je n’aime pas voir, du code que seul le programmeur qui l’a écrit comprend. Que pour toutes corrections ou modifications, nous avons besoin de lui.

Nous devons toujours écrire, du code pour les 10 programmeurs qui vont faire la maintenance de celui-ci. Il existe encore du code qui a été écrit avec des cartes perforées.

La continuité du désigne est aussi une autre chose importante. Les architectes ou les concepteurs des modèles organiques de l’application. Ne sont pas toujours à côté des programmeurs, lorsqu’ils ont besoins d’ajouter une classe ou une fonction dans cet ensemble.

Dans un mode idéal, je sais que c’est la responsabilité du concepteur de prendre cette décision. Mais, nous savons tous qu’en tant programmeur ou analyste qu’il arrive parfois de prendre cette décision sans l’approbation immédiate du concepteur.

Il faut voir l’intégralité comme une gestion des impacts du code produit dans le reste de l’application ou de la solution logiciel.

Et je me répète, encore et encore, les programmes de tests avec leurs résultats sont aussi importants.

Donc, l’intégralité fonctionnelle et organique d’un code est bien plus que le regarde de la qualité d’écriture du code lui-même. C’est une vue d’ensemble dans la validation du code produit.

La revue de code, ce n’est pas l’Inquisition !

L’une des bonnes pratiques des méthodologies Agiles et de l’Extrem Programming, est la révision de code.

Mais, souvent la révision de code est utilisée comme une forme d’Inquisition, une forme de dictature par certains membres de l’équipe.

Les principes qui sont derrière la révision de code ont le but de vérifier le respect des standards de programmations, de la simplicité des algorithmes et ainsi que de la compréhension générale de l’ensemble du code produit par l’équipe.

Elle permet aussi d’augmenter les compétences générales des membres de l’équipe. On peut s’en servir pour aider et former des membres qui ont moins d’expériences.

Mais, malheureusement, dans certaine équipe, certains coéquipiers qui ont un égo trop grand, se serve de cette technique comme une forme d’Inquisition en vers les gens moins expérimentés ou moins forts techniquement qu'eux.

J’ai même vu que certains l’utilisaient pour régler des conflits personnels. Quelle horreur !

La révision de code doit suivre aux minimums ces règles.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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 ?

En utilisant, cette technique dans un profond respect de tous les membres de l’équipe. Nous allons t’en renforcer la compétence moyenne de l’équipe que de l’esprit d’équipe.

Car, lorsqu’il y a confiance mutuelle au sein de l’équipe, les membres de celle-ci n’ont plus peur de demander de l’aide. Cette demande s’effectue tout naturellement.

De plus, la qualité va aussi augment progressivement. Ce qui va réduire tant le temps de révision que le temps de corrections subséquentes. L’expérience m’a démontré que si on prend le temps de bien le faire et surtout dans le fait dans un profond RESPECT, cette technique est plus que profitable.

Le “Pair Programming” revu et visité !

L’une des grandes forces de la méthodologie « Extrem Programming (XP) », est bien sont “Pair Programming” ou d’une mauvaise traduction, la programmation en duo.

Pour avoir travaillé en ce monde, je suis conscience tant de sa puissance que de ses forces. Un bon duo pourra rapidement acquérir un rendement de 2.5 à 3 fois, et peut-être plus, leur cumul du travail individuel. Mais, il faut une bonne complémentarité dans l’équipe.

Dans nos grandes organisations avec leurs grands projets, il est facile de trouver les individus qui fonctionneront bien sur ce principe.

Mais, lorsque nous intervenons dans de plus petites organisations, avec les effectifs réduits et aussi le budget d’autant réduit. Il est difficile d’immobiliser, 2 ressources sur une même tâche. Même, si à moyen terme, serait plus efficace.

Prenons par exemple un projet de 700-800 jours/personnes, environ 1 an avec 4-5 ressources. Il est difficile de doubler le nombre de ressources pour faire du « Pair Programming ». Et le temps total du projet (d’autant si c’est la première expérience ensemble des pairs), elle risquerait de ne pas trouver leur vitesse de croisière tant recherchée.

Donc, comment tirer parti de cette force, sans pour autant immobiliser les 2 ressources en même temps. C’est une question que je vais tenter de répondre avec vous.

Faisons ensemble les constats des forces de cette paire, et essayons d’en tirer parti au mieux.

1. On dit qu’il y a plus dans 2 têtes que dans une.
2. Qu’en travaillant à 2 sur un même ordinateur, la qualité intrinsèque du code et des algorithmes augmente
3. Si une personne est absente, surtout lors d’une absence prolongée. L’autre personne peut continuer où l’équipe avait laissé.
4. L’Augmentation du rendement, augmentation de l’efficacité.

Révisons ensemble cette liste. Essayons d’en exploiter les forces, sans passer à l’absolue du « Pair Programming »

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

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

i. Revue des standards de codification

ii. Le respect de la nomenclature de l’application.

iii. La simplicité de compréhension et la qualité des algorithmes.

iv. La documentation intrinsèque du code et autre documentation nécessaire à sa compréhension.

• Ce que ce n’est pas une revue de code

i. Un exercice pour démontrer l’incompétence d’un individu

ii. Un procès, une vengeance entre individus.

iii. Une amélioration du code par le réviseur. Le réviseur doit remettre ses recommandations de corrections à l’auteur. Il n’est jamais recommandé d’effectuer soi-même (Réviseur) les corrections à faire

• 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.
2. 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.

· Une solution que j’applique dans ces cas là est le principe de la ressource et demi. Une ressource qui a la responsabilité première d’une tache. Généralement, la personne plus expérimentée du groupe.

· A laquelle, s’ajoute une demi-ressource. Généralement, une personne moins expérimentée que la première. Mais, qui a toute la capacité de faire et surtout l’intérêt de le faire.

· Le secret de la sauce, c’est la communication entre les 2. La demi-ressource doit avoir la capacité. Donc, la connaissance nécessaire du «quoi » et du « comment » des travaux.

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

Pour avoir mis en pratique le principe de la ressource et demi, à plusieurs reprises. C’est le meilleur compromis sur plusieurs aspects pour les petites organisations.

Donc, en résumé, le « pair programming » c’est une excellente technique. Je vous la recommande, mais, tout comme application des principes Agiles. Il faut prendre le temps de bien évaluer nos besoins et d’aller chercher les outils dont on a besoin.

Le « pair programming » n’est pas une religion ! Mais, une bonne pratique de développement !

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 !

Agile, est-ce pour moi ?

Il y a toujours beaucoup de préjugés auprès des gens lorsqu'on veut leur parler de se lancer ou simplement adopter les méthodologies Agiles. Souvent leur premier réflexe est de répondre que les méthodologies Agiles ce n'est pas pour eux.

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 !

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.