Méthode Agile, SCRUM, c’est quoi ?

La méthode Agile, c’est quoi ?
Cette méthode est une théorie pour gérer vos projets. Elle est largement mise en avant à travers le produit de Microsoft : Team Foundation Server 2010.
Pour y voir plus clair avec cette méthode, il faut tout d’abord faire le point sur les méthodes et plus précisément sur les théories passées…

Un peu d’histoire ?

L’organisation des tâches avec la notion de temps apparaît avec Henry Gantt (1861–1919); Il avait étudié de manière approfondie l’ordre des opérations dans le travail. Il a axé son analyse de la gestion sur la construction navale pendant la première guerre mondiale.
Pendant la Deuxième guerre mondiale, des projets gouvernementaux et militaires complexes alliés à une offre de main-d’œuvre réduite en temps de guerre ont nécessité une réorganisation des structures. C’est à cette époque que furent créés les organigrammes montrant les relations entre les tâches de projet. Puis est apparu le PERT (Program, Evaluation, and Review Technique) qui permet d’évaluer un résultat probable.
Ce n’est qu’au début des années 1990 que l’on a ajouté des lignes de liaison vers ces barres de tâches, représentant ainsi des dépendances plus précises. Il paraît que c’est project de Microsoft.

La méthode en cascade.

C’est une méthode très cartésienne : Finissez la première étape pour passer à la seconde. Ce qui est vrai 😉
Par contre il faut largement anticiper les temps car l’analyse et la réalisation sont liées. Bref à la troisième étape ou la quatrième, vous risquez de refaire la première. Oups !

Malheureusement, c’est souvent cette “méthode” qui est utilisée dans les développements. On fait un premier prototype, qui devient une version montrable, donc vendable . Et puis on ajoute des morceaux jusqu’à avoir un bon gros produit… Jusqu’à que l’on décide de le réécrire.

Le cycle en V.

Ce cycle de suivi de projets date des années 1980 et encore très actuelle dans de nombreuses sociétés. En fait c’est un doux rêve. Prendre le temps de faire l’analyse, les pacifications jusqu’aux tests et à la recette.

Dans cette approche, que vous avez tous vus, il faut définir précisément le projet, ses étapes pour qu’à chacune des étapes on puisse contrôler par rapport à la théorie correspondante.
Dans le cas où on arrive à cette situation, c’est un idéal.
Mais pour y arriver il faut pouvoir isoler des ressources pour faire l’analyse et les spécifications. Puis définir les ressources qui vont réaliser. A chaque point d’avancement, vous faite le point avec les spécifications. si nécessaire, vous reprenez. A la fin, vous avez exactement ce que vous aviez prévu.
Avec cette méthode en V, vous avez la nécessité d’anticiper et de préparer dans les étapes descendantes les « attendus » des futures étapes montantes.
On ajoutera à ces deux grandes approches des projets, la spirale, l’itératif et toutes les combinaisons entre elles. Je ne rentrerai pas plus en détail ici.

Aujourd’hui, les principes de base de la gestion de projet sont représentés par le triangle du projet (triangle de projet : relation existant entre les éléments temps, argent et objectif. L’ajustement de l’un de ces trois facteurs a des répercussions sur les deux autres. Par exemple, si vous ajustez le plan de projet pour réduire les prévisions, vous risquez d’accroître les coûts et de faire baisser l’objectif.), un symbole rendu populaire par Harold Kerzner.

La méthode Agile et SCRUM.

Et voilà la méthode Agile. Ce qui change en premier lieu des autres méthodes est l’approche qui est axée sur le besoin du client. A l’opposé des méthodes que j’ai pu vous décrire précédemment, disciplinées, structurées et exigeantes sur la gestion de projet. La méthode Agile est reconnue pour être plus efficaces dans le cadre de projets complexes et fluctuants.

“Agile” est apparu en 1996 et validée en 2001 lors d’une réunion des gurus de ce type de méthode qui ont, à cette occasion, posé les grand principes de leur démarche et ont trouvé ce terme pour la désigner.

On parle le la méthode Agile mais en vérité ce sont des méthodes Agiles. Elles s’appliquent à divers types de projets. Les deux méthodes Agiles les plus connues en France sont : la méthode Scrum (1996) et la méthode XP, pour Extreme programming (1999).

Scrum dans la méthode agile ce sont 4 valeurs fondamentales  : L’équipe , l’application, la collaboration, l’acceptation du changement.

Agile, c’est une approche un peu plus “japonaise” du besoin. Dans un monde occidental, on cherche à produire avant de se préoccuper de le vendre.  L’approche japonaise et de produire un produit correspondant aux besoins et au prix du marché ! Et s’il n’est pas encore complet, on vendra la prochaine version. Au fait, ce n’est pas ce qui se passe avec la téléphonie ?

Donc pour revenir à Agile, je vais aborder la méthode “scrum” de Agile. Scrum définit un jeu minimal d’intervenants en vue de relever les principaux défis du projet de façon itérative : la planification, la gestion du temps et la gestion des obstacles. L’approche est de définir un besoin. Ce besoin peut être interne ou externe mais c’est à vous de le gérer ! Les règles sont simples mais strictes :

