Comment gérer les dépendances «externes» dans Scrum?

Si vous avez planifié un certain nombre d'histoires utilisateur pour un sprint et qu'une histoire candidate dépend d'un fournisseur externe qui livre quelque chose à votre équipe. Par exemple, un fournisseur de services en ligne ajoutant un nouvel appel API à son système ou activant votre compte de test sur son système ou similaire.

Vous savez que ça arrive «bientôt».

Allez-vous de l'avant et ajoutez l'histoire au sprint en espérant qu'ils vous fourniront ce qui est nécessaire à temps pour terminer votre histoire ou attendez-vous jusqu'au prochain sprint, quand vous savez qu'il sera prêt et que vous pouvez commencer immédiatement même si cela signifie ne pas commencer l'histoire le plus tôt possible.

Si le premier comment gérez-vous les points d'histoire «non gagnés» perdus à cause de la dépendance? crédit partiel (eek!) ou prenez-le sur le menton.

En fin de compte, cela dépend si vous êtes sûr à 100% que le fournisseur externe fournira quelque chose que vous pourrez utiliser au moment où vous en aurez besoin.

Si vous ne pouvez pas être sûr qu'ils livreront à temps, alors n'ajoutez pas l'histoire au sprint. Cependant, juste parce qu'ils ont toujours livré dans le passé, il n'y a aucune garantie qu'ils livreront cette fois.

Vous devez informer le client que cette dépendance existe et que vous devrez attendre que l'API (ou autre) soit disponible avant de pouvoir planifier le travail.

Du côté positif, vous pouvez présenter certains aspects de l'histoire, c'est-à-dire les décomposer davantage jusqu'à ce que vous ayez isolé autant que possible les dépendances. Cela pourrait vous permettre de faire une partie de l'histoire avant que le fournisseur ne livre son travail.

Une chose que vous pourriez faire est de créer une interface entre votre code et l'API tierce. Vous codez sur votre interface pour que le reste du projet puisse continuer et jusqu'à ce que la véritable API utilise une maquette pour renvoyer des exemples de données. Ensuite, lorsque la véritable API arrive, il vous suffit de modifier le code derrière l'interface, ce qui n'affectera pas le reste de l'application. Ne faites cela que si vous pouvez convenir avec le fournisseur de l'API que leur interface ne changera pas (du moins pas radicalement).

L'équipe est celle qui s'engage. Dans notre équipe, si nous sentons que nous attendons (par exemple) un développeur externe, nous avons appris à dire que nous ne sommes pas prêts à reprendre l'histoire. L'histoire n'est pas en état de reprendre.

Il y a de très bonnes chances que la livraison tardive, inattendue ou différente de la ressource externe signifie que vos estimations et priorités pourraient changer.

Jusqu'à ce que vous ayez toutes les informations, l'équipe ne devrait pas être si naïve de penser qu'elle peut terminer l'histoire. S'ils disent qu'ils le peuvent, alors cela arrive tard, dans un format attendu, ou pas du tout, ils ont tout laissé tomber.

Cela semble dur, mais je veux faire passer mon message.

Dans Scrum, il existe une définition de done et une définition de ready for user stories. Dans une situation comme la vôtre, il est important d'avoir une définition de prêt que toutes les parties prenantes comprennent et approuvent. Par exemple, il semble très raisonnable d'avoir une ligne dans votre définition de prêt comme:

• Toutes les API externes nécessaires à l'histoire doivent être fournies et testées.

Si vous avez besoin de cette API pour ajouter de la valeur à votre produit, la chose logique est de faire son attente jusqu'à ce que nous ayons vraiment cette API pour commencer notre travail. En attendant, nous pouvons faire d'autres États-Unis qui ajoutent de la valeur au produit, je n'aime vraiment pas ces États-Unis avec des implémentations simulées et autres, s'il n'y a pas de valeur réelle pour le client, il n'y a pas d'États-Unis, sa perte de temps et de ressources .

Si vous attendez quelque chose que vous ne savez pas encore, vous ne pouvez pas le planifier même si vous êtes sûr à 100% qu'il sera livré demain. Pourquoi? Parce que si vous ne le connaissez pas, vous ne pouvez même pas estimer sa complexité et si vous ne pouvez pas l'estimer, vous ne pouvez pas le planifier.

Si vous avez défini à l'avance une certaine "interface" / "contrat" ​​qui doit être suivie par une entreprise externe, vous pouvez la planifier et créer une maquette de service de votre côté. Votre développement utilisera le service simulé afin qu'il ne dépende pas d'une livraison externe. Le développement avec la simulation doit toujours être planifié pour le sprint où le service réel sera fourni car la fonctionnalité développée et testée contre la simulation n'est pas terminée - elle doit être testée avec le service réel pour être considérée comme terminée à la fin du sprint.

Communication et accords

Deux systèmes sont intégrés par des programmeurs et non par la méthodologie elle-même. Si une entreprise a décidé d'intégrer un système externe, il y aura un contrat entre (minimum) 2 entités. Le contrat doit garantir que l'intégration a lieu . Par conséquent, si l'accord entre les entreprises, ne nécessite pas une collaboration technique entre les deux départements, le problème n'est pas la méthodologie de développement. Le problème est la méthodologie commerciale (essentiellement le contrat) .

Cela dit, il doit être considéré comme un risque lors de la planification de ces cas et étant donné que vous ne connaissez pas la vitesse de l'équipe, vous devrez être généreux avec ces marges.

Comment un chef de projet peut-il gérer une dépendance vis-à-vis d'une équipe externe?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Si cela ne dépend pas de votre équipe et que vous pouvez faire d'autres tâches, je vous conseille de ne le prendre que lorsqu'il est prêt. Même si vous avez un service Web maquette, un schéma, une interface et / ou un contrat, il peut toujours se rompre (rappelez-vous la loi de Murphy?).