Le déroulement général du processus SCRUM devrait désormais être connu de presque tout le monde. Si ce n’est pas le cas, il convient de l’expliquer brièvement ici, en se référant au développement logiciel. Une équipe composée idéalement de sept développeurs travaille sur des tâches précédemment priorisées par le Product Owner dans le Product Backlog, durant des itérations (sprints) de deux à quatre semaines. Au début de chaque itération, l’équipe détermine conjointement la quantité de tâches à traiter dans le prochain sprint. Lors de la réunion quotidienne SCRUM, les développeurs se coordonnent brièvement chaque jour, se tenant ainsi mutuellement informés en permanence. À la fin d’un sprint, le résultat obtenu (incrément de produit) est présenté au client (revue de sprint) et l’équipe discute de la façon dont elle peut s’améliorer (rétrospective de sprint). Le SCRUM Master soutient l’équipe et assure un déroulement fluide du processus.

La méthode SCRUM est si concise qu’elle peut être transcrite sans problème sur un sous-bock

Si l’on souhaite donc établir un processus SCRUM, on pourrait penser qu’il ne faut pas plus que sept développeurs et un sous-bock. Le diable se cache cependant dans les détails et porte le nom de « développement agile ». Alors que SCRUM peut être expliqué sans problème sur un sous-bock, le développement agile nécessite déjà une transcription avec quatre valeurs et douze principes, appelée Manifeste Agile. La véritable valeur ajoutée de SCRUM ne se révèle donc pas par SCRUM lui-même, mais par l’intériorisation de ces principes et valeurs agiles.

Livraison continue

Contexte
Pour répondre aux besoins des clients, il faut répondre à la question de savoir quel est l’objectif principal que le logiciel doit atteindre. La plupart du temps, le développement logiciel commandé vise à simplifier les processus et donc à économiser de l’argent. Cela nécessite une mise en œuvre aussi rapide, économique et qualitative que possible de ses exigences dans un produit logiciel correspondant. Comme il est notoire que les coûts, le temps et la qualité ne peuvent pas être réduits dans leur ensemble, le développement agile utilise une astuce qui se reflète également dans le premier principe. Au lieu de livrer un produit logiciel fini, on livre le plus rapidement possible une première version du logiciel. Cette première version peut généralement être livrée après quelques semaines seulement et est tout juste suffisante pour générer un peu de valeur ajoutée pour le client.

Points d’attention
Ce qui semble simple en théorie nécessite cependant une certaine expérience et surtout des exigences précisément priorisées. Livrer un petit incrément fonctionnel est rarement le problème. Cependant, fournir une valeur ajoutée mesurable au client avec cet incrément représente le véritable défi. Au lieu de développer un processus de connexion pour un système qui n’offre par ailleurs aucune fonctionnalité dès le début, on peut par exemple offrir au client une première possibilité de gestion des données.
Il ne s’agit pas seulement de fournir de la valeur le plus tôt possible, mais surtout de manière continue. Cela fait de la priorisation une tâche continue qui prend certainement du temps. En contrepartie, elle garantit cependant que cet effort est constamment couvert par une réelle augmentation de valeur.

Flexibilité

Contexte
Le développement agile n’est pas une panacée. Pour organiser les projets avec succès, l’expérience dans le choix du modèle approprié est donc primordiale. Bien que certaines tendances puissent souvent être identifiées, chaque projet doit néanmoins être considéré et classé individuellement.
Au fil des années, il s’est avéré que les projets logiciels, et en particulier les nouveaux développements, présentent souvent certaines similitudes. Lorsque l’on souhaite développer ou faire développer un nouveau logiciel, il convient d’avoir au moins une vision globale qui permette de comprendre en quoi et comment le logiciel doit être utile. C’est à partir de ce moment que les différents modèles de processus entrent en jeu.
Le développement selon le principe de la cascade commence maintenant et élabore avec précision les fonctionnalités de la vision, y compris la logique, l’interface utilisateur, les dépendances entre les fonctionnalités, le temps nécessaire, etc. Une fois le projet spécifié par écrit, la mise en œuvre commence selon les spécifications.
Le développement agile opte pour une approche différente et tente de faire deux choses. D’une part, identifier la fonctionnalité qui apporte une valeur ajoutée concrète au client. D’autre part, mettre en œuvre directement cette fonctionnalité et la livrer ensuite au client. Les exigences ou les tâches qui sont encore plus éloignées sont, par exemple, consignées dans le Product Backlog, mais ne sont pas encore élaborées avec précision.

