Comme dit George Box : Tous les modèles sont faux mais certains sont utiles.
J’ai toujours aimé manier des concepts, en inventer, les relier. J’ai commencé à faire de la modélisation quand je concevais des logiciels, puis j’ai fait des modèles avec des outils de génie logiciel.
J’ai donné mes premières formations il y a déjà quelques années et c’était sur les méthodes les plus populaires[1] de l’époque : SADT et SA/RT.
Dans SA/RT le premier diagramme réalisé était le diagramme de contexte, et dans SADT on faisait souvent l’équivalent appelé, autant que je me souvienne, diagramme A-1.
En ces temps-là, j’en ai réalisés de nombreux, pour définir le contexte d’un système ou d’un logiciel. Puis les méthodes objet sont arrivées. Avec la méthode Fusion, qui me plaisait beaucoup, il y avait l’équivalent. Pas avec OMT.
L’utilisation du tableau des tâches avec des Post-it est devenue une pratique courante (mainstream) pour les équipes agiles.
Par contre, ce que je vois beaucoup moins souvent affiché sur les murs, ce sont des schémas. Par exemple un schéma de l’architecture du logiciel ou un modèle métier des concepts manipulés ou un digramme de séquence expliquant un comportement représentatif.
James Shore qui l’a déclenchée avec son billet The Decline and Fall of Agile.
L’article est intéressant, les commentaires aussi. En (très court) résumé : il y a des risques de se planter avec Scrum si on est mal formé et il faut des pratiques d’ingénierie pour éviter la dette technique.
Il y a une dizaine d’années, disons entre 1996 et 2000, le langage de modélisation UML était considéré comme l’espéranto du développement de logiciel. Le U de unifié pouvait même servir pour universel. Tous les développeurs étaient encouragés à utiliser UML[1].
Quel que soit le jugement qu’on peut porter sur les qualités et les défauts d’UML, force est de constater qu’aujourd’hui sur le terrain, UML n’est pas très utilisé par les équipes de développement. Pourquoi ? Un billet donne 13 raisons pour la descente d’UML dans les ténèbres. L’article est polémique, en tout cas il attire beaucoup de commentaires de développeurs qui s’y reconnaissent.
Courant mai, je visite des étudiants de l’IUP ISI en stage dans les entreprises toulousaines. Pour l’instant, j’ai vu 3 étudiants. Tous travaillent sur des projets innovants et utilisent des technologies de pointe. Côté méthode, 100% des projets utilisent Scrum. Les étudiants sont parfois amenés à expliquer Scrum à des collègues.
Dans une entreprise, j’ai vu un beau tableau des tâches (horizontal) avec des notes collantes au mur de la salle de réunion. Dans l’autre, c’est IceScrum qui est utilisé intensivement. Des initiatives venant des étudiants en stage et acceptées et même encouragées par les entreprises.
Les principes de modélisation agile s'appliquent aux travaux sur les processus
J’ai passé ma journée d’hier sur la modélisation d’un processus de gestion des incidents d’un centre de services d’un ministère, dans le cadre d’un alignement avec ITIL. La modélisation de processus, plus encore que la modélisation de logiciel, donne souvent des diagrammes très compliqués si elle ne suit pas les principes de la modélisation agile, en particulier Model with a purpose et Assume simplicity.
La représentation des processus, ça devient vite une usine à gaz[1] en particulier dans 2 cas :
J’étais ce matin à un séminaire organisé par l’ITSMF sur ITIL et ISO 20000. Vous allez me dire, quel rapport avec l’agilité, qui est le sujet de ce blog ? On y a bien parlé et abondamment de la roue de Deming, qu’on cite aussi dans les méthodes agiles et dont j’ai parlé dans un billet précédent. On y a bien mis en avant la nécessité de prendre en compte les besoins des clients pour la définition des services, et c’est aussi un des objectifs des méthodes agiles que de se rapprocher des clients. Mais sinon pas de rapport direct, on ne va pas dire qu’ITIL est agile, bien que ça rime.
Je reviens d’une semaine de déplacements dans le nord[1], ce qui fait que je n’ai pas alimenté le blog pendant cette période. Je ne pensais pas rester aussi longtemps, mais pour rester agile, j’ai adapté mon emploi du temps aux besoins de mes clients et partenaires.
