modélisation

Le diagramme de contexte

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

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.

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. Parmi mes activités sur des projets : pour un éditeur de progiciel dans le domaine bancaire, j’ai interviewé une quinzaine de personnes des équipes de développement, identifié les problèmes majeurs dans l’organisation et préconisé des pratiques agiles à instiller.

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. Je me souviens avoir essayé d’introduire une approche de modélisation raisonnée dans un guide méthode SDL pour l’Aérospatiale[1], mais sans grand succès.