Blog

> Actualités > Wiki’Déj : « Parlons d’agilité & de DevOps » – Questions / Réponses


Wiki’Déj : « Parlons d’agilité & de DevOps » – Questions / Réponses

Les Wiki’Déj étant avant tout un moment d’échanges et de partages, la présentation s’est poursuivie par une discussion avec les participants dont voici quelques brides.

O. : Peut-on faire un parallèle entre sprint et lot ?

S. : On peut faire cette association mais restons prudents à ce signifie « lot ». Le lot est plus fonctionnel et le sprint est plus organisationnel. Dans le sprint, on obtient bien un livrable et on parle bien de fonctionnalité. 

O. : Est-ce qu’il ne peut pas y avoir de problèmes de régression lorsqu’un nouveau sprint intègre des modifications qui vont toucher à des livrables déjà effectués ?

J’imagine que comme les tests sont réalisés sur des périodes courtes de développement, ils sont focalisés sur des besoins précis.

S. : Il existe différentes pratiques pour assurer la qualité logicielle : tests unitaires, tests de bout en bout, tests fonctionnels.

Pour rappel dans l’agilité, le projet est en mode incrémentale c’est-à-dire que l’on parle de sprint 1 qui correspond à une fonctionnalité 1 et à des tests 1 associés à cette dernière. Au sprint 2, on fera toujours les tests de la fonctionnalité 1 pour vérifier qu’elle fonctionne toujours.

Dans les pratiques de développement, on définit le développement en fonction du test. On réalise aussi de la relecture et validation croisées entre développeurs par exemple.

Oui, on réalise toujours des tests et on les accumule pour vérifier les précédentes fonctionnalités livrées.

Un avantage supplémentaire : le fait d’avoir une périodicité courte (2 à 4 semaines) permet d’identifier les non-régressions rapidement.

La non-régression apparaitra aussi dans la rétrospective et permettra d’en tirer un bilan. Si la cause est importante, on trouve des solutions collectivement avec l’ensemble des membres de l’équipe.

O. : Chez mon client, les sprints ne sont pas livrés en production. On suit un circuit classique et les sprints servent à faire avancer la recette mais ce n’est pas livré en production tout de suite. C’est le produit fini qui est livré avec une mise en production unique. Le projet est plus découpé qu’avant mais il n’existe pas ce lien sprint / mise en production.

S. : La prise en compte de nouvelles méthodes de travail et l’effort fourni par le client sont déjà une bonne chose. Vous êtes en transition, ça va s’améliorer !

Ecran montrant des lignes de code

D. : Est-ce que ce n’est pas le client qui aurait dû bien informer les membres de l’équipe et poser les bases des méthodes agiles qu’ils vont utiliser ? Il peut y avoir de l’appréhension quand on ne se sent pas suffisamment préparé à quelque chose de nouveau.

L. : L’agilité va jusqu’à la mise en production ? Car de nombreux clients fonctionnent comme ça, sans se terminer par une mise en production. Est-ce un élément primordial de l’agilité ?

S. :  Quelle est la finalité d’un développement ? La mise en production.

Après, quelle est la capacité de l’entreprise de pouvoir porter jusqu’à la mise en production ? C’est à ça que l’entreprise doit chercher à répondre.

Dans l’agilité, les méthodes sont nombreuses. Le cycle en V a aussi énormément évolué : on se retrouve maintenant dans cette méthode avec des itérations dans la partie entre les spécifications, le développement et l’intégration. Il y a des adaptations et les entreprises évoluent.

D. : De ce que j’ai compris, quand on parle de client, on ne parle pas forcément de client final. Ça peut aussi être des clients au sein de l’entreprise et on répond aussi à leurs demandes. C’est vraiment une intelligence collective, où le client (au sens large) et les équipes mettent ensemble leurs réflexions / idées etc… Peut-être que le frein dans ces exemples est d’ordre organisationnel ?

S. : Bien sûr. C’est pour cela que dans le second Wiki Déj, on aborde la notion de Devops où on apporte cet aspect. L’eXtreme Programming implique aussi des tests récurrents et des déploiements récurrents.

D. : Concernant les coûts, n’est-ce pas plus difficile de les établir sachant qu’il risque d’y avoir des changements ? N’est-il pas plus difficile à poser en méthode Agile par rapport au cycle en V ?

S. : Le client doit prendre en compte cette notion d’itération. L’idée est qu’il ait une unité de coût (sprint), dans laquelle le client sait ce qu’il peut avoir. Ce qui apporte une transparence.

Ce n’est pas du mode forfait. On va optimiser la valeur vis-à-vis du client. En interne sur le fonctionnement, on va minimiser le gaspillage.

