Philo SI

Jean-François Jagodzinski - Le Blog

Subscribe to RSS feed

Posts tagged with "Méthode"

L'agile n'est pas encore mort

Friday, October 7, 2011 10:13:51 AM

, ,

Je viens de poster un commentaire à l'article de Sébastien Douche intitulé "l'Agile est mort" sur son blog.

Je vous poste le contenu de mon commentaire ici.


Oui. Je partage cette amertume.
L'idée Agile est belle et voir comment elle est travestie et revendue heurte notre idéal et remet en cause les perspectives de l'aboutissement que pourrait être un monde Agile.

Je parle au présent mais pas encore au passé parce que je suis d'accord avec toi "Il faut avoir une vision systémique du mouvement (Agile)".

Ce système est différent de l'autre. Ces 2 systèmes sont en concurrence pour la survie, c'est trés darwinien. Ces systèmes sont habités par des êtres humains. Certains ont tout à gagner ou tout à perdre dans l'un des systèmes (ils sont inadaptés à l'autre).
L'une des façons de faire disparaître le système concurrent c'est de le nier en tant que système différent et de l'assimiler. C'est la différence entre révolution et évolution. C'est ce qu'essaie de faire le monde traditionnel. Dans le même temps, c'est facile pour lui, il fait ça depuis toujours. Il y a eu 25 (ou 50 ?) méthodes en informatiques (Merise, SADT, SA/SD, RUP, TTUP parmi celles que j'ai pratiquées ) + des modèles comme ceux d'UML.
La première chose que fait une organisation quand elle adopte une méthode, c'est de supprimer ce qui ne lui convient pas. J'ai TOUJOURS vu ça. Et c'était normal dans l'esprit de l'organisation (la théorie et la pratique sont 2 choses différentes). Par conséquent sa façon d'aborder l'Agilité est tout à fait cohérente. Il n'y a pas de conscience particulière, c'est un mode de fonctionnement automatique de l'ancien système. Il grandit en mangeant les méthodes qui apparaissent (manger c'est désorganiser un organisme pour en récupérer uniquement la substance qui contribue à notre vie).

En ce sens véhiculer le concept en tant que "méthodes" Agiles et dévastateur.

Mais si on discute de ça aujourd'hui à grande échelle, c'est parce qu'il y a eu 2001 et le manifeste Agile. Je suis certain que des tas de systèmes d'organisation nouveaux sont apparus ici ou là et sont morts faute d'avoir été amenés en contact avec une masse suffisante d'adeptes.
Pour faire exister un concept il faut lui donner un nom. A partir du moment ou l'on pouvait associer un nom à "ça" (ce que l'on faisait sans le dire parce que c'était mal, ou bien entre nous, ou quand j'étais étudiant... ) en lui donnant une consistance plus globale mais simple (4+12 principes) il était plus facile de passer l'information. Autre message (subliminal) : vous avez le droit de faire ce que vous faites, et même on vous y encourage.
Le fait que les signataires soient devenus consultant... oui ben ils ont vieilli aussi. Ce qui est important c'est que le message d'origine n'est pas "nous avons réfléchi à une nouvelle méthode" (en tant que consultants) mais "nous découvrons une nouvelle façon de faire du logiciel en le développant et en aidant les autres à le faire" (en tant que développeurs donc).

Perso je ne jeterais pas le bébé avec l'eau du bain. On peut discuter des principes du manifeste, comme on peut le faire avec la charte des droits de l'homme (si, si, il y a des trucs dont je discuterais bien). Ils existent parce que leur contenu à été suffisamment inspirant pour amener des hommes à créer un nouveau système viable. Ils continuent d'exister tant qu'ils restent la base d'un système.

Scrum Alliance, certifications... oui ça me gêne aussi Est-ce que ça a participé à l'amplification du mouvement ? Est-ce que ça lui a été nuisible ? Est-ce que ça à été bon mais que ça ne l'est plus ? Est-ce que Schwaber va sauver le mouvement avec Scrum.org ? Est-ce que le PMI va participer à la digestion de l'agilité par l'ancien système ? ... à suivre, en tout cas ça ressemble plutôt à un système vivant (bactéries, globules blanc, virus... est-ce que notre système biologique est un havre de paix ?).

