Indicateurs quantitatifs

Considérons quelques indicateurs (parmi tant d’autres) visant à quantifier le fonctionnement d’un projet agile

  • nombre de story points (de user story) réalisés dans une période (une itération, une release) par jour.homme, pour intégrer les variations de capacité de production (vacances, disponibilités partielles). Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Voici le backlog, voici la colonne story points, voici le total, je divise par tel ratio, voici le nombre d’itérations, voici la date d’atterrissage, vous pouvez décaler la release de x mois si on ne change rien.
  • nombre d’heures idéales (de tâches) réalisées dans une période (une journée, une itération) par jour.homme. Moyenne plus ou moins glissante. Instructif quand il s’agit de planifier la suite. Pas évident d’expliquer qu’en une journée on fait 5,8 h idéales et pas 7 ou 8, si ce n’est en le montrant
  • % des story points prévus qui ont été effectivement livrés dans l’itération. Pour éviter de trop s’engager à chaque fois et conserver la confiance.
  • % des story points prévus et livrés qui ont été finalement inclus dans la release finale, pour évaluer la quantité de changement du périmètre et la rationalité de la priorisation sur laquelle s’est appuyée la planification.
  • % des story points des user stories qui ont été ajoutés en cours de release, pour évaluer la stabilité du périmètre. Ok pour accepter le changement, mais ca prend du temps.
  • Somme de l’estimation en heures de correction idéales de bugs injectés par itération, pour évaluer la qualité du processus de devt, la surchauffe.
  • Etc… (Je n’aborde pas ici l’efficacité directe des rituels, comme la durée du standup ou le temps entre le moment où une idée est évoquée en rétrospective et le moment où elle est prise en compte (ou abandonnée))

L’essence de ces indicateurs est toujours la même. On confronte le projet au réel (demandes du métier, développement et corrections de defects) pour en déduire a posteriori des indicateurs sur le fonctionnement du projet permettant, en s’appuyant sur cet historique des projections sur l’avenir (toutes proportions gardées, le cône d’incertitude se réduisant au fur et à mesure de l’avancement du projet) ou pour identifier des plans d’action (resensibiliser le product owner, améliorer la qualité, …).

Ne pas mesurer le temps passé par les uns et les autres mais bien les progrès effectués par l’équipe.

Inclure des correctifs de la capacité de production quand une personne est absente ou ne l’est pas.

Rester prudent en exploitant ces résultats, les indicateurs ne se stabilisent pas forcément dans le temps. Il faut les assortir d’hypothèses, et assortir les conclusions que l’on en tire de ces mêmes hypothèses.

Le but ultime : annoncer les mauvaises nouvelles dès qu’on les connait pour prendre les mesures qui s’imposent (réduire le périmètre, augmenter l’équipe (à utiliser avec modération), arrêter le projet). Ne pas faire l’économie de l’effort de communication, de préparation du discours (s’appuyer sur des faits et non des impressions). S’attendre à une résistance, un frein à l’action. Personne n’aime annoncer des mauvaises nouvelles ou demander une rallonge.

Publié dans Agile, Leadership | Laisser un commentaire

Que fait-on quand on sait que l’on a raison

Dans un projet agile, le « pouvoir » du chef devient le « pouvoir » du groupe, puisque l’on instaure une auto-cratie pseudo-démocratique. Sauf que cette « démocratie » repose sur l’influence que chacun peut avoir (titre, prestige, aura, charisme, caractère, relations…). Que faire quand on sait que l’on a raison et que l’on ne sait pas convaincre ses collègues ?

  • Se faire violence pour aller vers ses collègues
  • Ecouter les autres et le leur montrer
  • Envisager avec sincérité les autres alternatives
  • Etayer son discours (de références, de preuves,…)
  • Trouver des appuis
  • Mettre de l’eau dans son vin, pour espérer faire avaler la coupe. Mettre du vin dans son eau, pour que cela serve à quelque chose
  • Négocier point par point, savoir prioriser ses points
  • Anticiper les objections
  • Ne pas oublier pour qui l’on travaille (qui paye son salaire, qui paye la facture, qui finance le projet…). Ceci dit, un client vous sera gré de jouer le rôle de poil à gratter, si vous êtes habiles.
  • Ne pas mettre les autres en porte à faux en leur absence
  • Ne pas mettre les autres en porte à faux en public
  • Etre irréprochable : on ne doit pas douter de la sincérité de la démarche
  • Améliorer le crédit dont on dispose auprès de ses interlocuteurs
  • Utiliser le système : prendre la parole en rétrospective, utiliser le bon sens, la bonne foi, puis s’appuyer sur le plan d’action établi.
  • Revenir à la charge autant de fois que nécessaire, à chaque retrospective s’il le faut.
  • Ne pas attendre de la reconnaissance ou des remerciements, viser juste l’efficacité.

