Dans l’industrie informatique actuelle, le concept d’Agile est devenu très populaire. Tout le monde parle. Presque toutes les entreprises informatiques ont adopté un certain niveau d’agilité.
Il existe également de nombreuses méthodes sous l’égide du développement agile, notamment Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM) et léger. RUP, Test Driven Development (TDD), et plus encore. Parmi les nombreuses méthodes de développement agiles, la mise en œuvre de Scrum est la plus populaire.
Agile ou cascade ? Voir les chiffres
Le rapport le plus récent du Standish Group couvrait les projets qu’ils ont étudiés entre 2013 et 2017. Pour cette période, la répartition globale des succès, des défis et des échecs est indiquée ci-dessous pour Agile et Waterfall, les projets Agile ayant environ 2 fois plus de chances de réussir, et 1/3 moins susceptibles d’échouer.
(Source : vitalitychicago.com — Comparaison des taux de réussite des projets Waterfall et Agile )
Cet article partage principalement la compréhension de Scrum, le processus de mise en œuvre de Scrum et les changements apportés par la mise en œuvre de Scrum, et explique ce qu’est un Scrum en cours d’exécution.
Qu’est-ce que Scrum ?
Scrum est un cadre de développement et de maintenance de produits complexes et est un processus de développement incrémental et itératif. Dans ce cadre, l’ensemble du processus de développement consiste en plusieurs cycles d’itération courts, un cycle d’itération court appelé Sprint, et chaque Sprint dure de 2 à 4 semaines.
Dans Scrum, utilisez le backlog du produit pour gérer les besoins du produit. Le carnet de produit est trié selon la priorité de la mise en œuvre, avec la valeur commerciale comme principe principal de tri. Dans le Sprint, l’équipe Scrum a sélectionné les exigences les plus prioritaires du Backlog du produit pour le développement. Les exigences sélectionnées sont discutées, analysées et estimées lors de la réunion de planification de sprint pour obtenir une liste de tâches appelée backlog de sprint. Lorsque l’équipe Scrum a terminé toutes les tâches de la liste de backlog de sprint, le sprint se termine et passe au cycle d’itération de sprint suivant.
Pourquoi Scrum a échoué dans certaines entreprises
Scrum a une grande valeur. Cependant, il est difficile d’implémenter Scrum dans certaines entreprises. Certaines personnes disent que Scrum n’a aucun effet substantiel dans leur organisation. Pourquoi ont-ils un tel résultat ? Les principales raisons pourraient être :
- Agile est plus rapide - L’équipe de projet n’a pas une compréhension correcte d’Agile. Il pense simplement que l’agilité est rapide, c’est-à-dire qu’elle rattrape le progrès, et qu’elle peut être libre de toute contrainte système.
- Agile est plus rapide, ou nous devons faire des heures supplémentaires — j’ai entendu dire que certaines entreprises devaient développer une nouvelle fonction. Du fait de la mise en place de scrum, l’équipe projet est amenée à faire des heures supplémentaires, et les tâches de développement de 2 semaines ou plus seront débloquées en une semaine. La mise en œuvre de Scrum signifie que l’équipe de projet fait des heures supplémentaires, ce qui conduit à une « peur » dans l’agilité de l’équipe de projet ;
- Le backlog de produit n’est pas bien entretenu - le bon de commande ne peut pas être qualifié pour le travail, ne peut pas diviser les histoires d’utilisateurs efficaces, ou la division de l’histoire de l’utilisateur est déraisonnable, ne peut pas réaliser le développement de génération incrémentielle ;
- Problème de formation d’équipe – Scrum a une forte demande d’équipes auto-organisées, mais de nombreux membres de l’équipe estiment qu’ils ne sont pas à la hauteur des normes d’auto-organisation ;
- Manque de culture Agile — Scrum prône la transparence du travail, la réalisation du projet en temps réel et la reconnaissance des tâches de chacun. Le Sprint Board et le burndown chart du projet ne sont pas obstrués, et beaucoup de gens ne sont pas à l’aise avec cela ;
- Inspecter et Adaptation non en place – Dans le processus d’itération, le problème ne peut pas être découvert à temps, ou le problème est trouvé, et le problème ne peut pas être résolu efficacement, ce qui frustre l’équipe du projet. et beaucoup plus.
Si la connaissance de Scrum n’est bloquée que dans :
« J’ai une idée le matin, elle sera réalisée l’après-midi, et elle sera en ligne le soir. »
C’est inapproprié. À mon avis, Scrum est définitivement précieux. Les principales fonctions de Scrum incluent :
- Scrum peut assurer de prioriser le développement du backlog produit qui a une grande valeur pour les clients et mieux répondre aux besoins des utilisateurs.
- Par rapport à la méthode de développement sous le processus en cascade, en mettant en œuvre Scrum, l’équipe peut doubler l’efficacité du développement et maximiser le rôle de l’équipe ;
- Scrum peut raccourcir les cycles de développement et augmenter l’efficacité de la livraison des projets.
Cependant, mettre en œuvre Scrum ne signifie pas qu’il n’est pas soumis aux règles et aux contraintes du projet. Alors, quelle est la posture correcte pour mettre en œuvre Scrum ?
Étapes pour la mise en œuvre de Scrum
1. Attribuez un bon de commande
PO est le propriétaire du produit, qui est un rôle, et PO est le seul propriétaire de la liste de tâches du produit de gestion. Bien sûr, dans certaines entreprises, le PO existe déjà en tant qu’organisation – par exemple, notre entreprise a mis en œuvre le PO en tant qu’organisation dans la mise en œuvre de Scrum.
En tant que propriétaire, il doit avoir une vue d’ensemble ; comprendre profondément les informations et la direction de l’industrie ; être capable de saisir la direction du produit, de prendre en charge la planification et la gestion à court, moyen et long terme du produit ; être en mesure de mener des recherches sur les utilisateurs et de planifier les fonctions des produits en fonction des exigences stratégiques de l’entreprise, de suivre les besoins en constante évolution et de continuer à innover en matière de produits.
De plus, si vous utilisez PO en tant qu’organisation, dans un projet de développement logiciel, l’équipe PO peut inclure d’autres parties prenantes telles que des chefs de produit, des utilisateurs finaux.
2. Former une équipe de développement
L’équipe est l’implémenteur du produit et est responsable de la livraison des incréments livrables potentiels et des incréments de produit « terminés » à la fin de chaque sprint.
L’équipe comprend principalement du personnel de développement et de test, et l’équipe doit être en mesure de mettre en œuvre la vision du produit du PO.
La taille de l’équipe devrait être d’environ 5 à 9 personnes.
L’équipe Scrum doit également être interfonctionnelle et les membres dotés de la capacité «full stack» sont préférables, même si cela peut être difficile à mettre en œuvre dans la plupart des entreprises.
3. Sélectionnez Scrum Master
Le Scrum Master est responsable du processus Scrum et sert le PO et l’équipe de développement. Le Scrum Master doit avoir le sens du rituel et peut organiser de manière efficace et efficiente la réunion de planification itérative, la réunion permanente quotidienne, la réunion de démonstration de fonction et la réunion de revue rétrospective ; le Scrum Master doit avoir un haut degré d’exécution et maintenir sa crédibilité pour aider l’équipe. Se concentrer sur les objectifs de livraison et les objectifs de qualité pour s’assurer que les équipes livrent efficacement des produits de haute qualité ; conduire les équipes à construire des processus efficaces, guider les équipes sur les valeurs, principes et pratiques agiles ; être responsable de la formation des autres membres de l’équipe pour s’assurer que Scrum est utilisé correctement ; Communication, gestion de problèmes, résolution de conflits, aider l’équipe à éliminer tous les obstacles.
4. Maintenir le backlog produit
Le Product Backlog est une collection de tous les éléments du backlog, et est basé sur la stratégie et la vision du produit de l’entreprise. Le bon de commande trie tous les éléments du backlog de produit en fonction de l’ordre de priorité en fonction des valeurs commerciales et forme une liste d’éléments prioritaires. Le carnet de produit peut servir de « feuille de route » de développement de produit. Pour comprendre le contexte produit, les items du backlog produit sont la meilleure référence.
Chaque jour, nous sommes confrontés à de nouvelles demandes de nouveaux concurrents, ce qui signifie que PO doit continuellement optimiser la conception de ses produits et ajuster les priorités du backlog de produits pour faire face aux nouveaux changements.
Dans ce processus, le PO doit consulter toutes les parties prenantes et les équipes pour s’assurer que les backlogs de produit reflètent les véritables revendications de l’utilisateur.
5. Estimation Agile à l’aide de Story Point
Une estimation relativement agile est généralement effectuée lors de la planification du sprint ou lors d’une retouche pendant un sprint et le backlog de produit est évalué par l’équipe avec le responsable du travail de développement et de test réel.
Afin de mener la planification de sprint plus efficacement dans la pratique, le PO et le Scrum Master feront une estimation approximative avant la réunion de planification de sprint. Ils doivent poser ce genre de questions telles que :
- Voir si le plan de sprint est réalisable ?
- Y a-t-il suffisamment d’informations pour compléter ces questions?
- La répartition des éléments du backlog produit est-elle raisonnable ?
Lorsque l’équipe de développement effectue une estimation, il est recommandé d’abandonner la méthode traditionnelle (c’est-à-dire le nombre d’heures à attribuer à la tâche) et d’utiliser une approche d’estimation agile en utilisant le point d’histoire – le nombre de Fibonacci (1, 2, 3, 5 , 8, 13, 21…) Fiche d’évaluation de l’effort nécessaire à la réalisation d’un item.
Au moment de l’estimation, l’équipe doit d’abord identifier un élément de backlog qui pourrait être sous forme de user story comme référence pour l’estimation. De plus, il est important de noter que lorsque le point de récit unique de l’évaluation est supérieur à 21, la user story doit être à nouveau divisée, et le point de récit utilisateur unique n’est pas supérieur à 8 est l’état idéal.
6. Réunion de planification de sprint
C’est la première vraie réunion Scrum. L’équipe, le Scrum Master et le PO s’assoient ensemble pour planifier le contenu du sprint. En tant que projet de développement logiciel, entrant dans la user story du sprint de planification, la user story aurait dû être divisée et la conception visuelle terminée.
Le cycle de sprint est généralement fixe, généralement de 2 à 4 semaines. L’équipe commence par la user story avec la priorité la plus élevée dans la liste des tâches du produit pour voir ce qui peut être fait dans un sprint.
Si l’équipe a déjà réalisé plusieurs sprints, en se référant à :
- Les « story points » complétés dans les itérations précédentes,
- L’équipe peut estimer les points d’histoire approximatifs pour cette itération.
- « Story points » équivaut à la vitesse de l’équipe.
Le Scrum Master et l’équipe doivent s’efforcer d’augmenter ce nombre à chaque itération de sprint.
Tous les membres de l’équipe doivent former un consensus sur l’objectif d’un sprint, c’est-à-dire ce qui doit être accompli dans une itération de sprint. Lors de la réunion de planification du sprint, le PO doit indiquer à l’équipe l’ordre de priorité de la mise en œuvre de la user story. L’équipe promet le nombre d’histoires qu’elle pourra terminer lors de la prochaine itération de sprint. Dans le processus de sprint, personne ne peut modifier unilatéralement le contenu du sprint sans autorisation.
7. Réunion debout quotidienne
Le Daily Stand-up est la source de vitalité de Scrum. Les participants comprennent généralement le PO, le Scrum Master et l’équipe. L’équipe communique en interne à un endroit fixe et à une heure fixe chaque jour. L’ heure est généralement le matin, la durée ne dépasse pas 15 minutes et debout. Le Scrum Master pose aux membres de l’équipe les questions suivantes :
- Qu’est-ce que vous avez fait hier?
- Quels travaux comptez-vous faire aujourd’hui ?
- Quels sont les obstacles et les obstacles ?
L’importance de ceci est de faire savoir clairement à toute l’équipe la progression de chaque tâche au cours de ce cycle de sprint et si toutes les tâches peuvent être terminées à temps.
Les tâches de l’équipe ne sont pas assignées de haut en bas, mais sont décidées de leur propre initiative et volontairement. Si la tâche précédente n’est pas terminée, vous ne pouvez pas postuler pour la tâche suivante et vous ne pouvez pas réclamer deux tâches qui ne peuvent pas être terminées le même jour.
Le Scrum Master est chargé d’éliminer les obstacles rencontrés par les membres de l’équipe.
8. Suivre l’avancement du projet avec Scrum Task Board
Dans Scrum, le travail doit être transparent, et la pratique la plus courante consiste à mettre en place un Scrum Task board.
Certaines équipes savent utiliser des outils tiers pour utiliser le tableau électronique Scrum, tels que Visual Paradigm ou Jira ; certaines équipes sont heureuses d’utiliser de grands tableaux blancs physiques hors ligne.
Que vous utilisiez un tableau Scrum électronique ou un tableau blanc physique, les colonnes du Kanban comprennent généralement trois parties : la liste de tâches, les éléments en cours et les éléments terminés. Au fur et à mesure de la progression de l’itération, l’équipe mettra rapidement à jour le sujet dans la colonne Scrum Kanban correspondante tous les jours.
9. Suivi des progrès avec des graphiques d’épuisement professionnel
Un autre outil pour rendre le travail transparent est le burn-out chart. Dans la figure ci-dessous, un axe représente la charge de travail et l’autre représente le temps. Chaque jour Scrum Master enregistre les points restant à compléter puis les dessine sur le burnout chart. Idéalement, le graphique est une courbe descendante, s’épuisant à zéro lorsque le reste du travail est terminé.
10. Démonstration du produit
La section de démonstration du Scrum Guide est appelée Sprint Review Meeting, qui stipule qu’elle doit inclure la démonstration du travail effectué par l’équipe de développement et répondre aux questions sur l’incrémentation du produit. La réunion se tient généralement avant la sortie de cette itération. Le travail le plus important de cette réunion est de vérifier les scénarios de mise en œuvre des user stories en acceptant les évaluations avec chacun des éléments terminés pour répondre à la définition de terminé.
Cette réunion est l’endroit où n’importe qui peut être un participant, non seulement le PO, le Scrum Master et l’équipe, mais aussi les parties prenantes, les entreprises et les managers, et même les clients.
Il s’agit d’une réunion ouverte où tout le monde peut participer, non seulement le PO, le Scrum Master et l’équipe, mais aussi les parties prenantes, les entreprises et les managers, et même les clients.
Les équipes ne doivent afficher que les éléments qui répondent à la définition de terminé, c’est-à-dire les résultats qui peuvent être livrés sans avoir à faire plus de travail. Ce résultat n’est peut-être pas un produit complet, mais au moins c’est une fonctionnalité complète et utilisable par l’utilisateur final.
11. Rétrospective de sprint
La réunion de rétrospective du sprint se tient généralement le deuxième jour après la fin de ce Sprint.
La réunion de rétrospective du sprint doit examiner attentivement les questions suivantes :
- Ce qui s’est passé pour être amélioré;
- Pourquoi est-ce arrivé?
- Pourquoi l’avons-nous ignoré à l’époque ;
- Comment pouvons-nous accélérer le travail.
En tant qu’équipe, pour que ce processus rétrospectif de sprint soit efficace, l’équipe doit se faire confiance. Il faut retenir la discussion et les arguments basés sur le projet et les problèmes techniques :
- Il n’y a pas de bien, de mal et d’inquiétude absolus,
- Encourager les collisions techniques ;
- Ne peut pas impliquer de discussions sur des attaques personnelles ;
- Résistez aux gens qui portent des lunettes colorées pour voir les gens,
- Guider tout le monde à une discussion rationnelle ;
- Accepter avec courage les défis des autres,
- Acceptez ses propres imperfections.
- Responsable de ses propres processus et résultats,
- remue-méninges et chercher des solutions aux problèmes. C’est crucial.
Enfin, l’équipe identifie l’une des améliorations les plus intéressantes et la définit comme la priorité absolue pour le prochain sprint. Vous devez définir ce qui est « réussi » de manière concrète et exploitable afin de pouvoir déterminer rapidement si les améliorations ont été apportées lors de la prochaine réunion de revue de sprint.
Une fois le dernier sprint terminé, commencez à entrer dans la nouvelle itération de sprint.
Sommaire
Scrum est une combinaison de 3355. Les concepts de base du framework Scrum peuvent être simplement mémorisés en tant que 3.3.5.5 comme suit :
3 rôles
- Propriétaire du produit
- Équipe de développement
- Maître de mêlée
3 artefacts
- Carnet de produit
- Backlog de sprint — Liste de tâches de sprint
- Incrément de produit — Incrément de produit livrable potentiel
5 événements
- Sprint
- Réunion de planification de sprint
- Réunion Scrum quotidienne
- Réunion de revue de sprint
- Réunion rétrospective Sprint
5 valeurs
- Ouvrir
- Le respect
- Courage
- Se concentrer
- Engagement
Les objectifs de 3355 sont derrière les trois piliers Scrum
- Transparent
- Inspection
- Adaptation
La Définition du « Done » (DoD) est obtenue en remplissant les 3 piliers à travers les 5 événements de l’ équipe Scrum .
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский