Agilité & Scrum
Aujourd’hui, l’agilité est de plus en plus pratiquée en entreprise. Pourquoi ? Est-ce que c’est juste une question de mode, de vague ou bien y a-t-il un vrai gain derrière cette méthodologie ?
Avant les méthodes Agiles
Avant l’agilité, nous avions les cycles en V ou bien les méthodes dites « waterfalls ». Ces méthodologies, qui sont encore valables et utilisées, offrent des avantages, mais aussi des défauts. Parmi ces défauts, le manque de transparence et le manque de retours utilisateurs. Ce qu’on leur reproche avant tout c’est « l’effet tunnel » où l’utilisateur est peu impliqué (voir pas du tout informé) de l’avancement du projet entre le recueil de besoins et la livraison finale.
Un autre effet négatif de ce tunnel est que souvent le besoin de l’utilisateur a évolué pendant la phase de développement. Enfin la frustration de l’utilisateur qui s’attendait, imaginait voir fantasmait cette application explose au moment de la livraison de par ce blackout. Mais aussi parce que les différents acteurs du projet y ont mis leurs interprétations du besoin qui, à tort ou à raison, éloigne le « rendu » de « l’attendu ».
Avec les méthodes Agiles
L’agilité remet l’utilisateur final au centre de l’application et c’est l’un des principes de base. On se focalise souvent sur les itérations de cette méthodologie sans vraiment approfondir le sens de celles-ci.
L’un des premiers principes est de montrer et démontrer ce que l’on fait durant le « sprint » à l’utilisateur lors des « démonstrations ». Ces démonstrations permettent de recueillir immédiatement les feedbacks utilisateurs et les intégrer dans les prochains développements. La frustration des utilisateurs est donc réduite, puisqu’il voit au fur et à mesure ce qui est développé et peut influer sur le développement. Il y a également un contact direct entre le développeur et l’utilisateur, ce qui à la fois implique le développeur, mais aussi coupe les différents intermédiaires et leurs interprétations.
Le second principe est la transparence, là aussi cela permet de réduire la frustration de l’utilisateur, car il sait très exactement ce qui a été fait et ce qui sera prochainement fait. Étant informé des difficultés, des problématiques, des enjeux, mais aussi des réussites et du travail réalisé, il devient peu à peu un membre honoraire de l’équipe. Dans certains cas, l’utilisateur peut même se transformer en sponsor et ardent défenseur du projet.
Une des cérémonies des méthodes Agiles est la rétrospective. Réunion d’équipe, fait par l’équipe pour l’équipe. Ce point de fin de sprint permet d’évoquer les difficultés rencontrées durant le sprint qui ont ralenti ou bloqué celui-ci. Moment d’introspection de l’équipe où, avec bienveillance et sans pointer qui que ce soit du doigt, on expose les problématiques. Une fois exposées, l’équipe décide d’action pour éviter que ces difficultés se reproduisent. Cela peut être matériel (changement de poste), logiciel (changement de version de librairie, changement d’outil …) ou bien même un changement organisationnel (tâches mieux découpées, préanalyses techniques des US …).
Enfin, l’un des principes de base est la livraison à la fin du sprint. Très lié à la « DoD » (Definition of Done), il est important qu’un ticket soit déclaré fini quand il est vraiment fini. Il est aussi important qu’à chaque fin de sprint, un livrable avec les développements validés soit fourni. Non seulement cela permet de s’inscrire dans « l’intégration continue », mais cela permet également d’avoir un résultat concret à la fin du sprint.
La durée des itérations est souvent déterminée par des contraintes calendaires. Or elle devrait être déterminée par la faisabilité des développements dans un minimum de temps, la récurrence des démonstrations produit et la difficulté à livrer à la fin du sprint. Plus les itérations sont longues et plus la transparence et la facilité à faire un livrable stable vont s’amoindrir jusqu’à disparaitre. Plus les itérations sont courtes et moins on pourra avoir des développements « lourds », pire on risque « d’endormir » l’utilisateur qui n’aura pas autant de temps à consacrer à l’application. Trop de démonstrations pour peu de changement risque de le faire décrocher du projet voir se l’adosser.
Comme vous venez de le voir, la méthode Agile a aussi ses écueils, mais globalement permet d’être plus efficace. Surtout sur des équipes débutantes moins rompues à l’informatique dans sa forme traditionnelle.
Les valeurs sur lesquelles repose la méthodologie Agile (Scrum, Kanban, …) ont surtout l’avantage de remettre du sens dans les projets au travers du contact avec les utilisateurs. À la fois en impliquant le développeur, mais aussi en lui faisant voir l’impact direct de ce qu’il a produit. Les projets sont faits pour les utilisateurs, pour les aider, pour leur faciliter la vie. Combien de projets les ont oubliés sur la route ? Combien de développeur ou de chef de projet ont pensé mieux connaitre le métier que l’utilisateur lui-même ?
Évidemment tout n’est pas noir ou blanc, des développeurs qui utilisent les cycles en V s’intéressent et s’approprient les problématiques des utilisateurs. Mais la méthode agile permet de poser un cadre officiel et normé autour de ces aspects relationnels.