Bref, la politique reste présente, elle se pratique dorénavant vers les côtés, en plus de vers le haut. On est loin des aspirations idéalistes du geek. On parle de guerilla facilitation, l’art de faire avancer les choses sans statut officiel.

Publié dans Agile, Humain | 3 commentaires

L’agilité, outil de communication

Peut-être que ce qui me plaît le plus dans l’agilité, c’est d’ouvrir enfin la boîte de pandore de ce que pense réellement l’équipe (développeurs, testeurs) et de mettre le management de projet devant ses responsabilités. On n’impose plus un planning ou une organisation du haut vers le bas (au moins en théorie).

Il y a en particulier la valeur agile du courage.

Courage de dire vers en haut (ou même à son client) : non, il vaut mieux faire comme ça, ou même, non, ça n’est pas faisable.

Courage de dire vers en haut : nous en sommes encore à la première itération, il est très prématuré de nous demander des dates. Attendons la fin de la 3ème pour avoir un début de visibilité sur notre vélocité.

La possibilité d’avoir ce courage vient de sa mise en avant comme valeur, mais aussi de l’accord explicite entre le management et l’équipe d’utiliser les méthodes agiles. On peut dire beaucoup de chose à un client qui adhère au discours agile, même si c’est pour de mauvaises raisons.

L’agile est un objet bien pratique. C’est un bel objet, bien marketé par les signataires du manifeste et leurs héritiers. C’est aussi un objet à géométrie variable, qui s’adapte au contexte.

Il faut du coup du courage au coach, puisqu’il y a des degrés de liberté, pour ne pas se laisser embarquer dans la direction qui convient le mieux au management ou dans celle qui convient le mieux à l’équipe. Il doit pousser gentiment tout le monde dans une bonne direction, où l’on se remet en question, où l’on confronte ses idées au monde réel. Il doit donc communiquer sur l’agilité, sans être non plus dans une orthodoxie trop fermée au spécificités du terrain.

Faire parler tout le monde, tous les corps de métier. Refuser de s’engager indument, mais tenir ses engagement. Savoir dire non. Savoir dire oui.

Ce n’est pas si nouveau que ça, mais c’est devenu plus facile.

PS: Ou bien est-ce juste une question de génération, les ex-développeurs étant maintenant aux manettes, et se souviennent-ils du temps où ils étaient dans la boue ?

Publié dans Agile, Leadership | Laisser un commentaire

La solitude du manager

Le management est un rôle qui va avec une grande solitude. Solitude devant la hiérarchie qui demande des résultats. Solitude devant les collaborateurs qui attendent de vous des réponses, des décisions, de l’efficacité.

Une solution consiste à chercher le contact de ses pairs. Si possible de même niveau mais dans des branches différentes de l’organigramme, sans relation opérationnelle avec soi, histoire d’éviter les conflits d’interet (difficile de négocier avec quelqu’un dont on a sollicité l’aide la veille). Le « supérieur » hiérarchique ne peut jouer ce rôle que partiellement, car il a aussi comme tâche l’évaluation. Passer son temps à poser des questions à quelqu’un sensé vous évaluer n’est pas forcément le mieux (ca dépend des cas, ceci dit)

De ces échanges, le jeune (ou moins jeune) manager pourra retirer des bonnes pratiques, des retours d’expérience, une aide à la réflexion sur un cas concret que l’on n’arrive pas à poser, mais aussi peut-être des éléments sur le fonctionnement de l’entreprise, ce qui est toujours bon à prendre (même si dans les potins il y a aussi parfois du faux). Peut-être aussi des éléments sur le consensus ambiant (par exemple : quelle rémunération donner, sujet parfois tabou pour la hiérarchie ? Les comparaisons en la matière sont toujours instructives)

