Avant toute chose : pourquoi Agile ?
Pour plusieurs raisons. Le cycle de feed-back court en est une des plus importantes. Dans un projet classique, basé par exemple sur la méthode en cascade, tout a déjà été mis en place et configuré avant que le client puisse voir le système pour la première fois. S'il s'avère à ce moment-là que certaines choses ont été mal comprises, cela nécessite beaucoup de travail de correction. Il y a également de fortes chances que les exigences et souhaits aient changé entre-temps et que le produit livré ne réponde plus aux besoins actuels. Pour éviter de tels risques, une approche plus flexible s'impose. Agile est une méthode particulièrement appropriée pour s'adapter à des circonstances en constante évolution. Elle permet une approche itérative sur des « sprints » courts de 2 à 4 semaines, des boucles de feed-back régulières et fait la part belle au changement et à une vision innovante. Elle part en effet du principe que les besoins des entreprises évoluent au cours d'un trajet d'implémentation. Les utilisateurs peuvent voir une démo de l'application à chaque sprint et indiquer directement si tout répond à leurs attentes. Ils ont également accès à un environnement UAT (User Acceptance Testing) qui leur permet de tester eux-mêmes la fonctionnalité, ce qui facilite l'adoption par les utilisateurs. C'est une deuxième raison d'utiliser agile. Les utilisateurs apprennent à connaître l'application dès le début et se sentent impliqués dans le projet. Parce qu'ils ont leur mot à dire, leur engagement augmente et ils sont donc plus enclins à accepter et à utiliser l'application. Une troisième raison est l'importance accordée à la création de valeur : l'offre d'une valeur ajoutée au client. Grâce à une priorisation permanente et à une concentration sur la valeur commerciale intrinsèque, on n'investit que dans des fonctionnalités importantes et pertinentes.
Coach agile : le « côté doux » du changement et l'utilité des connaissances et de l'accompagnement
Le travail agile a de nombreux avantages, mais ce n'est toutefois pas une formule magique que n'importe qui peut utiliser directement. Si vous n'avez jamais réalisé de projet agile dans D365 ou si la méthode agile est relativement nouvelle pour vous, il est dès lors recommandé de faire appel à un coach agile. Il répondra à toutes vos questions sur la meilleure manière d'aborder un projet agile et aidera les membres de l'équipe dans leurs démarches pratiques. Le coach vous assistera également dans l'interaction avec le client et aidera ce dernier à travailler avec agile. Un principe important de l'approche agile est en effet qu'une bonne et étroite collaboration entre les personnes et les équipes détermine le succès d'un projet, et cela n'est possible que si tout le monde est sur la même longueur d'onde. Un coach agile ne doit pas nécessairement avoir de l'expérience dans des projets D365, mais il doit bien sûr avoir en avoir dans le travail avec agile.
Sprint 0 : choisir des bases solides
Il est conseillé de commencer par un sprint 0. Ce sprint est un sprint préparatoire qui jette les bases de tous les sprints suivants et donne à l'équipe le temps d'apprendre à se connaître et de conclure certains accords. Au moyen de workshops, les premières exigences et les premiers souhaits des utilisateurs finaux sont passés en revue et transposés en user stories. Ces user stories sont ensuite regroupées dans un product backlog et classées par ordre de priorité suivant leur valeur commerciale. Les éléments ayant le plus de valeur pour les utilisateurs sont d'abord configurés et implémentés. Il doit ainsi s'agir d'un product backlog qui contient suffisamment de user stories pour remplir un premier sprint. Les user stories peuvent être divisées en parties suffisamment petites. Dans un projet sur mesure, seule la valeur commerciale pour le client est prise en compte dans un processus de hiérarchisation. Avec un projet D365, vous pouvez déjà créer de la valeur commerciale grâce aux fonctionnalités intégrées dans la suite logicielle. Le solution consultant joue un rôle important à ce niveau. Il doit veiller au fit/gap entre les fonctionnalités intégrées et la valeur commerciale demandée. Pendant le sprint 0, il est important de prêter aussi attention aux aspects techniques et aux exigences fondamentales du système, comme l'architecture, surtout si des intégrations avec d'autres systèmes doivent également avoir lieu.
Product owner : assurer le lien entre les parties prenantes
Si un bon product owner est déterminant dans la réussite d'un projet agile, c’est également le cas dans les projets D365. Un bon product owner n'est de préférence pas un manager : un manager ou responsable n'a souvent pas suffisamment de temps pour assurer un suivi adéquat d'un projet. La fonction de product owner n'est pas une fonction que l'on exerce à côté du reste. Un product owner est quelqu'un qui connaît le business et a de l'expérience en la matière. S'il s'agit par exemple d'une implémentation commerciale, le product owner devrait idéalement être − ou avoir été − un account manager. Il doit avoir un bon contact avec toutes les parties prenantes du projet et bien connaître les différents intérêts du business et de l'IT, mais aussi veiller à ce que la vision définie avant le début du projet fasse l'objet d'un suivi. À cet égard, il est extrêmement important pour le projet que le product owner reçoive un mandat unanime pour prendre lui-même des décisions. Sans cela, le projet risque d'être retardé dans l'attente de prises de décisions.
Minimum Viable Product : l'essence même d'une accélération rapide
Agile est basé sur le principe qu'à la fin de chaque sprint, un Minimum Viable Product (MVP) − un produit minimum viable réalisé avec un investissement le plus bas possible − peut être livré. Ces courtes itérations réduisent le risque d'échec, avec un feed-back immédiat fournissant un délai d'exécution plus rapide et évitant une complexité inutile. Pour autant que le lancement ait été fait de manière réfléchie et que l'intention soit telle, « minimum viable » ne signifie d'ailleurs pas « médiocre ». Un minimum viable product est une fonctionnalité qui peut également être utilisée de manière concrète et qui peut servir de base pour la suite. Dans D365, il est même possible de livrer plus facilement quelque chose après 2 semaines que dans un projet sur mesure. Le défi ici est toutefois que l'approche du projet et les connaissances des équipes doivent être adaptées à ces courts delivery sprints. Dans l'esprit de DevOps, Agile et les (automated) releases vont de pair. D365 peut ainsi être considéré comme un jeu de construction à partir duquel sont sélectionnés les blocs importants pour le projet et avec lesquels la suite de celui-ci peut être développée.
Sprinter, mesurer et apprendre : implémenter selon une vision progressive
Durant l'implémentation du projet, il est particulièrement important que la priorité du business soit abordée lors des réunions de planification de sprint, ainsi que la séquence technique de l'implémentation. Il est possible que certaines entités doivent d'abord être créées avant que d'autres éléments puissent l'être. Ceci pourrait avoir un impact sur le nombre de story points qu'une user story reçoit, ou sur l'ordre dans lequel cela devrait être implémenté. Les réunions d'évaluation de sprint et les rétros sont d'une importance cruciale au cours de cette phase du projet. Lors des réunions d'évaluation de sprint, les résultats sont présentés pour la première fois aux utilisateurs. Il est important d'écouter attentivement leurs commentaires et de profiter de ce moment pour leur permettre de découvrir D365. Le meilleur moyen d'y parvenir est de leur donner accès dès que possible après le sprint à un environnement dans lequel ils peuvent tester et valider eux-mêmes un certain développement ou une certaine configuration sur le plan fonctionnel. Si nécessaire, il est possible de prévoir quelques adaptations, qui seront traitées dans une itération suivante sur la base des priorités fixées. L'un des grands avantages de cette approche est qu'elle permet à tout un chacun de suivre de plus près l'état d'avancement du projet considéré. De plus, le business et l'IT sont également mieux alignés l'un sur l'autre et réalisent ainsi des gains de productivité.