modélisation

Le diagramme de contexte

Bubble revival

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.

Combattant du tableau blanc

Combattant du tableau blanc

Modélisation visuelle

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. Pourtant ce sont des artefacts qui sont particulièrement utiles pendant les réunions d’équipe, notamment la réunion de planification du sprint, et aussi tout au long de la journée, ne serait-ce que pour conforter un développeur dans ses choix ou faciliter une discussion impromptue.

Controverses

La controverse du jour

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.

La chute d'UML dans les ténèbres

Darkness

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.

Scrum vs MDA

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.

Modélisation agile de processus

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 :

Séminaire ITSMF

ITIL Agile ?

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.

Pérégrinations

Coucou me revoilà

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.

BMUF, Pigs and Chickens et Gripes

En vrac

BMUF

Après le BRUF, le BDUF, Scott Ambler s’attaque, dans un article du DDJ, à la grosse modélisation au début d’un projet, le BMUF.

Comme lui j’ai pratiqué la modélisation depuis très longtemps sur de nombreux projets et j’ai constaté qu’il y avait beaucoup de modèles trop détaillés faits au début et qui ne servaient à rien.