On vu dans les précédentes publications, le développement d’application et les interactions entre les individus.
Mais comme vous le savez tous, on peut avoir de millions de projets, mais si on a aucun client pour payer le développement, on ne fera pas longtemps du développement.
Comme il faut un client, il faut donc communiquer avec.. ! et les puristes.. Diront qu’on va aussi avoir besoin de contrat pour définir les limites du projet.
Vous avez tous raison, mais tout comme précédemment, je vais ressortir ma phrase fétiche, il faut repenser les concepts différemment.
Le contrat doit est un cadre de fonctionnement pas seulement un carcan immuable. Ce que tout client veut, c’est avoir un logiciel fonctionnel et surtout un logiciel qui résout son problème.
Mais comme personne d’entre vous n’a de véritable habileté de devins, est-ce qu’on peut croire qu’on peut écrire toutes les limites d’un projet informatique. Pour ma part, je ne le crois pas .. !
A l’inverse, il ne faut pas travailler sans contrat non plus, sans carde qui régit le projet. Mais à défaut de le fixé dans le béton, il faut peut-être trouver une approche qui nous permettra de faire évolué, lorsque nécessaire l’enveloppe budgétaire.
Ce que beaucoup de gens-conseil, et que je recommande aussi, c’est de définir un cadre d’évaluation (du genre "Planning Poker") les taches en mode unité, des unités très petites. Chacune de ses unités correspondra à une valeur monétaire. Par conséquent, il sera plus facile d’évaluer la complexité.
En structurant ce cadre, il ne faut pas oublier de dire un gros merci à notre client en lui disant que n’on allait pas que le revoir qu’en fin du projet. Tout comme pour les interactions entre les membres du projet, le client doit aussi faire partie de l’équipe.
Il doit dans la mesure du possible être accessible, ou la limite son représentant. Tous les membres de l’équipe doivent pouvoir y avoir accès. Une réponse rapide et efficace du client est un avantage.
Une organisation que j’ai connue, avait choisi d’impliquer le client en l’installer dans les mêmes locaux que l’équipe de développement. Le client avait son bureau dans la même salle, ce qui permettait aux membres d’y avoir accès rapidement et inversement.
Je dirais bravo, c’est une bonne idée, mais il faut trouver dans votre contexte la meilleure manière de l’impliqué le client, c’est de la trouver. Ce n’est pas tout les clients et les organisations qui peuvent se permettre de libérer le client pour l’installer au sein de l’équipe de développement.
Les méthodologies agiles, ce n’est pas une liste de recette magique, seulement des moyens pour résoudre tous les problèmes, mais aussi une manière de réfléchir différemment.
La solution que moi, je propose toujours à mes clients, c’est simplement de leurs dirent. Quand tu as 2 minutes, et que tu as le gout de voir où en est rendu. « Passe me voir, et je te promets que je vais essayer de prendre le temps de te le montrer. Mais, tout comme vous (le client), il pourrait arriver momentanément que j’ai une urgence à répondre, et dans ce cas-si, que je ne puisse pas répondre immédiatement à votre besoin. »
Généralement, mes clients étaient toujours heureux d’avoir la possibilité de venir me voir sans avoir peur de me déranger. Car, il le savait, que si je ne pouvais pas leur répond dans l’instant, je leur reviendrais rapidement.
Reporter une petite rencontre à l’improviste, il ne faut le faire avec discernement et intelligence. Mettez-vous dans la peau du client, si à chaque fois qu’il vient vous voir, vous lui répondez que vous n’avez pas de temps. Il ne reviendra plus !
Il est aussi permis, de gentiment demander à un client de vous laisser le temps pour travailler, lorsque celui-ci utilise un peu trop ce privilège.
En impliquant le client, en lui donnant l’importance qu’il mérite, nous aurons l’information, cette information tant recherchée.
De plus, en effectuant le développement en par petite phase comme expliqué dans un autre article. Le client sera beaucoup plus ouvert. Il faut bien sur lui expliquer que nous ne voulons pas un bar ouvert sur le budget de sa part. Et aussi, qu’il n’a pas non plus le bar ouvert sur les fonctionnalités incluses dans son logiciel.
Un client qui comprend qu’il y a un cout, un temps et un effort nécessaire pour tous tâches, et surtout que le tout régit dans notre cadre.
S’acharner dans discussion contractuelle avec un client, ce n’est pas profitable à personne. N’oublions pas notre but, tant celui de l’équipe de développement que celui du client, c’est de produire un logiciel qui fonctionne et surtout, qui correspond au besoin du client.
Travailler en agile, en méthodologie agile, c’est aussi faire un peut d’évangélisation. Il faut prendre le temps, d’expliquer pourquoi et comment on fait les choses, avec le temps, il y aura plus de gens qui seront convaincus.
Je crois que tout client avec qui on aura réussi, sera le premier à promouvoir cette nouvelle approche.
Être, agile ce n’est pas de changer les choses, c’est de penser différemment !
Principe de compression des données en mémoire de Prometheus
Il y a 4 jours
Aucun commentaire:
Enregistrer un commentaire