Une équipe qui grandit avec Agile Scrum

Développement QueryPie # 3: Introduction au processus de développement

한국어: https://medium.com/p/cfaa4b71c263/

Il n'y a pas de balles d'argent dans le monde. Néanmoins, les humains sont vulnérables à toutes sortes de désirs et sont toujours à la recherche d'une solution miracle.

Lorsque le Manifeste Agile a été annoncé en 2001, Agile était un candidat pour être une solution miracle dans l'industrie du développement logiciel. Dix-sept ans plus tard, Agile n'est plus la solution miracle que nous recherchions. Mais c'est devenu un outil pratique et formidable pour développer votre équipe et conduire votre entreprise vers le succès.

J'ai commencé ma carrière en tant que développeur web en 2004. Depuis 2011, je suis un développeur senior travaillant en tant que responsable dans de nombreuses équipes de développement. Après être devenu chef d'équipe, j'étais constamment préoccupé par la façon dont je pouvais atteindre tous les objectifs de mes projets de développement: des objectifs tels que la planification, la conformité, la qualité et la croissance de l'équipe.

À la suite de cette préoccupation, j'ai trouvé Agile. Donc, ce journal du développeur décrira mon expérience avec le développement Agile.

Agile: amélioration continue grâce au compromis

Idéalement, une approche de développement de logiciel serait de développer le logiciel achevé en temps opportun sur la base d'une planification et de prévisions complètes. C'est ce qu'on appelle le développement piloté par plan, et le logiciel est développé selon un processus appelé le modèle Waterfall. Pour que cela réussisse, toutes les conditions idéales doivent être réunies. Mais en réalité, il est difficile de prédire ce qui va se passer à l'avenir et il est inévitable que des changements inattendus se produisent. De plus, le processus de développement logiciel est fluide, ouvert et imprévisible.

Alors, qu'est-ce que l'Agile?

Agile est un compromis. Agile suppose des conditions réelles au lieu de parfaites et idéales. Il s'adapte aux changements constants et exploite des ressources limitées pour améliorer le projet. De cette façon, l'équipe de développement peut envisager le meilleur compromis et le mettre en œuvre ensemble.

Il existe de nombreux types de processus de développement Agile. Scrum, Kanban et Extreme Programming (XP) ne sont que quelques exemples. Chacun a des fonctionnalités différentes et une portée différente, mais peut être utilisé en combinaison les uns avec les autres.

Un nouvel essai et erreur du chef d'équipe avec le premier Scrum Agile

En 2011, je suis devenu chef d'équipe de mon propre groupe de développeurs et j'ai commencé à réfléchir au fonctionnement d'une équipe. L'étude des méthodologies de développement de logiciels a suscité un intérêt pour Agile. J'ai été très impressionné lorsque j'ai lu le livre Scrum et XP des Tranchées.

Scrum et XP des tranchées, comment nous faisons Scrum par Henrik Kniberg

L'itération que Scrum utilise est idéale et attrayante. L'équipe gère une tâche en tant que carnet de commandes, la replanifie et la résout sur la base d'un court cycle de développement itératif appelé Sprint, et crée un développement et une amélioration continus.

