Un chef et son buffet de services, un buffet de services Agile

Un chef et son buffet de services, un buffet de services Agile

Ce petit concept pour parler d’Agile, commence à faire du bruit sans que vous sachiez qui en est l’auteur!

Donc, comme je suis à l’origine de cette analogie, j’ai le devoir de vous expliquer ce qu’elle soutient.

Qui d’entre vous est déjà allé au restaurant ! Et une fois arrivé dans ce restant, vous vous trouvez devant 2 problématiques. Soit vous vous retrouvez dans un restaurant qui ne sert pas ce que vous pensiez y manger ou ne savez pas quoi manger. Mais encore, le serveur ne vous apporte pas le plat commandé!

Trop souvent en informatique et malheureusement en méthodologie Agile, vous vivez (vous les clients) ce genre de situations désagréables. Vous voulez vous lancer en dans cette aventure. Mais, vous ne savez pas comment et encore moins quelles implémentations prendre.

Donc, c’est pour cela que j’ai réfléchie à comment apporter une solution à ce problème et bien entendu , d'une manière Agile.

Premier constat, nous ne pouvons pas savoir ce dont vous avez besoin sans que nous vous l’ayons demandé. Mais, il ne suffit pas de demander, il faut aussi beaucoup écouter.

Deuxième constat, votre besoin peut et va changer ! Donc, pour être en concordance avec le principe de la réactivité aux changes (en référence au Manifeste Agile) que je dois donc vous offrir une solution qui suivra cette évolution.

En reprenant l’exemple du restaurant, je peux préparer un excellent menu, d’excellent mets. Mais, lorsqu'arrive le temps de choisir , il peut arriver que ce que j’ai préparé ne vous convienne pas exactement. Là sera mon vrai rôle de conseiller, de chef Agile en vous orientant vers de combinaisons qui pourraient répondre à votre besoin. Et si nécessaire; après tout, j’ai de très bons fournisseurs de produits alimentaires; je pourrai vous concocter une recette bien à vous. Une combinaison de méthodologies agiles (ou juste une seule) qui permettra d’adresse votre problème.

En Agile, il existe plusieurs méthodologies (Scrum, Leam, Kanban, XP, etc.) qui répondent chacune à différents besoins. Peut-être, l’une d’entre elle correspondra à votre besoin à certains moments. Et plus tard, dans le projet, se sera le tour d’une autre.

Mais choisir la bonne méthodologie Agile, c’est comme arrivé devant un buffet lorsqu’on est affamé ! On veut tout avoir, tout gouter, de l'entrée au dessert, en passant la petite soupe là-bas !

Si nous mangeons, nous goutons à toutes les choses comme des enfants, nous allons nous rendre malades. Et le problème (notre faim) que nous voulions résoudre pourrait être la cause de beaucoup d’autres. Dans ce cas-ci, potentiellement des maux de ventre pour avoir trop mangé.

Vouloir essayer toutes les méthodes, de demander à Pierre, Jean, Jacques n’est pas la solution. Mais, si vous arrivez aux buffets et que vous demandez, conseille à un chef d’expériences. Il vous fera surement découvrir des nouvelles choses, des nouvelles combinaisons que vous n’auriez jamais pensé d’essayer.

Si vous avez encore faim après la première, la deuxième assiette, vous pourrez en reprendre ou changer selon votre goût. Même chose, pour les méthodologies Agiles.

Imaginer, 10, 100 personnes qui arrive au buffet, croirez-vous sincèrement quelle prendront exactement la même chose devant l'éventail choix qui sont mis à leur disposition. Chacun de vos projets est unique. Donc, il faut appliquer de manière unique les méthodologies Agiles.

Donc, Agile et ses implémentations méthodologiques (SCRUM, XP, LEAN,Kanban, Crystal Clear et autres) doivent s'adapter à votre besoin au moment de votre commande. Au besoin, on pourra changer de chef, changer d’ingrédients, inventer, mixer avec l’aide d’experts pour trouver la recette! La recette qui vous permettra d’atteindre l’objectif de créer un logiciel qui correspond à vos besoins.

Je m'engage à vous concocter la recette dont vous aurez besoin au moment.

Aujourd’hui, vous avez le goût de manger quoi, vous avez besoin de combler quelle problématique ?

Mutatis mutandis, une réflexion sur le WebCamp de Québec