Ce à quoi il faut prêter attention
Dans l’approche du développement agile, des incertitudes peuvent survenir du côté du client, car aucune planification précise du temps et du budget n’est fournie, alors que le modèle en cascade fournit précisément cela comme prétendue sécurité. Cependant, la sécurité du modèle en cascade n’est souvent pas réelle, tout comme l’incertitude du développement agile n’est pas réelle. Les méthodes agiles permettent tout à fait une planification temporelle de certaines étapes ou d’un MVP. Toutefois, l’approche choisie ici consiste à ne donner une estimation du temps que lorsque toutes les variables sont connues.
Dans le développement logiciel, il s’est avéré que les meilleures idées pour améliorer un système surviennent au moment de l’exploitation et non de la planification. Vous remarquez certainement, lors de votre travail quotidien sur PC, certaines fonctions dans les programmes qui ne fonctionnent pas de manière optimale pour vous ou peut-être même qu’il vous manque quelque chose ? Si vous aviez planifié le logiciel, y auriez-vous pensé ? Et surtout, combien de temps et de ressources cela vous aurait-il coûté pour prendre en compte toutes les éventualités à l’avance ? C’est précisément là qu’intervient le développement agile, qui souhaite vous créer un avantage concurrentiel. D’une part en réduisant les coûts initiaux de planification et d’autre part en offrant la possibilité d’apporter à tout moment des modifications au logiciel.

Il est toutefois important d’être conscient du moment où certaines décisions doivent être prises. Il existe des décisions centrales qui ne peuvent pas être annulées ou qui ne peuvent l’être que difficilement. Cependant, la plupart ne sont pas de cette nature et peuvent être révisées avec un effort négligeable. C’est précisément ce principe que le fondateur d’Amazon, Jeff Bezos, décrit de manière assez illustrative en divisant les décisions en Type 1 et Type 2 Decisions. Les Type 1 Decisions sont les décisions irréversibles décrites ci-dessus. Les Type 2 Decisions sont décrites comme une porte que l’on peut à nouveau quitter en arrière si ce qui a été décidé s’avère inapproprié. Par conséquent, les Type 2 Decisions peuvent être prises rapidement et permettent ainsi une action agile. Les Type 1 Decisions s’accompagnent généralement de coûts considérables, tant en termes de temps que d’argent. À cet égard, Jeff Bezos décrit le phénomène selon lequel on s’appuie trop souvent sur des Type 1 Decisions, alors qu’il ne s’agit pas en réalité de décisions irréversibles.

Malgré la possibilité de réagir de manière flexible aux changements, il convient de respecter quelques règles du jeu pour s’assurer qu’aucun chaos ne se crée. Les changements ne doivent pas être effectués de manière arbitraire. Cela signifie que chacun peut proposer des changements à tout moment. Cependant, ceux-ci sont discutés en équipe avant leur mise en œuvre afin de s’assurer que chacun a bien compris le changement. Si plusieurs personnes du côté du client sont impliquées dans le développement, il est tout aussi important de discuter des changements avant leur mise en œuvre. En outre, précisément en raison de cette approche, les changements ne sont pas mis en œuvre immédiatement (dans SCRUM, par exemple, dans le sprint en cours), mais au plus tôt dans le sprint suivant.

Conclusion

Comme on peut le constater, les principes agiles ne remplissent pas seulement un dessous de verre, mais aisément des livres entiers. Par rapport à l’approche en cascade, les méthodes agiles comme SCRUM présentent des avantages décisifs. Il s’agit notamment de la possibilité de réagir de manière flexible aux changements ainsi que de la livraison continue de versions créatrices de valeur ajoutée. Par conséquent, des analyses et des améliorations continues sont nécessaires au cours du projet pour une application réussie. Ce n’est qu’ainsi que nous et nos clients pourrons profiter au maximum de l’approche agile.