La méthodologie agile a émergé dans le secteur du développement logiciel au début des années 2000. Dans les années 90, de nombreux projets de développement logiciel ont soit échoué, soit dépassé les budgets, soit pris du retard. La méthodologie agile s’est imposée comme une réponse face à cette tendance.
Des analyses approfondies ont démontré que c’était la méthode utilisée qui posait problème. À l’époque, les projets étaient définis et planifiés bien à l’avance. Les membres de l’équipe s’accordaient sur leurs tâches respectives et développaient des logiciels avec une phase de test présente seulement à la fin du projet. Cette méthode ne laissait aucune place aux ajustements et aux changements lors du projet.
De plus, les experts avaient besoin de changer la façon dont les logiciels étaient développés en adoptant une approche plus flexible, avec davantage de collaboration, de discussion et de retours d’expérience dès le début et tout au long du projet.
De nos jours, la méthodologie agile a largement été adoptée au sein du secteur. Bien que certains services d’ingénierie logicielle déclarent suivre les principes de la méthodologie agile, beaucoup se contentent en réalité de n’utiliser qu’une partie de ses outils, si bien que leurs collaborateurs (y compris les rédacteurs techniques) restent au second plan.
Ce blog vous donnera quelques conseils et astuces sur la manière dont vous pouvez organiser votre travail et votre équipe dans un paradigme agile, et comment éviter les pièges classiques.
Les principes de base de la méthodologie agile
En 2001, les partisans d’une nouvelle méthodologie ont formé l’Agile Alliance et publié l’Agile Manifesto (Manifeste agile), qui en donne la définition.
- Individus et interactions plutôt que processus et outils
La méthodologie agile invite les équipes de développement logiciel à se concentrer sur les personnes œuvrant à l’élaboration du produit plutôt que sur la configuration technique, afin de permettre un flux de travail fluide ponctué d’autant de discussions, de révisions et de changements que nécessaire.
- Logiciel opérationnel plutôt que documentation complète
La documentation ne doit pas être mise de côté, mais elle doit être appropriée et rédigée pour le public cible, qu’il s’agisse d’une documentation technique ou d’une documentation destinée à l’utilisateur final.
- Collaboration avec le client plutôt que négociation du contrat
La discussion et l’échange s’appliquent non seulement aux équipes en collaboration, mais aussi aux clients pour s’assurer que le résultat répond à leurs exigences.
- Adaptation aux changements plutôt que suivi d’un plan à la lettre
Les principes évoqués ci-dessus permettent de procéder à des ajustements lorsque cela s’avère nécessaire.
Voici quelques-uns des principes de base de l’Agile Manifesto.
- Le développement incrémental
Le développement incrémental est l’un des principes clés de l’Agile Manifesto. La méthode consiste à établir une liste d’exigences de haut niveau afin de donner la priorité à ce qui devrait figurer au sein du logiciel.
Le travail est organisé en sprints ou itérations, c’est-à-dire que le développement est réparti en périodes de plus en plus réduites au fur et à mesure des cycles, jusqu’à ce que le projet prenne fin. Chaque sprint comprend une phase de développement, de test, de révision et de documentation d’une fonctionnalité.
À la fin de tous les cycles, tout ce qui avait commencé avec l’itération doit être terminé et prêt à être livré au client. Les progrès sont mesurés en termes de logiciel opérationnel.
- L’équipe
La méthodologie agile repose sur une équipe interdisciplinaire de développeurs, d’assureurs qualité (AQ), de responsables de produit, de rédacteurs techniques et de concepteurs d’interface utilisateur/d’expérience utilisateur. Chacun s’accorde sur la charge de travail réalisable en un sprint et s’engage à la traiter avant la fin.
- La transparence
Les membres d’une équipe doivent, à tout moment, savoir où en sont les autres membres et où en est le projet dans son ensemble.
La transparence donne à chacun un aperçu des avancements du projet et rend l’estimation du temps d’exécution plus simple. Elle peut être garantie par des outils tels que des systèmes de tickets, le logiciel JIRA, ainsi que des tableaux numériques ou physiques avec des post-its.
Cette transparence met encore plus en évidence la méthodologie agile, où une modification est perçue comme une partie du processus de retours d’expérience continus, plutôt que comme une simple erreur.
La méthodologie agile en pratique : la méthode Scrum
La méthode Scrum est la méthodologie agile la plus populaire.
Le sprint commence avec le carnet de produit. Il dresse une liste des exigences principales pour les utilisateurs, dont le responsable de produit connaît les attentes. Il classe les récits d’utilisateur par ordre de priorité, les attribue à des équipes, et détermine si un récit d’utilisateur est accepté et achevé.
Un Epic est un récit d’utilisateur plus important, qui est divisé en plus petits récits d’utilisateur, puis transmis à des équipes de développement pour finaliser le tout en un sprint. La Definition of done (DoD) est un outil qui énumère toutes les activités nécessaires à chaque récit d’utilisateur.
Au début du sprint, toutes les personnes concernées, y compris le responsable de produit et le Scrum Master, se réunissent pour la planification. Ils décident de la durée d’un sprint, généralement moins de 4 semaines pour rester conforme à la méthodologie agile.
Le Scrum Master joue un rôle important en aidant l’équipe à rester sur la bonne voie et à atteindre ses objectifs. Il s’assure que les opérations sont fluides et que les critères d’acceptation sont remplis par l’organisation de réunions (entre autres).
Lors d’un sprint, des réunions se tiennent régulièrement. Les réunions « Daily Scrum » (ou stand-up) aident les équipes à s’organiser et à faire le point.
Quand arrive la fin du sprint, la révision se fait sous forme de démo afin de montrer les résultats. Tout le monde peut y participer, que ce soit les membres de l’équipe ou bien d’autres membres de l’entreprise, et parfois des clients selon la culture d’entreprise.
La rétrospective est une réunion de nature différente dont l’objectif est de regarder en arrière et d’analyser ce qui s’est passé correctement ou non. Des mesures pour améliorer le flux de travail sont alors prises.
À la fin du sprint, on obtient un incrément de produit, un logiciel opérationnel, qui peut être livré au client.
Quels sont les défis auxquels les entreprises font face avec une configuration agile ?
Dans une configuration agile, les rédacteurs techniques peuvent ressentir de la frustration, particulièrement lorsque les équipes ne parviennent pas à suivre les principes de communication et de transparence de la méthodologie agile. Vous trouverez ci-dessous quelques-uns des obstacles les plus courants pour les rédacteurs techniques et la façon de les surmonter.
Défis liés à la transmission de données
Souvent, les rédacteurs techniques signalent qu’ils n’ont reçu aucune donnée de la part des développeurs, ce qui rend plus difficile la rédaction de la documentation.
De bons récits d’utilisateur, comprenant également les besoins et les motivations de ceux-ci, peuvent aider les rédacteurs techniques à rédiger une rubrique de documentation. Puisqu’ils sont capables de se mettre à la place d’un utilisateur, les rédacteurs techniques peuvent aider le responsable de produit à rédiger le texte destiné à l’utilisateur. Les premières ébauches et maquettes fonctionnelles sont également utiles pour donner une meilleure idée des fonctionnalités.
De plus, la documentation doit apparaître dans la liste des travaux effectués. Bien que les rédacteurs techniques ne soient pas en capacité de finir la documentation en un seul sprint, la contribution des développeurs lors de sa préparation leur permet de la finir dans les temps.
Les réunions sont un bon moyen pour échanger des informations. Les rédacteurs techniques peuvent obtenir des données, poser des questions et transmettre des retours d’expérience aux développeurs. Ils peuvent aussi planifier des entretiens avec les membres de l’équipe.
C’est lors des phases de révision que les rédacteurs techniques comprennent mieux comment marche une fonctionnalité, surtout s’ils n’ont pas accès au produit. Enfin, en organisant des tests de convivialité, l’entreprise peut observer de nouveaux utilisateurs, ce qui lui permet d’améliorer sa documentation.
Défis liés à la gestion du temps
Idéalement, les ingénieurs doivent arrêter de coder quelques jours avant la fin du sprint pour permettre à l’équipe de rester sur la bonne voie. Ils peuvent mettre ce temps à profit pour transmettre des données aux membres de l’équipe de l’AQ et aux rédacteurs techniques. Cette organisation simplifie la révision et la correction des erreurs détectées.
Les rédacteurs techniques qui ont accès aux informations détaillées du produit peuvent commencer leur rédaction avant ou en même temps que l’implémentation. Si ce n’est pas possible, le fait d’utiliser des incréments plus importants pour la publication peut contribuer à faire retomber la pression.
Cependant, plus le processus de rédaction de la documentation est long, plus le risque d’apparition d’imprécisions et d’obsolescence des données augmente. Les données transmises par les experts techniques deviennent difficiles à obtenir et il reste peu de temps pour finir la rédaction technique avant que le produit ne soit livré aux clients. Il n’y a pas assez de temps non plus pour la traduction.
Travailler sans cadre structuré, où la publication implique de nombreuses tâches manuelles, retardera d’autant plus la rédaction technique. Il est donc primordial d’optimiser votre infrastructure.
Défis liés aux réunions
Les rédacteurs techniques travaillent souvent avec de nombreuses équipes. Par conséquent, en plus de leurs tâches en lien avec la méthode Scrum, ils doivent participer à de nombreuses réunions.
Si la situation le permet, ils doivent limiter le nombre d’équipes pour lesquelles ils travaillent ou ne pas assister à certaines réunions Daily Scrum. Une autre possibilité consiste à choisir un remplaçant. Par exemple, le Scrum Master peut prendre des notes et partager toutes les informations pertinentes avec les rédacteurs techniques plus tard.
Le plus important pour chaque équipe est de trouver quelles sont les méthodes qui fonctionnent le mieux pour elles.
Défis liés à la traduction
Dans le cadre d’une traduction d’itération, la modularisation du contenu doit être un aspect essentiel. C’est ce que les outils comme MadCap IXIA CCMS offrent, avec un flux de travail adapté à la traduction. De plus, l’interface utilisateur doit être localisée avant le début de toute traduction.
Il existe d’autres outils pour contrôler la terminologie et vérifier la langue. Ces outils sont utiles pour livrer un contenu cohérent de qualité, ce qui doit aussi être une priorité pour les traducteurs.
Plusieurs solutions existent pour surmonter les défis liés à la traduction. Elles impliquent, par exemple, de renoncer à l’impératif de terminer une traduction en même temps que le texte source ou de supprimer complètement la traduction du processus agile. Dans tous les cas, la phase de traduction ne peut pas commencer tant qu’il n’y a pas assez de textes sources disponibles. En plus d’assurer la cohérence et la qualité d’un contenu, cette démarche évite les changements fréquents et les frais de traduction exorbitants.
Voici quelques recommandations de plus pour utiliser au mieux la méthodologie agile :
Recommandations concernant l’équipe
Dans une configuration agile, les rédacteurs techniques doivent toujours faire partie des équipes Scrum. Cette organisation leur donnera accès aux données dont ils ont besoin, ainsi qu’aux personnes qui les détiennent. L’équipe bénéficiera également d’un retour d’expertise des rédacteurs techniques et de leur point de vue centré sur l’utilisateur.
Recommandations concernant l’infrastructure
La génération automatisée des sorties, le contrôle des versions et les compilations automatiques sont essentiels au système afin de dissocier la mise en forme du contenu, quel que soit l’outil utilisé par les rédacteurs pour produire la documentation.
Les révisions en ligne sont plus efficaces et facilitent le travail de manière considérable. L’utilisation de fichiers Markdown est aussi une bonne idée lorsque les ingénieurs et les experts techniques font partie du processus.
Travailler dans un environnement agile exige une communication constante afin de garantir son efficacité. À mesure que les rédacteurs techniques deviennent des membres à part entière de l’équipe, ils peuvent directement contacter les développeurs et les autres membres de l’équipe pour obtenir des données. Leur propre expertise permettra également à l’équipe de mener à bien un projet fructueux, le tout avec moins de frustrations !
À l’origine, ce blog a été présenté en tant que webinaire IXIAtalks par Marion Knebel de Parson. Le webinaire est accessible ici.
Découvrez notre série de webinaires IXIAtalks.
Cet article a été écrit en anglais par Amandine Mondélice, coordinatrice au sein de l’équipe MadCap IXIA CCMS et traduit par Julie Vieux, étudiante en master TSM à l’université de Grenoble, dans le cadre d’une collaboration avec les universités et avec l’aimable autorisation de MadCap.
