Projet mobile et méthode Agile : 2 questions fréquemment posées [#5/6]

InfleXsys Projet mobile et méthode Agile : 2 questions fréquemment poséesProjet mobile et méthode Agile : 2 questions fréquemment posées

La méthode Agile offre de grands avantages pour les développeurs d'applications mobiles, on l'a vu dans les articles précédents de cette série consacrée à l'agilité (cf "Appli mobile et Agilité : la méthode Agile expliquée à ma mère").

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.

 

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.

 

Projet mobile et méthode Agile : 2 questions fréquemment posées
Projet mobile et méthode Agile : changer d'avis, c'est possible... dans un certain cadre

 

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, 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.

 

Pour en savoir + :

 

Vous avez un projet de développement d'application mobile ? N’hésitez pas à nous contacter.