Introduction

En 2014, suite au départ de plusieurs personnes, j’ai eu l’occasion de devenir responsable technique de l’équipe produits chez Negotium Technologies.

À l’époque la situation n’était pas optimale, l’équipe était noyée sous les demandes de support, ce qui indiquait que la qualité n’était pas au rendez-vous, et que très peu d’activités étaient automatisées chez Negotium.

Cet article vous partage notre expérience lors de la mise en place du processus d’automatisation et du processus de livraison en continue. Par ailleurs, il présente la croissance que l’équipe a subi en deux ans. Elle a passé de 2 à 11 personnes et elle ne gère plus 2 produits/services, mais 5.

Sortir la tête de l’eau

Au départ, notre serveur de contrôle de code source plantait régulièrement (un vieux TFS 2010), les communiqués envoyés aux clients étaient faits sur un poste de développeur et nos processus étaient mal documentés.

L’équipe était mal outillée, ce qui nous a fait perdre énormément de temps !!!

Donc, la première étape a été de schématiser les processus opérationnels pour pouvoir les appliquer correctement et les améliorer continuellement.

La seconde étape fût de s’outiller correctement pour nos « besoins de base », c’est-à-dire faire une migration vers ¨Visual Studio Team Services¨ (voir mon blog à ce sujet) et mettre en place un ¨cluster System Center¨ pour bâtir des environnements autonomes correspondant à la demande.

Le temps gagné à ne plus attendre après le contrôle de code source ou après des environnements, ce qui représente environ 4 heures par semaine/développeur, a été investi dans l’augmentation de la production et de manière plus importante dans l’amélioration de nos méthodologies.

Se donner la capacité d’anticiper

À ce moment, Jean-François s’est joint à l’équipe et nous avons décidé de remettre en place ¨Scrum¨ au sein de celle-ci. Il y a énormément de documentations sur le sujet. Donc, j’assume que vous connaissez les principes de bases de la méthodologie et ses nombreux avantages.

La planification aux deux semaines et la formalisation du travail à réaliser, nous a permis d’augmenter notre productivité. Donc, moins de réunions, moins d’interruptions et plus de concentration.

De plus, ¨Visual Studio Team Services¨ fournit déjà un support complet de la méthodologie ¨scrum¨, alors il n’est pas nécessaire d’ajouter un outil, il est déjà présent.

Ce qui est important de comprendre, c’est que la livraison continue et les processus ¨DevOps¨ reposent sur le fait que la structure de livraison est itérative.

La planification sur plusieurs ¨sprints¨ a amené autre chose au niveau des produits soit l’obligation d’avoir une carte claire, et en amont de celle-ci, un argument commercial solide sur les produits. Nous connaissions à présent dans quelles directions allaient chaque produit et qu’ils avaient un budget défini. Ceci est très important pour le C-level.

Agrandir la famille

Début 2015, Negotium a fait l’acquisition de Pollen (voir communiqué de presse à ce sujet) ce qui nous a permis d’agrandir l’équipe en passant progressivement de 3 à 10 individus avec l’arrivée de Yann, Quentin, Benoit, Pascal et Sébastien.

Plusieurs problématiques se sont posées, tous reliés à la même question : Comment industrialiser la production de valeur à partir d’une idée ?

Formaliser Scrum

D’abord, il fallait s’assurer que chacun connaissait son rôle dans la structure et ses responsabilités afin d’arriver à travailler de concert.

Quentin est devenu notre ¨scrum master¨ et il accompagne les PO pour s’assurer qu’ils fournissent quelque chose de digérable pour l’équipe. Il accompagne aussi l’équipe pour s’assurer qu’elle arrive à avancer sans accrochage.

Nous avons nommé plusieurs ¨Products Owners¨, ce sont eux qui sont responsables du bon développement commercial et fonctionnel d’un produit:

–          Jean-François pour Oceanik

–          Nicolas pour Bizdesk

–          Yann pour Radar

–          Et notre partenaire Coginov pour Attribute

Approche Cloud first

Le fait d’avoir une approche ¨Cloud first¨, de respecter les bonnes pratiques associées à celle-ci et d’implanter les modèles recommandés (microservices, conteneurisation…), nous permet d’éliminer les problématiques de relève après échec, montée en charge et de nous concentrer sur notre valeur ajoutée.

Réduire la friction