Et puis le manager doit-il vraiment être seul ?

 « Parce qu’une seule personne décide au final ». C’est faux : la plupart des décisions de fond sont à défendre et faire valider par l’étage au dessus. Et puis, surtout,  l’agilité montre que la meilleure décision est collégiale.

« Parce qu’une seule personne est objectivée sur le résultat du projet ». Ce n’est pas une nécessité. Un manager éclairé m’avait un jour proposé un variable sur le résultat de mon projet plus une somme à répartir entre les membres de l’équipe.

Peut-être que l’aspect du rôle le plus incarné est celui du sens. Donner du sens. Communiquer une image de l’équipe à l’exterieur. Communiquer une image de l’entreprise aux collaborateurs. Avoir une réponse.

 Il y a aussi le rôle d’annoncer les mauvaises nouvelles. Une équipe scrum, même démocratique, répugnera à prendre un collaborateur dans un coin pour lui dire de changer d’attitude. Il faut quelqu’un pour recadrer, même s’il vaudrait mieux que les membres de l’équipe les plus proches du fautif lui en touchent deux mots, en apparté (l’idéal étant la ‘stéréo’ : le chef + les potes)

Et puis j’apprécie mes entretiens de « performance », il me faut un interlocuteur. Avoir quelqu’un avec qui se poser, faire un bilan, trouver des axes d’améliorations. Je ne sais pas ce qui se passe dans la tête de mon manager, alors. Je ne peux que l’imaginer en étant dans la situation inverse, à essayer de donner des pistes à mes collaborateurs pour qu’ils s’améliorent, en les secouant parfois, en ne cédant pas forcément à toutes leurs attentes, en essayant de trouver des solutions pour qu’ils poursuivent au mieux leur carrière chez « nous ».

C’est peut-être ce « nous » qui change tout. Un manager (dès le premier niveau dans l’organigramme) représente l’entreprise. Et l’entreprise souhaite avoir des collaborateurs autonomes. Donc ses représentants doivent l’être, et se débrouiller seul. Ou au moins, en avoir l’air, même si personne n’est complêtement dupe.

Publié dans Leadership | 3 commentaires

L’agilité dans la conception

Admettre que l’on n’est pas dans le secret des dieux

Ne pas concevoir maintenant en faisant des hypothèses sur le futur sans avoir les éléments.
Ne pas supposer que l’on va avoir besoin de quelque chose. Ne pas supposer que l’on ne va pas avoir besoin de quelque chose.
(cf Options Thinking dans Lean Software Development de Mary & Tom Poppendieck)

Avec agilité, mais avec clarté

Concevoir quand même à chaque itération, en équipe, pour bénéficier d’un maximum de créativité, pour partager la conception. Poser vraiment le problème, à fond.

Ne pas aller trop vite, aller assez vite

Prendre le temps d’étudier les différents scénarios, les critères selon lesquels on va les retenir, l’évaluation des scénarios afin de prendre la bonne décision.

Concevoir dans un intervalle de temps limité (ex: réunion de conception de 15h à 17h30, pas plus). Cela oblige à se concentrer sur l’essentiel.

Articuler besoin & solution

Concevoir et affiner sa conception en articulant les différents niveaux de besoin et solution.
J’ai besoin d’un historique règlementaire pour ça je logge tout dans un fichier pour ça j’utilise log4j et la programmation orientée aspect
Bien distinguer besoin (pourquoi) et solution (quoi). La solution d’un besoin devenant un besoin attendant lui même des solutions.
Ex:

Besoin = historique règlementaire, Solution = log dans un fichier
Besoin = log dans un fichier,Solution = log4j + POA
J’ai appliqué cette approche à mes initiatives open-source, cf http://softreves.wordpress.com)

Confronter sa conception au réel, au fur et à mesure.

Le réel ca peut être de tenter de l’implémenter et voir comment ça vient.
Le réel ca peut être d’élaborer des exemples et voir comment ils sont traités par l’algorithme.
Le réel ca peut être un collègue qui fait une revue de conception pour voir si elle est bien posée, si on n’a rien oublié d’évident.

Laisser faire le temps

Laisser reposer un peu, aussi, pour que les neurones et les synapses communiquent en vous et maturent l’idée.

Avec le courage de défaire et refaire