Les principes Agiles ne sont pas morts en tout cas. Un message très proche (sans l'étiquette "agile") est relayé en dehors du monde de l'informatique par des gens comme Stephen Denning (Radical management) ou les fondateurs de 37signals (Rework).

La question est : est-ce que ce message est en phase avec le monde à venir?

Et ça je ne sais pas, c'est une question de valeurs
- Si le monde actuel est principalement caractérisé par des jeunes qui se rencontrent via twitter pour mettre fin à une dictature, c'est possible
- Si le monde est principalement caractérisé par des jeunes qui cherchent l'adrénaline dans les frissons du CAC40, c'est compromis

En tout cas, moi j'opte pour la première représentation. Je me bat pour le nouveau système (mais j'ai pas de mérite c'est une question de survie je suis inadapté dans l'ancien).

Merci en tout cas pour m'avoir donné l'occasion de formuler ces idées qui traînaient dans un coin de ma noosphere

JF

Read more...

No comments

Communication et modèle

Wednesday, February 2, 2011 11:20:27 AM

, , , ...

On ne sait pas transmettre nos idées par duplication de cerveau à cerveau. C'est bien embêtant.

On a donc du avoir recours à différentes techniques qui nous permettent de communiquer les idées. On sait bien que nous communiquons par divers moyens, voix, gestes, expression, écrits… On connaît moins qu'il existe des niveaux d'échange différents selon les différentes idées que l'on cherche à communiquer.
En fait on peut reconnaître 4 niveaux de communication qui correspondent à 4 niveaux d'idées.

  • Au premier niveau le message permet de faire passer les informations sur soi "au secours!".
  • Au second niveau le message apporte une information simple à la communauté "Attention!".

    Ces 2 niveaux sont partagés par les animaux et sans doute également par les plantes si on en croit les études les plus récentes.
    Les circuits qui permettent de gérer cette information sont donc basiques, primaires, "hardcodé" dirait-on dans notre monde informatique. Ils sont très rapides et peu sujet à l'erreur.
  • Au troisième niveau notre message porte sur la description. C'est un messages complexe adressé à la communauté "la nourriture est abondante dans le champs de l'autre côté de la rivière". C'est un niveau essentiellement humain mais on peut penser que certains animaux le partagent (je pense à l'abeille).
  • Au quatrième niveau notre message porte sur l'argumentation. Niveau exclusivement humain qui met en œuvre notre matière cérébrale particulière, le neocortex, ça fonctionne moins vite mais ça a son efficacité.

On est assez fiers de notre capacité d'abstraction. Les animaux savent bâtir un modèle mental de leur environnement, très peu savent le transmettre à leurs congénères, mais aucun ne sait argumenter avec ces derniers sur l'opportunité d'aller chercher sa nourriture plutôt ici que là.

Nous si. On excelle dans ces 2 disciplines que sont la description et l'argumentation.
Enfin, on excelle… on sait communiquer des messages à ces niveaux.

Mais comme on ne sait pas répliquer nos pensées dans le cerveau de notre interlocuteur on utilise différents modèles. Pour que ces modèles soient efficaces, il faut une parfaite adéquation de toutes les parties quand au code utilisé. Si j'articule un son, par exemple "chaise", il faut que ce son évoque dans l'esprit de mon interlocuteur la même idée que j'ai présentement à l'esprit.

Avec mon fils qui vit dans la même maison que moi, il y a des chance que nos idées soient assez semblables. Avec d'autres ça dépend. On a de bonnes chances d'avoir nos idées en phase sur le nombre de pieds je pense, bois ou métal là nos idées pourraient ne pas se ressembler.

Modéliser lorsqu'il 's'agit d'éléments de notre environnement correspond toujours à généraliser. Et généraliser c'est perdre de l'information. Toujours.

Il existe une option.

Je peux t'apporter ma chaise. J'activerai alors la communication sur le niveau 2 "regarde!" et au niveau 3 je dirais juste un mot "chaise".
Quand on en parlera de chaise, je sais que l'idée que tu formeras est assez proche de celle que je forme moi-même.

Mais tu ne pourras quand même pas t'assurer qu'en en parlant à quelqu'un d'autre le message passe aussi clairement.

Read more...

No comments

Le manager est il au dessus du cadre Agile ?

