La semaine dernière nous avons parlé choix de méthodologie projet pour un projet décisionnel. L’objectif était de déterminer un critère simple pour trancher entre développement itératif (méthodes agiles) et cycle en V (vive les spécifications). Pour ceux qui ne lisent pas les commentaires, un expert de l’agilité est venu apporter des précisions importantes (avec une forme désagréable certes, mais sur le fond plein de sagesse), la première étant qu’on ne devait pas partir sur de l’Agilité sans prendre en compte les valeurs. C’est vrai et nous allons commencer par là avant de voir comment cela impacte directement le découpage du Datawarehouse en itération.

Les valeurs de l’Agilité sont inscrites dans le Manifeste Agile – je vous laisse consulter Wikipedia si vous êtes intéressés par l’histoire de la chose. Ce sont en fait quatre relations de valeur qui doivent toujours guider le chef de projet agile :

Notez bien que ces relations ne sont pas des oppositions, mais des axes de progression. Il faut le lire comme : « Il faut privilégier les individus aux processus ». Si vous entendez un chef de projet agile vous dire qu’il ne fera pas de documentation parce que ce n’est pas Agile, c’est qu’il n’a rien compris à l’histoire.

Pour moi l’Agilité repose vraiment sur ces relations. Ma méthodologie de projet agile (mes processus) n’est vraiment pas exemplaire, c’est un mini-SCRUM improvisé que je ré-invente à chaque projet. Par contre je bosse toujours d’abord sur les anomalies avant les évolutions, ma bonne relation avec le client passe avant l’exécution de toutes les clauses du contrat et j’adore quand un utilisateur propose de nouvelles idées – tant pis si on doit tout casser pour l’implémenter.

Evidemment fonctionner en mode Agile c’est une relation qui marche dans les deux sens. Tous les acteurs doivent jouer le jeu, les utilisateurs c’est évident, mais également l’acheteur par exemple, sans quoi vous risquez de mauvaises surprises en fin de mission (surtout si vous attendez des signatures de PV de livraison en fin de forfait, mais on parlera contractualisation plus tard)…

De ces 4 relations découlent 12 principes, qui donnent les grandes lignes sur comment implémenter l’Agilité. Les plus importantes :

• Livrer de manière continue des fonctionnalités complètes, utiles et utilisables
• Développer par itérations courtes (quelques semaines)
• Etre adepte du changement, privilégier les solutions simples et adaptables
• Rapprocher utilisateurs et développeurs
• S’améliorer continuellement

Il existe plusieurs méthodes de gestion de projet Agile, toutes itératives, toutes intégrant des métriques de progression et un framework de processus et documentation pour bien mettre en place une relation Agile avec l’utilisateur, mais je ne suis pas vraiment la bonne personne pour en parler (moi je suis un peu de l’avis de Ted Dziuba ;))

Ce qui est important, c’est que dans le quotidien il ne faut pas oublier les 4 relations de valeur de l’Agilité, dont la première qui dit bien que les interactions avec les individus doivent être priorisées par rapport au processus. Il ne faut donc surtout pas être rigide avec ses processus Agile, ce serait le comble ! La seule exception à cet impératif – et encore, ça se discute – c’est qu’une fois une itération commencée, on essaye de ne pas toucher à son contenu. En effet, comment arriver à livrer quelque chose de valeur si on ne finit jamais rien?

Ok tout ça c’est cool, mais dans la vraie vie je suis en mission, je veux faire du développement itératif mais je ne connais pas encore mon client. Est-ce que je peux faire de l’itératif, du processus Agile, sans les valeurs ? Personnellement j’en doute. Enfin je ne doute pas que ce soit faisable, on peut tout faire, je doute juste que cela finisse bien. Augmenter le rythme du cycle de livraison et la disponibilité face aux demandes de changement, cela augmente la friction avec l’utilisateur. Si on n’encadre pas cette relation avec les boucles de feedback que sont les valeurs Agile, cette friction devient frustration qui dégénère en conflit. Il faut « l’huile » que sont ces valeurs pour que cela puisse fonctionner sur le long terme.

Et puis quand on y pense vraiment, ces valeurs ne sont rien d’autre qu’un gros concentré de bon sens non ?

Maintenant que le contexte est donné on va pouvoir continuer sur comment découper son Datawarehouse en itérations agiles.