Les méthodologies traditionnelles : des limites et une résistance au changement

Transcription

1 Julien ALAMI Newsletter, spécial Agile Scrum, 2010 Une enquête réalisée par le Standish Group Study (2002) a montré que 2/3 des fonctions d un système d information sont rarement ou jamais utilisées, et qu uniquement 1/5 des fonctions sont toujours ou souvent utilisées par le métier. Donc, 2/3 des fonctions ayant exigé du temps et de l argent ne créent aucune valeur pour les affaires des entreprises. Pire encore, elles continuent leur chemin de gaspillage lors des opérations de maintenance et d évolution des systèmes. Comment peut-on arriver à ce type de paradoxe : accepter de consacrer du temps et de l argent à des fonctions que personne n utilise? Absence de priorisation basée sur le ROI entre les fonctions d un système est une des sources de cette aberration. Il faut dire aussi que les démarches traditionnelles adoptées pour construire les systèmes d information ne sont pas d une grande aide, bien au contraire, elles accentuent ce phénomène. Pour mettre fin à la spirale dépensière, des méthodologies alternatives ont vu le jour, comme la méthodologie Agile Scrum. Celle-ci a séduit un large public et des entreprises de renommée internationale, parmi lesquelles : Yahoo, Microsoft, Google, Motorola, SAP, Cisco, Lockheed Martin, GE Medical, Capilal One, FED (Réserve Fédérale Américaine), etc. Avec un numéro spécial consacré entièrement à Agile Scrum, nous avons voulu vous faire découvrir une autre voie pour ne construire que les fonctions dont vous avez réellement besoin. Bonne lecture Les méthodologies traditionnelles : des limites et une résistance au changement La méthodologie traditionnelle adoptée sur un grand nombre de projets de systèmes d information représente une cascade d étapes, dont la plus connue est la méthode cycle en V. Celle-ci commence par une phase de planification, de conception et de documentation très détaillée. Ensuite, arrive le développement, les tests, la validation et le cycle se clôture avec la mise en exploitation du système final. Cette méthodologie trouve son avantage dans sa suprême logique, son sens rationnel : il faut tout penser avant de construire, écrire tout, suivre un plan détaillé de réalisation. Mais elle accorde très peu d importance à l aspect gouvernance des projets, au facteur humain et à la priorisation des fonctions. Toutes les fonctions sont traitées avec le même niveau de priorité, quelques soient leurs ROI. De plus, elle exige un ensemble de facteurs clés de succès difficiles à faire réunir avant le démarrage d un projet, exemple : les bonnes idées doivent être identifiées préalablement au démarrage de tout projet ; l entreprise doit être capable de prévoir le futur avec précision, y compris les changements économiques et les imprévus métiers comme technologiques ; les responsables de projet doivent planifier les tâches incertaines avec exactitude. julien.alami@kenarthurgroup.com Mobile : Page : 1

2 Cependant, la réalité des entreprises est différente : l environnement économique est soumis à des changements réguliers, les bonnes idées peuvent arriver après un certain temps, les projets sont souvent confrontés aux imprévus techniques ou métiers et la planification de l incertain reste une tâche difficile à mener Autant de facteurs sources de changement que les méthodes traditionnelles ignorent. Des limites qui pénalisent fortement les projets des entreprises. De plus, une enquête de Standish Group (1994) a montré que 85% des projets menés selon les méthodes traditionnelles ont échoué. Ce sont ces terribles constats qui ont fait émerger la méthodologie Agile Scrum. SCRUM, terme anglais emprunté au sport de Rugby signifiant la Mêlée. SCRUM est apparue pour la première fois dans une étude réalisée par Takeuchi et Nonaka qui s intitule «The New New Product Development Game», publiée dans Harvard Business Review en Deux enquêtes de Standish Group sur les projets de systèmes d information : : - Taux de succès est de 15 % - Taux de dépassement en argent et en temps : 170 % : - Taux de succès est de 34 % - Taux de dépassement en argent et en temps : 70 % Une premiere raison d amélioration du taux de réussite est liée à la taille des projets. Ceux-ci sont devenus plus petit Méthodologie Agile SCRUM une réponse aux limites des approches traditionnelles de type cycle en V. SCRUM, une méthodologie expérimentale développée et formalisée par Jeff Sutherland et Ken Schwaber au début des année 95, marquant le lancement formel des approches Agiles. Caractérisée par un cadre de gouvernance simple, favorisant la rapidité dans la prise des décisions, la transparence dans le déroulement des actions et l épanouissement des équipes. L esprit fondateur de la démarche est la construction progressive du produit cible en commençant par les fonctionnalités à fort retour sur investissement (ROI), pour s assurer au fil de l eau de sa qualité, de sa cohérence avec les besoins de l entreprise, tout en prenant en compte les imprévus techniques, les évolutions du périmètre et les mutations du marché. Un cadre de gouvernance articulé autour de 3 piliers, qui sont agencés et ordonnés dans un processus itératif Le cadre d Agile Scrum est portée par 3 piliers structurant la gouvernance de fonctionnement de la méthodologie : 1- Rôles ; 2- Communication & suivi ; 3- Instances. Ce cadre vise à favoriser la transparence sur les projets, à remédier aux lenteurs dans la prise de décision, et à accroitre la motivation des équipes et le travail collaboratif. julien.alami@kenarthurgroup.com Mobile : Page : 2

