Les projets en mode agile : moins, c’est mieux
L’agilité, c’est depuis 15 ans le terme à la mode. Avec toutes ses déclinaisons “marketing”. Retour aux fondamentaux, dans la vraie vie.

“La perfection est atteinte, non pas quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à enlever.”
Antoine de Saint-Exupéry
Les projets en mode agile s’appliquent surtout au numérique. Je vais donc rester dans le cadre des projets web et mobiles. D’autant que c’est également mon coeur de métier depuis 10 ans.
À l’origine : le cycle en V
Pendant toutes mes études, on m’a parlé uniquement du cycle en V. (Comme quoi, les études ne font pas tout…)
À cette époque, le principe était le suivant : on concevait des projets informatiques en considérant que tout devait être su en amont du projet. Puis des tests étaient lancés pour valider la bonne conception du produit. Ce qui se justifiait probablement à une époque où l’informatique était statique et éloignée du consommateur.

Mais les projets se sont complexifiés au fur et à mesure que la technologie avançait.
Dès lors, on a proposé aux développeurs les plus compétents de s’occuper de cette énorme tâche. Ils sont devenus chefs de projet.
Puis le suivi de projet étant devenu ingérable, on a choisi de le découper encore : les chefs de projet géraient l’aspect organisationnel et les concepteurs imaginaient le fonctionnement des logiciels, en s’appuyant sur leur expérience.
Petit à petit, on a inventé des formations de chefs de projet, ne nécessitant aucune compétence technique. Et la même chose s’est passé côté conception.
Ce qui devait arriver arriva : la grande théorie de base n’avait rien à voir avec la réalité. D’autant que les métiers en amont du développement avaient de moins en moins de connaissance du terrain. Et donc imaginait des solutions impossibles à mettre en place tout en passant à côté de bonnes solutions.
Les délais ont explosé. La qualité s’est réduite.
Et on ne s’occupait toujours pas du client : on pensait à sa place.
Bref. Le cycle en V a trouvé ses limites.
L’arrivée des méthodes agiles
Le cycle en V était un fiasco. Mais quelle solution proposer alors ?
Plusieurs méthodes sont arrivées dans les années 90–2000.
Pour ma part, j’ai apprécié l’eXtreme Programming (XP) : la proximité avec le client et l’exigence qualitative rendaient le travail attrayant à moindre coût.
La méthode la plus populaire est SCRUM : intéressant, mais un peu complexe. On pourrait vite tomber dans les travers du cycle en V avec une inutile complexité.
Le TDD, qui veut que le développement soit orienté par les tests est également intéressant. Mais sur un projet déjà en place. Sinon, ça coûte vite cher.
Il y a aussi Kanban, très utilisé pour le développement.
Pour le reste, Wikipedia saura vous renseigner.

