Dans le développement agile, les équipes Scrum sont soutenues par deux rôles spécifiques. Le premier est un Scrum Master, le coach de l'équipe, qui aide les membres de l'équipe à utiliser le processus Scrum pour performer au plus haut niveau.
Le propriétaire du produit (PO) est l'autre rôle, et dans le développement de logiciel Scrum, il représente l'entreprise, les clients ou les utilisateurs, et guide l'équipe vers la création du bon produit.
Le modèle Scrum suggère que les projets progressent via une série de sprints. Conformément à une méthodologie agile, les sprints ne durent pas plus d'un mois, le plus souvent deux semaines.
La méthodologie Scrum préconise une réunion de planification au début du sprint, où les membres de l'équipe déterminent le nombre d'éléments sur lesquels ils peuvent s'engager, puis créent un backlog de sprint - une liste des tâches à effectuer pendant le sprint.
Au cours d'un sprint Scrum agile, l'équipe Scrum prend un petit ensemble de fonctionnalités allant de l'idée à la fonctionnalité codée et testée. À la fin, ces fonctionnalités sont terminées, c'est-à-dire codées, testées et intégrées dans le produit ou le système en évolution.
Chaque jour du sprint, tous les membres de l'équipe doivent assister à une réunion Scrum quotidienne, y compris le Scrum Master et le Product Owner. Cette réunion est limitée à 15 minutes maximum. Pendant ce temps, les membres de l'équipe partagent ce qu'ils ont travaillé la veille, travailleront ce jour-là et identifieront les obstacles au progrès.
Le modèle Scrum voit les mêlées quotidiennes comme un moyen de synchroniser le travail des membres de l'équipe lorsqu'ils discutent du travail du sprint.
À la fin d'un sprint, l'équipe effectue une revue de sprint au cours de laquelle l'équipe démontre la nouvelle fonctionnalité au PO ou à toute autre partie prenante qui souhaite fournir des commentaires susceptibles d'influencer le prochain sprint.
Cette boucle de rétroaction dans le développement du logiciel Scrum peut entraîner des modifications de la fonctionnalité fraîchement livrée, mais elle peut tout aussi bien entraîner la révision ou l'ajout d'éléments au backlog du produit.
Une autre activité de la gestion de projet Scrum est la rétrospective de sprint à la fin de chaque sprint. Toute l'équipe participe à cette réunion, y compris le Scrum Master et PO. La rencontre est l'occasion de réfléchir sur le sprint qui s'est terminé, et d'identifier les opportunités d'amélioration.
Le principal artefact du développement Scrum est le produit lui-même. Le modèle Scrum s'attend à ce que l'équipe amène le produit ou le système dans un état potentiellement livrable à la fin de chaque sprint Scrum.
Le backlog produit est un autre artefact de Scrum. Voici la liste complète des fonctionnalités qui restent à ajouter au produit. Le Product Owner priorise le backlog afin que l'équipe travaille toujours sur les fonctionnalités les plus précieuses en premier.
Le moyen le plus populaire et le plus efficace de créer un backlog de produit à l'aide de la méthodologie Scrum est de le remplir avec des user stories, qui sont de brèves descriptions de fonctionnalités décrites du point de vue d'un utilisateur ou d'un client.
Dans la gestion de projet Scrum, le premier jour d'un sprint et pendant la réunion de planification, les membres de l'équipe créent le backlog de sprint. Le backlog de sprint peut être considéré comme la liste de tâches de l'équipe pour le sprint, alors qu'un backlog de produit est une liste de fonctionnalités à construire (écrites sous forme de user stories).
Le backlog de sprint est la liste des tâches que l'équipe doit effectuer afin de fournir les fonctionnalités qu'elle s'est engagée à fournir pendant le sprint.
Les artefacts supplémentaires résultant de la méthodologie agile Scrum sont le graphique de burndown de sprint et le graphique de burndown de publication. Les graphiques Burndown montrent la quantité de travail restante dans un sprint ou une version, et sont un outil efficace dans le développement de logiciels Scrum pour déterminer si un sprint ou une version est dans les délais pour que tout le travail planifié soit terminé à la date souhaitée.
Le Scrum Master est le coach de l'équipe et aide les praticiens Scrum à atteindre leur plus haut niveau de performance.
Dans le processus Scrum, un Scrum Master diffère d'un chef de projet traditionnel à bien des égards, notamment en ce que ce rôle ne fournit pas de direction quotidienne à l'équipe et n'attribue pas de tâches à des individus.
Alors que le Scrum Master s'efforce d'aider l'équipe à être la meilleure possible, le product owner s'efforce d'orienter l'équipe vers le bon objectif. Le propriétaire du produit le fait en créant une vision convaincante du produit, puis en transmettant cette vision à l'équipe à travers le backlog du produit.
Le propriétaire du produit est responsable de la priorisation du backlog pendant le développement Scrum, pour s'assurer qu'il est à la hauteur au fur et à mesure que l'on en apprend davantage sur le système en cours de construction, ses utilisateurs, l'équipe, etc.
Le troisième et dernier rôle dans la gestion de projet Scrum est l'équipe Scrum elle-même. La méthodologie Scrum stipule que chaque personne contribue de toutes les manières possibles pour terminer le travail de chaque sprint.
Une façon de penser à la nature imbriquée de ces trois rôles dans cette méthodologie agile est celle d'une voiture de course.
L'équipe Scrum est la voiture elle-même, prête à avancer dans la direction dans laquelle elle est dirigée. Le propriétaire du produit est le conducteur, s'assurant que la voiture va toujours dans la bonne direction. Et le Scrum Master est le mécanicien en chef, gardant la voiture bien réglée et performant à son meilleur.
A ajouter.
En prévision de l’annonce d’un ambitieux projet de logiciel de gestion des données appelé ODIN, Haus Division a préparé un hologramme suscitant la curiosité des visiteurs à l’événement auquel Altitude Infra dévoilera ce dernier.
Essentiellement, le processus de Design Thinking est itératif, flexible et axé sur la collaboration entre les concepteurs et les utilisateurs, en mettant l'accent sur la concrétisation des idées en fonction de la façon dont les vrais utilisateurs pensent, ressentent et se comportent.