IV. Livraison agile, gouvernance solide.

En 2001, lemanifeste original Manifesto for Agile Software Development a articulé la position des développeurs contre la gestion descendante des logiciels.

Les principes de ce manifeste sont difficilement contestables et sont d'une simplicité rafraîchissante. Ils se résument à faire fonctionner le logiciel aussi rapidement que possible, à travailler avec le client en tant que membre de l'équipe et à réagir au changement, plutôt que d'essayer de tout planifier à l'avance, de passer le relais et d'attendre que les choses tournent mal.

En 2017, le terme "agile" est devenu de plus en plus un concept que les dirigeants veulent imposer aux développeurs. Il a également acquis de nombreux bagages en cours de route.

Comme les cochons de la Ferme des animaux d'Orwell, les adeptes de Scrum commencent à ressembler aux disciples de la gestion de projet obsédés par la méthodologie, contre lesquels le manifeste agile initial a réagi.

Scrum, une méthodologie spécifique de gestion de projet, est devenue presque synonyme du mot Agile. Comme c'est souvent le cas dans les cultures axées sur les développeurs, elle s'est enrichie de toutes sortes de protocoles, de tactiques et de jargons, comme une boule de neige qui dévale la pente. Lorsque Scrum n'apporte pas tous ses avantages présumés, le raisonnement habituel est que vous ne le faites pas correctement ; à moins que vous n'ayez adopté sans réserve tous les éléments de Scrum, vous faites du "faux agile" et votre projet est voué à l'échec. Il est intéressant de comparer ce point de vue avec le Manifeste Agile original. Comme lescochons dans la Ferme des animaux d'Orwell, les adeptes de Scrum commencent à ressembler aux disciples de la gestion de projet obsédés par la méthodologie contre lesquels le manifeste agile original réagissait.

Cela ne veut pas dire que l'Agile, ou même Scrum, sont de mauvaises choses. Obtenir un code fonctionnel dès que possible, faire des démonstrations et des itérations dans des cycles réguliers et limités dans le temps, intégrer le client dans l'équipe et utiliser un carnet de commandes pour gérer le changement, ce sont tous des principes que nous suivons chez Made Media Mais en réalité, nous parlons ici du cycle de développement d'un logiciel. Certains éléments de la conception d'un site web ou d'une application ne relèvent pas à proprement parler du développement logiciel. Scrum n'a pas vraiment de place pour le design au niveau macro. Nous combinons donc les processus de développement agile avec le pragmatisme global du projet, en faisant juste assez de conception en amont pour éviter de s'enfoncer dans des trous de lapin improductifs, et en ne déléguant pas entièrement l'assurance qualité à des tests unitaires qui voient la qualité strictement à travers la lentille du code.

Cela se manifeste généralement lorsque le rôle du chef de projet consiste à demander à l'équipe de production ce qui se passe et à mettre à jour son diagramme de Gantt pour mieux refléter la réalité. La queue de la réalité remue le chien de la fiction.

La méthode Agile est généralement opposée à la technique Waterfall, dans laquelle toutes les tâches sont planifiées à l'avance sur un gigantesque diagramme de Gantt, qui ressemble de plus en plus à une œuvre de fiction au fur et à mesure que le travail réel se met en place. Cela se manifeste généralement lorsque le rôle du chef de projet consiste à demander à l'équipe de production ce qui se passe et à mettre à jour son diagramme de Gantt pour mieux refléter la réalité. La queue de la réalité remue le chien de la fiction.

Alors oui, la chute d'eau a ses problèmes. Mais souvent, lorsqu'ils pointent du doigt une méthodologie telle que PRINCE2 ou des certifications telles que PMP, les partisans de la méthode agile se méprennent sur le véritable objectif de ces méthodologies. PRINCE2, par exemple, n'a pas grand-chose à voir avec la réalisation d'un projet. Il trouve son origine dans les marchés publics, où la livraison est très probablement effectuée par un partenaire d'externalisation (comme nous !) et est considérée comme l'activité du partenaire d'externalisation. Le véritable objectif de PRINCE2 n'est pas de réaliser le projet, mais de fournir suffisamment de documentation C.Y.A. pour prouver que ce n'est pas la faute du gestionnaire de projet lorsque le budget double et que le produit est toujours introuvable.

Ce qui ne veut pas dire que PRINCE2 est mauvais en soi. Son objectif est d'essayer de contrôler la gouvernance du projet , et non la réalisation du projet. Veiller à ce qu'un projet soit commandé sur la base d'une analyse de rentabilité. Fournir des lignes directrices quant au moment où il convient de tirer la sonnette d'alarme pour signaler que tout ne se déroule pas comme prévu. Anticiper et consigner les risques. Ces contrôles et équilibres sont importants lorsque vous devez répondre de vos budgets. Il s'agit de la réussite globale du projet.

Les projets Web sont une entreprise risquée. Le champ d'application est si difficile à définir avec des mots que l'on n'est jamais vraiment sûr de ce que l'on obtient, ou même de ce que l'on veut, tant qu'on ne l'a pas vu. C'est l'une des raisons pour lesquelles nous préférons les wireframes aux listes d'exigences. Mais personne ne vous donnera un chèque en blanc pour votre projet web, et vous devrez rassurer votre conseil d'administration ou votre sponsor sur ce que vous obtiendrez pour leur argent. Il est donc inévitable qu'il y ait un engagement matériel sur les fonctionnalités, les budgets et les délais dès le départ. C'est un point que les méthodologies axées sur le développement ont tendance à éluder. Vous savez pourquoi ? Parce que les développeurs se sentent à l'aise pour écrire du code, et non pour faire des promesses commerciales.

Chez Made Media , nous sommes conscients que les budgets des projets ont souvent mis des années à être gagnés et qu'ils ont été attribués avec des attentes précises quant aux résultats. Les méthodologies de développement agiles ne peuvent pas nous dispenser de notre engagement à répondre à ces attentes. Travaillant avec des budgets fixes, nous devons tempérer Scrum avec certaines réalités commerciales. Nous estimons en heures, et non en pseudo-abstractions comme les story points. Même si, parfois, cela nuit à l'ambiance du développeur.

Chez Made Media, nous utilisons donc une méthodologie qui emprunte beaucoup à Scrum, et un peu à DSDM et Kanban. Les clients sont invités à participer aux réunions de planification des sprints, ou même aux réunions quotidiennes s'ils le souhaitent. Mais un appel et une démonstration hebdomadaires constituent la base. En ce qui concerne la commande de projet, la gouvernance, les rapports et la responsabilité, nous suivons davantage les principes de PRINCE2. Et il n'y a pas de contradiction là-dedans.

Lecture obligatoire

• Peopleware Demarco et Lister démontrent que les principaux problèmes liés au développement de logiciels sont d'ordre humain et non technique. 
• Le mois de l'homme mythique: un aperçu pour tous ceux qui gèrent des projets complexes.
• Manifeste agile découvrant de meilleures façons de développer des logiciels
  en le faisant et en aidant les autres à le faire.
• Scrum est un cadre de développement logiciel agile itératif et incrémental pour la gestion du développement de produits.
• DSDM Méthode de développement de systèmes dynamiques.
• Kanban: un système d'ordonnancement pour la production allégée.
• Une critique de Scrum illustrée par des mèmes de premier ordre.

Le mois prochain : L'innovation au service d'un objectif