3 Reste à faire en point I. Rôles : Ce pilier définit les rôles fondamentaux nécessaires au bon fonctionnement de la méthodologie Agile Scrum, qui sont du nombre de trois : Product Owner, Equipe, Scrum Master 1- PRODUCT OWNER Il est le maitre d ouvrage du produit. Il connaît la finalité, les objectifs et les priorités du produit à réaliser. Le Product Owner est comptable des gains et des pertes envers le management de l entreprise. Le Product Owner n est pas un sponsor, c est un acteur engagé dans le projet et peut se faire assister des experts pour apporter des réponses ou des précisions à l équipe projet. Il est chargé de prioriser chaque demande figurant dans la liste de produit à réaliser (Product Backlog) sur la base du ROI. 2- EQUIPE Elle réalise le produit final. Elle est multi-compétences et comprend toutes les expertises nécessaires pour mener à bien sa mission. L équipe forme un bloc solidaire pour favoriser à la fois la montée en compétence de ses membres et le travail collectif. Il n existe aucune hiérarchie entre les membres de l équipe. 3- SCRUM MASTER Il est le pivot de la méthode Agile Scrum. Il doit aider le management, l équipe et le Product Owner à s approprier les principes de la méthode Agile Scrum. Il rend visible les difficultés et les obstacles rencontrés par l équipe et le Product Owner, et mobilisera les acteurs concernés pour les résoudre dans les plus brefs délais. Il doit protéger l équipe contre les sollicitations retardant le déroulement des travaux. II. Suivi & communication : Ce pilier présente les outils indispensables pour assurer un suivi rigueur et une communication efficace envers le management. Il a une finalité triple : (i) donner de la visibilité sur la totalité des travaux à réaliser et en cours de réalisation ; (ii) suivre au jour le jour la productivité de l équipe, et enfin (iii) identifier les obstacles et les difficultés bloquant les travaux. 1- PRODUCT BACKLOG 2- SPRINT BACKLOG Une liste de l ensemble des demandes à réaliser par l équipe projet : fonctions, programmes, installation des équipements, matériels et logiciels, etc. Elle est alimentée par les utilisateurs finaux, le management, le métier, la DSI, l équipe Cette liste est unique pour le projet et sous la responsabilité du Product Owner. Celui-ci affecte une priorité à chaque demande de la liste en fonction de son ROI pour l entreprise. Les travaux seront réalisés par l équipe dans l ordre des priorités fixées par le Product Owner. Le Product Owner peut regrouper un ensemble de fonctions dans des versions appelées Release Backlog. Liste des tâches à réaliser par l équipe durant l itération «le Sprint». Elle est alimentée uniquement par l équipe sur la base des fonctionnalistes convenus avec le Product Owner. Durant une itération aucune modification des fonctionnalités convenues avec le Product Owner n est permise. 3- BURNDOWN CHART C est un outil de suivi sous forme graphique montrant le réalisé et le reste à faire. Il existe deux types de Burndown Chart : 1. Sprint Burndown Chart assure un suivi des efforts accomplis pendant le Sprint. Il est mis à jour quotidiennement après la réunion «Daily Scrum». 2. Backlog Burndown Chart donne l avancement des efforts et le reste à faire pour finaliser le produit. Il est actualisé à la fin d un sprint BurnDown Chart Sprint 4- IMPEDIMENT LIST Cette liste regroupe tous les obstacles et difficultés que rencontrent l équipe et le Product Owner pour accomplir leurs missions. Elle est visible de tout le monde. Quelques exemples d obstacles que l on rencontre souvent sur les projets : Manque d implication du métier, absence du soutien des sponsors, dépendance en personnel clé, trop de discussion sans action, faible couverture de test, manque de priorisation dans les tâches et les fonctions,. julien.alami@kenarthurgroup.com Mobile : Page : 3

