Pratique et méthode
Sunday, 14. December 2008, 11:06:31
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.
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.
WIDGETIZE