¿Deberían los desarrolladores de clientes formar parte de nuestro equipo de scrum?

Si durante un sprint alguna tarea depende del desarrollo del cliente, ¿deberían considerarse los desarrolladores del cliente como parte del equipo?
En la reunión de planificación del sprint, ¿deberían asistir estos desarrolladores para compartir cuánto tiempo se dedicará a esa tarea?

Respuestas (7)

Creo que deberías hacer todo lo posible para que estas personas formen parte de tu equipo. Eso significará que seguirán las reglas que configuró en el proyecto. Eso significará que controlará mucho mejor la situación y logrará los objetivos del proyecto con mucha más confianza. Por lo tanto, la respuesta es " SÍ, POR SUPUESTO ".

Siento que el desarrollador del cliente (puede ser el líder del equipo) puede participar en la planificación del sprint. Esto es para mantener a todos en "la misma página" y asegurarse de que todos sepan en qué horario están y que conozcan el plan para "hacer las cosas". Al mismo tiempo, no es necesario que estén activos en otras reuniones.

No, no controlas sus horarios ni los gestionas.

Esto solo puede llevar a señalar con el dedo.

No, los administra con el Área de conocimiento de adquisiciones. Si son parte del equipo del proyecto, deben administrarse como una adquisición.

Bueno, no vi el Agile y el scrum, lo siento ma mal. Entonces sí, es una buena idea incluir un desarrollador líder de clientes. Si estuviéramos administrando usando PMP Framework, esto debería considerarse diferente, como una adquisición.

No es una mala idea, en mi opinión. Ciertamente mejorará la aceptación y la comprensión. Sin embargo, si es solo para un solo sprint, no estoy seguro de si vale la pena.

Pero incluso si lo hace, aún manejaría esto como una dependencia de su proyecto y lo seguiría muy de cerca.

La forma ideal de coordinar sería hacer que esa persona participe en sus scrums, o que un representante lo haga para informar el estado. Esto mantendrá abierta la comunicación, que es la única forma de coordinar de manera confiable las dependencias fuera de su equipo.

Si esto no es posible, crearía una historia para que un miembro del equipo maneje la relación: se comunique con el cliente, dé y obtenga estado y progreso, y asegúrese de que las cosas se integren bien una vez que entreguen lo que entreguen.

Porque al final del día, tendrás que integrar su trabajo con el tuyo de alguna manera. Incluso si lo trata como una adquisición. Es mejor identificarlo como una historia y administrarlo de manera proactiva.

A menos que se conviertan en miembros de pleno derecho del equipo, diría que no . No tendrían ningún compromiso con tus objetivos de sprint.

En su lugar, organizaría una reunión extra diaria (breve y limitada en el tiempo) con dependencias externas. Esto podría ser con desarrolladores de otros equipos, otras empresas o diseñadores externos. Algunos podrían llamarlo una especie de reunión Scrum-of-Scrums para externos.

He trabajado en un equipo donde dependíamos de otro equipo (externo) Web-service/API. Las reuniones diarias fueron un excelente lugar para discutir los impedimentos con los que nos encontraríamos y para discutir los próximos cambios para adaptarnos (actualizar la acumulación) a tiempo. Si depende completamente de una característica del otro equipo (que deben entregar en el mismo lapso de tiempo), sugeriría simular su trabajo para que pueda entregar un producto "funcional" dentro del sprint.