¿Qué haces si el desarrollador asume una tarea que estaba destinada a ti y no puede terminarla a tiempo?

Actualmente estoy trabajando con un par de estudiantes en un proyecto de curso (2x8h por semana).

En la planificación del último sprint, tomamos una historia principal de backlog para implementar, y se esperaba que yo fuera el principal implementador de la misma, además de una mano amiga.

Ahora, el primer día tuve que hacer un par de tareas de back-end (de las cuales soy responsable actualmente) y mi mano amiga, llamémosle Jerry, explora la tecnología. Una vez que volví a la tarea real, Jerry encontró una buena biblioteca para ayudar con la implementación y ya la probó, y acepté la biblioteca.

Pero cuando traté de colaborar sobre cómo implementar la función, Jerry me informó que desea implementar la función por sí mismo, a lo que acepté porque quería darle la oportunidad de demostrar su valía (todavía no ha escrito mucho código). ). Más tarde me pidió que escribiera pruebas para la función, lo cual hice, pero él no las usa y él mismo no escribe ninguna prueba (aparte tuve dificultades para escribir pruebas ya que se supone que no debo cambiar nada en su código).

El problema es 1) No creo que pueda hacerlo a tiempo (tenemos un sprint de 5 días, quedan dos días). 2) Me temo que esto se reflejará mal en mí, ya que tenía la intención de escribir la función. ¿Debería decir que se hizo cargo de la función en el próximo diario?

Probablemente se adapte mejor a Workplace SE.
@Sarov, ¿recomendaría cambiar la pregunta de alguna manera para que se ajuste mejor, o la naturaleza si la pregunta no encaja en la tarde? Pensé que debería ser en la tarde, ya que se trata de un proyecto y de Workplace más para un trabajo real en el que ganas dinero.
Hmmm. En una segunda mirada, supongo que puedo ver ambos aspectos. Escribiré una Respuesta.
Sin embargo, sugeriría eliminar las quejas personales que tiene con el compañero de trabajo, que no tienen nada que ver con el proyecto. Pregunta por los de Workplace.
@Sarov Traté de eliminar la parte que sugirió, espero que esté más claro ahora. Gracias

Respuestas (2)

Sus procesos se ven rotos.

El Sprint no pretende ser un compromiso que la empresa pueda usar para castigar a los desarrolladores por no cumplir.

Me temo que esto se reflejará mal en mí, ya que tenía la intención de escribir la función.

... ¿Quién dijo que esta función estaba destinada a usted? En Scrum, el trabajo se asigna al Equipo, no a los individuos. Si se asignó al equipo, ¿por qué se reflejaría mal en usted específicamente? Si se le asignó específicamente, ¿por qué otro desarrollador está trabajando en ello?

¿Debería decir que se hizo cargo de la función en el próximo diario?

El Daily Scrum no pretende ser un tirón de estado. ¿A quién le estarías informando de esto? ¿Por qué necesitan saber? El equipo debe estar facultado para abordar estos problemas por sí mismo.

Su proceso está roto. No pareces estar siguiendo Scrum, a pesar de mencionar Sprints. Deberías buscar arreglar tu proceso. Habiendo dicho eso...

Individuos e interacciones sobre procesos y herramientas

Sólo habla con el tipo. Ambos son (presumiblemente) adultos razonables y profesionales. Hable con él, dígale cómo se siente (trate de usar 'yo', no 'usted'), y luego pídale su opinión y escuche.

Para saber cómo hacerlo, es mejor que pregunte en Workplace o ipse.

No me di cuenta de que la asignación específica para mí no importa en absoluto, ya que solo se asigna al equipo desde el punto de vista del Scrum Master. Entonces, al Scrum Master no le importaría en primer lugar. Para aclarar, el equipo me asignó en la planificación del sprint. Gracias.
@Propósito Estás diciendo lo anterior como si el maestro de scrum estuviera de alguna manera a cargo de las cosas, que es incluso menos Scrum que las otras cosas que mencionaste. En todo caso, su Scrum Master es quien se supone que debe decirle cosas como las anteriores y ayudarlo a ser mejor en Scrum, no hacerlo sentir mal por hacerlo mal. Es su trabajo asegurarse de que haga Scrum correctamente, no es su trabajo asegurarse de que complete su trabajo.

1) No creo que pueda hacerlo a tiempo (tenemos un sprint de 5 días, quedan dos días).

Si este es el caso, simplemente plantéele el problema. Dile: "Jerry, si trabajas solo en esto, creo que no lo entregaremos en el tiempo que queda. Por favor, déjame ayudarte". Si se niega, plantealo con el Scrum Master (es un impedimento). Este es un tema para la Retrospectiva de Sprint.

2) Me temo que esto se reflejará mal en mí, ya que tenía la intención de escribir la función. ¿Debería decir que se hizo cargo de la función en el próximo diario?

Todo el Equipo de Desarrollo es responsable de entregar los elementos del Sprint Backlog, incluidos ustedes dos. Por lo tanto, hable con Jerry en el momento en que se dé cuenta de que (como equipo) no entregarán el artículo. Si no ayuda, plantee el problema en el Daily Scrum.

No se trata de avergonzar o (evitar) la responsabilidad. Se trata de transparencia. Sea amable y hable sobre el problema en sí ("Creo que no lo entregaremos si solo un desarrollador trabaja en él") y no señale con el dedo.