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

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

Sabes que viene 'pronto'.

¿Continúa y agrega la historia al sprint con la esperanza de que entreguen lo que se requiere a tiempo para que complete su historia o espere hasta el próximo sprint, cuando sepa que estará listo y puede comenzar de inmediato incluso si significa no comenzar la historia lo antes posible.

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

En última instancia, depende de si está 100% seguro de que el proveedor externo le entregará algo que pueda usar cuando 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 entregado en el pasado no hay garantía de que entreguen esta vez.

Debe informar al cliente que esta dependencia existe 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 entregar, es decir, desglosarlos aún más hasta que haya aislado las dependencias tanto como sea posible. Esto podría permitirle hacer algo de la historia antes de que el proveedor entregue su trabajo.

Una cosa que podría hacer es crear una interfaz entre su código y la API de terceros. Usted 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 retomar la historia. La historia no está en un estado adecuado para retomar.

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

Hasta que tenga 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 para nada, han decepcionado a todos.

Suena duro pero quiero expresar mi punto de vista.

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 listo que todos los interesados ​​entiendan 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 realmente 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, entonces no puede planificarlo, incluso si está 100% seguro de que se entregará mañana. ¿Por qué? Porque si no lo sabe, ni siquiera puede estimar su complejidad y si no puede estimarlo, no puede planificarlo.

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

Comunicación y acuerdos

Dos sistemas están integrados por programadores, no por 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) .

Dicho esto, debe considerarse un riesgo durante la planificación de esos casos y teniendo en cuenta que no conoce la velocidad del equipo, deberá ser generoso con esos márgenes.

¿Cómo puede un Project Manager gestionar una dependencia de un equipo externo?

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

Si no depende de tu equipo y puedes hacer otras tareas, te aconsejo que solo lo hagas cuando esté listo. Incluso si tiene un servicio web, esquema, interfaz y / o contrato de maqueta, aún puede romperse (¿recuerda la Ley de Murphy?).