Le 19 mai prochain, environ 400 professionnels de tous acabits de l’industrie du Web se réuniront dans une conférence participative de type BarCamp, ce sera donc une belle occasion pour tous de discuter.

 

L’objectif de ce genre de conférence est souvent partagé sur un domaine donné. Dans le cas qui nous intéresse, ils échangeront sur le Web. Mais si, aujourd’hui nous amorcions ensemble une réflexion le WebCamp, n’on pas pour le changer, mais juste pour poser un nouveau regard.

 

Un regarde de ce qui devrait être changé. C’est là l’essence de cette expression latine.

« En change ce qui doit être changé, et d’apprendre la différence de ce qu’il ne l’est pas ». Le changement c’est bien, pourtant il ne faut le faire sans réflexion à prime à bord.

 

Le Web arrivera bientôt à son âge adulte. Longtemps, il a été un monde réservé aux Geeks tant pour son utilisation que son exploitation. Progressivement, il s’est démocratisé à tous les niveaux. Il passa du programmeur jusqu’à l’artiste pour se rendre jusqu’à l’utilisateur.

 

La science de jadis devient un art ! Les techniques inaccessibles qu’aux professionnels devient facilement utilisable par nos utilisateurs.  Donc, aujourd’hui, demain, et pourquoi pas le 19 mai prochain. Nous devons apporter une réflexion sur ce qu’il serait intéressant pour l’aider à devenir grand.

 

De venir en grand, en mettant en place des outils, des stratégies de développement et différentes actions pour enfin  qu’on puisse dirent :  « Adulte, tu es maintenant ! » au sujet du Web. Et je crois que c’est une belle occasion, ce WebCamp  de Québec.

 

Avec les années plusieurs outils ont été mise à la disposition de toute personne qui s’intéressait aux technologies Internet. Du simple « vi » (éditeur en mode ligne d’Unix) pour écrire le HTML jusqu’au CMS le plus sophistiqué par exemple WordPress ou Drupal.

 

Des langages de programmation pour les types de programmeurs, avec Framework pour faire à peu près tout ce qu’on voudrait faire dans ce merveilleux monde du Web. En passant de l’open source jusqu’aux distributions commerciales.

 

Je ne crois pas qu’il y a un meilleur langage qu’une autre, il n’y a qu’un meilleur pour combler le besoin dans l’environnement technologique et organisationnel qu’il doit être livré.

 

Avec l’ensemble des outils qui sont mis à notre disposition, nous devons passer du travail de l’artisan à un travail plus professionnel. Cependant, il plus que le temps de mettre en place des stratégies, surtout des stratégies de développements.

 

Des stratégies qui ramèneront les principaux intéressés à leur place respective. Bien sûr, l’utilisateur final, c’est lui qui utilisera ce que nous allons construire. Sans oublie, les différents membres de l’équipe ou des équipes qui construiront le site Web ou l’application et bien sur le client qui payera le projet.

 

Bien sûr les méthodologies Agiles font partie de ces stratégies sans pour autant en être la seule. Le choix d’une stratégie doit être basé le partage. Le partage entre les individus, le partage d’information de données, le partage entre les organisations. L’échange et la communication doivent être au cœur même de cette stratégie.

 

Il faut aussi profiter des acquis qui se sont faits aux files des années. Aujourd’hui, nous ne devons pas toujours réinventer la roue. Plusieurs des choses, des bonnes et des mauvaises. Mais, il faut prendre le temps de valider leur utilisation. En prenant conscience que nous ne sommes plus seules. Que peut-être quelqu’un à déjà résolu le même problème que nous avons. Ou encore, que notre solution pourrait aussi servir à quelqu’un d’autre.

 

De l’open source aux formats ouverts, en passant architectures orientées services (incluant les environnements « clouds computing ») jusqu’aux différents réseaux sociaux. 

 

Plus d’un changement cogne à nos portes, nous ne pouvons pas (ou plus) faire la sourde oreille. Les gouvernements, les grandes entreprises comme la petite doivent prendre le temps d’évaluer toutes les solutions. Même les solutions qu’il n’y pas si longtemps, ne semblaient pas acceptable.

 

N’oublions pas, le Web n’est plus seulement dans nos ordinateurs bien assis à nos bureaux (au travail ou à la maison). Aujourd’hui, avec un ordinateur portable et un accès WIFI on peut avoir accès presque partout. Et ce n’est plus seulement l’ordinateur qui nous donne accès ce merveilleux monde !

 

