Dans notre premier article sur la gestion de projet, nous avons examiné les raisons du succès de cette forme de gestion et la manière dont les planificateurs et les équipes peuvent tirer parti du modèle Kanban. Dans celui-ci, nous allons nous pencher sur la méthode Scrum.
Vous souhaitez davantage d’informations sur la mise en place d’une stratégie de sauvegarde infaillible dans le cloud ? Inscrivez-vous à notre Guide de pratique pour des stratégies de sauvegarde Office 365 évolutives.
En savoir plus:
- Comment convaincre votre boss d’adopter Microsoft Teams
- Microsoft Teams : Comment éviter les fuites de données
- Microsoft Teams : 6 conseils pour les nouveaux administrateurs
Scrum : une méthode de gestion de projet agile
Scrum ne correspond pas à l’abréviation d’un terme, il s’agit simplement d’un concept pour les techniques de gestion de projet agiles. Il a été mentionné pour la première fois en 1986 dans l’article « The New New Product Development Game » et décrit comment une équipe peut mettre en œuvre plus rapidement des processus de développement complexes lorsque l’équipe se compose de petites unités auto-organisées. C’est exactement ce dont nous avons besoin dans le monde en évolution rapide d’aujourd’hui.
Certaines méthodes agiles peuvent être relativement peu structurées. La méthode Kanban, par exemple, permet aux utilisateurs d’assigner indépendamment des tâches à des collègues à partir d’un « panier de tâches ». À l’inverse, l’approche Scrum est davantage axée sur les processus. Pour réussir, elle doit être suivie et contrôlée quotidiennement et faire l’objet d’une mesure de performance rigoureuse. Pour cela, il faut créer des conditions d’encadrement claires.
Rôles et tâches de Scrum :
Propriétaire du produit
Le propriétaire du produit agit dans l’intérêt des utilisateurs du produit ou des parties prenantes d’un projet. Ainsi, il est responsable du succès du projet et doit donner la priorité aux exigences techniques pendant toute la durée du projet, en ajoutant de nouvelles exigences et en éliminant celles qui sont obsolètes si nécessaire.
Administrateur Scrum
Cette personne est chargée de veiller à ce que tous les processus soient correctement suivis. Similaire à un modérateur, il veille à ce que l’équipe puisse réussir à communiquer, la protège des perturbations extérieures et l’aide à résoudre les questions méthodologiques. En bref, son travail consiste à éliminer les obstacles qui empêchent un travail d’équipe efficace.
Équipe Scrum
Chaque équipe Scrum travaillant sur un produit ne doit pas compter plus de cinq à dix personnes. Chaque membre de l’équipe doit avoir un objectif et être capable de travailler de façon indépendante sur ses propres tâches.
Enfin, il y a les parties prenantes. Bien qu’elles n’aient pas un rôle central dans le processus Scrum, la prise en compte de leurs souhaits et de leurs commentaires est un facteur clé de la réussite du projet. Les parties prenantes peuvent être a) les clients, b) les éventuels utilisateurs finaux ou c) l’équipe de direction du projet correspondant.
Vous souhaitez en apprendre davantage sur la méthode unique de gestion de projet Scrum ? Lisez cet article informatif Cliquez pour tweeterArtefacts Scrum :
En plus des rôles, les éléments suivants appelés « artefacts » constituent les trois éléments centraux du processus de Scrum.
Exigences
Les objectifs des clients (parties prenantes) sont enregistrés comme des exigences et doivent être décrits comme des « récits utilisateur ». Ils ne doivent pas être rédigés dans une forme technique afin que le cas réel d’application de l’utilisateur demeure au centre de l’attention. Ces exigences doivent être mises en œuvre dans les packages de travail techniques dans le « backlog de produit ».
Backlog de Sprint
Les packages de travail, qui décrivent les fonctionnalités et les fonctions de chaque produit/projet et qui sont définis en tant que tâches concrètes (parfois avec des sous-tâches), sont recueillis dans le backlog de produit de Sprint. Un « Sprint » est une période d’un mois ou moins au cours de laquelle de petits incréments de produits sont créés.
Incrément de produit
Un incrément de produit est la somme de tous les éléments achevés pendant un Sprint. Ils doivent être soit des versions semi-fonctionnelles après différents Sprints, soit le produit fini à la fin du projet.
Les rôles et les artefacts sont des éléments du processus Scrum global, qui comprend :
- Exigences dans des cartes de récit
- Packages de travail dans le backlog de produit
- Priorités
- Planification de Sprint
- Tâches dans le backlog de Sprint
- Réunions dans Scrum
- Réunion de révision de Sprint
- Rétrospective de Sprint
- Perfectionnement du backlog de produit
- Achèvement du projet
Microsoft Teams et le Planificateur sont tous deux incroyablement utiles pour permettre aux administrateurs de Scrum et à leurs équipes de collaborer aussi efficacement que possible. Je recommande de les utiliser comme tels :
Activités de processus de Scrum avec Microsoft Teams et le Planificateur
1. Exigences dans des cartes de récit
Rôles : propriétaire, partie prenante
Application : canaux de Teams, Bloc-notes
Comme décrit dans la section « Artefacts de Scrum », les exigences des clients doivent être axées sur les fonctionnalités et les fonctions. Il est également utile d’utiliser la description comme un cas d’application afin de garder à l’esprit l’objectif du projet. Cela est essentiel pour réduire le risque d’une mauvaise planification.
Pour la première étape du processus de Scrum, je recommande Microsoft Teams. Les cartes de récit (c’est-à-dire les fonctionnalités et les fonctions individuelles) peuvent être décrites par canal (1). Cela permet également de séparer les dispositions plus détaillées, les fichiers et les autres exigences spécifiques (2).
L’application OneNote peut également être très bien intégrée dans l’équipe. Cet outil permet de décrire (a) les fonctionnalités et (b) les cas d’application individuels. Personnellement, je préfère la version mentionnée ci-dessus avec les canaux de Teams, car elle offre davantage de possibilités (chats, mentions J’aime, @mentions, connecteurs, etc.) et de flexibilité.
2. Packages de travail dans le backlog de produit
Rôles : propriétaire
Application : cartes du Planificateur
Au cours de la deuxième étape, les exigences doivent maintenant être traduites en packages de travail professionnels. Les cartes de tâches du Planificateur sont la solution idéale. Toutes les informations nécessaires peuvent y être enregistrées comme décrit précédemment ici.
3. Priorités
Rôles : propriétaire
Application : étiquettes du Planificateur
En préparation de la quatrième étape, les packages de tâches doivent d’abord être hiérarchisés en fonction de leur importance ou de leur dépendance. Les étiquettes sur les cartes sont précisément conçues pour cet usage.
4. Planification de Sprint
Rôles : propriétaire, équipe, (administrateur)
Application : réunion Teams, compartiments du Planificateur
Cette étape ne consiste pas seulement à estimer les efforts individuels des packages de travail et à assigner des tâches à une section de Sprint. Particulièrement au début, il est essentiel de préciser à quel moment et à quel endroit tous les membres du projet peuvent se réunir quotidiennement, à quoi doit ressembler le développement général du projet, quelles sont les étapes majeures et quels sont les détails à prendre en compte. Il s’agit essentiellement d’une question de coordination entre le propriétaire du produit et l’équipe. Je recommande également l’inclusion des administrateurs Scrum afin de traiter les aspects plus méthodologiques du projet.
À la fin de chaque session de planification de Sprint, les différents packages de travail du backlog de produit (1) devraient être affectés au Sprint respectif (2). Le Planificateur est la plateforme idéale car il permet de compartimenter le projet. Si vous ne pouvez pas vous rencontrer en personne afin d’organiser la planification, je vous recommande vivement d’utiliser la fonctionnalité de réunion (y compris la vidéo) dans Microsoft Teams. Grâce à cette fonctionnalité, chacun pourra soit avoir les cartes de tâches devant lui, soit les partager sur l’écran.
5. Tâches dans le backlog de Sprint
Rôles : équipe
Application : tâches dans les cartes du Planificateur
Le travail sur les packages de tâches dans un Sprint commence à l’étape cinq. Cela devrait normalement prendre au maximum une à quatre semaines et être suivi de réunions quotidiennes Scrum (voir étape six : réunions Scrum). Pour une planification détaillée des progrès, je recommande de diviser les packages de travail en (sous-) tâches individuelles. Celles-ci peuvent être définies dans chaque carte de tâches du Planificateur.
6. Réunions dans Scrum
Rôles : administrateur, propriétaire, équipe
Application : réunion Teams (vue d’ensemble de la cartographie du Planificateur)
Un élément central de l’approche Scrum est la tenue de réunions quotidiennes d’une durée maximale de 15 minutes. Au cours de ces réunions, chaque membre de l’équipe fait un rapport sur ce qui a été fait depuis le dernier Scrum, sur ce qu’il fera jusqu’au prochain et sur ce qui entrave son travail. L’administrateur peut en déduire les mesures nécessaires pour surmonter ces obstacles.
Microsoft Teams fournit la base parfaite pour de telles réunions, en particulier avec les équipes multisites. Comme à l’étape quatre (« Planification de Sprint »), chaque participant peut suivre les tâches sur la vue cartographique du Planificateur pendant la réunion ou par le biais du partage d’écran. Toutefois, en raison de la concision des Scrum quotidiens, il convient de se demander si cela est nécessaire ou si la diffusion audio et vidéo est suffisante.
Réunion de révision de Sprint
Rôles : administrateur, propriétaire, équipe, partie prenante
Application : réunion Teams (vue d’ensemble de la cartographie du Planificateur)
À la fin de chaque Sprint, il devrait y avoir un contrôle de la progression. En fonction du projet et du produit, une version (partielle) du résultat peut être achevée et présentée au client. Celui-ci peut alors accepter le résultat, le rejeter, donner son avis ou même formuler de nouvelles exigences. Cela souligne les avantages de la gestion de projet agile, qui permet de réagir en permanence à l’évolution des tâches.
Alors que ce n’est guère possible lors des Scrum quotidiens concis, utiliser les cartes de tâches du Planificateur comme support visuel lors des réunions de révision de Sprint est fortement recommandé. Toutefois, les révisions de Sprint devraient durer au maximum une heure.
Avec les restrictions d’autorisation par canal d’équipe (voir Microsoft User Voice), qui on l’espère seront bientôt disponibles, un « canal externe » peut être créé avec le client, des réunions peuvent être organisées et des fichiers peuvent être partagés sans que d’autres documents internes ne deviennent accessibles. En attendant, la fonctionnalité de réunion actuelle, y compris la numérotation téléphonique, est un moyen optimal d’organiser les révisions de Sprint avec des clients (externes).
Quel outil pour quelle situation : #MicrosoftProject ou #MicrosoftPlanner ?
8. Rétrospective de Sprint
Rôles : administrateur, équipe (propriétaire)
Application : réunion Teams (canaux Teams)
En plus de se concentrer sur le projet/produit dans le cadre de la révision de Sprint, l’équipe devrait se réunir séparément et discuter du processus de travail. Celui-ci devrait être continuellement vérifié et amélioré.
En tant qu’alternative à la réunion, un commentaire peut également être ajouté directement dans les canaux de l’équipe.
9. Perfectionnement du backlog de produit
Rôles : propriétaire
Application : compartiments du Planificateur
À partir des résultats de l’étape sept (« Réunion de révision de Sprint »), le propriétaire du produit doit organiser et mettre à jour le backlog de produit. Les packages de travail terminés doivent être marqués comme étant terminés dans le Planificateur et déplacés vers le journal du produit. Les nouvelles tâches ou celles mises à jour peuvent être reprises dans le backlog de produits ou être programmées directement pour le prochain Sprint.
10. Achèvement du projet
Rôles : propriétaire, partie prenante
Application : compartiments du Planificateur, réunion Teams
Une fois tous les Sprints terminés, le produit final peut être livré au client. Le Planificateur doit alors marquer toutes les cartes de tâches dans le backlog de produit comme étant terminées.
En outre, grâce à ce diagramme simple, un propriétaire de produit a toujours une vue d’ensemble de ses projets Scrum et de l’état des tâches qu’ils contiennent.
Récemment, Microsoft a ajouté la fonctionnalité permettant d’exporter un plan au format Excel. Bien que des actions de formatage et de transformation supplémentaires soient nécessaires, cette nouvelle fonctionnalité vous permet de créer d’autres fonctionnalités d’analyse et de création de rapports telles qu’un diagramme d’avancement (couramment utilisé pour Scrum).
Microsoft travaille sans relâche à la mise en place de nouvelles fonctionnalités dans Office 365 et le Planificateur. Ainsi, les rendez-vous dans Microsoft Outlook et les tâches dans le Planificateur sont désormais liés. La connexion à d’autres flux de travail d’Office 365 est également en cours de développement, comme on peut le lire sur la feuille de route d’Office 365.
Indépendamment des développements futurs, le Planificateur est déjà un outil idéal pour la gestion de projets agile et l’approche Scrum, notamment grâce à son intégration facile dans Microsoft Teams. Je recommande donc aux entreprises qui souhaitent mettre en place des structures de travail agiles d’essayer le Planificateur en combinaison avec Microsoft Teams, en particulier lorsqu’il s’agit de projets de petite ou de moyenne envergure.
Vous souhaitez en savoir plus sur les méthodes de gestion de projet ? Abonnez-vous à notre blog !
