Processus de publication de l’équipe
Pour adopter la méthode DevOps, la première étape consiste à évaluer votre processus actuel. Ceci implique d’analyser les éléments suivants :
- Vos artefacts existants, par exemple, les packages de déploiement et NuGet, ainsi que vos dépôts de conteneurs.
- Vos outils existants de gestion de test.
- Vos outils existants de gestion du travail.
- Les stratégies de migration et d’intégration recommandées
C’est ce que va faire l’équipe Tailspin pour voir si DevOps peut l’aider.
Une fois Irwin (le chef de produit) parti, Amita dit : « Nous avons besoin d’aide. Je ne sais pas pour quand sont attendus ces correctifs, mais je sais que c’est pour bientôt. Notre processus ne nous permet pas d’agir rapidement. De plus, le nouveau site web Space Game va devoir attendre la résolution de cette pagaille. La sortie du jeu est pour bientôt. »
Andy regarde Mara. « Cela vous fait beaucoup de choses à intégrer… vous n’êtes là que depuis quelques semaines… »
« Ça va aller », répond Mara. « Vous pouvez peut-être m’expliquer comment les choses fonctionnent ici. Par exemple, comment un jeu passe-t-il de la phase de développement à la phase de production ? »
« C’est une excellente question », dit Andy. « Je ne suis pas sûr qu’on puisse vous donner une réponse simple, mais nous allons essayer. »
L’équipe décide d’aller au café pour se détendre et discuter de façon informelle. Ensemble, ils vont essayer de comprendre pourquoi ils ont tant de problèmes.
En buvant son café, Mara écoute et prend des notes. Les idées fusent un peu dans tous les sens. Voici son impression globale sur l’équipe :
- Elle utilise une approche en cascade. Ce sont les responsables qui définissent les priorités. Les développeurs écrivent du code et livrent la build à l’équipe chargée de l’assurance qualité. Celle-ci teste la build puis la livre aux Opérations pour le déploiement.
- L’approche en cascade peut convenir à une petite équipe, mais ici, les objectifs ne sont pas toujours clairement établis et semblent changer fréquemment.
- Les tests sont effectués relativement tard dans le processus. De cette façon, il est plus difficile et plus coûteux de corriger les bogues et d’apporter des modifications.
- On ne sait jamais ce que signifie réellement terminé. Chaque membre de l’équipe a ses propres idées. L’équipe ne s’accorde pas sur un objectif métier global.
- Il y a du code dans un système de gestion de versions centralisé. Un grand nombre d’outils et de scripts se trouvent uniquement sur les partages de fichiers réseau.
- De nombreux processus sont manuels.
- La communication est aléatoire et se fait principalement par e-mail, document Word et feuille de calcul.
- Le feedback est rare et incohérent.
- Côté positif, l’équipe semble bien s’entendre et vouloir améliorer les choses.
Lorsqu’elle regarde ses notes, Mara sait qu’elle doit mettre toutes ces informations en ordre. Le fait de les organiser facilitera l’évaluation du processus. Elle est convaincue que la méthode DevOps va permettre de résoudre une bonne partie des problèmes de l’équipe. Toutefois, elle doit trouver un moyen de convaincre son équipe.
La mise en place de la méthode DevOps nécessite de comprendre les processus existants. À partir de là, vous pouvez évaluer ce qui va et ce qui ne va pas, et vous concentrer sur ce qui doit être amélioré.
Mara demande : « L’un de vous a-t-il déjà effectué un exercice de mappage des flux de valeur ? »
Andy lève les yeux au ciel, Amita soupire et Tim dit « Nous avons assez de paperasse comme ça. »
Mara dit « Ne vous inquiétez pas. C’est moi qui m’en occuperai ».
Soulagés que la nouvelle recrue s’en charge, chacun retourne à son travail.