Jagodzinski JF

Posts tagged with "Méthode"

Pratique et méthode

Sunday, 14. December 2008, 11:06:31

Philosophie, Modelisation, Agile, Méthode

On parle ici et là de méthodes Agile. Avec un grand A. Je crois bien l'avoir orthographié de cette manière dans pas mal de billets.
Pourtant je passe mon temps à éviter ce terme et à lui préférer celui de "pratique" quand je parle de l'agilité. Le terme de "méthode" entraine aussitôt dans nos esprit cartésiens les réflexes de rationalisation: petit 1, petit 2... qu'elle est votre méthode ?

On a eu en France précédemment la méthode Merise : d'abord nous parlons de conception - à ce niveau on élude toute question qui à trait au "comment", on parle du "quoi". Comme il y a deux composantes, les "données" et les "traitements", on va donc scinder en deux notre réflexion...ça c'est une méthode.

Nous est venue par la suite d'outre atlantique UML. UML n'est pas une méthode mais un outil de modélisation. J'ai entendu parlé de "méthode UML" (ou peut-être ai je inféré le terme "méthode" quand on m'a parlé d'UML ?) longtemps avant d'avoir à l'utiliser. Je m'y étais intéressé plusieurs fois mais ne trouvant pas le bout du fil pour dérouler la pelote, j'ai remisé à plus tard ma compréhension d'UML.

Jusqu'au jour ou il a fallu mettre UML en pratique. Ca m'a donné un peu de mal, cherchant une "méthode", à comprendre, un niveau auquel rattacher une information. Et puis j'ai compris qu'il n'y avait pas de niveau, pas de rapport entre le type d'information et le diagramme dans lequel on doit la mettre, pas de lien nécessaire entre les types de diagramme...bref pas de méthode.

Comme le dit Bernard Morand (que je cite de mémoire) "comme il faisaient bien du Merise, ils ont bien fait de l'UML". Maîtriser un démarche méthodologique aide grandement à utiliser un modèle pour la représenter.

Quand on parle d'agilité, on y associe des démarches dans lesquelles ont codifie surtout des attitudes en posant des principes (privilégions les interactions entre les individus, privilégions l'acceptation du changement, ...).

Ces principes sont davantage proche de maximes qui fondent une sorte de "morale" que de préceptes décomposant des étapes qui aboutiraient à faire une méthode. En mode agile, on prend en compte nos perceptions davantage que notre raison, même si celle-ci est éminemment mise à contribution. On trouve des décompositions, des hiérarchisations, des étapes ... qui peuvent conduire à croire à de nouveaux processus que l'on doit suivre de façon dogmatique.

Il faut sortir des anciens schémas, rester sur le terrain de la méthode c'est passer à coté du principe.
Il y a une prise en compte davantage d'information quand on est plus prêt du but que lorsqu'on dessine un plan. Les arbres et le maisons sont présents partout ou je voyage. Mais plus je me rapproche de chez moi, plus les arbres et les maisons ont du sens, ils portent en eux le parfum du foyer.

La turbulence

Tuesday, 7. October 2008, 06:43:09

Philosophie, Agile, Méthode

Dans la présentation de l'intervention de Jérôme Barrand à l'Agile tour de Grenoble ont peut lire:

Il est communément admis aujourd’hui que la turbulence est et sera le contexte de travail de l’entreprise

Oui, j'aime bien cette image.

La turbulence est un système dynamique qui échappe encore à l’entendement des hommes ce qui naturellement les conduits à ne pas regarder les changements en jeu. James Gleick à écrit un bon livre sur la théorie du chaos qui permet de mieux entrevoir de quoi il pourrait bien s'agir.

Si l’on regarde l’eau au sortir d’une pile de pont on peut voir l’évolution d’un système d’informations. En deçà d’un certain débit l’écoulement est lisse. Si le débit augmente un peu, un tourbillon se forme, le tourbillon s’écoule pendant qu’un autre apparaît à sa place puis s’écoule à son tour. Une information commence à être générée.