D. : L’agilité change effectivement le paradigme et notamment en matière de management puisque tout le monde est impliqué dans la réussite. Quelles difficultés as-tu rencontré dans tes expériences ?

S. : Oui, cela apporte vraiment le respect du travail de l’autre et le courage.

C’est compliqué de parler d’Orange car c’est une structure complexe et large. Tous les projets fonctionnent cependant en Scrum ou Kanban, le SAFe est intégré depuis à peu près 2 ans. L’agilité depuis une dizaine d’années. La transformation est longue mais le plus important est de partager une vision. Qu’est-ce que l’on se fixe comme objectifs atteignables ?

La démarche la plus importante est d’y aller pas à pas, petit à petit. Je fais un pas et je consolide, et on le fait tous ensemble.

E. : Moi je travaille sur des projets en agilité depuis au moins 5 ans donc je connais déjà un peu. Je suis un peu l’empêcheur de tourner en rond comme j’ai un rôle d’architecture et que nous sommes sur un logiciel énorme qui était existant. Sur une partie qui a été mal conçue initialement, on a parfois des difficultés à s’intégrer car les gens ont tendance à faire des choses simples avec cette temporalité mensuelle. Sans chercher à améliorer. C’est difficile des fois de remettre en cause ce qui a déjà été fait en se souvenant que « j’ai un mois pour faire quelque chose ». Dans ce genre de cas, il est plus facile pour les gens de continuer à faire ce qu’ils font.

Par contre, au niveau des relations entre les équipes, de la confiance avec le client et entre les équipes, c’est beaucoup plus agréable car il y a de la négociation. Elle se fait très tôt, elle est revue et il y a beaucoup plus de discussions. On est dans une confiance mutuelle alors qu’avant on était plutôt dans une relation client / fournisseur.

On est en méthode Scrum, avec 80/100 personnes travaillant sur l’ensemble du projet.  

S. :  Ce dont tu parles, moi je l’intègre sous « dette technique ». Et elle est effectivement plus ou moins compliquée à gérer. Et dire « on remet à plat quelque chose qui fonctionne », c’est compliqué. Cet effort là doit être partagé.

Et on revient aussi sur la notion Lean de gaspillage : au bout d’un moment, il faut savoir si on pousse le tas de sable ou si on veut libérer la voie.

E. : Oui c’est ça. Souvent, on va faire un besoin conçu pour que ça marche rapidement. Et donc si la semaine suivante, on revient avec un besoin à peu similaire, on va repartir en faisant la même chose. Alors que si on s’est posé à réfléchir sur la source du problème, ça demande plus d’investissement au départ mais après on le gagne largement. Moi, mon rôle c’est plutôt celui-là. Donc ce n’est pas toujours simple de négocier cette partie-là.

S. : On parle d’agilité, de Scrum, de méthode… On peut parfois parler d’équipes localisées partout dans le monde aussi. Cette culture Agile, elle est internationale.

C. : Je suis de mon côté sur un poste fonctionnel dans une petite équipe, on y adhère sur le principe. Je m’occupe de faire de l’assistance utilisateurs sur un logiciel de l’administration publique. Avec le Covid, nous avons été obligés de livrer des mises à jour quasiment mensuelles. A chaque mise à jour, nous avions des Redmind où on indiquait les évolutions nécessaires pour que les utilisateurs puissent remplir leurs obligations conformément à la législation. L’enjeu est de taille pour les utilisateurs finaux.

Un Redmind pour nous est un sprint. Là nous avons une mise à jour prévue dans quelques jours et nous sommes dans une non-régression et validation globales de nos Redmind.

S. : Il n’y a pas de taille d’équipe minimale, au contraire ! Vous avez eu une grande capacité d’adaptation et vous avez su réagir en fixant les bons délais et prioriser en fonction de l’utilité client. Vous êtes dans une logique d’agilité.


N’oubliez pas qu’il s’agit du premier volet d’une trilogie, donc restez connecté(e) pour approfondir la thématique du DevOps sur les deux prochains volets !


Si vous souhaitez aller plus loin, voici quelques références transmises par Stéphane :


Morgan

À propos de l'auteur

Morgan | Actuellement Consultante RH pour Philae, j'ai débuté ma carrière sur la partie recrutement. Aimant le contexte ingénierie / conseil, J'ai intégré Philaë en 2016 en tant que Responsable des Ressources Humaines. J'interviens à la fois sur le recrutement de nos futurs collaborateurs, et sur leur accompagnement RH. J'accompagne aussi l'entreprise sur les projets RH et leur pilotage.