Les comités d'architectures, pour ou contre.

Les comités d'architectures, pour ou contre.

On dit en méthodologies Agiles qu'on doit prioriser le travail d'équipes. Mais, à quel prix ? Surtout quand et comment, on parle d'architecture logicielle.

Un architecte logiciel au sien d'une équipe traditionnelle est le maitre après Dieu. Il est surtout le maitre désign logiciel. C'est lui, éminence grise, sur ce domaine. Les autres membres de l'équipe n'ont qu'à appliquer ce que ce « Dieu » a décidé.

En plus, de son travail s'effectue en début de projets. Où il met les grandes lignes de l'architecture (L'ARCHITECTURE LGOCIEL) et puis s'en va du projet. Et dans de très rares cas, lorsqu'on est vraiment chanceux et que le projet est long (conséquemment très gros). Et parfois, il reviendra en cours de projet, pour faire une revue d'architecture.

Mais, disons que cette stratégie n'est pas vraiment « Agile ». Mais, certaines organisations pour aider (ou favoriser) le travail d'équipe. Mais aussi la compréhension des membres des équipes de développement. Elle forme de ce qu'on appelle des comités d'architecture.

Un comité où les membres, indépendamment de leurs niveaux de compétences, s'assoient ensemble pour construire l'architecture du logiciel et bien sûr la mettre en œuvre. Arriver à un consensus sur les différents choix d’architectures nécessaire aux projets.

J'avoue que dans certains contextes et lorsque l'équipe est restreinte, cela peut fonctionner. Par contre, si l'équipe est trop grande, que la disparité des compétences (surtout en architecture logiciel) ne s'égale pas. On peut tomber dans le piège de la réunitivite. La maladie des réunions qui s'étire pour n'arriver à aucun consensus.

Donc, c’est quoi le compromis qu'il faut faire. Je sais, vous voulez une solution toute faite. Mais, si vous êtes lecteurs réguliers de mon blogue, vous savez que je ne donne jamais de solutions toutes faites. Je propose généralement une approche plutôt qu'une solution.

Mais, c'est quoi le rôle de l'architecte logiciel au sein d'une équipe Agile. D'abord concevoir cette architecture logiciel, je sais c’est évident. Mais, c'est bien de se le rappeler. Mais, contrairement aux environnements traditionnels. Il n'est pas le « DIEU » de l'architecture. Mais, l'expert aux SERVICES, oui aux SERVICES des autres membres de l'équipe.

De plus, son intervention aux projets de ne doit pas se limiter à une p'tite vite en début de projet. Mais, tout au long du projet. Il est au service de l’équipe et de ses membres

Donc, l'approche que j’utilise (oui je suis aussi Architecte logiciel « Agile ») et qui fonctionne avec les équipes dans lesquelles je l'ai appliqué. C'est que je conçois seul une première version de l'Architecture. Une fois conçu, je la présente oui, à un comité d'architecte « RESTREINT ». Il est généralement composé de 2 à 3 autres personnes (membre de l'équipe bien sur), ceux qui sont les plus expérimentés ou qui peuvent apporter quelque chose aux discussions.

Je présente toujours le concept d’architecture, en disant que je leur présente ma vision pour leur faire valider. Je suis à leur service et non l'inverse. Le but de cette première rencontre, c’est d'établir les bases de « NOTRE » vision de l'architecture logicielle. Lorsqu'il est nécessaire, nous pouvons ensemble la raffiner.
Une fois que cette petite équipe est arrivée à un consensus. Je dis bien un consensus, peut-être pas à la véritable architecture. Mais, les premières bases qui doivent être mises en début de projet. Elles seront et devront être raffinées en cours de projet. J'utilise cette approche à chaque phase importante d'architecture.

Tout faire en équipe, c'est philosophiquement bien. Mais, impossible à appliquer correctement dans le monde réel. Si nous sommes trop nombreux à discuter ensemble pour des choses simples. Il risque fort qu'on consomme du temps inutilement. Prendre de faire la sélection d'un groupe de composantes ou des grandes lignes d'architectures. Nous n'avons pas besoin d'avoir l'opinion de chacun des membres. Au besoin, leur poser individuellement la question, pourra très bien suffire

Il faut prendre le temps d'évaluer la rentabilité des efforts et le temps consommé aux projets. N'oublions pas, notre « ULTIME » but c'est de produire un logiciel. Ne pas faire, des réunions justes pour faire réunion.

En résumé, faire des comités d'architectures logiciels, oui, seulement lorsque c'est nécessaire. Rappelez-vous de vous poser les questions suivantes.

Pourquoi je fais quelque chose ?

