Scrum - la gestion des fiches à l'ère du numérique

De nos jours, il est important de réduire au maximum le délai de mise sur le marché d'un logiciel. C'est justement SAP-Les projets sont bien trop complexes pour qu'il soit possible d'établir un rapport complet. Cahier des charges à créer.

Lors du développement de produits selon une approche classique, il s'écoule souvent des mois, voire des années, avant qu'une Spécification est achevée.

Et même une fois terminé, il peut encore présenter des lacunes et des imprécisions. Mais même avec un concept sans faille, le risque existe de devoir attendre plusieurs mois (voire plusieurs années !) avant de pouvoir lancer le produit sur le marché ou sur les marchés. Exigences de vos clients.

Parmi les principales lacunes du développement de logiciels classiques, on trouve donc :

• des étapes de développement trop importantes - si le projet échoue ou prend une mauvaise direction, on s'en rend compte beaucoup trop tard
• Pensée en silo - le domaine spécialisé et le domaine du développement n'ont guère de contact direct
• Perte d'efficacité - la bureaucratie et les charges administratives entravent la productivité
• des problèmes de communication : malentendus ou manque de clarté Exigences sont remarqués trop tard

La cause de ces problèmes se trouve dans les Modèles d'approche même, car elles sont trop rigides et bureaucratiques et enferment inutilement toute l'équipe dans un corset. L'agilité s'en trouve limitée et les erreurs sont détectées trop tard.

Dans Scrum, outre le produit, la planification est développée de manière itérative et incrémentale. Cela permet d'obtenir des résultats intermédiaires exécutables (incréments de produit) qui peuvent être présentés très tôt au client ou au service spécialisé.

Cette transparence permet d'éviter les erreurs ou les omissions. Exigences sont rapidement visibles et peuvent être pris en compte dans l'itération suivante (appelée sprint).

Le site Processus de développement dans Scrum

Scrum repose sur un processus très simple. Seuls trois rôles sont impliqués dans un processus Scrum.

Le Product Owner met en place les objectifs techniques. ExigencesLe Scrum Master joue le rôle de chef de projet et l'équipe Scrum développe le produit.

Backlog de produit

Dans le Product Backlog, les Exigences gérés, élargis et priorisés.

Contrairement à la démarche classique avec cahier des charges et Cahier des charges le Product Backlog est modifié si nécessaire. Ainsi, les nouvelles connaissances ou circonstances peuvent être directement intégrées dans le développement du produit.

Il sert de source unique d'exigences pour toutes les modifications apportées au produit. Le Product Backlog répertorie toutes les fonctionnalités, les améliorations et les corrections de bugs qui constituent les modifications apportées au produit dans les futures versions, il évolue avec le produit et son utilisation et n'est pas une structure figée comme un Cahier des charges.

Backlog de sprint

A intervalles fixes et réguliers, un paquet de travail, appelé incrément, est défini à partir du Product Backlog.

L'incrément est traité pendant le sprint, qui est le cœur de la méthodologie Scrum. Le backlog de sprint est l'ensemble des entrées du product backlog sélectionnées pour le sprint.

Le Sprint Backlog rend visible l'ensemble du travail que l'équipe de développement doit effectuer pour atteindre l'objectif du sprint.

Le sprint

Le cœur de Scrum est le sprint, une période d'un mois maximum au cours de laquelle un incrément de produit fini, utilisable et potentiellement livrable est produit.

L'incrément est traité pendant le sprint. Pour ce faire, l'incrément est divisé en petits paquets de travail, appelés tâches, attribués à un responsable et la charge de travail est estimée.

Une tâche peut avoir un statut défini par l'équipe, par exemple "A faire", "En cours" et "Terminé".

Pendant un sprint, toutes les tâches sont notées sur des post-it et affichées sur un tableau d'affichage appelé ScrumBoard. Ce Scrumboard est par exemple divisé en trois colonnes : "À faire", "En cours" et "Terminé".

Chaque équipe ou membre de l'équipe marque l'avancement du travail en attribuant les fiches respectives au bon statut sur le tableau d'affichage.

Lors d'une réunion quotidienne de 15 minutes, appelée Daily Scrum, l'équipe de projet coordonne ses activités pour les prochaines 24 heures.

Chaque membre de l'équipe répond à trois questions :

• Qu'ai-je fait depuis le dernier Daily Scrum ?
• Qu'est-ce que je prévois de faire jusqu'au prochain Daily Scrum ?
• Est-ce que quelque chose m'a gêné dans mon travail (impediments) ?

Contrôle de la progression vers un objectif

A la fin du sprint, lors de la réunion de revue de sprint, l'équipe présente le résultat et le feedback est pris en compte dans la planification des sprints suivants et le processus recommence.

Cette approche itérative vous permet de combler les lacunes Exigences identifier plus rapidement et définir plus efficacement des solutions

Les ScrumBoards sont accrochés au mur dans un bureau, ce qui les rend peu agiles et flexibles.

Spécialement en SAP- Les projets impliquent généralement tellement de personnes qu'elles ne peuvent pas tenir dans un bureau ou que les conditions spatiales ne permettent pas d'aménager une salle d'équipe dédiée.

A cela s'ajoutent des difficultés logistiques supplémentaires dues à Délocalisation de proximité- ou des composantes de délocalisation.

Même lors de la réunion des parties prenantes, un tableau blanc s'avère être un instrument encombrant et peu pratique pour présenter l'état actuel des choses.

Le backlog et le burndown sont souvent utilisés en Excel-L'état d'avancement du projet est également géré manuellement dans une liste de tâches. Excel-La liste de contrôle est gérée par le système de gestion de la qualité afin de pouvoir générer un burndown chart.

Alternative électronique

Les ScrumBoards électroniques offrent ici une alternative judicieuse, car ils réunissent l'ensemble du processus Scrum dans une seule application et chaque membre de l'équipe peut y accéder à tout moment.

"Les post-it virtuels" ne perdent pas leur pouvoir adhésif et le tableau d'affichage peut enfin être utilisé comme tableau d'affichage.

Si les conditions spatiales permettent de disposer d'une salle d'équipe, vous pouvez également afficher le ScrumBoard électronique sur un téléviseur ou un écran (tactile) pour tous les membres de l'équipe.

Scrum dans SAP

Dans un projet SAP, ces scrumboards électroniques présentent toutefois l'inconvénient de ne pas être intégrés au système SAP.

Afin d'exploiter au mieux la méthodologie Scrum, le ScrumBoard de bsc apporte des solutions intégrées pour la gestion de projet. SAP® permettent à votre équipe de gagner considérablement en efficacité.

Grâce à l'utilisation du framework moderne UI5, notre ScrumBoard se distingue par un design d'interface moderne et intuitif.

Il est facile à utiliser par glisser-déposer et permet aux membres de votre équipe de se concentrer sur leurs tâches et de les accomplir plus rapidement.

Les instances de contrôle ne doivent pas renoncer à des informations essentielles et actuelles.

Le ScrumBoard numérique vous aide, vous et votre équipe, dans toutes les activités quotidiennes et le traitement de l'état des projets parallèles, l'attribution et la gestion des nouvelles tâches et de nombreuses autres actions sans ajouts confus ou distrayants.