Maintenant, nous avons un nombre plus important de développeurs. Par conséquent, nous devons nous assurer que le travail en parallèle et/ou asynchrone ne posera pas de problèmes d’intégration et ne sera pas trop coûteux à gérer.

Sur suggestion de Yann, nous sommes passés à un processus git flow pour la gestion des branches (supporté par git, hébergé sur ¨Visual Studio Team Services¨). Ce fut clairement une réussite réduisant la complexité et la durée d’intégration. (Voir ressources à ce sujet)

Automatiser le plus possible

Quand on perd 30 minutes par semaine par développeur et qu’on n’est que deux développeurs, ce n’est pas très grave. Toutefois, lorsque nous sommes onze ceci représente beaucoup de temps perdu.

Nous avons très vite compris qu’il fallait automatiser le plus de choses possibles. Au départ ce n’était que de simples ¨scripts powershell¨ pour arriver aujourd’hui à une industrie opérationnelle complète logicielle avec ¨build¨, tests, déploiements, configuration et adaptations (scale, failover…) automatisées.

Effectivement, il y a un coût initial, surtout lorsque l’équipe doit le découvrir, mais les gains dépassent largement le temps de réalisation de la tâche à la main.

Maintenant que la tâche est automatisée, nous n’avons plus peur de le faire plus souvent et autant que possible. Cela permet d’avoir un retour d’information quasi-immédiat sur le changement apporté et de pouvoir réagir en conséquence.

Pour illustrer mon propos, voici un exemple parmi tant d’autres :

Lorsqu’un des membres de l’équipe pousse du code, car il estime avoir terminé une fonctionnalité, automatiquement et ce sans aucun clic de sa part, le système compile et effectue toutes les actions pour passer du code, au livrable pour finalement, le tester. (Puis ensuite déploie, la QA embarque…)

Pendant que ce processus s’effectue, il est libre de faire autre chose et obtiendra le résultat dès que ce sera terminé.

Il n’a plus besoin d’attendre la construction mensuelle où l’on espère que rien n’est cassé (mais on ne le sait pas) pour avoir un retour d’information sur son code.

Le responsable qualité

En septembre dernier, nous avons eu la chance d’intégrer Ahmed à notre équipe en tant que responsable qualité. Quelqu’un qui a une formation en assurance qualité apporte beaucoup à l’équipe. Son arrivée a responsabilisé les développeurs à voir les choses d’une manière différente pour s’assurer que les problèmes existants soient connus, et que le moins de problèmes possibles arrivent chez les clients etc.

La grande difficulté auquel nous avons été confrontés lors de son arrivée était d’augmenter d’un coup l’assurance qualité. Du coup, nous n’étions plus capables de livrer des nouvelles releases, car celles-ci ne répondaient pas aux critères de la phase qualité.

Évidemment, cette phase d’amélioration globale de la qualité et de la fiabilité des produits s’est traduite par une réduction de l’utilisation du support et une meilleure maîtrise de ceux-ci à moyen terme.

La suite pour nous

L’avenir dans notre cas est de :

–          Continuer à intégrer de nouveaux membres à cette famille

–          Ajouter d’autres produits et services à notre portefeuille (Restez à l’affût !)

–          Automatiser les aspects de qualité du code

–          Mettre en place une stratégie de conteneurisation pour faciliter et standardiser les déploiements déjà en grande partie automatisés.

Ressources complémentaires

Vidéos DevTeach Montreal 2016 – VSTS Devops

  • https://channel9.msdn.com/Blogs/MVP-VisualStudio-Dev/DevTeach-Montreal-2016-VSTS-Devops-Ep-01-Introduction
  • https://channel9.msdn.com/Blogs/MVP-VisualStudio-Dev/DevTeach-Montreal-2016-VSTS-Devops-Ep-02-Build
  • https://channel9.msdn.com/Blogs/MVP-VisualStudio-Dev/DevTeach-Montreal-2016-VSTS-Devops-Ep-03-Release
  • https://channel9.msdn.com/Blogs/MVP-VisualStudio-Dev/DevTeach-Montreal-2016-VSTS-Devops-Ep-04-Test
  • https://channel9.msdn.com/Blogs/MVP-VisualStudio-Dev/DevTeach-Montreal-2016-VSTS-Devops-Ep-05-Technical-Debt-Management

 

Fermer le menu