4 III. Instances : Ce pilier précise le rôle et les objectifs de chaque comité de rencontre entre les différents acteurs pour planifier les travaux, préciser les priorités des tâches, suivre l avancement des travaux, identifier les points de blocage, valider les travaux finis, faire une revue d amélioration 1- SPRINT PLANNING Réunion de planification qui se déroule au début de chaque itération «Sprint» et se divise en deux parties : Partie 1 : Etape de qualification des fonctionnalités de la Product Backlog candidates à l itération. Elle se tient entre l équipe, le Product Owner et le ScrumMaster. Elle permet de prendre connaissance des intentions et préoccupations du Product Owner dans le but de bâtir un produit en adéquation avec les besoins du métier. Partie 2 : Une rencontre entre l équipe et le ScrumMaster pour étudier dans le détail les fonctionnalités sélectionnées pour le Sprint. Celles-ci peuvent être décomposées en tâche, si nécessaire. L équipe estime donc le temps de réalisation de chaque tâche et alimente le «Sprint Backlog» selon l ordre convenu avec le Product Owner. 2- DAILY SCRUM Réunion de suivi quotidienne entre l équipe et le ScrumMaster, d une durée de 15 minutes. Chaque membre de l équipe doit répondre à 3 questions, pas plus : (i) ce que j ai fait hier? (ii) ce que je vais faire aujourd hui? (iii) Mes problèmes actuellement? A la fin de la réunion, on réactualise les suivis (Sprint Backlog, Burndown chart, Impediment list) pour rendre visible l avancement des travaux, les difficultés rencontrées et les efforts accomplis par l équipe. 3- SPRINT REVIEW 4- RETRO SPECTIVE Une réunion qui se tient à la fin du Sprint durant laquelle l équipe présente le produit réalisé pendant l itération. Elle est présidée par le Product Owner qui acte les fonctions finalisées de la Product Backlog et détermine avec l équipe et le management l objectif du prochain «Sprint» Sont présents à cette réunion, l équipe, le Product Owner, le Scrum Master, le management, le client et toute autre personne. Cette réunion dure maximum 4 heures Une réunion entre l équipe et le Scrum Master et présidée par ce dernier. Elle a lieu juste après la réunion de «Sprint Review». Durant cette réunion, l équipe entame une revue auto-critique : les points positifs de fonctionnement sur lesquels l équipe doit capitaliser ; les points négatifs qu il faut améliorer et comment les améliorer ; les points à éviter et à ne jamais reproduire Julien ALAMI et Jeff SUTHERLAND (Co-fondateur de la méthode Agile Scrum) Le Product Owner est le seul responsable de la Product Backlog Les demandes de la Product Backlog doivent être priorisées sur la base du ROI Aucune tâche du sprint Backlog ne doit dépasser 2 jours (16 heures) La réalisation doit porter en priorité sur les demandes ayant le ROI le plus élevé Un sprint ne doit jamais être prolongé au-delà du délai fixé julien.alami@kenarthurgroup.com Mobile : Page : 4