Et puis si, confronté au réel, quelque chose cloche, avoir le courage de remettre ses plans sur le métier, en particulier de prendre le temps de le faire.
Plus tard, si confrontée à de nouveaux besoins, la conception qui a été implémentée est maintenant inadéquate, re-concevoir, re-factorer (grâce à une couverture par les tests automatiques élevée).

Publié dans Agile | Laisser un commentaire

Innover dans une SSII

CMMI a pour vocation la capitalisation, l’homogénéisation des pratiques, afin que tous les projets fonctionnent pareil, et afin d’avoir le même niveau de pression sur chaque projet. C’est louable, mais cela me semble un peu limité en terme d’innovation : les chefs de projets appliquent les pratiques officielles, et ne vont pas tous chercher beaucoup plus loin. Les experts diront, à juste titre, que les règles CMMI sont configurables selon le contexte.

Inversement, j’ai récemment répondu à un twitt de @bcourtine qui demandait s’il fallait rentrer dans subversion les fichiers de conf de Eclipse, i.e. s’il fallait que les environnements de tous les membres de l’équipes soient identiques, s’il fallait uniformiser ces environnements de développement. Je pense que oui, je pense que l’équipe doit échanger sur les pratiques et se mettre d’accord (dans le cadre du projet précis qui lui est confié). Je pense aussi que c’est un pré-requis indispensable à la construction de scripts ou d’outils de productivité innovants, parfois propres à chaque projet. Il a très bien détaillé son point de vue sur son blog.

J’en reviens à mon délire sur le personnage de l’Oracle. Il faut que les membres de l’équipe, des équipes, puissent s’exprimer, apprendre, inventer, tester, construire. Pas seulement pour leur motivation, cela importe aussi pour leur éducation et donc leur valeur.  Il faut aussi qu’ils échangent, qu’ils confrontent, qu’ils partagent. Est-il vraiment indispensable de leur offrir de ce fait un ennemi commun, la direction de projet qui n’y connait rien ?

Peut-être cela a-t-il aussi à voir avec l’artisanat logiciel. L’artisant est un expert, mais aussi un designer et quelqu’un qui organise toute sa production pour concilier les pôles de son activité : produire de la valeur et de la qualité, tenir ses engagements de budget et délai, innover car le marché innove.

Croire que l’on peut appliquer pendant des années des pratiques vieilles de plus de trois ans et des socles techniques aussi agés me semble une douce illusion.

CMMI n’est pas incompatible avec l’innovation. Ce qui est incompatible c’est l’idée anti-agile que la nature des innovations ne peut venir que d’en haut. L’innovation vient des échanges et de la confrontation au terrain, ainsi que de la confrontation aux idées passées et présentes. Cela n’est pas possible si chacun bosse dans son coin. Cela n’est pas non plus possible si la direction n’alloue jamais de budget pour tester ou capitaliser un test reussi.

Publié dans Agile, Entreprise, Humain, Leadership | 2 commentaires

Agilité et 2.0

L’agilité et le web 2.0 ont certaines choses en commun.

Je pense en particulier au renversement des choses. C’est l’équipe qui prend la main sur certains aspects dévolus jusque là au chef de projet. Pour le web 2.0 c’est le visiteur du site (le client) qui alimente une partie du site (commentaires, …). Dans les 2 cas, il y a un courant issu de la base vers le haut.

Il y a par ailleurs une vision très pragmatique des choses, démocratique. On vote pour estimer une user story. On vote pour qualifier l’intérêt de tel ou tel produit.

Maintenant, les sites qui ont du 2.0 ne sont pas que cela. La publicité, le contenu éditorial ou marchand continuent d’exister, mais l’adéquation est plus grande.

De même, le projets agile ont un budget, des sponsors, des contraintes. C’est juste qu’ils se passent mieux, qu’ils atteignent mieux leurs objectifs.

Quand je parle d’agilité à des non informaticiens ils me regardent avec des yeux ronds : comment avez-vous pu imaginer procéder différement si longtemps ?

Publié dans Agile, Humain, Leadership | 4 commentaires

Le filtre du temps

Nous avons la sensation qu’il y a une évolution globale au sujet de l’informatique, grace à internet. Avenement de l’agilité. Craftsmanship, etc…

Pourtant il ne faut pas oublier que nous évoluons nous mêmes dans le temps. Par exemple j’ai débuté comme développeur, puis chef de projet, puis architecte, puis… A chaque époque (à chaque contexte ?) ses outils, ses préoccupations. Le même article me parlera différemment maintenant et par le passé. Comment même savoir ce qu’il m’aurait apporté dans le passé ?

