Situation de départ au lancement du développement du site web
Nous collaborons depuis plusieurs années avec un client grand compte qui nous confie régulièrement le développement de nouveaux sites. Vu la manière de travailler, à savoir que le client n’est généralement pas en mesure de fournir au départ des spécifications claires, détaillées et stables, le travail est facturé selon le principe de la régie mutualisée, tous les mois, au temps passé, même si au départ un budget temps indicatif est généralement estimé.
Or justement parce que diverses demandes et modifications interviennent en cours de projet, les budgets initiaux sont généralement largement dépassés, ce qui logiquement n’enchante pas le client.
Du coup nous avons été sollicités pour traiter une demande de création de site au forfait, et compte tenu du fait que les spécifications n’étaient précise qu’en apparence (essentiellement de visuels) le choix a été fait de tenter une approche de développement beaucoup plus agile, de manière à réduire les coûts, sous réserve bien sur que n’apparaissent pas des demandes franchement nouvelles en cours de projet.
Progression du développement agile
Le maître mot a été la décomposition du projet en mini “briquettes” (ou atomes) faciles à réaliser.
Une semaine complète a été consacrée à ce travail d’analyse, avant le démarrage du développement.
Ensuite, chaque membre de l’équipe de développement a reçu sa “liste de briquettes” à réaliser.
Il est important de noter que comme il s’agissait d’un projet expérimental, unique jusqu’à ce jour pour nous, les développeurs (en l’espèce des binômes roumains intégrateurs front office / programmeurs back office) n’ont reçu que peu d’informations sur la démarche générale, laquelle n’a été vraiment conceptualisée qu’en cours de route (puis présentée). Les développeurs ont donc pu avoir une certaine impression de désorganisation, alors qu’au contraire le développement des briquettes a été très rapide, ceci d’autant plus que l’équipe s’est soudée très rapidement.
Bien sur une fois les briquettes assemblées, il a fallu combler certains « trous », voire préparer quelques briquettes en plus, mais c’est dans la nature même de la logique agile, rien de pénalisant ni même de surprenant, les trous ont bien vite été comblés, et après quelques derniers ajustements, le projet était bouclé.
Premier bilan du développement
Au final, le temps de développement s’est avéré légèrement inférieur à celui prévu, et il est donc resté du budget pour réaliser les premières modifications demandées par le client.
Quand à l’équipe de développement, elle semble avoir apprécié l’expérience !
Pour rendre à César ce qui est à César, voici les caractéristiques retenues de chaque méthode qui a été utilisée :
– De la métode de développement Agile a été adopté l’état d’esprit, le planning, la rapidité et la flexibilité
– Scrum a fourni les itérations, la collaboration très rapporchée et l’ouverture d’esprit
– Enfin la méthodologie de programmation extrème a apporté les itérations, la flexibilité et des livrables fréquents
Si nous considérons que ce projet a été un succès, il aurait pu l’être encore davantage, notamment en terme d’efficacité et de coûts, mais le fait que nous ayons eu plusieurs interlocuteurs clients, pas forcément coordonnés, a entraîné certaines modifications ultérieures qui auraient pu être prévues bien plus en amont.
Ceci dit, la méthode du découpage en briquettes (diviser pour régner, comme nous ont enseigné les romains) dans une optique agile est assurément une recette gagnante !
PS : Merci à Cristian Gabor, mon associé, dont j’ai repris, en le synthétisant, le récapitulatif du projet qui a été présenté aux salariés