Gauche, gauche, gauche… tous ces tourbillons tournent dans le même sens. Ce système d’information atteint vite ses limites et ne peut plus rien nous apprendre de neuf. Une augmentation de débit encore, un nouveau mouvement apparait, le sens s'inverse, gauche, droite, gauche, droite... Le système s'enrichit mais reste prédictible.
Une fraction de débit en plus et l’on bascule dans un système chaotique. Les tourbillons se succèdent alors tournant à gauche ou à droite sans ordre précis. Gauche, gauche, droite, gauche, droite, … Le système génère de l’information en flux continu. Un flux dont on ne sait prédire la suite.

Les mathématiques atteignent leurs limites quand il s’agit de modéliser la turbulence. On a longtemps pensé qu’il s’agissait de mouvements sans ordre, sans loi, non modélisables.
La théorie du chaos nous montre que de nouvelles lois de la nature existent. Ce qui nous apparaît sans ordre n’est qu’un ordre que nous ne comprenons pas. Des instruments comme les fractales et les attracteurs étranges donnent des bases sinon de compréhension du moins de mise en évidence.

Le débit des informations dont dépend l'entreprise est passé à une vitesse supérieure. Nous n’avons plus le temps avec les schémas classiques de modéliser un système d’information puis de le produire avant que les éléments à l’origine du système n’aient déjà changés.

Les anciens modèles ont atteint leurs limites. L'Agilité est un début de réponse, un nouveau modèle qui n'est plus basé sur la prédiction mais sur l'intégration continue des informations observées qui ne devient possible qu'a partir d'intelligences distribuées.

Un modèle pour répondre à la turbulence.

No comments

Agile et Philosophie

Sunday, 16. March 2008, 09:32:30

Philosophie, Agile, Méthode

Je viens de suivre la formation SCRUM de Valtech Training. Je suis trés content.

Les principes de l'agilité m'ont toujours semblé évidents et je les ai, dans une certaine mesure, toujours mis en application.
Bien sûr, nourri de Merise et de méthode cascade, puis d'UML et de RUP, il est difficile, de soi même, de faire émerger dans ses pratiques l'ensemble des principes agiles.
Mon intérêt pour le FLOSS (Free Libre Open source Software, pour rester impartial) m'a amené à la lecture d'articles ( la cathédrale et le bazar entre autres) qui m'ont procuré la joie du petit caneton noir noyé parmi les jaunes qui découvre l'existence de ses semblables. L'open source m'a surtout interpellé sur la capacité de ces équipes à travailler ensemble. D'autres lectures par la suite et notamment celle des blogs (en point d'entrée celui de Claude Aubry que j'ai mis dans mes liens) m'ont aidé à cibler davantage parmi les pratiques Agiles et à déterminer la cible qui m'est la plus proche: SCRUM.

L'un des fondamentaux philosophique de la gestion Agile d'un projet avec SCRUM c'est l'empirisme.
Les doctrines empiristes sont apparues en Angleterre au XVIIe, initialisé par John Locke . En France c'est le rationalisme de Descartes qui est en vogue à cette période. L'approche cartésienne suppose à l'esprit de l'homme la capacité d'atteindre de façon innée et avec rigueur une connaissance de la réalité extérieure à partir de la seule raison. Sans être tout à fait sceptique (comme le sera Hume un peu plus tard) Locke est sur la ligne empirique: il n'existe pas de connaissance qui ne soit d'abord originaire de nos sens.
Je trouve intéressant d'examiner ce débat de la période des Lumières en s'interrogeant sur les conséquences (existent elles ?) dans nos esprits d'aujourd'hui.
On parle de "concept", d'"intuition", de choses qui "dépassent l'entendement" ou d'"empirisme" sans réelle conscience que ces termes ont été longuement discutés par les philosophes et que leur sens n'est finalement pas aussi évident, mais sans doute beaucoup plus profond, qu'il nous semble.
Qu'elle est l'influence des courants philosophique dans nos certitudes et nos pratiques. Existe -t-il une approche cascade cartésienne plutôt continentale opposée à une approche agile empirique d'inspiration anglo saxonne ?
Je n'en suis qu'aux interrogations et je ne vais pas me baser sur quelques observation pour aboutir à une quelconque conclusion. J'intégre pour l'instant ce sujet à mes réflexions et j'observe que ce débat autour des méthodes informatiques puise davantage qu'il n'en a conscience sans doute dans les racines philosophiques.