Tout ce que je peux dire c’est ce que j’ai trouvé sur internet pour les développeurs à l’époque où je l’étais, puis pour les chef de projet à l’époque où je l’étais, …

J’ai la sensation d’une évolution, mais qui a évolué : le monde ou moi ?

Ca me fait penser à Héraclite (?) : Un même homme ne peut pas se baigner 2 fois dans le même fleuve. La deuxième fois ce n’est plus le même homme ni le même fleuve.

Publié dans Pensée | Laisser un commentaire

Matrix

Rassurez-vous je ne vais pas faire une n+1ème métaphore sur la base de la pillule bleue (ignorance) et de la pillule rouge (lucidité). Je voudrais évoquer un autre aspect de Matrix, le personnage de l’Oracle.

Elle fait partie du système, mais elle est là pour que les humains s’intègrent au système, pour qu’ils aient la sensation d’avoir leur mot à dire, d’être maîtres de leur destin, tout en revenant dans le giron du système à la fin.

Cet « empowerment » des humains me fait penser à l’agilité, et au rôle du chef de projet dans un contexte agile. Au final, il faut que les choses soient faîtes, que les contraintes soient respectées. Pourtant, les décisions doivent venir de l’équipe.

Cela vaut aussi pour le recrutement ou l’encadrement dans une SSII. Il faut que le collaborateur s’y retrouve, qu’il ait la sensation de progresser. Et pourtant il faut que les choses soient faîtes, que les contraintes soient respectées.

La beauté du personnage de l’Oracle est qu’elle croit sincèrement oeuvrer pour le bien commun, malgré ses contradictions. Et vous ?

Publié dans Agile, Entreprise, Humain, Leadership | 2 commentaires

Oath of Non-Allegeance

Après le manifeste agile, la déclaration d’interdépendance, l’artisanat logiciel : le serment de non allegeance

Publié dans Agile | Laisser un commentaire

Quand faire de la conception

Lors de son entretien bi-annuel, un jeune développeur me disait ne pas savoir quand il était sensé faire de la conception. Il ne voyait pas trop à quoi ca pouvait servir.

  • Moi : Comment tu fais pour coder ?
    • Lui : Quand je démarre une tâche de développement, je me lance sans conception et ça marche très bien.
  • Lui : pourtant j’ai lu « Coder proprement« .
    • Moi : Regarde la notion de design patterns, lis le gof (ou un autre bouquin plus récent sur la notion de patterns)
  • Moi: Comment font tes collègues ?
    • Lui : Ils font de la conception (diagrammes sur papier) avant de se lancer.
    • Moi : Il y a des gens qui raisonnent « visuellement », d’autres différemment. Peut-être est-ce ton cas ?
  • Moi : Regarde la conception émergente. (Etape par étape, sans anticiper)
    • Lui : Mais ce n’est pas de la conception si tu le fais pas avant
    • Moi : Tu le fais au fur et à mesure. Ca marche. J’ai réussi comme ça à implémenter des choses vraiment compliquées en très peu de temps.
Publié dans Agile | 1 commentaire

Communautés et paradigmes

Différents paradigmes (contradictoires) peuvent être présent pour un même contexte :

  • Méthodes agiles. Customiser le mode de fonctionnement pour chaque projet. Notion de cône d’incertitude pour expliquer que les estimations initiales sont très aléatoires. L’idée d’abaque de chiffrage est impensable
  • CMMI. Formaliser les pratiques, donc les uniformiser pour tous les projets, jusqu’à faire des statistiques (des charges, mais aussi des taux de defauts, …)
  • Software craftsmanship. Emphase mise sur les pratiques d’artisanat (parfois par opposition à l’ingéniérie).

On les oppose, mais dans un contexte réel, il faut plutôt chercher à la articuler, à les faire coexister.

En effet, les méthodes agiles me semblent parfois être le rêve fou de développeurs qui ont pris le pouvoir. Software craftsmanship de vieux développeurs expérimentés, pour les « techniques » par opposition aux gestionnaires, pour la créativité individuelle par rapport à l’uniformité et à la norme. CMMI de chefs de projet (et encore il y a PMBOK), PMO et ingénieurs qualité. Tous ces profils ont leur place dans un ecosysteme.

