Soyons agiles — Approche pour les projets informatiques

@Pixabay

Depuis la création de uxShadow en 2016, nous avons travaillé dans des projets informatiques en cascade ou en agile (parfois un mixe des deux). Nous nous sommes rendus compte au fil des années que les chances de succès étaient liées au choix tourné vers l’approche agile. Pour nous c’est l’approche qu’on affectionne le plus (❤) et c’est pour cette raison qu’on souhaite vous la présenter.

Agile comme un félin ?

Oui, c’est une approche qui se caractérise par sa capacité à être souple, à s’adapter à tout moment du cycle de vie du projet et à produire rapidement des features et corrections constantes si nécessaires. Cela permet aussi de renforcer la cohésion et faciliter la communication entre les membres de l’équipe agile (Product owner, développeurs, designers).

…sauf que cette approche n’a jamais été innée dans le monde informatique.

Elle est apparue dans les années 1990, lorsque l’informatique a commencé à proliférer. Il y avait beaucoup de retard de livraison des applications car le développement devenait de plus en plus en plus complexe surtout dans les gros secteurs tels que l’aérospatiale, l’automobile… Les ingénieurs étaient frustrés des prises de décisions non modifiables prises en début de projet, et commençaient donc à discuter des moyens de développer des logiciels plus simplement, sans la surcharge du processus et de l’écriture de documentations populaires à l’époque. Les échanges ont abouti à la célèbre réunion Snowbirds dans l’Utah au début de 2001 où étaient présents dix-sept développeurs dont les plus connus : John Kern, Kent Beck et Ward Cunningham (pionniers de l’Extreme Programming), Arie van Bennekum, et Alistair Cockburn. C’est là que le manifeste agile est né, véritable tournant dans l’histoire de l’Agilité.

Les 4 valeurs et 12 principes de l’agilité

Ce manifeste énonce 4 valeurs clés (Lire ici le Manifeste agile). Il faut accorder de l’importance :

• Aux individus et leurs interactions plutôt qu’aux processus et aux outils ;
• à un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;
• à la collaboration avec les clients plutôt qu’à une stricte application d’une matrice de répartition des tâches
• à l’adaptation au changement plutôt qu’à l’exécution d’un plan qui devient caduc en cours de projet.

Le manifeste agile suit 12 principes qui sont :

• Satisfaire le client en priorité : Pour savoir si le client est satisfait il faut savoir l’intégrer dans le processus de développement, car travailler en cycles courts et avoir un chef de produit (PO) en interne pour valider les livraisons ne suffisent pas.
• Accueillir favorablement les demandes de changement : Cela veut dire, rester flexible et accepter les changements au cours du développement du produit par itérations successives, obtenir les retours utilisateurs, améliorer le produit au fur et à mesure.
• Livrer le plus souvent possible des versions opérationnelles de l’application : Il est recommandé que chaque sprint soit accompagné d’une ou plusieurs livraisons de features fonctionnelles qui sont en phase avec la proposition de valeur du produit. S’il est nécessaire d’avoir plusieurs sprints pour avoir une livraison valide, il est possible de prévoir un sprint long. Dans le cas opposé, s’il y a trop de fonctionnalités validées au cours d’un sprint, il faut prévoir des sprint plus courts pour que la qualification, ou le PO puisse avoir le temps de tout valider.
• Assurer une coopération permanente entre le client et l’équipe projet : les membres de l’équipe ont souvent des language métiers différents (développeur vs PO vs designer). Il s’agit de faire en sorte que chacun puisse s’entendre et collaborer ensemble. Par exemple, le PO doit traduire parfaitement les besoins en exigences techniques aux développeurs.
• Construire des projets autour d’individus motivés : Une équipe agile doit être motivée pour réussir. En Scrum par exemple (une des méthodes agiles), les tâches sont chiffrées en points qui ne correspondent à aucune valeur. Il faut quelques sprints pour que l’équipe arrive à déterminer combien de points elle est capable de produire, parce que les membres apprennent à se connaître, apprennent des erreurs et des succès des sprints précédents. Transférer les membres d’une équipe à l’autre brutalement peut casser cet équilibre.
• Privilégier la conversation en face à face : Privilégiez l’oral en face à face dans une réunion en présentiel, et limiter autant que possible l’écrit aux équipes qui travaillent dans d’autres régions géographiques.
• Mesurer l’avancement du projet en termes de fonctionnalités de l’application : on peut utiliser des méthodes telles que Scrum pour tout mesurer, tout KPIser : points, burn-up/burn-down charts… C’est bien de produire des fonctionnalités mais cela ne suffit pas si ceux-ci reviennent sous la forme de bugs dans un ou deux sprints. Le but de chaque itération est de produire du logiciel qui fonctionne, idéalement dans les temps estimés, c’est la meilleure façon d’évaluer la performance d’une équipe.
• Faire avancer le projet à un rythme soutenable et constant : Les demandes de changements par exemple ne doivent pas créer de la friction ou épuiser l’équipe. Une équipe fatiguée est une équipe peu productive.
• Porter une attention continue à l’excellence technique et à la conception : Cela veut dire conserver la méthodologie de gestion choisie, écrire des specs claires avant de les transmettre aux développeurs.
• Faire simple : Less is more. Il faut simplifier les tâches, la documentation et l’utilisation du produit par les utilisateurs.
• Responsabiliser les équipes : c’est laisser de l’autonomie aux membres de l’équipe, les laisser s’auto-organiser. Une équipe travaillant sous la contrainte est moins performante.
• Ajuster à intervalles réguliers les processus : L’amélioration continue est le principe le plus important. Une rétrospective en fin de sprint peut permettre de faire le point et de proposer des pistes d’amélioration pour les prochains sprint afin de ne pas refaire les mêmes erreurs.

Aujourd’hui, ces 4 valeurs et 12 principes continuent de guider l’approche Agile et sont utilisées par un grand nombre d’équipes. Les entreprises vont appliquer cette approche au travers de plusieurs méthodes comme le Scrum, le Kanban, le Lean, le SAFe qui répondent à des besoins et problématiques différentes. Lors d’une enquête, Scrum apparaît comme le plus populaire avec 66% des répondants qui l’identifient comme la méthode qu’ils suivent le plus étroitement, et avec 15% supplémentaires pour des méthodes dérivées de Scrum (ScrumBan 9 % et Scrum/XP 6 %).

Diagramme issu de l’enquête 15th State of Agile Report 16

Dans les prochains articles nous vous parlerons plus précisément de la méthode Scrum qui nous paraît la plus adaptée dans les contextes dans lesquels nous sommes intervenus et comment est intégré l’UX designer dans ces projets.