Le pilier des méthodes agiles est de ne pas reproduire les erreurs du cycle en V :
- des équipes réduites au maximum
- un périmètre simple et bien défini
- une orientation du développement par les tests
- une proximité des développeurs / designers avec le client
- pas de hiérarchie au sein du projet.
L’objectif est d’avoir une vélocité optimale.
Les dérives
Bien des entreprises trouvent l’agilité “cool” car on a l’impression que c’est plus simple à gérer.
Hors, cela nécessite une véritable discipline. Souvent difficile à effacer quand la culture d’entreprise est bien ancrée.
Les rôles permanents
La principale dérive est que les rôles définis ponctuellement à chaque itération (le rôle est attribué à chacun au fur et à mesure des itérations) deviennent des niveaux hiérarchiques déguisés du cycle en V :
- le product owner devient manager
- le scrum master devient chef de projet.
Ainsi, les développeurs / designers perdent la proximité avec le client. Les product owner / scrum master ne sont plus en phase avec la réalité du terrain.
La cohésion d’équipe est réduite à néant.
La baisse de qualité
En s’appuyant sur le SCRUM, qui reste la méthode la plus populaire, le risque de baisse de qualité est élevé.
On veut délivrer rapidement et régulièrement des fonctionnalités. Et on passe moins de temps à la revue du code.
La conséquence est une dette technique qui s’accumule et réduit significativement la vélocité de l’équipe.
L’extreme programming répond très bien à cette problématique en exigeant un niveau de qualité supérieur du code.
Les conflits potentiels
La communication permanente peut amener à des conflits, en blâmant tel ou tel membre de l’équipe. C’est humain : on a toujours besoin d’un coupable.
Il faut donc définir des règles strictes sur le contenu des échanges afin d’éviter ces conflits.
Les conflits interpersonnels sont à gérer entre deux personnes au risque de créer un mauvais effet de groupe.
Ma propre expérience de l’agilité
Cela fait quelques années que je pratique l’agilité au quotidien.
Projets open-source
J’ai contribué à quelques projets open-source. L’avantage de l’open-source, c’est que le niveau d’exigence est élevé car les contributeurs sont nombreux. Pour autant, on n’a pas les moyens d’avoir une grande théorie en amont des projets.
Au final, force est de constater que cela fonctionne très bien : l’open-source est aujourd’hui présent dans 100 % (ou presque) des entreprises du numérique.
Développement professionnel en mode projet
Pendant bientôt 10 ans, j’ai développé à distance plusieurs dizaines de sites et applications. Avec des succès et des échecs. (beaucoup plus de succès que d’échecs, bien heureusement !)
Chaque développement était un projet à part entière dans une équipe réduite de 1 à 4 personnes.
Plus il y avait d’intervenants, plus c’était chaotique. Et c’est normal : la multiplicité des intervenants en termes de communication, en particulier à l’oral, nuit gravement à la cohésion des projets.
Les meilleurs projets, où la qualité était au rendez-vous et où les délais étaient parfaitement respectés, avec tous ce points commun : une équipe réduite à son minimum. En gros : moi et un designer en direct avec le client. C’est tout.
Application en mode POC (Proof of Concept)
Je travaille en ce moment avec un autre développeur sur le design et la conception d’un POC.
Nous avons travaillé (plus ou moins) en mode Extreme programming. Avec des tests unitaires, du contrôle réciproque du code et surtout en effectifs réduits sur un périmètre bien défini. Sans faire de plans sur la comète : la prise de décision s’est faite au fil de l’eau. Tout en se formant ponctuellement de manière opportuniste, en considérant cet aspect comme partie intégrante du projet.
Le cadre du POC étant technique, nous avons nous-même fait le design de l’app.
En l’état, nous tenons nos délais, la qualité est au rendez-vous, les fonctionnalités prévues sont intégrées. Et l’entente est au top.
What else?
Apple Design Awards : les meilleurs apps mobiles
Chaque année, Apple désigne les meilleures apps mobiles au monde selon plusieurs critères qualitatif. Ce sont les Apple Design Awards.
Quelques équipes à succès ayant gagné en 2017 :
- Blackbox : un jeu conçu par 1 développeur / designer
- Splitter Critters : un jeu conçu par 2 développeurs / designers
- Mushroom 11 : un jeu conçu par 4 personnes
- Bear : une app conçue par 3 personnes
- Things 3 : une app conçue par 10 personnes
- Enlight : 5 personnes
- AirMail 3 : 2 personnes

On parle des meilleures apps mobiles au monde !
En phase avec le Lean Startup
Le Lean Startup (“sans gras autour” en anglais) est une approche des projets d’entreprise visant à réduire l’inutilité pour améliorer la qualité.
En gros, on commence par concevoir un produit très minimal, on le fait tester, on analyse les retours.
L’idée principale est de ne pas rester dans sa tour d’ivoire. On va se confronter à la réalité tout au long de la vie du projet.

On travaille pour le client et non pour soi. On apprend du client et non de son imaginaire personnel.
Le Lean Startup est donc complètement en phase avec l’agilité.
Que faire des métiers historiques du cycle en V ?
De nombreux métiers intervenaient autrefois en amont du développement.
Tous ces métiers qui n’ont aujourd’hui plus vraiment leur place au sein des projets agiles.
Tant que faire se peut, personne ne doit rester sur le bord du chemin.
Ces métiers nécessitent cependant des compétences d’analyse qui permettent de dégrossir le travail des développeurs et designers. Ces anciens métiers sont remplacés par de nouveaux, avec les mêmes personnes.
Par exemple : analyse des retours clients, relation client, préparation des processus de tests pour les clients et tout ce qui peut apporter de la valeur à la relation client.
La différence principale est que, plutôt que d’imaginer ce qui va plaire au client, on va analyser son comportement pour en tirer des enseignements.
Let’s go !
Mon seul conseil : allez-y, foncez.
Inutile d’appliquer la méthodologie au pied de la lettre : c’est le meilleur moyen de tomber dans les dérives.
Exploitez le potentiel de vos équipes en permettant à chacun de se responsabiliser et s’impliquer dans le projet.
Si les grands groupes mondiaux et les petites équipes de l’open-source ont réussi à le faire, pourquoi pas vous ?

“Ce n’est pas l’augmentation quotidienne mais la diminution quotidienne.”
Bruce Lee


