Mientras era estudiante en Apple Developer Academy @ BINUS, tuve la oportunidad de convertirme en Gerente de Proyectos y Productos durante los últimos 4 meses, en la construcción de KOBAR, una aplicación educativa de gamificación.

Apoyando a mi equipo como Gerente de Proyectos y Producto, Project Management tiene muchas herramientas que se pueden utilizar, tanto en la metodología de trabajo como en su propio software. Durante 4 meses, mi equipo ha utilizado la metodología SCRUM donde se ha convertido en una rutina para el equipo realizar reuniones de sprint, scrums diarios, revisiones de sprint y retrospectivas de sprint.

• Sprint controla el mecanismo de arrastre que limita la sobrecarga de entrada,
• La planificación de Sprint permite la autoevaluación de cada tarea que inicia la lucidez y el crecimiento con respecto a DoD (Definición de Hecho).
• El desarrollo diario de Scrum mejora la coordinación entre el equipo para mostrar y expresar sus ideas.
• La revisión de Sprint incluye al equipo Scrum junto con los demás accionistas. Lo que toma los comentarios del equipo de scrum y también se ha realizado una inspección aquí.
• La retrospectiva de Sprint brinda la oportunidad de examinar los obstáculos del momento y recibir suplementos para el próximo Sprint.

Usamos la asistencia de JIRA para la gestión de proyectos porque en este software, se nos ayuda a poder delegar tareas fácilmente a cada individuo, asistidos si habrá un problema secundario en la cartera de pedidos.

“Los que planifican lo hacen mejor que los que no planifican, aunque rara vez se apegan a su plan”. —Winston Churchill

Al comienzo del período del proyecto, todos los trabajos pendientes aún se pueden completar de acuerdo con el tiempo predeterminado. La división de tareas, fueron claras y estructuradas de acuerdo al cronograma deseado. Sin embargo, cuando ingresa al período de desarrollo, hay muchas cosas que deben ajustarse para que sea un poco abrumador para el equipo completar las tareas asignadas.

Aquí es cuando surgen los problemas, muchas veces cuando se debería haber completado una tarea y comenzar el siguiente sprint, el equipo no ha podido completarla. Al principio estábamos confundidos ¿por qué? ¿El tiempo dado no es suficiente?

Pero se sabe que el principal problema es,

hay demasiada acumulación en un sprint, donde no podemos alinear las expectativas con la realidad.

Entonces, ¿por qué ocurre este problema?

• Sobreestimamos lo que podíamos completar en una iteración.
• Uno de los elementos de trabajo era mucho más grande de lo que esperábamos.
• Las inyecciones de servicio/trabajo no planificado entraron en la iteración.

Comprenda la causa raíz y descubra cómo evitarla. Mi equipo usa la retrospectiva del sprint para evaluar la causa y aprender de ella. Cada persona del equipo comparte su perspectiva y cómo superarla.

Discutir el futuro de cada backlog

• Si el backlog tiene una alta prioridad, debería ser útil mover el mismo backlog al siguiente sprint . Tal vez el tiempo dado no sea suficiente con el tamaño de los elementos de trabajo, por lo que aún está bien
• Si el trabajo pendiente tiene una prioridad baja, determine si el trabajo pendiente se puede desglosar y mueva el trabajo pendiente al trabajo pendiente del producto.

Todo basado en mi experiencia y respaldado por los recursos de:

¡Cualquier comentario es muy apreciado! por favor, ¡golpéame aquí !

© 2022 Nathania Joyce Irene. Reservados todos los derechos.