Discussion :

[myopus]

Bonjour à tous,

étant convaincu (mais aussi vaincu) des abbhérations du travail au forfait (besoins mal exprimés dans une démarche trop théorique pour le client, requêtes émergentes lors de réunions intermédiaires, etc...) je trouve que l'agilité est une façon rationnelle de satisfaire à la fois le client et le développeur.

D'une façon très grossière, j'y vois cependant deux écueils majeurs :

1 = la difficulté de présenter un budget au client, certains fils en parlent ici ou là, un peu comme si c'était une question secondaire ... pour ma part, et ne serait-ce que par cet aspect, je ne parviens pas (ou peu) à "vendre" de l'agilité.

2 = après avoir lu les deux excellents docs de Pascal Van Cauwenberghe
(agilefixedprice et fixedpriceprojets), je continue d'être convaincu que la mise en production rapide et le feedback du client n'apportent que de bonnes choses, aussi bien du point de vue du but à atteindre que de la confiance qui se créé entre le client et le développeur.
Mais quid du client qui est, comme souvent, organisé autour de procédures hétérogènes mais fonctionnelles, qui lui permettent de gérer au quotidien son activité (mal, il est vrai, puisqu'il fait appel à nous pour rationaliser l'ensemble).
Prenons le cas de cet entrepreneur qui est parvenu, au fil du temps, avec le tandem Word/Excel, et quelques applications satellites, à gérer l'intégralité de sa procédure commerciale, du prospect à la facturation. Que va-t-il faire de ma première livraison, quand cette dernière ne lui permet que de gérer ses prospects et leur historique, par exemple ? Va-t-il vraiment affecter une personne à l'utilisation "test" de ce premier module ?
A moins que ce premier module ne puisse être "temporairement" intégré à sa solution actuelle ?

Merci de m'avoir lu, toute expérience sur ces deux point sera la bienvenue..

Gilles

[nanomag]

Bonsoir,

Pour le point 2 :
Cela va dépendre il me semble de la méthode utilisée, si tu veux réellement appliquée au pied de la lettre une des méthodes agiles.
Pour ma part l'équipe, dans laquelle j'étais, appliquait un mix entre XP et scrum.

La première itération (développement réel et livraison) a toujours été plus longue que les suivantes, par exemple 3 semaines au lieu de 15 jours.

Une fois que les user stories ont été définies par le client puis estimées par l'équipe de dev, Le client va devoir choisir (avec l'aide du Chef de projet, si le client n'est pas très à l'aise avec le concept agile) quelles fonctionnalités sont prioritaires pour lui.

Ces fonctionnalités ou user stories sont "atomiques", les plus petites possibles. L'écueil, il me semble est d'avoir une fonctionnalité à livrer qui serait "gestion des prospects", c'est bien trop vague.

Il est bon de découper
1- je veux pouvoir créer un prospect
2- je veux modifier un prospect
3- je veux supprimer un prospect
4- je veux stocker des "contacts téléphoniques" avec un prospect (date, heure)
4-bis un contact telephonique peut avoir un objectif
4-ter je veux pouvoir saisir des notes pendant un contact téléphonique
5- importer un fichier csv de prospect
6- exporter en csv la liste des prospects
7- je veux saisir une commande
8- je veux imprimer une facture
9- je veux pouvoir modifier l'aspect graphique de ma facture

Lors de la 1ère livraison, il est tentant de vouloir regrouper par thème les prospects (histoire que le développeur reste concentré sur un aspect de l'appli). Mais ce n'est pas l'objectif.
L'objectif étant une livraison fonctionnelle

Il faut alors discuter pour voir ce qui est indispensable avec le client.
par exemple les points 3, 4bis, 4ter, 5, 6, 9 ne vont pas être indispensables au tout début.

le point 3, 4bis étant relativement importants, ils seront surement mis dans l'itération suivante.

Cela va laisser 3 semaines (ou 1 mois) au client pour réfléchir à la suite.
On peut laisser 1 semaine entre la livraison et la prochaine itération pour que le client prenne en main l'application et voit en conditions réelles ce qui lui manque le plus. il va peut-être se dire je veux plutôt le temps passé réel au téléphone, plutôt que les notes prises durant l'appel téléphonique.

S'il s'agit d'une migration d'un logiciel à un autre totalement différent, (pas d'intégration/interférence possible entre les 2 applications), tu peux demander au client de saisir pendant 1 heure ou 2 heures de la journée les infos dans les 2 applications (c'est sûr ça fait double travail, mais il peut comparer les résultats, l'interface, l'utilisabilité..)

Pour le point 1 c'est plus facile il me semble que le point 2.
tu vas estimer la durée des taches : (ici en points mais tu peux le faire en heures, en ce que tu veux...)
1- 20 pts
2- 30 pts
3- 10 pts
4- 30 pts
4bis 10 pts
4ter 15 pts
5- 40pts
6- 20 pts
7- 20 pts
8- 10 pts
9- 40 pts

Etant donné que tu livres des itérations courtes (15 jours). tu définis en 15 jours : je peux faire 100 points. (100 heures, 100 ce que tu veux...) ou 200 ou 300 selon la taille de ton équipe.

Si tes user stories sont etismées par ton équipe ou toi même, tu n'as plus qu'a dire à ton client, vous avez 100 points, choisissez les fonctionnalités que vous voulez et vous les aurez dans 15 jours.

On s'engage alors à faire les points : 1, 2, 4, 7 et 8 en 2 semaines !

L'une des principales force et faiblesse des méthodes agiles (en tout cas d'XP) est que le client doit être impliqué.

S'il n'est pas favorable à la méthode, ou s'il n'a pas compris l'importance de son implication tu vas droit dans le mur :
par exemple, sur un des projets on a quasiment été obligé de rédiger les user stories à la place du client. c'est le "comble", comme si on pouvait savoir mieux que lui ce dont il avait besoin !

Si au contraire, il est impliqué, il va y avoir du feedback sur chacune des livraisons, les user stories restantes vont évoluer au fur et à mesure de l'avancement du projet et du coup mieux s'orienter sur les besoins réels de ton client. au final, le produit sera efficace par rapport aux besoins (mais pas nécessairement aux besoins/fonctionnalités auxquelles on s'attendait au début

En espérant t'avoir éclairci tout ça

[hegros]

Bonsoir,

1 = la difficulté de présenter un budget au client, certains fils en parlent ici ou là, un peu comme si c'était une question secondaire ... pour ma part, et ne serait-ce que par cet aspect, je ne parviens pas (ou peu) à "vendre" de l'agilité.

C'est pourtant ce que vends SDMS, utilisé notamment par BNP, la méthode d'estimation fonctionne sur le principe qu'on estime (et donc s'engage)que sur la phase (ou en agilité l'itération) à venir le reste n'étant que projection il en va de même avec le budget même si d'autres couts comme ceux d'exploitation ou de maintenance ne sont pas pris en compte ou de façon secondaire..

Voilà je pense donc qu'avec l'agilité cela ne devrait pas changer ou apporter du plus puisque tu présenteras un budget précis pour l'itération planifiée avec des projections "standard" mise à jour en fin d'itération pour le reste à venir.


Il faudrait compter entre 3-5 itérations pour que le client, projet, l'équipe et la machine se mettent en marche.