• La durée du projet est découpée en itérations courtes. Entre 0,25 et 2 ou 3 semaines suivant le projet. Une itération contient qu’une partie de l’application, complète ( développée et testée) .
• Une réunion initiale commence chaque itération pour définir les tâches. Qui fait quoi, comment, avec quoi. Les itérations doivent être claires pour tous les participants.
• Chaque jour, une courte réunion de 5 minutes maxi permet à toute l’équipe d’avoir une vue globale du projet : de savoir ce qui s’y passe et comment ça se passe. C’est le moment de faire remonter un problème. Si problème il y a avait, ce sera à ajouter à l’itération suivante ou a modifier une caractéristique du projet. Par exemple, une fonction ne sera pas mise dans la version; Ce sera peut-être ajouté à la prochaine.
• Une réunion finale présente une démonstration de ce qui est fait avec ce qui s’est bien passé ou pas.
• Parallèlement à cela, des tableaux de bords sont régulièrement générés pour avoir une vue réelle de l’avancement.

En tant que chef du projet,vous organisez, pilotez. Vous faites tout pour que tout fonctionne correctement et que l’équipe puisse réaliser ses tâches sereinement. suivant la structure vous définissez aussi les priorités et les fonctionnalités que doit remplir l’application. Mais parfois, c’est une autre personne ou en tous les cas avec les équipes commerciales par exemple.

Prenons par exemple qu’un client veuille une application assez simple : Un bouton qui quand on clic dessus fait apparaître un message “hello word” et l’application se ferme.
Voilà un projet complexe, je vous l’accorde 😉

Avec cette méthode Agile, on va créer un environnement de travail correspondant à ce projet. Puis dans cet environnement, on va définir les grandes lignes : On fera une itération par ligne dans cet exemple simpliste.

• Créer une interface avec un bouton
• Créer un message, l’afficher
• Fermer une application

Puis on planifie ces tâches à des personnes. Avec une date de début,et une durée maximale. Très important ce dernier élément.

Grâce à cette situation, vous allez déjà pouvoir évaluer un coût et faire une proposition à votre client avec un délai et un coût. Le coût est entre autre lié au prix de l’heure des intervenants et au bénéfice que vous comptez faire.
A cette étape, avec Team foundation server, vous pouvez même faire un lien vers des états issus de Reporting Service. Ces états peuvent être consultés par le client via un extranet afin de suivre l’avancement du projet.

Quoi qu’il en soit, vous avez donc une planification qui “se fait” avec des ressources, des dates et des durées.
Pour chaque itération, vous pouvez détailler; Quelle interface, quelle forme ? Modale pas modale, etc. Mais cela ne devra pas repousser les délais. Cela permettra de définir une ou des tâches limpides pour les intervenants.

Dès que le projet commence, vous devez suivre au jour le jour l’avancement avec les intervenants. Pas des heures évidement mais 5 minutes. Est-ce que l’on tient les délais de chaque tâche ? Est-ce qu’il y a des problèmes techniques ?

S’il y en a, à vous, en tant que responsable de projet de prendre la décision : On laisse, on passe à l’itération suivante ? Ou est-ce que l’on met plus de temps ?

Par exemple, les deux premières étapes se passent bien mais la troisième rencontre un problème : L’application ne se ferme pas comme on le voudrait : Si un antivirus est présent, il empêche la fermeture.

On va donc prendre la décision de stopper là l’étape et de terminer le projet. Dès l’apparition de cet écueil, vous allez prévenir le client : Si vous avez un antivirus, alors il vous faudra fermer manuellement. Les caractéristiques du produit seront alors de l’utiliser en modifiant les règles de l’antivirus. Pour fermer avec un antivirus il faut ajouter 2 jours au projet par exemple.

Vous avez donc bien rempli le contrat, dans les temps, avec une restriction d’utilisation parfaitement identifiée.

On pourrait discuter de long en large s’il faut le prévoir avant ou pas. Le plus intéressant de cette méthode est qu’elle permet de définir une relation gagnant gagnant avec des étapes précises et temporellement stables. Si on avait effectivement voulu le prévoir, on aurait ajouté une itération d’analyse qui déterminerait le contenu des itérations suivantes. Mais tout en définissant le temps et le rayon de recherche très précisément.

Pour revenir à Agile SCRUM, la méthode prend toute son ampleur si elle est exploitable de toute l’entreprise. Ainsi la notion de coût, de délais, de situation, de charge, de tests sont des éléments qui doivent être vus à tout moment.
Cela va permettre d’aborder des notions de seuil de prix, de capacité de charge, de tendance à la réalisation et de la qualité produite.

Par exemple, dans ce schéma, on peut avoir une vue de la charge par itération. Cette simple vue peut alors aider à prendre une décision suite à une absence d’un intervenant de prendre un intérimaire ou de donner une charge supplémentaire à un intervenant déjà dans le projet.

Dessous vous pouvez voir l’évolution entre les tâches terminées et celles restantes.

TFS et Agile

Un modèle de processus dans Team Foundation Server inclut les types d’élément de travail, requêtes, rapports et instructions textuelles. Les éléments de travail ne sont donc plus simplement des tâches mais ils peuvent être aussi un récit utilisateur, Bogue, problème, test. Vous pouvez créer votre propre type d’élément de travail ou personnaliser l’élément de travail particulier proprement dit.
TFS peut être “piloté” via Excel pour le suivi des temps par exemple mais aussi par Project.
Au delà du projet informatique cette méthode pourrait s’appliquer aux installations, à la maintenance, et pourquoi pas à la partie commercial.

Afin de vous laisser méditer sur la gestion des projets, je ne pouvais pas clore ce chapitre sans ce dessins que vous n’avez pas pu louper mais que je ne me lasse pas de revoir.