6.1 Le mouvement Agile
L’Agilité est une méthode de développement logiciel née au début des années 1990 en réaction aux taux d’échecs des méthodes classiques trop rigides qui peinent à respecter le budget initial, les délais et les besoins des clients.
Les causes de ces échecs sont nombreuses :
- en amont : une définition des besoins et donc des fonctionnalités à développer mal établie, déclinées en tâches mal estimées et non priorisées ;
- au cours du processus de développement : un manque de communication, de collaboration et de transparence (tant envers le client qu’entre le directeur technique, les chefs de projet et les développeurs), un manque de flexibilité qui empêche d’intégrer tout changement et amélioration en cours de route ;
- en aval : un produit qui finalement ne correspond pas aux attentes de l’usager.
En réponse à ces difficultés, plusieurs figures éminentes du développement logiciel vont commencer à élaborer des méthodes plus « agiles » pour maximiser la valeur des produits proposés aux utilisateurs et accroître la satisfaction des développeurs. En 2001, 17 d’entre eux se rencontrent pour débattre des critères communs à leurs méthodes respectives, d’où sortira le « manifeste Agile » prônant 4 valeurs : - Les personnes et leurs interactions sont plus importantes que le processus et les outils ; - Un logiciel qui fonctionne prime sur la documentation ; - La collaboration avec le client est plus importante que le suivi d’un contrat ; - La réponse au changement passe avant le suivi du plan. Ces 4 valeurs se déclinent en 12 principes communs à toutes les méthodes agiles :
- Satisfaire le client en livrant tôt des logiciels utiles, qui offrent une véritable valeur ajoutée ;
- Accepter les changements, même tard dans le développement ; - Livrer fréquemment une application qui fonctionne ;
- Collaborer quotidiennement entre clients et développeurs ;
- Bâtir le projet autour de personnes motivées en leur fournissant environnement et support, et en leur faisant confiance ;
- Communiquer par des conversations en face à face ; - Mesurer la progression avec le logiciel qui fonctionne ; - Garder un rythme de travail durable ; - Rechercher l’excellence technique et la qualité de la conception ; - Laisser l’équipe s’auto‐organiser ; - Rechercher la simplicité (pragmatisme) ; - A intervalles réguliers, réfléchir aux moyens de devenir plus efficace.
L’Agilité peut se définir d’une manière plus condensée comme une « approche itérative et incrémentale pour le développement logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui produisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeants des utilisateurs » (définition proposée par Scott Ambler, développeur canadien officiant pour IBM).
L’Agilité se présente ainsi comme une « nouvelle culture de développement »26, une philosophie de gestion de projet logiciel moins lourde et bureaucratique qui peut se décliner en plusieurs méthodes dont les plus connues sont eXtreme Programming (clairement axée sur les pratiques d’ingénierie logicielle) et Scrum (dont la portée est plus large et peut s’appliquer à toute gestion de projet). C’est cette seconde méthodologie qu’a adoptée AgileCorp et qui est par ailleurs la plus répandue des méthodes Agiles.
6.2 La méthode Scrum
Le terme anglais « Scrum » signifie « mêlée » : cette méthodologie s’inspire des valeurs et de l’esprit du rugby pour les adapter aux projets de développement logiciel en promouvant la formation d’une équipe de développement multifonctionnelle et soudée dans l’atteinte d’un objectif précis (comme le « pack » lors d’un ballon porté au rugby) aiguillée par un Scrum Master (dont le rôle est similaire à celui d’un demi de mêlée) qui leur donne la direction et le tempo. La méthode Scrum peut « théoriquement s'appliquer à n'importe quel contexte ou groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de son principal promoteur Jeff Sutherland »27.
Comme toute méthode Agile, Scrum suit un processus incrémental (le produit est construit morceau par morceau qui viennent s’ajouter progressivement) et itératif (grâce à des
26 AUBRY, Claude (2010). SCRUM, le guide pratique de la méthode agile la plus populaire. Paris : Dunod, 267 pages. 27 http://fr.wikipedia.org/wiki/Scrum_(méthode)
rétroactions qui permettent de revenir sur ce qui a été fait dans une perspective d’amélioration continue).
La méthodologie Scrum déploie tout un arsenal d’outils et de « cérémonials » pour la gestion de projet logiciel, à l’origine d’un jargon technique assez complexe pour les néophytes qui peut toutefois se décomposer en quatre catégories :
‐ Des rôles (Product Owner, Scrum Master, Equipe, Stakeholders) ‐ Des blocs de temps (release, sprint)
‐ Des réunions, aussi appelées cérémonials (planification de release et de sprint, mêlée quotidienne, revue de sprint, rétrospective)
‐ Des artefacts (backlogs, plans, Burndown charts).
6.2.1 Les rôles
Le Product Owner
Le « Product Owner » (PO) est chargé de définir les objectifs et fonctionnalités du produit (qu’il précise dans une liste appelée « backlog de produit ») en fonction des besoins du client et des futurs utilisateurs. Il doit également s’assurer de partager sa vision avec les autres acteurs (ingénieurs, commerciaux, marketing) pour éviter les différences de définition.
La PO est donc responsable des décisions stratégiques en choisissant l’orientation générale du projet et prend également en charge des décisions tactiques en précisant l’ordre dans lequel les différentes parties du produit seront développées.
Ce titre est souvent traduit en français par « directeur de produit », le terme de « directeur » n’est cependant pas à prendre dans le sens hiérarchique du terme mais comme celui qui donne la direction : il n’a aucune responsabilité hiérarchique sur les personnes, il est chargé de donner une orientation au produit et prend ses décisions en accord avec l’équipe, le plus souvent possible au consensus. Dans cette perspective, il est présent tout au long du développement (par opposition aux projets classiques où le représentant des besoins du client n’intervient qu’au début et à la fin du processus).
Le Srum Master
Le « Scrum Master » (SM) accompagne l’implantation de la méthodologie Scrum dans l’organisation et plus particulièrement dans l’équipe de développement : il l’encadre le temps de la former à Scrum (il organise et anime les réunions entre autres), l’aide à progresser puis
l’encourage à devenir autonome. Le rôle du SM est ainsi centré sur les processus et l’organisation du travail, tandis que celui du PO est axé sur le produit.
Une fois l’équipe mature (c’est‐à‐dire quand elle a atteint un niveau d’auto‐organisation très élevé), le SM a principalement pour rôle de minimiser les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe (administratifs par exemple). Ce titre est ainsi parfois traduit par « facilitateur » ou même simplement « animateur » en français. Il est même possible d’envisager des équipes sans SM lorsqu’elles sont très petites et/ou très matures. La SM n’est donc pas un « chef de projet » dans la terminologie habituelle, ce rôle est tout simplement éliminé dans Scrum : une partie de ses attributions est dévolue au PO, l’autre étant déléguée à l’équipe elle‐même, encouragée à s’auto‐organiser.
L’équipe
L’une des caractéristiques forte de Scrum est ainsi l’auto‐organisation des équipes de développement. Ce principe signifie « que les membres de l’équipe s’organisent eux‐mêmes et n’ont pas besoin d’un chef qui leur assigne le travail à faire »28.
Cette auto‐organisation se manifeste par une collaboration et une communication intense entre les membres, favorisée par la petite taille de l’équipe (de 2 à 7 personnes).
Le principe d’auto‐organisation implique également une équipe « multifonctionnelle » qui concentre toutes les compétences nécessaires au développement du produit (contrairement aux méthodes de gestion de projets habituelles où les développeurs et testeurs sont scindés dans des équipes différentes).
Ainsi, il n’y a pas de rôles spécialisés et prédéfinis ni de hiérarchie interne : c’est l’équipe qui définit elle‐même la façon dont elle organise son travail, ce n’est ni le SM ni le PO.
Stakeholders
Les « Stakeholders » sont des intervenants externes qui souhaitent suivre l’avancement du produit sans pour autant s’investir dans sa réalisation : experts, directeurs techniques mais aussi clients.
Un autre principe fort de Scrum est en effet la participation du client dans le processus de développement : il peut à tout moment compléter ou modifier la liste des fonctionnalités à produire (à l’exception de celles qui sont en cours de réalisation pendant un sprint).
28 AUBRY, Claude (2010). SCRUM, le guide pratique de la méthode agile la plus populaire. Paris : Dunod, 267 pages, p 41‐