5 Processus Scrum, un processus itératif pour limiter les effets tunnels et donner de la visibilité en rapport avec la réalité des travaux Le processus Scrum a été structuré pour limiter les effets du tunnel qui sont sources de gaspillage de temps et de l argent et caractérisant les méthodes traditionnelles. De ce fait, ces étapes sont cadrées pour : (i) donner une visibilité précise et conforme à la réalité sur le déroulement des travaux, (ii) permettre la prise de décision juste à temps pour éliminer les points de blocage et corriger les dysfonctionnements, (iii) réorienter les efforts vers le plus utile. Le processus Scrum débute par l établissement de la Product Backlog qui regroupe l ensemble des demandes sur le projet. Le Product Owner fixe les priorités de chaque demande sur la base du ROI et maintient celle-ci à jour pour refléter l évolution des besoins. Ensuite, les demandes de la Product Backlog sont ordonnées en priorité décroissante. Avant de lancer le Sprint (itération), a lieu une réunion de planification de Sprint qui se déroule en deux étapes : Etape 1 : l équipe, ScrumMaster et le Product Owner revoient les demandes de priorité supérieure à réaliser durant le sprint, échangent sur l objectif et le contexte de ces demandes et se mettent d accord sur la notion de «travail terminé» Etape 2 : l équipe se concentre à détailler les demandes, à les transformer en tâches à réaliser durant le sprint et à estimer la durée de réalisation de chaque tâche. Le sprint (itération), une étape de traitement des demandes convenues avec le Product Owner et rien que ces demandes. Il dure entre 1 et 4 semaines et aucune modification de son but n est permise. Le Sprint n est jamais prolongé au-delà de la durée fixée au départ, bien que l engagement ne soit pas tenu dans sa totalité. Durant le sprint une réunion quotidienne a lieu pour faire un point sur l avancement des travaux et des éventuels obstacles. A la fin du Sprint, l équipe montre les travaux réalisés aux parties concernées, les utilisateurs, le management et toute autre personne lors de la «réunion de revue de Sprint» Celle-ci sera suivie d une autre réunion dite «Sprint Rétrospective» durant laquelle l équipe entame une revue auto-critique : ce qui a bien marché, ce qui pourrait mieux marcher, ce qu il ne faut jamais faire. Après la réunion «Rétrospective» un autre cycle redémarre en intégrant les points d amélioration convenus. julien.alami@kenarthurgroup.com Mobile : Page : 5

6 Les bénéfices que les entreprises peuvent en tirer à travers l utilisation de la méthodologie Scrum : Productivité, Time-to-market, Qualité, optimisation des coûts La méthodologie Agile Scrum est dans les moyens de toute entreprise, petite ou grande et adresse tout domaine d activité. Elle a fait ses preuves sur des projets de systèmes d information et d organisation et a été adoptée par des grandes entreprises, comme Microsoft, Google, Yahoo, etc.. Les entreprises qui l on adoptée ont tiré de grands bénéfices comme en témoigne une enquête de VERSIONONE dite «State of Agile Development Survey» auprès de 3061 entreprises dans 80 pays. Cette enquête a montré que ces entreprises ont : 1. accru la productivité sur des projets SI de 89% 2. accéléré le Time-to-Market de 83% 3. ont réduit le nombre d anomalies de 84% 4. ont optimisé leurs coûts de 65% Nous venons de passer en revue les principes de la méthodologie Agile Scrum qui sont du vécu opérationnel et de retour d expérience. Ceux-ci sont caractérisés par un pragmatisme visant, en priorité, à produire de la valeur sur les projets, à donner de la visibilité sur leurs déroulements, à corriger en permanance les dysfonctionnements rencontrés et à prioriser les tâches sur la base du ROI. Du bon sens dont la seule motivation est de construire des outils créateur de valeur pour les entreprises et de stopper les gaspillages en temps et en argent. Références : - Microsoft - Google - Yahoo - FED - Motorola - SAP - Cisco - GE Médical -. Domaine d utilisation de Scrum : - Systèmes d information - Projets d organisation - Marketing - Commercial / Vente - Recherche & Développement AGILE SCRUM Les principes de Toyota : - Respecte tes collaborateurs, respecte tes clients, respecte tes partenaires - Des processus efficaces menés par des gens simples Sources : 1- Graphique 1 : Standish Group Study Reported at XP2002 by Jim Johnson, Chairman 2- Taux de réussite des projet IT : a. b. julien.alami@kenarthurgroup.com Mobile : Page : 6