Publié le 18 janvier 2022.
Début des projets chez Padok
Chez Padok, nous réalisons des missions DevOps pour nos clients, qui ont tous des problématiques d’infrastructure différentes. Comme nous prenons à cœur la satisfaction de nos clients, nous avons fait le choix d’intégrer l’agilité dans nos méthodes de travail.
En effet, la méthode agile permet d'améliorer le delivery des équipes.
Grâce à ces méthodes, nous pouvons itérer avec plus de flexibilité sur les différents livrables, et ainsi apporter rapidement de la valeur au client. Néanmoins, il est indispensable de définir en amont du projet des succès avec le client afin de s’aligner sur les gains que nous allons lui apporter.
Pour ce faire, nous commençons toujours par une première étape où le Tech Lead du projet et le client (généralement le Product Owner et le Sponsor) définissent plus précisément les enjeux business du projet. Elle est fondatrice pour toute la suite, puisque ces derniers vont nous permettre de construire des succès appropriés. D’ailleurs pour les projets long terme, souvent supérieurs à 3 mois, nous sommes amenés à réitérer cet exercice pour être constamment en phase avec les attentes du client.
Définition des succès
Chez Padok, c’est le Tech Lead et son équipe qui construisent ensemble les succès. Ils seront validés par le client pour permettre aux différentes parties de se mettre d’accord sur les objectifs du projet, et de s’aligner sur les gains attendus. A noter qu’il n’y a pas forcément de contraintes sur le nombre de succès, tout dépend du projet et des problématiques à adresser.
Voici les 5 choses importantes pour définir un bon succès, que nous illustrerons ensuite avec un exemple :
- L’intitulé 🚀
L’intitulé du succès est sous forme de user story, plutôt concis et doit être suffisamment précis pour que l’on puisse comprendre facilement le gain pour le client. En outre, on doit être capable de trouver la mesure directement.
- La mesure 📈
La mesure du succès est un chiffre qui nous permet de savoir si l’on se dirige vers le succès (ou pas). C’est très factuel, et cela évite les réponses “philosophiques” pour savoir si on l’a atteint ou non.
- Le pourquoi ❓
Le pourquoi du succès est un ensemble court de phrases, qui permet à quelqu’un qui n’aurait pas le contexte du projet de comprendre l’origine du succès et sa pertinence. Ainsi, il doit suffisamment être clair pour que l’on comprenne tout de suite la valeur apportée au projet et au client.
- La date de check 📅
La date de check est la date à laquelle le succès est censé être atteint. Sans cela, on ne pourra pas voir si on est toujours dans les temps pour le valider.
- Le comment 💡
Le comment permet de s’aligner avec son client sur les grandes lignes de l’implémentation du succès.
Cas pratique avec un de nos projets
Pour rendre l’exercice un peu plus concret, nous allons prendre l’exemple d’un projet sur lequel nous travaillons actuellement. Comme il s’agît d’une mission longue, nous définissons de nouveaux succès tous les trimestres.
Pour donner un peu de contexte, notre client déploie régulièrement de nouveaux services sur ses plateformes à destination de ses utilisateurs. Un grand nombre de développeurs y travaillent, et une équipe Ops Padok est là pour construire et assurer la bonne disponibilité de l’infrastructure. En outre, ils font quotidiennement du Run (résolution incident, traitement des alertes et de tâches) pour les développeurs qui auraient besoin de support.
L’un des enjeux majeurs du client est de réduire cette forte dépendance entre les devs et les Ops, afin de diminuer le leadtime des nouveaux changements sur les plateformes. Car en effet, les devs ne sont pas toujours autonomes pour debugger puis fixer leurs problèmes.
Nous allons donc reprendre ici nos 5 étapes pour définir un bon succès pour cette difficulté !
- L’intitulé
|
Exemple correct ✅ : |
Exemple améliorable ❌ : |
|
En tant que développeur de l’entreprise X je n'ai pas besoin des Ops plus de 25 fois par semaine |
En tant que développeur je suis plus autonome sur la plateforme Alpha |
Dans l’exemple de gauche, l’intitulé est plus précis et permet d’identifier rapidement la mesure qui est le nombre de demandes de Run.
- La mesure
La mesure est le nombre de demandes de Run par sprint faites par les Devs aux Ops. Elle est factuelle, et permet de bien montrer l’autonomie des Devs vis-à-vis des Ops. De plus, on voit bien la cible à atteindre qui est moins de 25 demandes de Run par sprint.
- Le pourquoi
Pour ce cas de figure, le pourquoi serait “Aujourd’hui les devs font environ 35 demandes par semaine aux ops, et nous avons identifié certaines tâches pour lesquelles nous pouvons les rendre autonomes afin de réduire leur lead time associé.”
- La date de check
C'est-à-dire que nous devrons avoir moins de 25 demandes de Run par sprint à la date du xx/yy/2022.
- Le comment
Voici les grandes étapes que nous allons réaliser pour atteindre ce succès (comparable à des macros).
La mention ETQ signifie “En tant que ..”.
- ETQDev je sais comment récupérer un heap dump en dev
- ETQLeadDev je sais comment récupérer un heap dump en preprod
- ETQDev je sais comment déposer des fichiers sur S3 en dev
- ETQLeadDev je sais comment déposer des fichiers sur S3 en preprod
- ETQDev je sais comment debug mes ressources K8S sur le cluster dev
- ETQDev je sais comment voir et changer les secrets en dev
- ETQLeadDev je sais comment voir et changer les secrets en preprod
Conclusion
Nous avons pu voir à travers cet article les 5 bonnes pratiques pour définir un bon succès. Ainsi, vous allez valider avec le client les gains qui lui seront apportés au cours de ce projet et lui donner plus de transparence sur votre impact. Cela améliorera grandement sa confiance en vous.
Si vous voulez en apprendre plus sur les méthodes employées chez Padok, vous pouvez lire l'article de Yohan sur le Kaizen : un outil qui peut vous aider à diminuer drastiquement le nombre d’incidents ! 😉