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

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).

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.

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. .

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.

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

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?).