Hacer un gráfico de trabajo pendiente con 4 sprint

Estamos en un grupo de 3 estudiantes de informática y estamos haciendo un sitio web para nuestro cliente.

Primero, hicimos un diseño para el sitio web, y nos tomó 2 semanas terminarlo. Lo convertimos a HTML y CSS durante otras 2 semanas. Lo hicimos de esta manera porque algunos de los miembros del grupo no están familiarizados con las herramientas que estamos usando, por lo que dedican tiempo a aprender nuevas tecnologías, desde PSD hasta HTML/CSS. Cuando tenemos los formularios comenzamos la parte de codificación.

La motivación detrás de la creación de tal historia es satisfacer las necesidades de nuestro cliente para su sitio web.

Tenemos 4 sprints:

  • 1er sprint es diseño (2 semanas)
  • El segundo sprint es html y css (2 semanas)
  • 3er sprint es base de datos (1 semana)
  • El cuarto sprint es la codificación (3 semanas)

¿Cómo puedo hacer una historia que apunte desde el 1er sprint hasta el 3er sprint? Necesito hacer un gráfico de trabajo pendiente para esto, pero no sé qué hacer.

¡Hola y bienvenido a PMSE! Para mejorar las respuestas, sería genial si pudieras agregar algunos detalles más: ¿De qué tipo de historia estás hablando? ¿Cuál es tu motivación detrás de crear una historia así? ¿Por qué necesita crear un gráfico de evolución para esto ?
Hola Phamela, edité esta publicación para incluir detalles de los comentarios. ¿Puede aclarar si tenía la intención de usar Scrum para este proyecto o simplemente está tomando prestados componentes de él? Gracias.
Estamos destinados a usar Scrum, gracias por editar mi publicación.

Respuestas (3)

Si todo lo que está buscando es un gráfico de quemado para medir el progreso, le sugiero dividir cada sección en tareas y no preocuparse por las historias. Cada una de estas tareas se puede estimar en horas y puede quemar las horas de las tareas completadas. Esto le permitirá realizar un seguimiento del progreso y adaptarse a su horario.

User Stories es un concepto que realmente no se aplica a la forma en que ha dividido su trabajo, ya que son piezas de funcionalidad de usuario de extremo a extremo que abarcan los 4 sprints. Si crea historias de usuario, no habrá completado ninguna hasta el final con su horario actual, haciéndolas inútiles para el seguimiento del progreso.

Lo que te ayudará en un futuro próximo no es la aplicación de un framework específico sino algunos aspectos básicos. Esos aspectos subyacen en casi todos los marcos:

  • Conozca sus requisitos. No importa si los documenta por Historias de usuario o requisitos atómicos
  • Haga un plan de proyecto / lista de tareas / cartera de pedidos , cómo cumplir con esos requisitos (parece que ya tiene esto)
  • Manténgase transparente dentro de sus equipos con respecto a las tareas actuales, las tareas terminadas y los problemas futuros mediante la introducción de charlas breves de forma regular utilizando su plan de proyecto / lista de tareas / trabajo pendiente
  • Trate de prever los próximos problemas pensando en los posibles riesgos dentro de su equipo

Sin saber demasiado sobre PM ágil, esos pasos lo llevarán a una ejecución clásica en cascada , tal vez con algunos aspectos ágiles, por ejemplo, diarios. Con respecto a su experiencia (estimada) y la fecha de vencimiento de su proyecto, esta no será una mala elección .

Por cierto, como es habitual cuando se trata de temas complejos. Todos los aspectos que destaqué aquí son un campo de estudio por sí mismos. Si encuentras alguno interesante, solo busca en Google las palabras de moda :)

No estás haciendo Scrum

Según su pregunta, no parece que esté haciendo Scrum en absoluto. En Scrum, el objetivo de un equipo de desarrollo es producir un incremento de producto potencialmente entregable que pueda proporcionar un valor real a los usuarios finales. Si está dividiendo los sprints en diseño, HTML/CSS, base de datos y codificación, en realidad no está haciendo Scrum sino en cascada.

En su lugar, la cartera de productos debe contener historias de usuarios que representen los problemas que tienen los usuarios y que luego el equipo de desarrollo pueda tomar y convertir en un software funcional. Para hacer esto, una sola historia de usuario podría descomponerse en todas las tareas anteriores, base de datos, diseño, HTML/CSS, codificación, etc., pero solo para una sola historia de usuario o para varias historias de usuario que el equipo pueda comprometer. para completar en un solo sprint.

Para aclarar, en Scrum, todas estas actividades se realizan en cada sprint , no se dividen en diferentes sprints.

Gráficos de evolución

En cuanto a su gráfico de evolución, el gráfico en sí debe representar la cantidad de puntos de la historia que aún no se completaron en ese sprint. Esto se basa en la estimación del esfuerzo que hace el equipo durante la reunión de refinamiento del trabajo pendiente con el propietario del producto.

Una historia de usuario no se considera "terminada" hasta que se completan todas las tareas que cumplen con los criterios de aceptación y la definición de finalizada. Una vez más, esto significa que el diseño, la codificación, HTML/CSS, la base de datos, etc. deben completarse para que una historia de usuario se marque como finalizada.

Más información sobre Scrum

Hace unos momentos, ocho de nosotros en nuestra oficina acabamos de completar la capacitación Certified ScrumMaster de Scrum Alliance. Antes de comenzar Scrum, recomiendo concentrarse mucho en aprender lo que significa Scrum. Un buen lugar para comenzar es el libro de Jeff Sutherland Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo , así como la Guía de Scrum . Si es realmente serio, le recomiendo tomar el curso Certified ScrumMaster.

Gracias por recordármelo y explicarlo, le pregunté a mi maestra al respecto y ella dijo que está bien que me guste lo que mencioné anteriormente, pero ahora explicas más y es un buen comentario que recibí de ti =)
La publicación original nunca afirmó que estaban haciendo Scrum, aunque la etiqueta podría eliminarse. Tampoco creo que una respuesta deba anunciar el curso Certified Scrum Master.
@SpoonerNZ, después de ver los comentarios, creo que es posible que esta respuesta deba modificarse para abordar la pregunta en su nueva forma. En cuanto a la capacitación CSM de Scrum Alliance, no estoy afiliado a ella en absoluto, ni estoy afiliado al libro Scrum de Jeff o la Guía Scrum. Consulte la guía de nuestro centro de ayuda sobre spam y autopromoción .
Además, ¿otras metodologías ágiles utilizan el término "sprint" y "story points"? Pensé que eran específicos de Scrum, pero eso puede ser una suposición incorrecta.
Mucho de lo que comúnmente se considera parte de Scrum son en realidad solo conceptos que se usan a menudo con Scrum. Eche un vistazo a la guía de Scrum ( scrumguides.org/scrum-guide.html ) y verá que mucho de esto NO es scrum, pero sigue siendo útil. Disculpas si soné grosero, pero creo que hay certificaciones mucho más valiosas que la capacitación de Scrum Alliance, ciertamente dentro del Reino Unido donde resido.
Gracias SpoonerNZ. Estoy aprendiendo mucho con todas las respuestas que obtuve de aquí, disculpas por mi publicación. Soy nuevo con Agile y estoy aprendiendo de mis errores =)