Chaque contexte se fait sa sauce. A quand un paradigme chapeau ? Voire un guide avec pour chaque aspect des alternatives avec chacune ses conditions d’application ? Et une cross-fertilization (enrichissement mutuel d’approches différentes) ?

Publié dans Agile, Entreprise, Humain, Pensée | Laisser un commentaire

Vieux con agile

Comme je l’ai dit tout récemment à un membre d’une équipe que je coache, au risque de passer pour un vieux con, « vous avez de la chance que l’agilité soit à la mode, j’aurais bien aimé qu’elle le soit quand j’étais développeur ». C’est vrai qu’il y aurait eu moins de choses à inventer et surtout moins de choses à essayer de vendre avec difficultés au management. Tant mieux pour les jeunes.

Publié dans Agile, Entreprise, Humain, Leadership | Laisser un commentaire

Livres évalués

J’ai fait un inventaire rapide des livres que j’ai pu lire depuis que je bosse, sur l’info, le management, la communication, la vision des choses.

Vous pouvez le trouver ici, cette liste sera mise à jour régulièrement.

Publié dans Agile | Laisser un commentaire

Gestion des priorités des actions

J’ai enfin retrouvé le modèle de priorisation des actions (apparement dit d’Eisenhower) en fonction de leur urgence et de leur importance.

J’apprécie toujours autant l’idée que l’on jette sciemment des actions à la poubelle sans même y prêter attention :-)

Publié dans Efficacité | 1 commentaire

« cross-fertilization » entre rédaction et développement informatique

Ai suivi une formation à la rédaction. Ca m’a donné quelques idées de « cross-fertilization » entre rédaction et développement informatique que je partage avec vous ici.

La « cross-fertilization » (terme issu du brainstorming) c’est l’apparition de nouvelles idées du fait de la mise en regard de deux thèmes que l’on ne met pas en regard d’habitude. De cette confrontation naissent des idées.

Faire des passes sur son code en le considérant uniquement sous l’angle de la lisibilité, comme un texte qui doit être lisible. Indentation, espacement. Intention. Titres, sous-titres.

Inversement, il serait productif d’appliquer à la rédaction des (longs) documents des principes tirés de la gestion de corpus de code assez volumineux : règles de nommage, homogénéité, mais aussi principes objets (ne pas multiplier les niveaux d’héritage, …)

Considérer les modèles de document/les plans types comme on considère des design patterns. Condition d’application, structure / guide d’utilisation, combinaison de plusieurs « documents patterns » pour un document final.

Faire des statistiques sur les mots « flous » dans un document pour déterminer son niveau d’aboutissement (je ne pense pas uniquement aux TBD)

Uniformiser la production du document final, travailler uniquement sur la créativité + le contenu + les méta-données, générer le produit fini automatiquement (uniformité, look léché, productivité)

Outils de CMS appliqués à la rédaction de documents ?

Publié dans Pensée | Laisser un commentaire

Le concret – Suite

Le principe agile qui consiste à livrer une version fonctionnelle (voire déployable en production) à la fin de chaque itération confronte l’équipe projet à tous les problèmes et lui interdit d’aller se perdre dans les méandres d’anticipations fumeuses et abstraites.

Je pense qu’on peut généraliser cette confrontation au réel au quotidien, à de nombreuses activités.

Par exemple, il y a une différence entre

  1. se dire ce que l’on va mettre dans une présentation
  2. être assis devant son portable et faire vraiment la présentation en 20 slides maximum avec si peu de place (ou trop de place)
  3. être debout devant tout le monde et dérouler sa présentation en 50 minutes maximum avec tant de choses à dire (ou si peu à dire)

Passer du théorique à la rédaction/conception/devt, puis passerà la confrontation des pairs (au test), puis aux clients. Et faire cela souvent.

Publié dans Efficacité | Laisser un commentaire

Planning

Paradoxalement, il ne faut pas trop se focaliser sur les dates quand on dresse un planning.

Identifier les tâches, les ressources, les contraintes d’affectation.

Estimer les tâches

Estimer les dépendances (strictes ou pas)

Une fois que c’est clair, la date se calcule toute seule.

