chevron-bottomchevron-leftchevron-rightdownloadfacebookinstagramlink-outlinkedinminusplus
Accessibilité Tous les articles

Waterfall vs agile: Quelle est la différence dans un projet BI?

Catégorie

Agilité

Publication

Mai 2014

Publié par

Marc-Denis Léger

Comme vous le savez, l'agilité a gagné en popularité depuis quelques années. Il va s'en dire qu'il y a plusieurs différences entre la gestion agile de la livraison et la gestion de projets Waterfall. Il existe, entre autres, plusieurs paradigmes dans les organisations qui n'ont connu que la gestion dite traditionnelle des projets. Tentons de changer ces façons de faire en rappelant les piliers de l'agilité.

En résumé, dans une structure "conventionnelle" de gestion de projets, habituellement, il y a un ou des besoins initiaux: le client, un gestionnaire de projets et une équipe de développement. Bien souvent, le gestionnaire de projets scinde le travail et le distribue aux membres de l'équipe de développement. Ces personnes ont des tâches précises afin que, quelques mois plus tard, le projet soit livré et présenté au client.

En mode agile, les choses se passent très différemment. Premièrement, il n'y a pas de gestionnaire de projets! C'est l'équipe de réalisation qui, avec l'aide du client (product owner), découpe le travail à accomplir en plusieurs itérations pour finalement livrer la solution. C'est une façon très différente de travailler, vous ne trouvez pas?

J'ai pris part personnellement à plusieurs projets agile et je crois ardemment que le succès de cette approche repose sur les trois piliers de la méthodologie agile-scrum.

Voici pourquoi:


1-La transparence de l’équipe agile

Cet aspect est évidemment très important car il permet, notamment, de souder et de solidifier la confiance entre le client et l'équipe de travail. Quoi de plus facile, car le product owner fait quotidiennement partie des rencontres de statut (daily scrum) pour discuter de l'avancement du sprint en cours.

De plus, comme le projet est découpé en petits livrables de deux à quatre semaines et que l'équipe de réalisation se commet à la livraison de cet incrément, il n'y a pas de place à la cachotterie. S'il y a des roadblocks, ces derniers sont communiqués très tôt au scrum master et au product owner.


2-La planification et l’inspection du projet agile

Une autre valeur essentielle de la méthodologie agile-scrum est l'inspection. Lorsqu'on livre un incrément toutes les deux semaines, par exemple, le rythme est assez soutenu. Plusieurs étapes permettent de prendre un pas de recul lors du développement agile. En premier, il y a les sprint planning. Au début de chaque itération, cette rencontre sert non seulement à planifier la prochaine livraison, mais aussi discuter en équipe des actions à prendre en fonction de la réalité du projet. Ensuite, viennent les daily scrum. Finalement, à la fin de chaque sprint, il y a la rétrospective, c'est-à-dire l'étape ayant pour objectif d'améliorer constamment les façons de faire de l'équipe ainsi que les interactions entre ses membres.


3-La flexibilité et l’adaptation à l’agilité

Finalement, l'adaptation est, selon moi, le plus grand avantage de cette méthode. Comme le client (product owner) fait partie intégrante de chacune des étapes du processus de livraison, il est beaucoup plus facile pour l'équipe d'adapter le backlog afin de refléter la réalité d'affaires et ce, en cours de projet. En plus, tel que mentionné dans les 2 étapes précédentes, les occasions de se rencontrer et de discuter ne manquent pas. Cela favorise donc les échanges pour livrer une solution qui répond entièrement aux besoins de l'organisation.

Pour conclure, ayant vécu les deux méthodes de livraison des projets d'intelligence d'affaires, il m'est possible d'affirmer qu'il est plus facile d'adapter les livraisons à la réalité d'affaires lorsque la méthodologie agile-scrum est utilisée. C'est d'autant plus vrai lorsqu'on accompagne l'organisation dans un premier projet d'intelligence d'affaires. Souvent, le client n'a pas une idée précise de ses besoins. Il devient donc essentiel de pouvoir adapter la solution au fur et à mesure.

Avez-vous déjà vécu des projets qui auraient nécessité un changement d'orientation en plein milieu de projets?

Restez à l’affût des dernières tendances analytiques