Du petit téléphone intelligent, en passant les tablettes PC  ou le fameux IPAD. Et même, la télévision qui servira bientôt comme terminal  pour naviguer sur Internet. En plus, programme télévisé qui sont webdiffusé.

La TÉLÉVISION qui s’annonce de se présenter dans le WEB et bien sûr le présenter aussi ! Nous n’avons qu’à penser ToutTv.com démontré ce point.

 

Mais, il ne faut pas oublier notre ami Google que presque chaque jour, repousse les limites. Une vraie « vague » d’évolution que nous ne sommes pas les seules à utiliser.  Il n’est pas loin, le jour où un client va nous demander une application comme Google Earth. Car, lui aussi l’utilise maintenant.

 

Je ne sais pas ce comment demain sera fait. Mais, une chose est sûre ! Ce sera au moins Web. Donc, c’est important de tenir des activités comme le WebCamp et d’y apporter une réflexion sur le changement en cours.

Au plaisir de discuter avec vous au WebCamp.  

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.

Agile et la modélisation, une première réflexion !

Traditionnellement dans les projets, construire ou non, l’architecture (donc la modélisation) ne se posait pas comme question. Dès que le projet était assez gros, on lui affectait un architecte (ou une équipe d’architecte et de modélisateur) pour construire l’architecture logicielle. Leur responsabilité était d’effectuer la modélisation du logiciel et de la base de données pour tout le système. (L’architecte, bien entendu je ne parle pas de la personne, mais du ou des rôles au sein du projet).

Durant cet exercice classique, l’architecte ou le modalisateur effectuait la conception du logiciel et de sa base de données. Un travail qui pouvait prendre beaucoup de temps. Un beau travail qui n’apporte rien au client, et ce, tant que le travail de programmation n’était pas commencé.

Mais en Agile, comme nous livrons des petits morceaux d’applications fonctionnelles par cycles. Il est difficile de penser qu’on peut faire toute la modélisation en début de projet. D’autant plus que de cycle en cycle, le besoin peut changer. Donc, ce qu’on aura modélisé au début (selon les approches classiques) risque de plus correspondent au besoin ou tout simplement être invalidé en cours de route.

Cette réflexion, pourrait faire conclure plusieurs personnes qu’il n’est pas nécessaire d’effectuer la modélisation ou de créer une architecture logicielle. Pourtant, même si nous sommes en Agile, elle demeure aussi importante.

Maintenant que nous sommes d’accord avec ce principe. Vous me direz comment, il faut le faire ? Je n’ai pas de techniques infaillibles. Mais, quelques principes que j’utilise selon le besoin.

Il y a plusieurs façons de faire cette modélisation, cette architecture logicielle. Mais, ce qui est généralement reconnu est de le faire selon le principe du juste à temps. C’est donc de faire ce qui est nécessaire pour le cycle.

Pour ma part, je conseille la règle du 110-120% nécessaire pour le cycle. L’excédentaire est une prévision pour le cycle suivant. 100% du besoin de ce que nous devons construire et 10-20% de mise en place des pièces qui seront nécessaires pour l’interconnexion des cycles suivants.

Par exemple, si nous travaillons sur la facette de la fiche Client. Il serait intéressant de prévoir les orientations des facettes commandes et facturations. Sans pour autant compléter le travail de ces dernières facettes.

Il arrive parfois pour le besoin du projet, nous avons besoin de mettre en place les bases ou les orientations d’architecture. Dans ce cas, n’ayez pas peur de faire un premier cycle consacré qui couvrira ces orientations. Mais, surtout faire une modélisation qui pourra évoluer selon les besoins durant le déroulement du projet. Il sera toujours le temps de le faire dans le cycle qui touchera la facette concernée.

Construiriez-vous une application, s’en savoir où en aller ? S’en avoir une vision de l’architecture sur quoi baser votre développement. Bien sûr que non. Donc, faire de la modélisation va de soit. Pour ce faire, voici quelques techniques qui peuvent vous aidez à faire cette modélisation. J’aime bien utiliser la modélisation par domaine pour la partie plus organique et les « User Story » pour la partie plus fonctionnelle.

Une bonne référence qui vous permettra de mieux faire la lumière sur le comment de la modélisation en contexte Agile, je vous suggère cette référence en Anglais : Agile Modeling. Elle couvre beaucoup de techniques relatifs à cette approche.