Pour qui je le fais ce quelque chose?

Et surtout comment on doit fait la chose ?

Quelle est le meilleur outil pour construire le Web ?

Quelle est le meilleur outil pour construire le Web ?

Lors du dernier #WEBCAMP #QC, cette question a été lancée. Il y a eu un débat intéressant !

Mais, j'aimerais si vous me permettez, d'y réponde en plus de 140 caractères.

Toujours lorsque me pose ce genre de question, je réponds à peu près la même réponse. « un petit calepin, un crayon,  mes deux (2) oreilles et mon équipe ».

Car, avant toute de choses, l'origine de l'application web que nous voulons construire est un « CLIENT ».  Sans lui, il n'y aurait pas de projet !

Mes 2 oreilles me permettent l'écouter, mon calepin et mon crayon prendre des notes sur son besoin. C'est seulement après pris conscience de son besoin que je puisse enfin choisir qu'elle sera le meilleur outil pour répondre à son besoin.

Peut-être parfois, je prendrai des plates-formes #OpenSource ! D'autres du .Net ou même du Java (J2EE). Mais,  peu importe vers quoi se tournera mon choix, il devra absolument répondre à ces critères.

1-Techniquement et efficacement rentable pour mon Client !  Si pour arriver à construire l'application qui rempli son besoin ! Que parce que j'ai choisi le langage « X » dans l'environnement « Y », le projet me prend 6 mois de plus avec des « Gourous » qui seront seules à comprendre ce qu'ils font. À mes yeux, je me tire dans le pied.

2-Une fois le projet terminé ! Est-ce que le client ou encore une équipe réduire, sera capable de supporter et d'entretenir l'application et son environnement ! J'ai trop vu souvent ! De belles applications, qui faisait pour quelque chose de simple (informatiquement parlant) et qui demandait une armée pour la supporter. Et là, je ne parle pas d'une plate forme de gestion de grandes entreprises. !

3-Mes choix technologiques sont-ils compatibles avec l'environnement de mon Client. Exemple, si mon client est ORACLE-JAVA-LINUX-Progress mur à mur, et que je lui arrive avec une application construire en ASP.NET sur une base de données SQL SERVER. Comme on dit l'application a besoin d'être belle ..!

4-L'expertise, l'expertise (les ressources humaines) nécessaire pour la mettre en œuvre existe-t-elle sur le marché local ou régional de MON CLIENT. Si mon client est perdu dans le Grand Nord et les seuls programmeurs qui peuvent l'aider et qui habite sa région, ne connaît que le PHP. Je n'irais pas l'écrire en JSF parce que tout simplement moi j'aime ça. On attache nos clients par la qualité des services qu'on lui rend et non par notre expertise technique qu'on possède.

5-Le web existe depuis longtemps, il a vu passé plus d'un langage ! C Pour faire les CGI-BIN, de l'ASP standard, Java pour faire des applets et tout le reste.  La question n'est pas de répondre qui est le meilleur ! Mais, qui est le meilleur aujourd'hui ! Si refaisons le projet dans un an, dans 2 ans nos choix seront peut-être différents.

Je fais du Web depuis presque ses débuts ..! Et malgré toutes ces années, je n'ai pas trouvé le LANGAGE DE PROGRAMMATION meilleur que tous les autres. J'en ai juste trouve certain mieux adapter pour répondre à un besoin ou à contexte donné.
Rappelez-vous, le langage de programmation est un outil et non un moyen. L'outil est remplaçable par un autre. Quant au moyen, c'est la seule manière de faire la chose.

En résumé,  ayez un bon coffre à outils !

Si vous me racontiez une petite histoire ?

C’est souvent comment, j’aborde mes séances d’ « User Storie » avec des usagers.
Au cours des prochaines lignes de ce billet, je vais essayer d’apporter mes lumières sur l’utilisation de cette méthodologie d’identifications de besoins et des fonctions de l’application des utilisateurs.
Beaucoup de gens plus traditionnels on peur de s’y impliquer trop à font ou encore ne savent pas comment le faire, sans embarqué dans dans une spirale de besoins. Ou encore pire, en utilisant un langage trop compliquer pour l’utilisateur.
L’utilisateur moyen comprend souvent mieux son son travail que le pense ! Pourquoi pas, de lui proposer une technique simple pour nous l’expliquer. Si on leur permet de nous parler, sans qu’ils sentent moins compétant ou inférieur à nous. Généralement, ils vont nous faire de belles surprises. Nous connaissons l’informatique, mais eux connaisse leur domaine. Notre logiciel doit s’adapter à leur besoin et aussi à leur domaine d’affaires. Laissons-les-nous en parler !
Les histoires utilisateurs (ou en anglais « User Stories ») permet de créer cet environnement facilitateur, et ce, sans l’utilisation d’outils complexes. Il est rare de trouver une personne qui est incapable de parler ce qu’il fait à tous les jours.
Qui ne sait pas dessiner grossièrement un écran juste pour donner un premier ébauche de ce quoi il pourrait ressembler. Mais, surtout prendre le temps d’écouter l’utilisateur sur ce qu’ils voudraient en faire.