Sunday, September 26, 2010 12:54:17 PM

, , ,

Une équipe que je coache s'est laissé imposé par le management métier le remplacement d'une story en cours de sprint. Le PO était en vacances, le manager de la partie métier a directement fait sa demande au management du SI qui a redescendu la demande à l'équipe.

Les équipiers sont mal à l'aise, mais disent ils, c'est difficile d'aller à l'encontre d'un ordre qui vient du management.

La question fondamentale n'est pas tant de savoir s'il fallait le faire. C'est plutôt pour l'équipe de juger de la force qu'elle a mise, de l'ensemble des mesures et des alternatives qu'elle a proposées pour défendre le cadre Scrum.

Je discutais de ce point avec le responsable des projets Agiles de l'entreprise. Son opinion est qu'il ne faut pas être trop rigoureux, tout au moins pas rigoriste.
L'Agilité c'est aussi l'adaptation. Il peut arriver qu'un PO demande un changement et s'il a de très bonnes raisons ont peut considérer sa demande.
Du point de vue de ce responsable on a trop souffert dans nos systèmes passés (projets à cycle en V) de l'excés de rigueur.

Je déteste la rigidité, la rigueur, les cadres imposés...je suis par nature un homme de service et de compromis.
Mais je ne suis pas de son avis

Scrum est fait de 2 choses :
  • Un espace de liberté au profit de la création et de l'adaptation au service desquels le chaos est sollicité.
  • Un cadre strict et une discipline forte qui permettent d'empêcher la propagation du chaos au projet lui-même .



C'est le principe du moteur à explosion . L'énergie est générée dans une chambre de combustion qui permet de la contenir.
La récupération de l'énergie est maîtrisée : celle-ci est dirigée pour générer une puissance utile.
Retirez la chambre de combustion et provoquez l'explosion, comme dirait notre ancien président ça fait pschiiiiit.

Nos problème passés venaient il vraiment de la rigidité du process ?
Parmi les raisons qui font que l'on prône la rigueur en gestion traditionnelle de projets on peut ressortir la longueur du cycle de production et la dépendance hiérarchique des tâches. Une gestion rigoureuse était mise en place pour tenter de garder la maîtrise des budgets et des délais.

La contrepartie en est que l'obtention d'un produit à la fois minimal et parfaitement adapté à l'utilisateur tenait du challenge.

Pour tenter de corriger les erreurs d'appréciation initiales, il existe un processus de gestion des exceptions. C'est ce que l'on appelle l'"escalade" auprès du manager.

Les managers ont le pouvoir de briser les règles pour arranger des écarts fonctionnels ou des reports de délai.
En réalité ce processus est un dysfonctionnement qui répond à un dysfonctionnement (mais qui a aussi bien d'autres logiques d'existence)

La philosophie Scrum est de proposer des cycles courts dans lesquels des fonctions finalisées sont livrées.
Le risque de ne pas produire une fonctionnalité prioritaire dans un délai compatible avec un besoin métier réel est sinon nul du moins très limité. Et dans le cas ou il est avéré, ce risque peut sans doute se gérer sans briser le cadre Scrum (par une solution dégradée temporaire).

Le recours à l'escalade doit être vue comme une facilité du projet traditionnel , dans lequel le manager a le pouvoir de déroger au processus.

En passant en organisation Agile le manager a délégué son pouvoir.

S'il veut favoriser la progression vers l'agilité alors il doit aussi se soumettre à la discipline que demande le cadre Scrum.

Comme disait un manager aux débuts de ma carrière : passées les bornes, il n'y a plus de limites.



Crédits : perso: Auguste - Musée du Vatican
http://lemondedekoulou.over-blog.com/40-categorie-705456.html
http://commons.wikimedia.org/wiki/File:Moteur_plan.PNG
http://commons.wikimedia.org/wiki/File:Tableau_SYMPHONIA.jpg

Read more...

No comments

Pratique et méthode

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

, , ,

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.

Read more...

No comments

La turbulence

Tuesday, October 7, 2008 6:43:09 AM

, ,

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, March 16, 2008 9:32:30 AM

, ,


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

Read more...

No comments

Penser n'est pas connaître

Wednesday, March 5, 2008 2:57:05 AM

, , ,

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.

Read more...

No comments