Mais, surtout voyez cette référence, commune une autre boite d’outils, et non le moyen comment faire la modélisation. Être Agile, faire un projet en Agile, ce n’est pas d’abandonner vos bonnes pratiques. C’est simplement, parfois, de les utiliser différemment !

En autres mots, il ne faut pas chercher à tout réinventer toute la modélisation. Il suffit de restreinte sa pensée au besoin du cycle. Rappeler-le souvent à vos architectes classiques.

Rappelez-vous la règle du rhinocéros. Il est difficile de le manger d’une seule bouchée, mais en toutes petites bouchées, c’est plus facile.

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 !

Mes petites résolutions Agiles pour l’an 2010.

Quelle belle tradition que sont les résolutions du Nouvel An. J’ai eu donc l’idée de vous partager aujourd’hui quelque une de mes résolutions pour ce Nouvel An. Mais, surtout un pour une année que j’espère où les méthodologies agiles prendront encore plus la place qui lui revient.

La première, nous (Moi, mon organisation, vous, tout le monde) à parler avec le plus de justesse possible des méthodologies Agiles. Quand nous voulons être une référence, il faut toujours vérifier ses affirmations et les baser sur la vérité, une vérité vérifiable.

La deuxième, dépassé plus que la simple formation. Travailler avec les gens pour les accompagner à s’accaparer les méthodologies. Je crois que pour les méthodologies Agiles, prend la place qu’elles méritent. Les gens doivent s’accaparer un peu comme leur langue maternelle.

La troisième, accompagner les gens ainsi que leur organisation, dans leurs choix et leurs transitions vers les méthodologies Agiles. Si vous le ne savez pas encore, choisir d’effectuer ce virage n’est pas une chose facile. Donc, les gens ont besoin de notre aide, mais surtout de notre accompagnement.

La quatrième, continué, continué à expliquer, mais surtout à ÉCOUTER les gens qui s’intéresse aux méthodologies agiles. Comme dit le bon vieux proverbe, on a deux (2) oreilles et une bouche. Donc, on doit écouter deux (2) fois plus !

Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.

En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.

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, 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é !

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.

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.

Qu’est-ce que sait d’être Agile .. ! Partie 3 (La collaboration avec le client..!)

On vu dans les précédentes publications, le développement d’application et les interactions entre les individus.

Mais comme vous le savez tous, on peut avoir de millions de projets, mais si on a aucun client pour payer le développement, on ne fera pas longtemps du développement.

Comme il faut un client, il faut donc communiquer avec.. ! et les puristes.. Diront qu’on va aussi avoir besoin de contrat pour définir les limites du projet.
Vous avez tous raison, mais tout comme précédemment, je vais ressortir ma phrase fétiche, il faut repenser les concepts différemment.

Le contrat doit est un cadre de fonctionnement pas seulement un carcan immuable. Ce que tout client veut, c’est avoir un logiciel fonctionnel et surtout un logiciel qui résout son problème.

Mais comme personne d’entre vous n’a de véritable habileté de devins, est-ce qu’on peut croire qu’on peut écrire toutes les limites d’un projet informatique. Pour ma part, je ne le crois pas .. !

A l’inverse, il ne faut pas travailler sans contrat non plus, sans carde qui régit le projet. Mais à défaut de le fixé dans le béton, il faut peut-être trouver une approche qui nous permettra de faire évolué, lorsque nécessaire l’enveloppe budgétaire.

Ce que beaucoup de gens-conseil, et que je recommande aussi, c’est de définir un cadre d’évaluation (du genre "Planning Poker") les taches en mode unité, des unités très petites. Chacune de ses unités correspondra à une valeur monétaire. Par conséquent, il sera plus facile d’évaluer la complexité.

En structurant ce cadre, il ne faut pas oublier de dire un gros merci à notre client en lui disant que n’on allait pas que le revoir qu’en fin du projet. Tout comme pour les interactions entre les membres du projet, le client doit aussi faire partie de l’équipe.

Il doit dans la mesure du possible être accessible, ou la limite son représentant. Tous les membres de l’équipe doivent pouvoir y avoir accès. Une réponse rapide et efficace du client est un avantage.

Une organisation que j’ai connue, avait choisi d’impliquer le client en l’installer dans les mêmes locaux que l’équipe de développement. Le client avait son bureau dans la même salle, ce qui permettait aux membres d’y avoir accès rapidement et inversement.

