¿Cómo manejar las dependencias 'externas' en scrum?

13

Si ha planeado varias historias de usuario para un sprint y una historia candidata depende de que algún proveedor externo le entregue algo a su equipo. Por ejemplo, un proveedor de servicios en línea que agrega una nueva llamada a la API a su sistema o habilita su cuenta de prueba en su sistema o similar.

Sabes que llegará 'pronto'.

Continúa y agrega la historia al sprint con la esperanza de que te proporcionen lo que se requiere a tiempo para que completes tu historia o ¿esperas hasta el próximo sprint, cuando lo sepas? Estará listo y podrá comenzar de inmediato, incluso si eso significa no comenzar la historia lo antes posible.

Si el primero, ¿cómo maneja los puntos de historia 'no ganados' perdidos debido a la dependencia? crédito parcial (eek!) o llévalo a la barbilla.

    
pregunta TygerKrash 03.10.2011 - 14:09

6 respuestas

12

En última instancia, depende de si está 100% seguro de que el proveedor externo le proporcionará algo que puede usar en el momento en que lo necesite.

Si no puede estar seguro de que se entregarán a tiempo, no agregue la historia al sprint. Sin embargo, solo porque siempre han realizado entregas en el pasado, no hay garantía de que lo hagan esta vez.

Debe informar al cliente que existe esta dependencia y que tendrá que esperar a que la API (o lo que sea) esté disponible antes de poder programar el trabajo.

En el lado positivo, puede haber aspectos de la historia que puede ofrecer, es decir, descomponerla hasta que haya aislado las dependencias tanto como sea posible. Esto podría permitirle hacer parte de la historia antes de que el proveedor realice su trabajo.

Una cosa que podrías hacer es crear una interfaz entre tu código y la API de terceros. Codifica a su interfaz para que el resto del proyecto pueda continuar y hasta que tenga la API real use un simulacro para devolver datos de ejemplo. Luego, cuando llega la API real, solo tiene que cambiar el código detrás de la interfaz que no afectará al resto de la aplicación. Solo haga esto si puede estar de acuerdo con el proveedor de la API de que su interfaz no cambiará (al menos no drásticamente).

    
respondido por el ChrisF 03.10.2011 - 14:42
12

El equipo es el que hace el compromiso. En nuestro equipo, si sentimos que estamos esperando (por ejemplo) un desarrollador externo, hemos aprendido a decir que no estamos dispuestos a continuar con la historia. La historia no está en condiciones de retomar.

Existe una gran posibilidad de que la entrega tardía, inesperada o diferente del recurso externo signifique que sus estimaciones y prioridades podrían cambiar.

Hasta que tengas toda la información, el equipo no debería ser tan ingenuo como para pensar que puede completar la historia. Si dicen que pueden, entonces llega tarde, en un formato esperado, o en absoluto, han decepcionado a todos.

Suena duro, pero quiero transmitir mi punto.

    
respondido por el Kieren Johnstone 03.10.2011 - 14:35
4

En Scrum hay una definición de hecho y hay una definición de listo para historias de usuario. En una situación como la suya, es importante tener una definición de lista que todos los interesados comprendan y estén de acuerdo. Por ejemplo, parece muy razonable tener una línea en su definición de listo como:

  • Todas las API externas necesarias para la historia deben entregarse y probarse.

Si necesita esta API para agregar valor a su producto, lo lógico es esperar hasta que tengamos esta API para comenzar nuestro trabajo. Mientras tanto, podemos hacer otros EE. UU. Que agreguen valor al producto. Realmente no me gusta este EE. UU. Con implementaciones simuladas y similares. Si no hay un valor real para el cliente, no hay EE. UU., Es una pérdida de tiempo y recursos. .

    
respondido por el AlfredoCasado 19.02.2014 - 02:16
2

Si está esperando algo que aún no sabe, no puede planearlo, incluso si está 100% seguro de que se entregará mañana. ¿Por qué? Porque si no lo sabes, ni siquiera puedes estimar su complejidad y si no puedes estimarlo, no puedes planearlo.

Si definió por adelantado una "interfaz" / "contrato" que debe ser seguido por una empresa externa, puede planificarlo y crear un servicio simulado de su lado. Su desarrollo utilizará el servicio simulado para que no dependan de la entrega externa. Aún se debe planificar el desarrollo con simulacro para el sprint donde se entregará el servicio real porque la característica desarrollada y probada contra el simulacro no se ha completado, debe probarse con el servicio real para que se considere como completada al final del sprint.

    
respondido por el Ladislav Mrnka 03.10.2011 - 16:44
2

Comunicación y acuerdos

Los programadores integran dos sistemas, no la metodología en sí. Si una empresa ha decidido integrar un sistema externo, habrá un contrato entre (mínimo) 2 entidades. El contrato debe garantizar que se realice la integración . En consecuencia, si el acuerdo entre las empresas, no requiere una colaboración técnica entre ambos departamentos, el problema no es la metodología de desarrollo. El problema es la metodología comercial (básicamente el contrato) .

Habiendo dicho eso, debe considerarse un riesgo durante la planificación de esos casos y, dado que no conoce la velocidad del equipo, deberá Sé generoso con esos márgenes.

¿Cómo puede un gestor de proyectos gestionar una dependencia en un equipo externo?

enlace

    
respondido por el marcocs 19.02.2014 - 07:26
1

Si no depende de tu equipo y puedes hacer otras tareas, te aconsejo que solo lo tomes cuando esté listo. Incluso si tienes un servicio web, un esquema, una interfaz y / o un contrato de maqueta, todavía se puede romper (¿recuerdas la Ley de Murphy?).

    
respondido por el Pedro Polonia 19.02.2014 - 01:39

Lea otras preguntas en las etiquetas