La méthode Agile offre de grands avantages pour la mise en œuvre de projet mobile, on l’a vu dans les articles précédents de cette série consacrée à l’agilité.
Pourtant, sa souplesse est sujette à des interprétations inappropriées et à des questions récurrentes de la part de nos clients.
Nous vous proposons de préciser ce point dans les lignes qui suivent en abordant 2 questions qui se posent couramment.
Lors d’un développement d’application mobile en mode Agile, le client peut-il vraiment changer d’avis à tout moment ?
Le client peut changer d’avis (c’est tout le principe de l’Agilité) mais dans un certain cadre.
Si le product owner (responsable du projet, côté client) énonce de nouvelles exigences en cours de sprint (ou modifie des exigences déjà formulées), leur priorité peut être discutée avec le scrum master (chef du projet, côté réalisation).
Mais cela ne remet pas en cause les exigences du sprint en cours.
Ces nouvelles exigences pourront éventuellement être prises en compte dans l’un des sprints suivants, à l’issue d’une négociation entre le product owner et le scrum master.
Un projet de conception d’appli mobile en mode Agile peut-il être contractualisé dans la mesure où son périmètre est variable ?
Oui, bien sûr ! Deux modes de contractualisation existent : le développement « au forfait » ou « en régie ».
Le développement en régie consiste à facturer le temps exact passé sur un projet, tandis que le développement informatique au forfait est facturé sur un montant fixe qui se calcule en fonction de l’ampleur du projet.
Pour un projet de développement d’application mobile en méthode Agile, la régie est possible mais le client préfère habituellement le forfait, pour être en mesure de prévoir son budget.
Cela constitue un risque pour le prestataire car il devra prendre en charge les éventuels imprévus et retards.
Limiter ce risque revient à réduire la souplesse de la méthode.
Il faut donc trouver un juste équilibre : une solution consiste à négocier par exemple la réalisation d’une exigence qui n’était pas prévue initialement en retirant une exigence de priorité plus faible et de même coût.
Cette négociation entre le product owner et le scrum master nécessite d’avoir dès le début attribué un degré d’importance ainsi qu’un nombre de jours/homme de développement à chaque histoire utilisateur du backlog afin de pallier les changements éventuels pouvant apparaître en cours de route.