Je dirais bravo, c’est une bonne idée, mais il faut trouver dans votre contexte la meilleure manière de l’impliqué le client, c’est de la trouver. Ce n’est pas tout les clients et les organisations qui peuvent se permettre de libérer le client pour l’installer au sein de l’équipe de développement.

Les méthodologies agiles, ce n’est pas une liste de recette magique, seulement des moyens pour résoudre tous les problèmes, mais aussi une manière de réfléchir différemment.

La solution que moi, je propose toujours à mes clients, c’est simplement de leurs dirent. Quand tu as 2 minutes, et que tu as le gout de voir où en est rendu. « Passe me voir, et je te promets que je vais essayer de prendre le temps de te le montrer. Mais, tout comme vous (le client), il pourrait arriver momentanément que j’ai une urgence à répondre, et dans ce cas-si, que je ne puisse pas répondre immédiatement à votre besoin. »

Généralement, mes clients étaient toujours heureux d’avoir la possibilité de venir me voir sans avoir peur de me déranger. Car, il le savait, que si je ne pouvais pas leur répond dans l’instant, je leur reviendrais rapidement.

Reporter une petite rencontre à l’improviste, il ne faut le faire avec discernement et intelligence. Mettez-vous dans la peau du client, si à chaque fois qu’il vient vous voir, vous lui répondez que vous n’avez pas de temps. Il ne reviendra plus !
Il est aussi permis, de gentiment demander à un client de vous laisser le temps pour travailler, lorsque celui-ci utilise un peu trop ce privilège.

En impliquant le client, en lui donnant l’importance qu’il mérite, nous aurons l’information, cette information tant recherchée.

De plus, en effectuant le développement en par petite phase comme expliqué dans un autre article. Le client sera beaucoup plus ouvert. Il faut bien sur lui expliquer que nous ne voulons pas un bar ouvert sur le budget de sa part. Et aussi, qu’il n’a pas non plus le bar ouvert sur les fonctionnalités incluses dans son logiciel.
Un client qui comprend qu’il y a un cout, un temps et un effort nécessaire pour tous tâches, et surtout que le tout régit dans notre cadre.

S’acharner dans discussion contractuelle avec un client, ce n’est pas profitable à personne. N’oublions pas notre but, tant celui de l’équipe de développement que celui du client, c’est de produire un logiciel qui fonctionne et surtout, qui correspond au besoin du client.

Travailler en agile, en méthodologie agile, c’est aussi faire un peut d’évangélisation. Il faut prendre le temps, d’expliquer pourquoi et comment on fait les choses, avec le temps, il y aura plus de gens qui seront convaincus.
Je crois que tout client avec qui on aura réussi, sera le premier à promouvoir cette nouvelle approche.

Être, agile ce n’est pas de changer les choses, c’est de penser différemment !

Qu’est-ce que sait d’être Agile .. ! Partie 1 (Les individus)

Beaucoup de gens se disent Agile.. Mais qu’est-ce que sait d’être Agile.
Être Agile s’est d’abord avant tout, quatre grands principes :

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

Dans ce premier article, nous regarderons l’aspect des individus et les interactions dans un projet en méthodologie Agile.

« Les individus et les interactions doivent primer sur les processus et les outils. » Beaucoup de méthodes, processus ont toujours cherché à créer la recette miracle qu’on pourrait appliquer à tous les projets pour garantir la rentabilité et le succès (livré à temps et selon le budget du contrat.).

L’expérience, et il semble que je ne suis pas seule, m’a démontré que cette recette miracle n’existe pas.. ! L’un des principaux problèmes est classement des individus par « type de profile » mais sur tout dire comment chacun des profiles va communiquer avec l’autre. Régir les communications par des documents structures.

Les grands mérisiens de se monde ont oublié que les individus, ont une capacité extra ordinaire, c'est-à-dire « SE PARLER » . Il suffit de mettre un groupe de personne ensemble avec intérêt en commun dans une salle, et en quelques minutes ! Il y aura la majorité des gens qui discuteront ensemble.

Ce que dit les principes de la méthodologie agile, laissons les gens parler, communiquer ensemble. Ils trouveront la meilleure méthode de communiquer. Il n’est pas interdit de mettre en place des processus et des outils qui faciliteront cette communication. Mais, il ne faut pas chercher à les structurer de manière telle que les individus refusent de communiquer.

Il faut leurs données des outils simples, des wikis, des post-its, une adresse de courriel..

