Jeff a participé à un excellent webinaire organisé par SmartBear jeudi dernier. Si vous l'avez manqué, voici le lien vers le webinaire. webinaire archivé et les diapositives. Nous avons reçu des centaines de questions de l'auditoire et SmartBear en a envoyé quinze. Elles seront bientôt toutes affichées sur leur site, mais nous avons pensé vous en donner un échantillon. Si vous avez regardé le webinaire et que vous voulez connaître toute l'étendue de la pensée de Jeff sur le Scrum, vous pouvez vous inscrire à nos cours Scum Master de mars ou d'avril qui sont en cours de préparation.
Quelle taille d'équipe est "trop petite" pour scrum ?
La réponse rapide est zéro. Nous avons vu des Scrum de trois de deux et même d'une personne. Mais pour la plupart des équipes, la règle des 7 plus ou moins deux est la meilleure solution. En général, l'équipe compte suffisamment de membres pour permettre une fonctionnalité croisée, mais pas trop pour ne pas rendre la communication et le partage difficiles. Le problème le plus courant que je rencontre est celui des équipes trop nombreuses. Si vous avez une équipe de plus de 9 personnes, elle est tout simplement trop grande. Les études montrent qu'une équipe de 5 personnes est plus rapide qu'une équipe de 7 personnes.
Comment gérer la propriété du produit et les clients au sein de l'équipe avec un logiciel d'emballage sous film rétractable lorsqu'il existe un large éventail de types de clients ayant des besoins différents ?
Nous aidons toutes nos entreprises à développer des "personas", qui sont des archétypes d'utilisateurs pour le produit. Product Owners devrait suivre notre cours Product Owner pour approfondir ce sujet.
Il faut qu'il y ait une seule "vision" pour un produit. Il peut y avoir différents types de clients (personas) qui achèteront votre produit pour des besoins différents, mais il doit y avoir une personne qui donne la priorité à tous les besoins des différents clients. Est-il plus important de mettre en œuvre une fonction X pour un certain type de client, ou une fonction Y pour un autre ?
Les priorités ne peuvent pas être les mêmes. Si le produit est suffisamment important pour qu'il y ait plusieurs équipes et plusieurs propriétaires de produits, il faut toujours qu'il y ait un chef Product Owner qui puisse régler les questions de priorité au sein de l'équipe des propriétaires de produits. Je recommande vivement que, même dans les grands projets, il n'y ait en fin de compte qu'un seul carnet de commandes organisé par ordre de priorité. La raison en est que l'ensemble du groupe doit se concentrer sur les éléments les plus prioritaires, plutôt que de disperser ses efforts sur les fonctionnalités qu'il juge importantes, plutôt que sur ce que le propriétaire du produit et les clients jugent important.
Lire le Étude de cas Citrix Online pour voir comment prioriser les versions d'un portefeuille de produits au niveau de l'entreprise. Il s'agit d'un autre sujet abordé en détail dans notre cours Product Owner.
Ce cours Product Owner se tiendra à Boston du 31 mai au 1er juin.
French 
English 
Spanish