Agile: La création de produits minimum


Auto

Produit minimum

Vous avez peut-être reconnu l’image en début d’article. Elle circule beaucoup en ce moment sur Linkedin dans les gestionnaires de projet. C’est une image très simpliste, mais qui explique parfaitement la vision d’un développement Agile. Alors, au lieu de simplement partager cette image (trop tard, je l’avais partagé avant d’écrire cet article, mais bon), j’ai décidé d’écrire un texte complet en lien avec elle.

Analyse de l’image

Commençons par décortiquer cette image. Il y a 2 projets pour construire une voiture.

La première, qui se rapproche de la gestion de projet traditionnel. Donc le client demande une voiture, alors on fait une voiture en 4 étapes. Rapide et on va direct au but et on espère que le produit final est bien ce que demande le client. On utilise des techniques pour s’assurer de bien comprendre le client dès le départ et que le client sache bien ce qu’il désire. On optimise du mieux qu’on peut le projet pour terminer le plus rapidement possible le produit demandé. Entre temps, le client ne comprend rien et ne revoie que des promesses.

Le 2e projet est un exemple de développement qui va toujours donner un minimum utilisable par le client. Ceci se rapproche drôlement de la mentalité d’un développement Agile. Donc le client nous demande toujours la même voiture. Dès qu’on a le mandat, on peut commencer immédiatement le projet en faisant un premier jet qui sera très loin du produit final. Ensuite, on peut immédiatement présenter au client et le client pourrait même déjà utiliser le produit. Ensuite, on raffine de plus en plus et à chaque itération on se rapproche de plus en plus de ce que le client désire. On remarque immédiatement qu’il y a une étape de plus, puisque oui, c’est un développement plus long.

Pourquoi créer un minimum de produit

Je crois bien que cette question, plusieurs se la posent. Puisque pourquoi ralonger un projet, si ce n’est que de donner des versions que le client n’a pas demandé ? Cette question se répond avec mon analyse du premier projet: « On utilise des techniques pour s’assurer de bien comprendre le client dès le départ et que le client sache bien ce qu’il désire. On optimise du mieux qu’on peut le projet pour terminer le plus rapidement possible le produit demandé. Entre temps, le client comprend rien et ne revoie que des promesses.« . Puisque oui, c’est la différence. Quand le client ou le projet a beaucoup d’inconnu, que souvent même le client ne sache pas vraiment ce qu’il veut, ou encore, il y a une entité au dessus du client qui n’arrête pas de changer les requis. L’Agilité dans un projet est la clé de la réussite. Il faut être en mesure de présenter un produit utilisable par le client, qui n’est pas complet, mais qui permettra de mieux comprendre l’impact du produit qu’il a demandé. Puisque oui, tout développement a une répercussion. Combien d’histoire de  blocage d’une intégration j’ai entendu parlé. D’employé qui ont juste complètement refusé d’utiliser un produit qui a mal été présenté. Le développement minimum permet d’aider sur ce point. Les employés se sente participé au produit en étant incluant à chaque étape et pouvant aussi visualisé où le développement est rendu. Les utilisation peuvent ainsi donner leur opinion et leur suggestion. L’intégration des utilisateurs dans le développement est la clé, mais il faut toujours prendre en considération que des utilisation, ne sont pas tous des personne travaillant en TI. Donc pouvoir voir un produit est beaucoup plus accessible que de recevoir un meeting avec des powerpoint sur ce que ça devrait donner dans plusieurs mois.

Alors pourquoi ne pas toujours créer des produit minimum

Puisque c’est très long à concevoir. Si le client sait exactement ce qu’il désire et les requis ne change jamais, être Agile est juste une perte de temps. Mais pour être franc, est ce que ça arrive qu’un projet de change pas, à part sur des projets personnels? Je dois avoué, que je n’ai jamais vu ceci. Il y a toujours des changement, des requis non-dis que le client s’attendait de recevoir, mais n’en a jamais fait mention. Mais il arrive que l’Agilité, n’est pas toujours une source de réussite.

Conclusion

Je me base toujours sur mon historique avec le client. Est ce que les requis change avec le temps. Petit « hit » comme ça, si une équipe de Marketing est lié au projet, c’est une assurance qu’il vaut mieux être Agile et présenté des produits utilisable à chacune des présentation, même si le développement prend le double du temps requis.

Maxime Savard

Advertisements

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s