Pour en revenir à ma formation Valtech, elle vient ponctuer un déja long parcours inspiré d'agilité pour officialiser une volonté d' avenir agile.
Tout le chemin reste à faire. Les éléments de mon expérience me permettent de concevoir sans trop de difficulté un rôle de Scrum Master dans un développement logiciel de 2000j. Mais les éléments venant de la formation ne me permettent pas encore de concevoir une réponse aux autres projets informatiques. Je vois dans ce qui m'entoure beaucoup de projets soit petits (200 j/h), soit d'intervention partielle (maintenance applicative), soit d'intégration de produit déjà développé (progiciel de Gestion relation client par exemple). Quid de SCRUM sur ce type de projet ?
Il va me falloir compléter mes informations, et puis imaginer encore...

Penser n'est pas connaître

Wednesday, 5. March 2008, 02:57:05

Cascade, Méthode, Agile, Philosophie

En informatique on pense beaucoup. Un programme informatique n'est finalement qu'une vue de l'esprit. Traditionnellement, on commence par penser le travail à faire, à écrire ce que l'on pense, parfois à le modéliser, ce qui constitue un "contrat" de réalisation. La chose est ensuite développée, testée, etc.
C'est la façon historique de faire, connue sous le nom de "méthode cascade" parce que les étapes s'enchaînent, la fin de l'une donnant le signal de début de la suivante.

Quand je dis "façon historique" je veux dire que cette méthode de travail a été mise au point à un moment de l'histoire informatique et qu'elle a intégré les contraintes de cette époque. Les fondamentaux en étaient un environnement centralisé d'une part, un développement contraint d'autre part par des opérations longues de compilation et d'intégration. S'en suivaient des opérations de déploiement importantes et l'incapacité de montrer les résultats de la programmation aux utilisateurs avant plusieurs mois.

Les environnements ont changés, la programmation aussi. En environnement Web et en utilisant des technologies de scripting un développeur est pratiquement capable de montrer en temps réel la progression de son travail à un utilisateur situé dans un autre pays.
Les méthodes Agiles sont naturellement nées de ces nouveaux fondamentaux. Elle n'ont pourtant pas encore émergées et la grande majorité des projets nouvelles technologies sont encore pilotés à partir de méthodes cascades.

La méthode cascade repose sur une approche conceptuelle. On peut alors comme Kant se poser la question de savoir

jusqu'à quel point je puis espérer arriver à quelquechose avec la raison si me sont enlevés toute matière et tout concours venant de l'expérience

Les objets ne nous sont compréhensible qu'au travers d'une architecture complexe de ressentis, de concepts et de jugements. L'objet nous est donné dans l'intuition à travers nos sens sous ses multiples représentations. Ces représentations sont synthétisées et l'objet peut-être pensé dans l'entendement en relation avec nos concepts.
Au travers de l'expérience je passe en revue mes concepts si on peut dire pour y raccorder l'objet, et c'est mon jugement qui me permet de mettre en phase les uns avec l'autre.
Ceci posé, il est nécessaire de déterminer les limites de chaque élément. L'un des outils de maniement des concepts est la logique, et Kant établit ici la distinction entre ce qui constitue la partie analytique de cette logique et la partie qui en est dialectique. Cette notion est intéressante en ce qu'elle détermine les limites de l'emploi de nos concepts.

c'est une chose très séduisante et très engageante que de se servir de ses seules connaissances pure de l'entendement et de ces principes purs - et même en dépassant les bornes de l'expérience qui seule cependant peut nous fournir la matière à partir de laquelle ces concepts purs de l'entendement peuvent être appliqués (...) donc puisque la logique ne saurait être qu'un canon pour apprécier l'usage empirique, on en abuse quand on lui donne la valeur d'un organon (...) et quand on se hasarde avec le seul entendement pur, à juger, à affirmer, et à décider synthétiquement sur des objets en général.

Les Méthodes Agiles et SCRUM en particulier ont saisi l'opportunité de la disparition des contraintes informatiques pour se rapprocher de la connaissance de l'objet du développement qui est donnée par l'expérience. On élabore moins en pensée, on fait davantage intervenir les sens. Les divergences de jugement sont captées plus tôt dans le projet, partant, l'adéquation de l'objet aux concepts est mieux comprise et partagée.
Cela ne peut qu'être au bénéfice de l'utilisateur.