Car, n’oublions pas, notre quête ultime dans cet exercice, c’est de livrer en fin de projet la meilleure application. La meilleure application qui correspond tant aux besoins de notre utilisateur. Mais, aussi selon contexte organisationnel (incluant sa capacité de payer aussi).
Trop souvent pour atteindre cet objectif, on utilisait un jargon trop technique; peut-être pour nous monter un peu trop savant ! Mais en restreignant notre langage à celui que tout le monde peut comprendre et surtout l’utilisateur. Il sera vite à l’aise de nous parle de toutes ses préoccupations. Il sera toujours temps d’écrire une belle documentation pour conserver ou officialiser ce besoin.
Nous en méthodologies Agiles, nous acceptons le changement. C’est vrai. Mais, plus rapidement ce changement arrive. Mais, aussi sa compréhension devient claire plus vite nous adapter dans le projet. Plus, nous aurons la capacité de l’adresser et d’y faire face. Plus auront la facilité d’atteindre notre objectif final.
Cette belle histoire que l’usager va nous raconter. Elle ne doit pas être laissée à tous les vents. Mais, accompagner tant dans son traitement que dans son discours. On peut bien raconter, les contes des mille et une nuits. Si cela n’apporte rien à la compréhension, cela ne sert à rien.
Il aussi intéressant, de permet à l’occasion de parler de sont travail d’une manière plus générale. Car, en racontant ces petits à côtés. À une oreille, bien à viser, on peut découvrir bien choses qui vont nous aider dans notre quête.
J’aime bien entendre raconter mon utilisateur ce qu’il fait en prenant son café en arrivant le matin. J’y ai découvert de vraies petites perles. Souvent même, sans que l’utilisateur se rendre compte de ce qu’il m’avait raconté, de l’importance de son histoire.

Raconter une histoire, c’est bien beau. Mais, comment faut-il le faire. Comme dit l’expression, nous avons deux oreilles et une bouche. C’est qu’il faut écoute 2 fois plus qu’on parle. Prendre des notes au besoin, des petits schémas, de petits dessins et l’utilisateur n’y voit pas d’inconvénient, enregistrer les conversations.
Il faut aussi, bien sûr, prendre des notes de ce que l’utilisateur nous explique. La manière le plus simplement, c’est par l’utilisation de grand Post-it ou d’un tableau. Si vous utiliser un tableau, d’apporter une caméra pour prendre une photo de ce qui a été écrit au tableau. C’est important de garder ces grands Post-it ou photos pour conserver une trace de ce qu’il a été discuté avec les utilisateurs.
Il est très conseillé de limiter à 4 ou 5 points de formes par fiche. On se croit toujours avoir une mémoire très supérieur à la réalité. Mais, il est facile de se rappeler de l’information comprise dans 4-5 items. Plus que ça, il sera difficile de combler l’information des points formes.
Et quand on dit, des points de forme. On ne dit pas de romans. Il faut se limiter à une ou deux phrases courtes. Une phrase d’actions et surtout affirmative. Nous voulons décrire ce qu’on veut faire et non l’inverse.
Restons simples, restons Agile tant notre approche que dans nos actes. Et faisons- le ensemble, en impliquant l’utilisateur, nous atteindrons notre objectif. De créer la meilleure application pour notre utilisateur. Et j’en suis sur, il en sera d’autant satisfait. Car, il se sentira impliqué dès le début et jusqu’à la fin.
Lors de ces séances d’ « user stories » vous ne devez pas diriger la conversation ou la rencontre. Mais, vous devez l’animer, idéalement nous en voulons toujours plus, avoir toute l’information d’un seule coup. Mais, parfois, il sera nécessaire, tant pour compréhension du système système ou domaine d’affaires. Ou parce que l’utilisateur avait plus d’information à nous donner.
Il sera toujours le temps, d’en refaire une autre pour compléter ou même améliorer la compréhension du besoin. Parler, s’assoir avec notre utilisateur, lui donner l’occasion de nous parler de son besoin, c’est aussi ça d’être Agile.
Avez-vous une petite histoire à me raconter ?

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 !

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