Pour aborder la thématique du DevOps, nous avons eu la chance d’accueillir un orateur externe pour présenter ces Wiki’Déj : Stéphane, Ingénieur innovation chez Orange. Longtemps Chef de Projet en méthodes Agiles, il accompagne aujourd’hui les projets qui souhaitent évoluer vers le DevOps.
On ne peut parler de DevOps sans avant tout parler d’agilité. C’est donc le sujet abordé par notre invité le 29 septembre dernier lors du premier volet de la trilogie Wiki’Déj DevOps.
Aujourd’hui, nous la démarrons ainsi en discutant autour de l’agilité.
Petit disclaimer : il ne s’agit pas ici d’aborder un cours sur l’agilité. C’est une discussion à partir des retours d’expérience de notre orateur dans un contexte agile / DevOps.
Sans plus tarder…
Le constat
Depuis les années 90, l’objectif sur les projets est bien d’être toujours plus efficace et rapide pour fournir une solution au client.
Le logiciel est ainsi passé depuis une dizaine d’années en mode production industrielle, contraignant les équipes projets à s’adapter dans ce but.
Que signifie « être efficace » ?
C’est fournir un bon logiciel correspondant à la demande du client tout en optimisant les coûts et les ressources.
Quoi faire pour cela ?
C’est à cela que répond l’agilité. Être plus réactif et s’adapter aux changements !
En complément si l’on prend la philosophie Lean par exemple, on retrouve la réduction du gaspillage comme pilier avec un focus sur l’orientation donnée au client, à ce qui est essentiel.
Quel intérêt ?
L’intérêt pour l’entreprise d’entrer dans une démarche agile est donc une plus forte adaptation au changement grâce à l’intelligence collective qui devient la nouvelle méthode de travail.
La promesse pour le client est ainsi d’avoir plus de visibilité en obtenant le produit le plus rapidement possible entre ses mains. Et aussi davantage de transparence en comprenant mieux les coûts et en ayant une plus forte capacité à les maîtriser.
Et qu’en est-il de l’intérêt pour les collaborateurs sur le projet ? Une plus grande satisfaction du travail effectué, plus de confiance et de responsabilités.
4 valeurs
Afin d’harmoniser les pratiques, un manifeste Agile a été écrit en 2001 par des experts du développement logiciel et pose 4 fondements :
- Privilégier les individus et leurs interactions plutôt que les processus et les outils ;
- Privilégier un logiciel opérationnel plutôt qu’une documentation exhaustive ;
- Privilégier la collaboration avec les clients plutôt qu’une négociation contractuelle ;
- Privilégier l’adaptation au changement plutôt que l’exécution d’un plan.
Vous avez là les clés pour initier des pratiques Agiles sur vos projets !
En pratique, qu’est-ce que ça donne ?
Il faut avant tout changer ses méthodes, ses pratiques et sa vision.
Au lieu de définir un cahier des charges très exhaustif avec des coûts et délais que l’on a du mal à respecter comme dans le cycle en V, on fixe des coûts et délais précis pour travailler sur un périmètre défini et non plus sur l’ensemble. On morcelle le projet en gardant la constante coûts / délais et c’est le périmètre qui évolue.
Les méthodes agiles ont ainsi permis de doubler le taux de réussite des projets.
On cherche toujours la simplicité des processus. Même s’ils peuvent être parfois répétitifs, ils ont l’avantage d’être accessibles à tous. La prise en mains est plus rapide permettant une meilleure adaptation de chacun sur le projet.
Enfin, on se focalise sur la productivité et avant tout ce qui est utile pour le client. Le client est bien entendu l’utilisateur final, mais dans les méthodes agiles, il s’agit aussi des autres personnes du projet. Celle qui met en production. Celle qui développe un autre bloc. Nous avons toujours des clients, des personnes avec qui l’on va partager.
Plus concrètement, il existe une variété de méthodes qui peuvent être appliquées. En voici quelqu’unes :
- Rapid Application Development (1991)
- Scrum (1995), par Ken SCHWABER et Jeff SUTHERLAND
- eXtreme Programming (1999), par Kent BECK
- Kanban ou carte de signalisation inspiré du modèle Toyota (2003), par David J. ANDERSON
On peut noter que cette recherche d’une meilleure productivité dans le développement logiciel émergeait bien déjà dans les années 90, avant même l’écriture du manifeste.
La méthode Scrum
Etant l’une des plus utilisée, arrêtons-nous quelques instants pour faire un focus sur la méthode Scrum (pure agilité) qui concerne l’organisation d’une équipe.
Elle provient du terme « mêlée », en référence au rugby. Tout le monde est autour d’une table et échange autour de la livraison d’un produit. Il existe même des rôles et des personnages dans cette méthode.
Les « sprints » (étapes de livraison) correspondent à des périodes fixes qui varient entre 2 et 4 semaines et terminent en production. Toute l’équipe a pour objectif de livrer quelque chose durant cette période : une fonctionnalité, une évolution… Il n’y a pas de stockage ni de gaspillage.
Ainsi périodiquement, une livraison au client est effectuée. On livre presque en temps réel pour mettre la solution entre les mains du client le plus rapidement possible.
Les coûts sont également fixés à l’avance : on sait combien de personnes vont travailler sur chaque sprint et combien cela va donc coûter.
Tous les jours, il y a notamment le « Daily Meeting » qui dure 15 minutes : on fait le tour de table et chaque personne dit ce qu’elle a fait la veille, et ce qu’elle va faire le jour même. Chacun est en capacité de pouvoir présenter clairement son activité puisque le sprint est préparé et délimité : la vision est commune.
Pour préparer cette partie, il existe en complément le « Poker Planning » (réunion préalable). Il définit combien cela va coûter en travaillant sur les « User Stories ». Une « User Storie » décrit le besoin précis du client pour une fonctionnalité / un élément.
En gros dans le périmètre, on cherche à apporter de la valeur pour le client tout en atteignant les objectifs fixés. En découpant les objectifs afin qu’ils soient plus « petits », ils deviennent aussi plus réalisables.
Les échanges avec le client restent constants en parallèle afin de bien valider chaque étape ou de s’adapter si besoin.
D’autre part, l’approche est itérative : on revient régulièrement sur les choses durant un sprint. Notamment avec la phase de bouclage où toutes les équipes valides les phases effectuées (développement, qualification, déploiement…) avant que la livraison le soit.
Elle est aussi incrémentale : on avance pas à pas. On construit en constant en s’appuyant sur ce qui a été fait au préalable. On tente ainsi d’optimiser la prédictibilité sur le projet et le contrôle du risque.
On obtient une meilleure visibilité sur le planning des équipes par exemple.
On y gagne que la confiance et l’engagement entre les parties est renforcée.
La rétrospective est un élément également primordial de la démarche : elle permet de s’améliorer grâce aux retours.
Selon Stéphane, il s’agit d’ailleurs de la partie la plus importante. On sort la tête du guidon pour voir ce qui a fonctionné et s’en féliciter, et aussi exposer les éléments à améliorer. En clair, qu’est-ce qui a merdé ? Qui a eu des difficultés pour bien faire son travail et pour quelle raison ?
Il s’agit de respecter le travail de l’autre, d’avoir le courage d’admettre les difficultés rencontrées afin de pouvoir trouver des solutions et corrections collectivement pour la période suivante. On avance ensemble main dans la main dans un objectif commun. Pour cela, la dynamique à garder en tête est de s’améliorer en constant. On réduit ainsi les risques.
Agilité à l’échelle supérieure
Qu’en est-il lorsque l’on se positionne non plus à l’échelle des fonctionnalités mais à celle du produit ?
Le nombre d’équipe est multiplié et demande en somme une organisation différente. Sur un projet de 200 personnes par exemple, cela représente une dizaine d’équipes Scrum travaillant ensemble. Il faut donc être en mesure de pouvoir les harmoniser, les synchroniser.
On peut utiliser pour ça des framework comme par exemple le SAFe (Scaled Agile Framework) conçu par Dean LEFFINGWELL en 2011. Il instaure un langage commun au sein d’une même entreprise et guide les différentes équipes vers le développement d’un produit (program board). On augmente la compréhension entre les équipes, avec le management etc… SAFe mélange le Lean, l’agilité et l’optimisation.
Comment fait-on ?
Pour s’initier à l’agilité, Stéphane recommande de se faire aider par un coach ou encore de se plonger dans les principes fondateurs. S’immerger. C’est un état d’esprit, un mode de fonctionnement à acquérir.
Comment finir ?
Dans le cadre d’un projet ou d’un produit, on peut terminer le projet au sprint suivant si l’on veut. On s’adapte au besoin.
Est-ce que ça coûte moins cher ?
Oui et non, tout dépend où l’on place le prisme.
En méthode Scrum, le « peut-être » n’existe pas. On sait au début de chaque sprint quelle fonctionnalité va être développée ou non. Si on prend en compte la qualité (prouvée), la réactivité en étant toujours en contact avec le client, 100 % utile pour le client… La réponse est oui selon Stéphane.
S’adapte à tous les projets ?
Non, quand il s’agit de logiciels / solutions complètement autonomes. L’agilité et ses méthodes viennent dans une nouvelle réflexion où les interactions avec l’extérieur sont nombreuses. Les logiciels sont liés, vont chercher les données à gauche et à droite… De ce fait, cela nécessite de pouvoir s’intégrer. Je ne peux plus attendre 6 mois pour savoir si l’intégration fonctionne donc il faut pouvoir maintenir et vérifier régulièrement.
A retenir
L’agilité :
- Se concentre sur un processus simplifié ;
- Met l’accent sur le changement en étant plus réactif ;
- Accélère la livraison.
Aujourd’hui, l’agilité évolue même vers le collectif et le managérial : « mieux agir ensemble ».
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 que nous vous invitons à lire juste ici. Vous retrouverez également des références de ressources pour aller plus loin.