Philo SI

Supposons que votre patron vous demande de mettre en place une solution informatique pour octobre prochain (on est en décembre).
Vous vous renseignez auprès de quelques fournisseurs habituels et ils vous disent qu'il semble assez improbable de développer la solution avant décembre.
Vous en faites part à votre patron qui refuse un report de délai. Débrouillez-vous pour que ce soit octobre.!

A partir de là, la procédure est connue au bon chef de projet que vous êtes. Vous consultez en gardant la date initiale (octobre), les fournisseurs vont bien faire avec. Les honnêtes qui ont leur carnet de commande bien rempli déclinent, ceux qui sont moins honnête, ou moins expérimenté, ou qui ont absolument besoin d'une commande vont rivaliser d'astuce pour se convaincre et vous convaincre qu'ils peuvent le faire.

Vous passez commande à l'un d'entre eux.

Votre problème maintenant va être de gérer la colère de votre patron s'il n'a pas sa livraison en octobre. Attention, dans ce cas la faute ne doit pas être la votre mais bien celle du fournisseur ou du métier, ou un mixte ... il faut donc bien gérer ces relations (ainsi que celle avec le patron, plus délicat,le mouiller un peu mais pas trop, il doit s'en sortir au final).

Vous allez donc gérer le projet:
     - Envoyer des mails chaque fois qu'un jalon n'est pas respecté, faire des comité de pilotage qui montrent des plannings rassurants sur lesquels les autres s'engagent…etc (ce n'est pas toujours facile, il sont expérimentés aussi et voient bien la corde…un bien beau combat).
     - Avec de la chance le métier peut venir avec une demande non prévue. C'est toujours une bonne occasion d'être contraint malgré soi de reculer la livraison.
     -Une chose à ne jamais oublier est d'insister auprès du fournisseur sur le fait que l'on veut absolument de la qualité, le PAQ (plan d'assurance qualité) est un bon outil, faites bien valider la partie qualité logicielle. Mais attention, il ne faut pas s'impliquer au-delà, ce serait se compromettre. Le but est surtout que le fournisseur livre en octobre (en s'arrangeant bien comme il veut).
A ce moment là, votre patron ne pourra rien nous reprocher.

Le temps nécessaire à corriger les bugs du logiciel est de toute façon totalement imputable au fournisseur (qu'est-ce qu'on aurait bien pu y faire ?).
Bien sûr, celui-ci va chercher à requalifier quelques bugs en demandes d'évolutions non prévues au départ, mais si on à bien gardé trace des mails, des compte-rendus, etc. on doit s'en sortir à moindre frais.

C'est à ça qu'on voit le bon chef de projet, il sait satisfaire son patron.
Il peut s'engager sur l'impossible, faire en sorte de trouver quelqu'un qui veuille bien le fournir, justifier qu'il a atteint l'objectif.
Avec talent, il n'aura jamais montré que chaque évènement qui permet de le dégager d'une responsabilité est une bonne nouvelle. Au contraire ! il aura paru préoccupé par les obstacles.

Par la faute des autres (qui n'ont pas respecté leurs engagements pourtant on leur avait bien dit) le résultat n'est pas utilisable en l'état, mais la charge financière est largement reportée sur le coupable (et tout est bien dans le meilleur des mondes possibles).

Le patron à son tour dispose de tous les arguments pour justifier auprès de sa direction que le projet est un succès(quelques couacs à cause de <liste de coupables> mais financièrement ont s'en sort bien). Il est reconnaissant au chef de projet et après quelques succès de ce type lui offre une promotion.

Et c'est là le problème ! Les bon chefs de projet ne restent pas longtemps en place (puisqu'ils ont promus) et sont souvent remplacés par des inexpérimentés qui causent beaucoup de souci à leur patrons.

Du coup celui-ci est stressé et tout le monde en pâti...

Maintenant c'est pire, ils veulent nous mettre des Screeeuum Maaaster qui comprennent rien ... mais alors rien au projet !

Read more...

Je l'avoue, je suis un peu démuni face à toutes les théories qui cherchent à donner des modèles chiffrés à l'agilité et à Scrum en particulier.
Je regarde avec intérêt toutes les expériences. Je note avec intérêt le fait qu'un ratio ait pu être tiré d'un certain nombre de sprints sur ce projet ci ou que l'on ait constaté la véracité d'une théorie sur le coût de correction des bugs sur ce projet là.
Mais je suis mitigé sur les généralisations qui s'en suivent souvent implicitement.

C'est une tendance naturelle de l'humain de vouloir rationaliser et trouver des lois générales à partir d'expériences (ce que l'on appelle en philosophie l'induction). Je me demande s'il n'est pas imprudent de généraliser si rapidement à partir d'éléments factuels (les projets, les équipes, le degré de pratique) si différents, d'ailleurs sans les considérer tous ensembles.
Et tant qu'a chercher des modèles, je crois qu'il faudrait intégrer dans notre réflexion ceux de notre temps et ré-interroger les vérités dogmatiques pré-agile.

Il y a un terme utilisé en écologie qui est absent de l'entreprise et qu'il faudrait je pense intégrer dans notre réflexion : "écosystème"

La notion d'écosystème concerne une communauté d'êtres vivants ainsi que les conditions de son environnement. Il est caractérisé par ses interactions dans ses aspects biotiques et abiotiques (Source wikipedia).
La composante biotique se rapporte à l'intéraction du vivant sur le vivant (compétition, prédation, symbiose...), la composante abiotique se rapporte à l'action du non-vivant sur le vivant (sol, climat,...).

Les modèles écologiques ne se traduisent pas simplement. Enfin pas toujours. Je veux dire par là qu'ils peuvent être temporairement simples et prédictifs et puis basculer dans quelque chose d'imprévisible. Ce n'est pas que l'équation soit complexe, au contraire elle peut-être trés simple. Mais elle est fortement liée aux conditions initiales de l'expérience. Ce type de modèles est appelé chaotique.

Un bon exemple est donné par la fonction logistique de Robert May . Le diagramme de bifurcation ci-dessous montre les variations possibles dans la production du vivant en fonction de son environnement(aspects biotiques et abiotiques confondus). La population est exprimée en % de la capacité maximale du territoire considéré.
On peut lire en ordonnée (nommée "x") le % de population animale de l'année prochaine (calculée à partir d'une population actuelle de 25%) en tenant compte du facteur correctif ("r") qui matérialise les conditions particulières propre à l'environnement.

Lorsque le coefficient traduisant le facteur environnemental est inférieur à 3,5 les choses sont assez simples et prévisibles. Par la suite ça se gâte sérieusement et au dela de 3,57 toute infime modification, que ce soit du coefficient "r" ou bien de la population initiale, affiche un résultat qu'on ne pouvait prévoir.

Si l'on veut apporter un regard neuf sur notre travail, il peut-être intéressant d'aborder la réflexion sous cet aspect. D'un point de vue du projet informatique, la partie environnementale (non vivante) se rapporterait aux éléments tangibles (locaux de l'entreprise mais aussi équipement du projet - serveur d'intégration par exemple). La partie biotique serait composée des relations entre membres de l'équipe, hiérarchie, client ..etc

L'écosystème du projet est sensible à ces 2 composantes.

Un bon environnement de travail, un équipement de haut niveau, est facteur de facilité de travail mais aussi de motivation. Cette partie est assez simple à identifier en général, les actions d'amélioration sont souvent facilement quantifiables, cette partie est plutôt rationnelle.

Le fait qu'une équipe s'entende bien ou pas, qu'un "prédateur" se manifeste, qu'un "leader" soit en vacances, que la confiance soit là ou qu'elle n'y soit plus,... sont des éléments irrationnels. Il n'y a pas de loi simple qui puisse de l'une de ces causes quantifier un effet.
On saurait sans doute dire dans quel sens l'un de ces éléments fait avancer le curseur "r" mais on ne sait pas dire de combien (et quid s'il y a plus de 2 élèments?). Difficile d'identifier l'impact. Pire, on pourrait croire que l'impact est faible alors qu'il vient de pousser le curseur en zone rouge...vers les 3,56 disons.

Je ne sais pas qu'elle est la fonction qui permettra de modéliser la production agile. Mais il me semble clair qu'elle sera plus proche de celle de May que de la droite euclidienne ou de la courbe en cloche de notre ami Gauss.

C'est pourquoi le rôle du Scrum Master n'est pas de mettre en pratique des lois tirées sur les nombres mais d'observer et d'être attentif en permanence aux conditions de l'écosystème. Il remet toujours en question son jugement, il n'intervient pas en dogmatique mais dose ses interventions en fonction de l'état (biotique / abiotique) de l'environnement.

C'est une fonction davantage sensible que rationnelle.

Read more...