Philo SI

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

Dans le cas d'un projet de prestation en ingénierie informatique dont l'objectif est de produire un logiciel (un outil à destination d'utilisateurs), le prix de la prestation peut-être ramené au coût du temps passé.
Le nombre de personnes que multiplie le nombre de jours nécessaires donne le prix du projet, les autres frais (déplacement, achat logiciel spécifique,...) sont en proportion la plupart du temps négligeables.

Pour le Chef de Projet de la SSII qui va réaliser cette prestation, le budget de réalisation va ainsi être un budget en "jours". Piloter le projet revient à estimer, compter, agencer du temps.

Le temps est un concept des plus trompeurs. On le ramène naturellement à des chiffres puisqu'on sait le mesurer, et à partir de chiffres on maîtrise tout.
Tout ce passe comme s'il existait du temps dans la nature, de la même façon qu'il y a des arbres, des virus ou des phénomènes électromagnétiques. Une fois identifié, analysé et confronté à notre collection d'êtres mathématiques on modélise. Maîtriser le modèle c'est pouvoir transmettre et partager la "connaissance" de la chose.

Et pourtant, entre une période de stress et une période d'ennui on a bien du mal à accorder le modèle à la chose. Un plus un ne font pas deux dans notre perception.
Si par ailleurs j'essaie de me souvenir des évènements passés, je me rend compte que je suis bien incapable de les situer de façon objective. J'associe simplement des pensées qui me permettent de trouver un point d'accroche sur mon référentiel (c'était avant la visite du client que je me rappelle être le 6 novembre, mais après la fourniture de la spécification, et je me souviens que c'était un mardi parce j'ai mangé des raviolis ce jour là).

J'entendais l'autre jour Albert Jacquart qui citait Saint Augustin pour qui

s'il ne se passait rien, le temps n'existerait pas

et lui opposait la vision d'Einstein pour qui

le temps c'est ce qui passe quand rien ne se passe.

La vision exprimée par Kant de façon plus rationnelle analyse le temps comme un "concept transcendantal de l'intuition". C'est ce que l'on appellerait en informatique un "méta concept", c'est un concept qui permet de construire d'autres concepts.
L'intuition est l'endroit de notre conscience qui assemble les éléments de la perception, ceux qui nous sont donnés par nos sens. Puisque nous percevons notre environnement de façon multiple (on a 5 sens) et progressive (on ne voit pas tout à la fois) il est bien nécessaire de pouvoir assembler ces informations pour en déduire des objets. Deux concepts permettent de le faire, le Temps et l'Espace.

L'une des différences de la pratique Agile par rapport à la pratique classique prédictive réside dans la relation au temps.

Il ne s'agit plus de faire comme si l'on pouvait contrôler les évènements par rapport à un temps vu comme un élément externe et objectif. La pratique Agile intègre le fait que, pendant que le temps passe, c'est par une intensification de la perception et par une extension de celle-ci dans le périmètre des compétences que vient la maîtrise du projet.

Read more...