Plongée au cœur du backlog de l'équipe numérique
Il y a quelques semaines, les membres des équipes produit et ingénierie de l'équipe numérique ont participé à un "Debt Bash".
Notre objectif était de régler les problèmes techniques et les bogues qui nous gênaient, ainsi que d'autres services et les visiteurs de nos sites. Nous avons (principalement) mis nos projets principaux en suspens et consacré les quatre jours de travail (nous reconnaissons le jour de Martin Luther King Jr. comme jour férié dans la ville) à ces tâches.
- Last updated:
-
Comment en est-on arrivé là ?
Notre équipe est responsable de la maintenance d'un certain nombre d'applications et de services web de la ville, dont Boston.gov, qui est loin d'être le moins important. Chaque service municipal est représenté sur Boston.gov. Au-delà de la simple fourniture d'informations, les résidents ont la possibilité d'effectuer de nombreux services municipaux, notamment :
- payer les contraventions et les impôts fonciers
- en s'inscrivant aux lettres d'information, et
- être informé en cas d'urgence.
Avec une telle envergure, les bogues sont inévitables. Nous travaillons constamment à améliorer les fonctionnalités pour les utilisateurs du site web, tant à l'intérieur qu'à l'extérieur de l'hôtel de ville.
Tout en assurant la maintenance de ces systèmes existants, nous développons de nouvelles fonctionnalités et de nouveaux produits. Nous suivons l'avancement des projets en cours sur notre wiki d'équipe. Nous disposons également d'une feuille de route publique pour nos projets futurs. Lorsque nous sommes pleinement concentrés sur ces nouveaux projets, il peut être difficile de prioriser de petites modifications ailleurs. Même si la correction d'un bug ne prendrait pas longtemps à écrire, le coût de changement de projet peut être très élevé.
L'une des questions que l'équipe d'ingénierie et de développement produit se pose lors de ses réunions hebdomadaires est : « Y a-t-il des expériences que nous souhaitons essayer ? » Nous faisons cela afin de pouvoir tester des changements dans la façon dont nous travaillons ensemble sans pour autant les imposer définitivement. Si quelque chose semble fonctionner en pratique (c'est la seule façon de le savoir), nous pourrons l'adopter, sinon nous cesserons de le faire.
(Le mérite de poser la question de l'expérimentation revient entièrement à Kristen Johnson et Rich Paret de Crashlytics/Fabric/Firebase. Nous avons basé une grande partie de notre processus sur leurs méthodes.)
Le fait de consacrer une semaine à des tâches moins prioritaires qui s'accumulaient était une idée qui est née directement de cette question.
Comment avons-nous fait ?
Nous avons prévu la semaine de la liquidation de la dette quelques semaines à l'avance afin de nous laisser le temps de nous préparer. Nous nous sommes assurés que toute notre équipe en soit au courant, y compris notre responsable de contenu et nos concepteurs. Pourquoi ? Nous voulions qu'ils signalent les problèmes et qu'ils soient conscients qu'il n'y aurait aucun progrès sur d'autres projets pendant la semaine.
Nous avons utilisé un projet GitHub à l'échelle de l'organisation pour créer un tableau Kanban pour la semaine. Nous pouvions ajouter des tickets GitHub de n'importe lequel de nos référentiels au backlog du projet. Les chefs de produit ont classé ces tickets par ordre de priorité la semaine précédente afin que tout le monde puisse démarrer sur les chapeaux de roue au début de la semaine de Debt Bash.
Qu'est-ce qu'on a fait ?
- Nous avons migré notre application proxy d'API CodeRed de Heroku vers notre nouvel environnement Amazon Web Services, ce qui nous a permis de réduire un peu notre dette technique dans le cadre de notre migration en cours hors de Heroku.
- Nous avons ajouté un environnement local basé sur Docker pour notre installation Drupal de Boston.gov afin que les développeurs, tant à l'intérieur qu'à l'extérieur de la ville, puissent lancer Boston.gov sur leur machine en environ 15 minutes. Avant, cela prenait toute la journée, voire ne fonctionnait pas du tout.
- Un bug qui affichait incorrectement certains biens sur la page de la loterie Metrolist a été corrigé.
- Correction de l'intégration du tableau de bord Tableau sur notre page consacrée à la diversité des employés .
- Un bug dans les abonnements aux newsletters a été corrigé. Ce bug empêchait l'envoi de nouveaux e-mails de confirmation si la personne n'avait pas répondu au précédent.
- Texte d'aide amélioré sur la carte des conseillers municipaux .
- Améliorations pour budget.boston.gov . Cela comprend l'amélioration de l'infrastructure existante et la simplification du processus de création d'archives des budgets précédents.
- Nous avons libéré l'espace disque nécessaire sur nos serveurs Drupal en migrant la vaste bibliothèque de photos, de vidéos et de documents de boston.gov. Nous avons transféré ce contenu vers un espace de stockage plus fiable et économique sur un service Amazon appelé S3 .
- Intégration de search.boston.gov , initialement une application web distincte, dans Drupal.
Qu'en pensons-nous ? / Que pensons-nous de ce qui s'est passé ?
Lors de la réunion hebdomadaire suivante entre les ingénieurs et les chefs de produit, nous avons discuté de notre expérience "Debt Bash". Globalement, nous étions très heureux d'avoir pu dégager du temps dans nos agendas pour nous pencher sur ces problèmes.
Nous avons rencontré un obstacle qui a affecté le volume de travail que nous avons pu accomplir. Deux de nos ingénieurs n'ont pas pu participer beaucoup car ils étaient en train de mettre en place SuccessLink . Il s'agit d'une application web qui aide les jeunes de Boston à trouver des emplois d'été. Comme le programme SuccessLink suit un calendrier fixe (nous ne pouvons pas repousser le début de l'été !), les inscriptions doivent commencer en février. Avec cette échéance qui approchait rapidement, nous ne pouvions pas mettre ce projet en suspens comme nous l'avons fait pour les autres.
Dans l'ensemble, nous avons apprécié l'expérience du Debt Bash et nous allons continuer à le faire à l'avenir. Nous prévoyons de commencer avec un rythme bimensuel, mais nous allons expérimenter et affiner les choses au fur et à mesure.
L'équipe numérique explore constamment des moyens d'améliorer son flux de travail. Les séances régulières de "Debt Bash" sont simplement un autre moyen pour nous d'être plus agiles et efficaces.
- Last updated:
-