Une machine à café.. ! Qui n’a pas réglé un problème majeur en allant chercher un café à la machine à café. Tout ceux qui ont travaillé avec moi savent que veut dire « Coffee Time’s ».Une petite expression.. ! pour dire OK.. Les amis, on prend une pause.. Pour se changer les idées.. ! Discuter autrement une problématique qu’on cherche à résoudre. Briser la forme, de voir autrement le problème.. mais surtout de prendre une petite pause.. Pour se changer les idées.. ! Ça fait du bien.

L’autre point important pour se dire agile.. c’est de tout mettre en œuvre pour éviter le temps supplémentaire… ! Un moyen que j’ai appliqué et que je sais beaucoup applique, c’est la règle du pouce 3-6.

La règle du pouce 3-6, est simple. C’est de découper en petite tâche de 3 et 6 heures. Vous me direz pourquoi 3 et 6 heures. C’est simple, 3 heures auxquelles on ajoute une heure, donc 4 heures au total, c’est une demi-journée et même chose pour 6 heures, représente une journée lorsqu’on lui additionne une heure (7 heures).

Une tâche de 3 heures, normalement au bout d’une heure, la ressource attitrée aura une bonne idée du travail faire. Elle aura identifié toutes les problématiques qu’elle devra résoudre. Et l’heure d’étalonnage au besoin permettra de finir le travail.

Le cas échéant qu’une ressource, identifie un problème majeur, récupéré une heure de travail, sur un projet normal de développement, c’est très facile.

A l’inverse, une tâche d’une durée de 30-40 heures, le temps normal d’évaluation de la complexité et des différentes problématiques qui pourraient survenir, c’est au moins une dizaine d’heures. Ce qui rend la récupération des heures perdues, encore plus difficiles. Donc, qui provoque souvent du temps supplémentaire.

Mais cette règle du pouce 3-6 demande aussi une grande responsabilisation des ressources et prise de confiance de demander rapidement de l’aide. Plus rapidement qu’on sait qu’il y a problème quelque part, et quelque nature que se soit, plus vite on peut réagir, chercher des solutions.

L’implication de chacune des ressources, l’implication en contexte Agile sont très importantes. C’est l’une des clés du succès. Le premier projet que les gens vivront en Agile, vos gens risquent d’être un peu perdu..

Parce la responsabilité ne repose plus sur les épaules d’une seule personne, mais sur tous les membres de l’équipe, sur eux en particulier. Les anciens principes chacun avaient sa responsabilité, et on ne devaient pas franchir la frontière de la responsabilité de l’autre. En Agile, chacun à un rôle principal et un rôle secondaire. Ex un développeur en plus de sa responsabilité de développer l’application, pourrait être l’assistant à l’administrateur de données.

L’avantage de cette double responsabilité, si le principal est trop occupé ou encore absent, son second peut prendre en charge momentanément effectuée le travail que l’autre aurait fait normalement.

Il est conseillé d’attribuer les rôles selon les intérêts des individus. Car, un individu qui a de l’intérêt pour une tâche, une expertise.. il s’y investira naturellement davantage que pour une qu’il n’en a pas.

Faisons confiance aux ressources, donnons les outils pour faciliter leur travail. Le climat de travail sera agréable pour tous, donc productif.
L’autre chose qu’il ne faut pas oubliée. L’être humain n’est pas fait pour travailler 20 h par jour. En partant de se principe, il faut se rappeler quand on peut éviter le temps supplémentaire, il nécessaire de le faire.

Dans un projet plus traditionnel, le temps supplémentaire est un moyen de récupérer le retard que la vie du projet à occasionné. Mais, la règle du 3-6 cherche justement à minimiser les retards.

Les méthodologies Agiles ne disent pas qu’il ne faut pas faire du temps supplémentaire. Mais qu’il faut prendre tous les moyens pour l’éviter. Et si, le besoin survient, la période de temps supplémentaire ne devait pas dépasser 4-5 jours par mois ou par cycle.

Le temps moyen d’un cycle, que j’ai connue qui généralement utilisé est entre 5 et 20 jours, mais si vous me permettez, la durée des cycles et leur fonctionnement, se sera le sujet d’un autre article.

En terminant, des ressources reposées et heureuses vont s’impliquer et mettre tout en œuvre pour le succès du projet. Car, tant le succès que l’échec, leur sera attribué individuellement que collectivement.
Soyez Agile, restez ouvert d’esprit et essayez de penser différemment.

L'équipe de GénérationAgile.