architecture

Intégrer plutôt que séparer

En mars, j’avais présenté les premiers principes de la permaculture, en préparant la soirée-débat Permaculture et agilité du 21 mars au 100e singe. J’avais été interrompu après le 7e principe par l’urgence de ma relecture pour la sortie de mon livre Scrum, qui a été finalement publié en mai. Je parle de permaculture dans cette 5e édition, mais je n’y détaille pas les 12 principes. Le 8e principe “Intégrer plutôt que séparer” est typique de l’approche systémique qui met l’accent sur les connexions entre les éléments, alors qu’un approche plus traditionnelle (cartésienne) se préoccupe plus de décrire les éléments décomposés.
Combattant du tableau blanc

Combattant du tableau blanc

L’utilisation du tableau des tâches avecdes 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.

Agilité et architecture

Hier en discutant, avant de commencer l’atelier TOC, entendu parler, à propos une grande entreprise dont les équipes faisaient du Scrum “maison”, de la résistance opposée par les architectes à la diffusion de l’agilité dans les projets. Agilité et architecture ou plus exactement Agility and Architecture, c’est le titre du numéro d’avril du magazine Computing Now d’IEEE Software. Du sérieux. J’ai commencé la lecture et je la conseille aux architectes (en particulier de type reloadus) comme aux agilistas.

L'architectus oryzus, une espèce à protéger

J’ai fait du latin dans ma jeunesse… Dans son célèbre article Who needs an architect?, Martin Fowler distingue l’architectus reloadus et l’architectus oryzus : Le premier prend les décisions importantes, souvent très tôt, et les fait appliquer. L’architectus oryzus est un expert aussi, mais plus investi dans le projet. Il collabore intensivement avec le reste de l’équipe, il met les mains dans le cambouis quand c’est nécessaire. Il agit plus comme guide et médiateur.

Tranche verticale ou tranche horizontale ?

Les 2, mais fines. Le projet IceScrum a une nouvelle vie. Un point sur lequel tout le monde s’accorde : il faut améliorer l’IHM. Les utilisateurs souhaitent quelque chose de plus ergonomique, les développeurs aimeraient introduire plus de technologie de type RIA. IceScrum est une application Java EE qui incorpore le framework IceFaces qui, bien que récent, offre de nombreuses possibilités pour faire du RIA. Lors de la récente revue, le but pour le prochain sprint a donc été recentré sur l’amélioration de l’usabilité du logiciel.

SigmaT3 : conception émergente

Une alternative au BUFD, qui sera présentée au séminaire de vendredi Le cycle de vie d’un projet qui suit une méthode agile est composé d’itérations successives. Une question fréquente est : de quoi faut-il disposer pour commencer la première itération, en particulier en ce qui concerne la conception[1]. Quelle quantité de conception faut-il ? L’approche classique est de faire l’essentiel de l’architecture au début du projet. Les agilistes considèrent qu’on en fait souvent trop, ce qui est du temps perdu, et appellent cela le BUFD : big up front design[2].

L'agilité, un méméplexe à replacer dans le contexte

Mémé qui ? Sur InfoQ, je tombe sur une critique de l’article de Philippe Kruchten, Voyage in the Agile Memeplex. Le sous-titre est In the world of agile development, context is key, ce qui est plus parlant. Je connais bien Philippe, nous nous sommes croisés à Alcatel au début des années 80. Il travaillait sur les gros PABX (>100 lignes) et moi sur les plus petits. Nous nous rencontrions lors de revues de projet.

L'Agilité au détriment de l'architecture ?

La réponse est non. Dans InfoQ, un article de Amr Elssamadisy qui se demande si les pratiques Agiles ne se font pas au détriment de l’architecture et de la conception. C’est vrai que lorsque je présente les méthodes Agiles, on me fait souvent la remarque suivante : avec des itérations aussi courtes, on n’aura pas le temps de réfléchir à une architecture solide. Eventuellement suivie d’une autre : si on construit un logiciel juste pour les quelques fonctionnalités [1] sélectionnées pour une itération, le risque est grand de devoir retoucher l’architecture dans les itérations suivantes.