Rôles
Les membres d'une équipe Scrum effectuent au moins l'un des trois rôles. La plupart des personnes effectuent le rôle de membre d'équipe dont la responsabilité est de créer et de terminer le logiciel. De plus, le propriétaire du produit représente les clients dans l'équipe et le ScrumMaster aide l'équipe et le propriétaire du produit à respecter efficacement les processus du Scrum.
Dans cette rubrique
Équipe
L'équipe se compose des personnes qui sont chargées de la création du logiciel. Elle sélectionne des récits utilisateur au début du sprint, collabore pour implémenter et tester ces récits utilisateur au cours du sprint, et présente le logiciel terminé lors de la révision du sprint. L'équipe est autonome parce qu'elle se gère elle-même et son travail. Elle est interfonctionnelle car elle contient les compétences dont elle a besoin pour fournir les récits utilisateur du journal des travaux en souffrance du produit. MSF for Agile Software Development v5.0 ne distingue pas les rôles dans l'équipe en fonction de critères tels que la discipline d'ingénierie ou le domaine de compétence.
La définition d'une bonne équipe
Il n'est pas facile de constituer et de faire progresser une bonne équipe de développeurs. On rencontre partout des exemples de bonnes équipes : des équipes chirurgicales, des équipes de basketball, et des chiens de berger avec leurs responsables. Chaque membre de l'équipe peut avoir sa spécialité, mais l'équipe travaille ensemble et réussit ou échoue ensemble.
Les bonnes équipes de développeurs sont également composées de personnes qui partagent le même objectif. Une équipe de développeurs ne doit pas être considérée simplement comme une assemblée d'experts où chacun à son tour s'acquitte des tâches propres à son domaine de prédilection. En fait, une équipe doit être un groupe de personnes dont les compétences et l'expertise collectives sont supérieures aux compétences de l'individu. Grâce à sa collaboration, communication, confiance et son ouverture, une équipe peut atteindre ses objectifs et dépasser les compétences individuelles de ses membres pour devenir une unité ultra-performante.
Une bonne équipe dispose des personnes et des compétences nécessaires pour livrer un logiciel fonctionnel. Les membres à plein temps de l'équipe doivent posséder tout ou partie des compétences exigées pour accomplir le projet. Des individus remplissant des rôles spécialisés tels que concepteurs, spécialistes de l'exploitation, architectes ou experts dans une technologie spécifique peuvent ne pas être disponibles à plein temps. L'équipe peut faire intervenir des spécialistes externes pour des activités à court terme. Toutefois, les membres à plein temps de l'équipe doivent être représentés par des personnes qui peuvent couvrir la plupart des compétences exigées pour réaliser le travail.
Responsabilités principales de l'équipe
La responsabilité principale de l'équipe est de créer le logiciel qui répond aux attentes des clients et aux critères de l'équipe pour aboutir à un logiciel fini. Les responsabilités de l'équipe démarrent au cours de la réunion de planification des sprints et finit à la réunion de révision des sprints. Au cours de la réunion de planification des sprints, l'équipe divise les récits utilisateur en tâches. Au cours de la réunion de révision des sprints, l'équipe présente le logiciel fonctionnel au responsable du produit et éventuellement aux clients.
L'équipe est également responsable de ses propres résultats. Elle se gère elle-même pour la définition et la réalisation du travail qu'elle a choisi d'effectuer et pour la collaboration entre les membres de l'équipe de façon à optimiser l'efficacité de celle-ci. Elle doit toujours chercher à améliorer ses résultats en prenant part aux activités suivantes :
Définissez les critères des éléments qu'elle considère comme finis et terminez chaque tâche avant de passer à la suivante.
Adoptez des pratiques d'ingénierie efficaces.
Pour plus d'informations, consultez Pratiques d'ingénierie.
Aidez le propriétaire de produit à développer des récits utilisateur efficaces et les classer par ordre de priorité.
Estimer les récits utilisateur.
ScrumMaster
En tant que ScrumMaster, vous êtes chargé de constituer et de gérer une équipe compétente, qui respecte les processus de Scrum. Vous êtes l'agent de modification qui aide l'équipe à surmonter les obstacles.
Qualités d'un bon ScrumMaster
Pour être un bon ScrumMaster, vous devez posséder ou instaurer une communication, négociation et compétences de résolution de conflit excellentes. Vous utiliserez ces compétences au quotidien pour aider votre équipe dans son travail de développement. Vous devez activement écouter non seulement le discours oral et écrit des personnes, mais aussi le mode de communication des messages (langage du corps, expressions du visage, rythme vocal et communication non verbale). Vous devez poser les questions nécessaires pour discerner les problèmes cachés et confirmer ce que vous avez compris de la part de vos interlocuteurs. Vous devez utiliser cette qualité d'écoute active pour identifier les problèmes potentiels de l'équipe et contribuer à maîtriser ces derniers. Il est plus rentable de corriger un bogue dès sa découverte ; par ailleurs, il est plus simple et moins gênant de résoudre un problème rencontré par l'équipe lorsqu'il est encore minime et gérable plutôt que de le laisser s'étendre et échapper à tout contrôle. Vous devez mettre en confiance l'équipe, le propriétaire du produit et les parties prenantes métier tout en permettant à l'équipe d'accroître sa productivité de manière significative. Vous devez rassembler, analyser et présenter les données aux parties prenantes métier de façon à montrer les progrès et les résultats de l'équipe. Par exemple, si votre équipe a considérablement augmenté la valeur du travail produit et si elle génère moins de bogues, vous devez montrer cette amélioration aux parties prenantes métier.
Responsabilités principales de ScrumMaster
Votre responsabilité principale consiste à vous assurer que l'équipe et le propriétaire du produit respectent les processus du Scrum. Par exemple, vous ne devez pas laisser la réunion Scrum quotidienne devenir une discussion libre de 45 minutes. Vous devez également veiller à ce que le propriétaire du produit ne demande pas à l'équipe d'ajouter un travail à un sprint après le début de son exécution. Vous ne devez pas laisser l'équipe présenter des récits utilisateur au cours de la réunion de révision sprint si ces récits ne sont pas entièrement terminés.
Vous devez contribuer à résoudre les problèmes majeurs que l'équipe peut rencontrer. Vous devrez peut-être effectuer de petites tâches, comme l'approbation d'un bon de commande pour l'achat d'un nouvel ordinateur de build, ou des tâches plus importantes et délicates, par exemple la gestion des conflits entre les membres de votre équipe. Lorsque l'équipe est engagée dans une interaction difficile, vous devez l'aider à surmonter le cap et à travailler plus efficacement à l'avenir.
Propriétaire du produit
En tant que propriétaire du produit, votre fonction principale est de servir d'interface entre les clients et l'équipe. Vous serez sollicité à plusieurs niveaux et par divers clients et parties prenantes.
Qualités d'un bon propriétaire de produit
Vous devez analyser les spécifications du client et les traduire sous la forme de récits utilisateur. Vous devez être un bon négociateur pour pouvoir aider des clients à comprendre les compromis entre les fonctionnalités demandées et leur impact sur la planification. Vous devez travailler avec les clients pour classer le journal des travaux en souffrance du produit par ordre de priorité afin que l'équipe génère les produits ou les systèmes les plus importants, un par un. Des connaissances d'expert dans le secteur commercial ou l'industrie du système en cours d'élaboration sont essentielles. Par exemple, vous devez avoir une certaine expérience dans les soins médicaux et l'assurance médicale si votre équipe est chargée d'élaborer un système pour les soins médicaux d'un hôpital. Sans ces connaissances, vous ne pouvez pas classer le journal des travaux en souffrance du produit par priorité de façon efficace ou expliquer les éléments du journal des travaux en souffrance du produit à l'équipe. Des compétences financières de base vous seront aussi utiles, notamment une connaissance du délai de récupération sur un système, pour amortir les budgets, et établir un budget de dépenses et d'un capital. Votre compréhension des processus Scrum et votre engagement en leur faveur est également important pour la réussite de l'équipe.
Responsabilités principales du propriétaire de produit
Vos responsabilités principales consistent à représenter les besoins des clients et des parties prenantes métier auprès de l'équipe et à répondre aux questions de l'équipe. Vous devez conserver le journal des travaux en souffrance du produit et le classer par ordre de priorité. Pour maintenir ce journal, vous devez communiquer régulièrement avec les clients, les parties prenantes et l'équipe. Vous devez rencontrer les parties prenantes au moins chaque semaine ou toutes les deux semaines. L'ordre dans lequel les récits utilisateur sont implémentés affectera le délai de récupération et la quantité de travail que l'équipe doit effectuer. L'équipe vous aidera à comprendre comment la séquence des récits utilisateur affecte le travail. Vous devez aider les parties prenantes à comprendre les effets de ces décisions de classement. Vous limitez aussi la nécessité de faire appel à des spécifications détaillées en étant disponible pour les membres de l'équipe lorsqu'elle a des questions sur la manière d'implémenter des fonctionnalités. Pour permettre à l'équipe d'avancer, vous devez connaître ces réponses ou pouvoir les trouver très rapidement (en quelques heures). Si vous n'êtes pas disponible, les résultats de l'équipe souffriront.
Notes
Le niveau de détail au niveau des spécifications dépend de nombreux facteurs, notamment le type d'application que votre équipe développe. Pour de nombreuses applications, des récits utilisateur élaborés correctement et des canaux de communication ouverts sont les recommandations les plus efficaces. Toutefois, une application qui traite les tests de laboratoire peut nécessiter des spécifications détaillées afin que l'équipe puisse analyser dans le détail l'impact des modifications qu'elle effectue dans le temps.
Vous travaillerez également avec l'équipe et les parties prenantes pour générer des tests d'acceptation de build. qui permettent à l'équipe de déterminer quand un récit utilisateur particulier est terminé et de se préparer pour la révision sprint. Vous devez comprendre, identifier, et présenter le risque aussi bien à l'équipe et aux parties prenantes.