Processus Scrum (source: https://en.wikipedia.org/wiki/Scrum_(software_development))

Cependant, je n'ai pas pu introduire immédiatement la méthodologie Scrum à mon équipe en raison de la nature de mon département à l'époque. Nous étions en train de corriger de nombreux problèmes et nous devions continuer à développer des logiciels, donc il n'y avait pas de place pour une nouvelle méthode. Lorsque j'ai commencé à incorporer légèrement Scrum dans notre flux de travail, cela a sans surprise échoué. J'ai découvert la difficulté de travailler avec Scrum, l'équipe et le client doivent être préparés… ce qui n'est pas une tâche facile.

Mon équipe est donc revenue à la façon dont nous travaillions avant Scrum. Notre ancienne méthode ressemblait à ceci:

  1. recevoir la demande par téléphone ou email
  2. écrire la demande sur un post-it
  3. mettre le post-it sur le mur
  4. l'opérateur saisit un post-it et le ramène à son bureau
  5. l'opérateur résout la demande
  6. la demande résolue est déplacée dans l'agenda commun de l'équipe

Je suis sûr que vous ne serez pas surpris d'apprendre que les moniteurs de mon équipe étaient constamment remplis de post-it!

(source: https://happytango.com/…what-a-post-it-note-was/)

Kanban était simple et facile, mais il a manqué 2% d'excellence

En 2013, j'ai changé d'emploi et j'ai eu une autre chance de considérer le flux de travail de mon équipe. À cette époque, le livre Kanban et Scrum: tirer le meilleur parti des deux a été publié. J'ai beaucoup appris sur Kanban en étudiant ce livre.

Kanban et Scrum: faire les deux par Henrik Kniberg et Mattias Skarin

La méthode de Kanban est un peu plus simple. Cela nécessite de créer quelques colonnes distinctes, de les étiqueter en conséquence (c.-à-d. À faire, à faire, à faire) et à ajouter des tâches sur des cartes / post-it notes aux colonnes. Ces tâches se déplacent ensuite de colonne en colonne en fonction de leur statut. C'est une méthode assez facile à utiliser et c'est un excellent moyen de visualiser le processus de travail.

planche de toile simple (source: https://en.wikipedia.org/wiki/Scrumban)

Cette méthode peut sembler évidente, mais Kanban ajoute quelques règles au processus. Certaines des règles de base de Kanban divisent les projets en tâches plus petites, les hiérarchisent et limitent le nombre d'opérations simultanées. Si vous êtes curieux de connaître la méthode Kanban, veuillez vous référer au livre Kanban et Scrum pour plus d'informations.

La gestion des tâches d'une équipe à l'aide de la méthode Kanban est très simple. Tout le monde peut comprendre le processus et le suivre pour maximiser la productivité, et les avantages qu'il a procurés à mon équipe étaient excellents.

Mais je me sentais très coupable de l'échec de mon premier Scrum. Je voulais travailler de manière plus organisée avec la méthode Scrum.

Un retour à Agile Scrum avec une nouvelle start-up:

En 2015, lorsque j'ai rejoint une start-up, j'étais dans une situation où je devais diriger une toute nouvelle organisation de développement. J'ai réalisé que c'était le moment idéal pour réintroduire Agile Scrum dans mon flux de travail.

Lorsque l'idée du premier produit a été décidée, le travail de développement a été réparti dans les meilleurs segments possibles et compilé en détail pour combler l'arriéré. Nous avons défini notre Sprint pour un cycle de 2 semaines. Je n'étais pas sûr de passer un mois à planifier cette période. Un cycle par semaine semblait trop court. Le cycle de 2 semaines comprenait une pause d'une semaine et si les progrès étaient trop lents, nous avons utilisé le week-end pour compenser.

Les premiers mois, sans l'aide d'aucun logiciel, nous avons utilisé un tableau blanc et des post-its pour Sprints. Trello et Jira étaient populaires à l'époque, mais la culture Scrum était encore nouvelle et inconnue de tout le monde dans mon entreprise, y compris moi. Nous ne pouvions donc pas nous permettre le temps d'apprendre une nouvelle méthode, c'est pourquoi nous nous sommes appuyés uniquement sur notre tableau blanc et nos post-its.

Tableau de gravure du 3e sprint

Scrum's Velocity: amélioration continue des performances

Le concept le plus important dans Scrum est la concentration. Cette approche commence par l'hypothèse raisonnable qu'il n'y a qu'un temps limité pour qu'une personne se concentre réellement sur une seule tâche. Il est donc préférable de fixer des heures de travail fixes pour une journée et de gérer le pourcentage de travail effectué ce jour-là. À cette fin, nous appelons l'unité de travail segmentée une histoire et attribuons une valeur de point dans la carte d'histoire appelée un point d'histoire.

️ Les points d'histoire sont utilisés pour mesurer l'effort global nécessaire pour développer un travail. Si un développeur se concentre à 100% pendant une heure sur une tâche, c'est un point. Lorsque vous marquez des points d'histoire, nous devons faire attention à ne pas surestimer ou sous-estimer. Il est essentiel de trouver le score exact pour la taille de la tâche. Sur la base des points d'histoire que nous avons définis pour le sprint spécifique, nous pouvons calculer la vitesse après avoir pris en compte le temps nécessaire pour un sprint.

Vitesse = Points d'histoire / Temps réel pris:

Par exemple, si 10 développeurs travaillent sur des points d'histoire pendant 10 jours, huit heures par jour, où les histoires sont classées à 528 points, la vitesse serait: 528 points / (10 personnes x 10 jours x 8 heures) = 66%

La vélocité est calculée en additionnant tout le personnel participant au Scrum. Le calcul de la vitesse par les individus peut amener inutilement les membres de l'équipe à se faire concurrence, ce qui à long terme peut être nocif.

Fait intéressant, les objectifs de vitesse pour le Sprint suivant sont calculés sur la base de la moyenne de la vitesse atteinte dans le couple de Sprints précédent. Chaque Sprint fixe toujours un objectif légèrement plus élevé que la moyenne du résultat précédent, créant un objectif constamment mis à jour et stimulant. Ainsi, une fois qu'une équipe atteint son objectif, le sentiment d'accomplissement est élevé. S'ils échouent, alors l'option de fixer un objectif plus facile en raison de la valeur moyenne réduite pour le prochain sprint. Cette gestion de la concentration permet à l'équipe Scrum d'améliorer continuellement la précision et les performances de son plan.

Progression du sprint basée sur Scrum:

L'équipe Scrum partage un objectif ambitieux commun, poursuit le projet et tient une courte réunion tous les jours. Ceci est appelé Daily Scrum Meeting, ou Daily Stand-up Meeting car la position debout est recommandée pour que les réunions soient aussi courtes que possible. Lors de ces sessions, les membres Scrum partagent leurs progrès et maintiennent le niveau de pression de réussir dans l'équipe.

Cycle de sprints Scrum (source: développement logiciel agile avec Scrum par Ken Schwaber et Mike Beedle)

Après chaque sprint, un temps de réflexion et de planification est nécessaire. Améliorer les liens d'équipe en comparant les objectifs et les performances, en calculant les niveaux de concentration et en distribuant des éloges ainsi que la consolation par la réflexion est si important. Vous ne devriez jamais blâmer personne. Il s'agit d'un effort d'équipe.

Lors de la réunion de planification pour le prochain sprint, en fonction des progrès et de l'expérience, vous pouvez mettre à jour le contenu des cartes récit dans le carnet de commandes et affiner les valeurs de l'histoire. Ensuite, définissez l'objectif de concentration pour le prochain Sprint, convenez de la portée et du calendrier du Sprint et recommencez (voir les livres ci-dessus pour plus de détails sur la façon de le faire).

J'ai acquis beaucoup d'expérience dans la gestion de ma propre équipe Scrum pendant deux ans. Scrum a concentré mon équipe sur la tâche et a naturellement conduit à des performances plus élevées et à une planification précise. Mais le plus important de tous, les membres de l'équipe sont devenus très confiants et capables de construire un lien profond les uns avec les autres. Nous avons grandi rapidement en équipe.

Nous avons essayé plusieurs outils pour gérer notre processus, et avons finalement décidé de la plate-forme Jira. Je pense personnellement que Jira est l'outil le plus puissant et le plus pratique pour les méthodes Kanban et Scrum.

Capture d'écran: sprints actifs d'une planche Scrum (source: https://support.atlassian.com/jirasoftware-cloud/)

Le tableau de projet de type Scrum dans Jira fournit des fonctionnalités de gestion du backlog et un tableau Scrum avec une variété de rapports. Les outils de mesure tels que les rapports Sprint, les graphiques de gravure, les graphiques de concentration et les rapports de version nous ont aidés à gérer nos performances.

Festa, la plateforme événementielle développée grâce au succès de Scrum:

En décembre 2017, j'ai rejoint l'équipe de développement d'une plateforme de vente d'événements sud-coréenne appelée Festa. À l'époque, Festa se préparait pour son premier lancement de produit après avoir terminé la validation de principe (POC). Le produit lui-même était un site Web pratique où les utilisateurs pouvaient acheter des billets pour un événement grâce à une procédure de paiement facile.

Comme il s'agissait d'une nouvelle équipe, nous devions parler de notre flux de travail et de nos processus. J'ai suggéré Scrum. Une fois la proposition acceptée, nous avons décidé du premier produit minimum viable (MVP) et créé un carnet de commandes.

L'accent était mis sur le calendrier de lancement du produit. La date de sortie du produit était déjà déterminée, j'ai donc dû terminer le projet selon un calendrier fixe. La période qui m'a été accordée était d'un peu plus d'un mois.

La nouvelle équipe Festa pourrait-elle terminer et lancer le produit à temps?

Site Internet de Festa (source: https://festa.io/)

Comme notre échéance était d'environ un mois, nous avons décidé d'un cycle de Sprint d'une semaine. En gérant fidèlement l'arriéré tout en répétant le cycle Sprint, nous avons pu prédire très précisément le temps qu'il faudrait pour préparer le lancement de notre produit.

À l'aide d'une fonctionnalité spéciale de Jira, nous avons attribué des numéros de version aux cartes récit et implémenté des rapports de version. Avec cette fonctionnalité, nous avons continuellement identifié la date de sortie prévue et ajusté de manière agressive la portée du développement pour atteindre nos objectifs.

Festa.io scrum ver1.0.0 Report

L'équipe Festa a toujours bien performé avec Scrum et a réussi à commercialiser le produit à la date cible. Si vous regardez le rapport de version ci-dessus, vous pouvez voir que notre score d'histoire a augmenté avec une pente fixe. C'est la preuve que l'équipe a toujours développé le produit en temps opportun avec une performance constante.

Nouveau défi Scrum: développement de QueryPie dans CHECKER

En 2018, j'ai commencé à travailler pour CHECKER, une nouvelle start-up en Corée du Sud qui développe un puissant outil IDE appelé SQLGate. Au début, je me suis simplement concentré sur la recherche d'une place pour moi dans le nouvel environnement, et une fois que j'étais à l'aise avec ma nouvelle position, j'ai commencé à me concentrer sur la production de résultats. Après quelques ajustements, j'ai recommencé à réfléchir à l'amélioration des performances de mon équipe. C'est à ce moment que j'ai proposé Scrum à mon équipe.

Selon vous, quel est le facteur le plus important lors de l'introduction d'un processus Scrum Agile? Je crois que c'est la réputation des gens qui participent à l'adoption du processus. La confiance est la base de l'acceptation et de la volonté d'essayer quelque chose de nouveau. Après avoir été un membre essentiel de CHECKER pendant plus de six mois, j'ai réussi à gagner la confiance de ma direction et des membres de mon équipe. Grâce aux efforts de chacun, nous avons créé une équipe Scrum fiable.

CHECKER est une start-up florissante qui sécurise rapidement des membres d'équipage actifs et talentueux grâce aux efforts de cadres hautement dévoués. J'ai été inspiré par leur enthousiasme à réussir et leur volonté de relever de nouveaux défis. C'est donc avec grand plaisir que je crée un processus Scrum qui stimulera la productivité de l'entreprise et fera croître notre entreprise de manière auspicieuse.

Challenge Le défi Scrum actuel de CHEQUER est QueryPie, dont vous pouvez en savoir plus dans cet article.

J'ai déjà beaucoup d'expérience dans la gestion de Scrums via Jira, j'ai donc pu diriger mon équipe dans l'exécution de mon plan pour notre premier Sprint. Notre objectif de concentration initial a été fixé à 64% sur la base de l'expérience (70% est l'objectif idéal dans mon esprit). Le nombre de membres d'équipage était de quatre, et le premier Sprint n'était que de huit jours. Sur la base de ces facteurs, l'objectif à atteindre serait: 4 personnes x 8 jours x 8 heures par jour x 64% de concentration = 164 points d'histoire.

Rapport QueryPie scrum ver1.0.0

Dans l'image ci-dessus, vous pouvez voir comment j'ai organisé le backlog et défini la cible de la version 1.0.0. La date cible était le 1er mars. Mais quand j'ai vu le rapport de version quelques jours après le démarrage du Sprint, la date d'achèvement prévue était le 5 mars. Il m'a fallu quelques secondes pour réaliser que je n'avais pas pris en compte le week-end. Oups! Le samedi et le dimanche sont des jours de repos importants!

Dans ce rapport, j'ai ajouté que les 2 et 3 mars, nous ne travaillerons pas. La date d'achèvement estimée a été augmentée du nombre de week-ends, changeant le dernier jour au 11 mars. Mais à ce rythme, nous aurions 10 jours de retard sur la date cible, nous avons donc dû nous ajuster. Avec seulement quelques jours de Sprints, les talentueux membres d'équipage de CHECKER se sont rapidement adaptés à la méthode Scrum et ont pu affiner les cartes et les scores des histoires qui étaient initialement mal réglés.

Le premier défi Sprint s'est terminé en 8 jours. Notre rapport Sprint montre que notre équipage s'est très bien comporté au final. En raison de leur travail acharné, la date d'achèvement prévue a été confortablement ajustée au 22 février. La différence entre les estimations de date d'achèvement optimistes et pessimistes sur le graphique s'est également rétrécie. Je pense que nous obtiendrons un rapport de version avec une très grande précision une fois que nous aurons terminé deux autres sprints.

Ce n'était qu'un court sprint de 8 jours, mais l'équipe de CHECKER a appris à travailler de manière systématique et efficace. En réussissant le premier Sprint, nous avons gagné en confiance et renforcé le lien entre nous. Nous avons grandi ensemble tout au long de la méthode Scrum, et nous allons encore grandir à travers les Sprints qui vont suivre.

Récapitulatif du parcours Agile Scrum:

Beaucoup de commentaires sont sortis du processus Agile Scrum. Certains pensaient qu'il serait bon de suivre les progrès de l'équipage. Mais d'autres pensaient que cela provoquerait une concurrence inutile et une stigmatisation négative, nous devons donc l'aborder avec prudence.

Travailler en équipe ne doit pas impliquer de compétition. Nous devons créer un lien et avancer régulièrement vers un objectif commun. Si des membres d'équipage éprouvent des difficultés, nous devons les aider à améliorer la vitesse du processus Scrum et à grandir ensemble.

J'espère que ma longue histoire aidera quelqu'un là-bas. Donnez une chance à Scrum et donnez de la force et du leadership à votre équipe. Si vous continuez à travailler ensemble, sachez que le succès sera à nos portes.