Archives mensuelles : janvier 2014

Votre projet est un arbre

Elle est mal tenue cette forêt, il y a des arbres partout! — Obélix

En informatique on aime les patterns. Il a des trucs qu’on refait partout. Par exemple les arbres.

Les arbres, en informatique, sont des structures de données récursives, chaque élément est un noeud qui peut avoir des enfants, les éléments sans enfants sont des feuilles et… Enfin comme toujours le mieux c’est d’aller voir wikipédia. L’exemple typique c’est le système de fichier : les répertoires, les noeuds contiennent des répertoires, qui contiennent des fichiers, les feuilles.

Capture d’écran 2014-01-30 à 22.33.22

Et donc comme on aime les patterns on voit des arbres partout. Enfin moi en tout cas.

Par exemple dans les livres ou les articles : en général ils sont un plan, avec des chapitres,  des sous chapitres, etc… Ben ça fait un arbre :

I Le grand chapitre
    I.1 Petit chapitre premier
        1.1.a Le baba
            Le contenu du a
        1.1.b
            Contenu...
     [...]
II Le grand chapitre rouge

Autre exemple : les minds maps, technique de brainstorm. Ca se représente en étoile, mais si on le met à plat, ça reste quand même un arbre :

mm_languagelearning

Le code du projet est un arbre…

Idem pour le code : on a non seulement l’arbre du système de fichier avec les modules,  paquetages et classes, mais aussi les fonctions, avec les if, boucles, etc… le tout est arbre.

…Mais aussi le projet tout court

Il m’est venu à l’esprit qu’un projet, si on le prend comme un ensemble de tâches à réaliser est aussi un arbre : à la racine on a la tâche de plus haut niveau (le projet quoi), et puis on découpe et on affine en descendant, jusqu’à arriver aux trucs super bas niveaux du genre « importer la classe Machin » :

arbre

Bien sur, comme les arbres, les projets sont tous différents, votre projet peut-être un hibiscus, un baobab, un chêne, voir un peuplier (comme les roseaux).

So what ?

Explorer cette comparaison est intéressant. Ainsi :

Le niveau d’intérêt des protagonistes pour chaque étage de l’arbre varie en fonction de leur responsabilités.

Plus un exécutif est haut dans la hiérarchie (directeur de projet, CTO, …), moins sa vision sera proche des feuilles. Il explore l’arbre moins en profondeur.
Dragonnier millénaire

Remonter mentalement dans l’arbre permet de mieux comprendre le projet.

Pour comprendre un système il faut s’en extraire : passer à un niveau de réflexion de plus haut niveau permet de mieux comprendre les tâches en cours. Pour bien travailler, il faut comprendre le but du projet et sa structure générale. Et donc avoir une bonne vision de l’arbre, de ce qu’il y a à faire, et pourquoi.

Il possible de remonter de quelques niveaux pour changer de solution.

Quand on bute sur un problème ou qu’une solution s’avère inadaptée, plutôt que de s’acharner à la même profondeur, remonter de quelque niveaux permet de trouver peut-être une autre solution plus simple. Par exemple si on arrive pas à faire marcher une implémentation, plutôt que de s’acharner, on peut essayer de trouver une autre solution. On explore alors une autre branche.

On peut faire quoi avec les arbres ?

En théorie des graphes et en IA, on peut faire plein de trucs avec des arbres. Par exemple il y a des parcours en largeur et en profondeur. Comparons avec les méthodes de gestion de projets :

Parcours en largeur

Le cycle en V adopte plutôt un parcours en largeur du projet, explorant toutes branches et affinant la granularité jusqu’à arriver aux feuilles. On ratisse large, on analyse tout.

Parcours en profondeur

A l’inverse, en agilité, on fait plutôt un parcours en profondeur de certaines branches, par priorité. On explore les branches correspondants aux storys, et l’arbre est découvert (voire taillé) petit à petit.

Sur la même veine :

L’élagage

Lors d’une recherche en IA, on parle d‘élagage quand on ignore volontairement des branches pour accélérer. Pour un projet ce serait une réduction de périmètre.

L’équilibrage

Pour que  les recherches dans un arbre soient efficaces il faut qu’il soit équilibré. Dans la mesure où les tâches sont réparties entre des équipes et des personnes, l’équilibrage d’un projet est aussi intéressant.

Conclusion : Software craftmanship et taille-haie

Edward-ScissorhandsL’idée derrière le terme « software craftmanship » c’est qu’un développeur est plus un artisan qu’un ingénieur : il façonne une pièce unique avec ses mains, son savoir faire et les matériaux bruts qu’on lui fournit. Comme un artiste qui sculpte des troènes.

C’est peut-être à cause de tout cela qu’on parle tant de green-IT.