Yo, como algunos otros programadores, no soy un gran fan谩tico de las manifestaciones. A veces, todo este refinamiento de sprint, revisi贸n de sprint y sesiones retrospectivas son molestos.
Los equipos donde trabaj茅 nunca hab铆an
planeado rallyes de
p贸ker , pero recientemente particip茅 en un verdadero equipo alien铆gena. Estoy familiarizado con todo este equipo (con la excepci贸n del nuevo arquitecto), pero nunca vi personalmente la composici贸n completa del equipo en acci贸n, as铆 que observ茅 con inter茅s sus enfoques sobre el trabajo en equipo. Adem谩s de ser bastante divertido, pude aprender algo nuevo y 煤til para m铆. En este art铆culo quiero compartir mis impresiones de participar en un rally de planificaci贸n de p贸ker.
Frecuencia de planificaci贸n de reuniones de p贸ker
Ni siquiera sab铆a que algunos de nuestros equipos practican Planning Poker. El hecho es que en nuestros proyectos, los miembros del equipo de dos oficinas: la oficina principal holandesa y la oficina administrativa rusa. Usar Planning Poker para contenido de sprint en nuestro entorno es simplemente poco realista. Para tales sesiones, necesita reunir un equipo completo en un solo lugar y es dif铆cil organizarlo de manera regular. Por lo tanto, el equipo lleva a cabo tales sesiones solo para tareas atrasadas durante varios a帽os, algunas de las cuales parecen locas y poco realistas para la implementaci贸n, bueno, tareas que requieren m谩s tiempo del que los gerentes est谩n listos para dar en el momento actual. Para estos prop贸sitos, la planificaci贸n del p贸ker es perfecta, en mi opini贸n. Si tiene experiencia en el uso de Planning poker para equipos distribuidos sin reunir a todo el equipo en una sala, ser谩 interesante familiarizarse, darse de baja en los comentarios.
驴Para qu茅 equipos ser铆a beneficioso usar Planning Poker?
El equipo bajo consideraci贸n est谩 desarrollando tanto la parte de software del software para equipos m茅dicos como el software para la parte de hardware correspondiente: firmware. Por lo tanto, tales sesiones ser谩n informativas para la mayor铆a de los miembros del equipo, ya que alguien trabaja con solo una parte y no conoce los detalles y las dificultades encontradas en otras partes del software. Durante el rally, comenzaron muchas discusiones entre las personas con las calificaciones m谩s bajas y m谩s altas: "Es f谩cil hacer esto". S铆, a veces los programadores experimentados hacen una calificaci贸n baja, y en algunos casos la calificaci贸n baja es dada por la inexperiencia, porque este es un firmware de "
sarcasmo" para una pieza de hardware normal, y por qu茅 molestarse durante tanto tiempo
</ sarcasmo> .
Las grandes tareas se desglosan y eval煤an individualmente
La mayor铆a de las tareas conten铆an al menos 3 partes, basadas en los detalles del proyecto: software, firmware y, en realidad, las pruebas. Para sistemas complejos del grupo de elementos constituyentes, se realiz贸 una evaluaci贸n para un elemento.
Puedes invitar a alguien de otro proyecto a participar
Al evaluar la complejidad de una tarea, las preguntas adicionales de los principiantes pueden ser muy 煤tiles. Como entiendes, me invitaron a esta sagrada misi贸n. El hecho es que una persona ignorante puede hacer preguntas que tambi茅n ser谩n 煤tiles para contabilizar las calificaciones de los miembros del equipo. Yo mismo not茅 un par de veces c贸mo, despu茅s de mi pregunta, algunas personas inmediatamente comenzaron a buscar otra tarjeta, aunque ya hab铆a decidido la calificaci贸n.
Tiempo requerido para planificar sesiones de p贸ker
Tales sesiones requieren mucho tiempo. El tiempo de discusi贸n para cada tema depende de la integridad de los requisitos y la comprensi贸n de la soluci贸n del problema. El tiempo de discusi贸n del problema puede variar de 5 a 30 minutos. As铆 que particip茅 para discutir el 煤ltimo tercio de la parte de las tareas pendientes. Tom贸 una hora y media.
Entonces para resumir.
Todo est谩 bien con moderaci贸n. La planificaci贸n de sesiones de p贸ker son actividades 煤tiles, pero requieren mucho tiempo, por lo que no creo que sea aconsejable tenerlas con mucha frecuencia, a menos que tenga tiempo libre. Al reunir tales reuniones de vez en cuando, mantendr谩 una conciencia general del equipo en diferentes partes del proyecto, lo que ayudar谩 a mejorar el proceso de resoluci贸n de problemas. Y para alguien puede ser una buena oportunidad para familiarizarse con otras partes del proyecto en caso de que se aburra de trabajar con el suyo.