Et ce n’est qu’alors que l’on doit la mettre en regard des contraintes de dates, et revoir l’ensemble si ca ne « rentre » pas, en priorisant à la baisse certaines tâches, en acceptant explicitement de prendre le risque d’en paralléliser d’autres, …

L’acte de  planifier en mode agile se fait en équipe, pour que chacun puisse contribuer : contrainte à laquelle on n’a pas pensé, tâche que l’on n’a pas explicitée, …

Ne pas se focaliser non plus sur la tête qu’il aura dans MS-Project, mais bien sur le découpage le plus adéquat, le plus proche du mode de fonctionnement réel.

Et puis, un de mes mentors m’a indiqué qu’il dressait son planning sous excel et n’utilisait MS-Project que pour le communiquer (en ressaisissant les éléments à un niveau de granularité faible).

Publié dans Agile, Efficacité, Humain, Leadership | Laisser un commentaire

Le temps qualitatif

Ca m’agace toujours quand j’entends un chef de projet dire à un développeur : pour la tache T23 on avait prévu 2j, tu es déjà à 3j il faut aller plus vite.

Pour moi, on ne peut pas dissocier le temps (3j) de ce à quoi il est consacré. Ca change tout de savoir que :

  • pour cette tache on a du faire un refactoring de toute l’application
  • pour cette tâche on a du changer de version de composant …

La vraie question c’est plutôt :

  • fallait-il ou non faire ces tâches annexes ?
  • quel niveau de qualité fallait-il se fixer ?
  • Ces choses ont-elles été décidées officiellement ?

Ensuite, il faut rappeler un point : le problème n’est pas que le chef de projet avait prévu 2j, on peut aussi bien passer 4j.

Le problème c’est que l’on a vendu 2j (de budget) ou une date.

Sur la base de quoi ?

Avait-on fait une analyse profonde des caractéristiques des tâches, des tâches sous-jacentes ?

Dans CMMI on capitalise un modèle de charge à passer (en moyenne), mais il n’est pas toujours assez finement paramétré par le niveau d’exigence du client ou les spécificités du projet.

Dans les méthodes agiles, il y a la « definition of done », mais elle est générale (pour qu’une tâche soit finie, il faut avoir mis à jour la javadoc, passé tous les tests, …) alors que les décisions à prendre sont « locales » : ai-je besoin du même niveau d’exigence ergonomique pour les écrans d’administration, …

Bref, il est surtout urgent se concerter, de faire valider par le décideur (chef de projet ou product owner).

Et s’il faut utiliser des statistiques, d’utiliser des statistiques portant sur le projet en cours (velocité), si tant est qu’il n’ait pas évolué dans la nature de ses tâches (architecture technique stabilisée, bugs suite à mise en production, …).

Publié dans Agile, Humain, Leadership | Laisser un commentaire

Agilité agile

J’en viens à me dire que pour faire de l’agilité sur un projet, il faut renoncer à appliquer une méthode agile précise. Même si le principe défendu par tous les agilistes est de commencer par appliquer les techniques « officielles » afin de monter en compétences dessus avant de vouloir les changer.

Ceci étant dit, il convient de s’adapter au mieux à la réalité du projet : personnalité de l’équipe, historique commun ou non, expérience des uns et des autres, …
En particulier renoncer à avoir une norme agile au niveau de l’entreprise.

Cela revient à opposer agilité et CMMI : définition d’une norme, respect de cette norme, optimisation basée sur des statistiques sur les autres projets, …
Sauf à identifier au niveau CMMI un certain nombre de pratique, leur domaine et conditions d’application, les dérogations possibles, les interdépendances (pas de campagnes de refactoring sans tests unitaires automatisés,…)

Si CMMI est la norme, s’il faut expérimenter et quantifier pour adopter, eh bien allons y. Expérimentons et quantifions.

Et soyons souples sur le terrain, en « oubliant » peut-être de préciser tous les détails d’implémentation lors des revues CMMI…

Peut-être que pour finir de se généraliser, l’agilité devrait renoncer à son nom. Pousser les pratiques en faisant appel au bon sens, unitairement, au lieu de faire un agile big bang. Le but n’est pas d’avoir 100% des projets estampillés agiles. Le but est d’améliorer 100% des projets pour qu’ils atteignent leurs objectifs métier. Ne pas renoncer non plus à l’évangélisation, mais essayer de ne pas faire trop peur.

Publié dans Agile, Entreprise | 1 commentaire