Ajedrez - antoniomartel.com

Archivos por Etiqueta: teoría

Error nº 8: El Scrum Master reparte las tareas

Se trata de que los equipos de trabajo sean auto-organizados y se repartan ellos mismos las tareas. Ellos son quienes mejor saben cómo hacer el trabajo y cómo mejor repartírselo entre ellos. Si dejamos que el Scrum Master o el jefe de proyecto reparta el trabajo probablemente no quede balanceado entre todos los miembros del equipo quedando más peso en unos que en otros o se hayan asignado tareas a alguien que no tiene ahora las habilidades técnicas para resolverlo igual que algún otro.
Si dejamos que ellos mismos, los miembros del Equipo de Trabajo, se repartan las tareas a realizar, el trabajo quedará más repartido y ellos tendrán un sentimiento de reparto más justo. Se trata de que levanten la mano y digan ‘Esa tarea la hago yo’ o ‘Creo que quién mejor puede hacerla es Carolina’ a lo que Carolina puede responder ‘Quizás sí, pero ya tengo asignadas las tareas 14 y 16 ¿Qué tal si la hace Fernando? Ya lo hizo una vez y puede ir ganando más experiencia con eso’.

Error nº 7: Reuniones diarias de Scrum demasiado largas

Esto suele suceder cuando las reuniones de la Daily Scrum se utilizan para resolver los problemas y las dudas que se están teniendo en el trabajo diario. Esta es una reunión que debe mantenerse muy corta y en la que sólo deberemos comentar lo que hicimos ayer, lo que se hará hoy y qué problemas nos estamos encontrando o vamos a necesitar solución.
Es en este último punto cuando todo el mundo tiene una posible solución y la comenta en la reunión por lo que ésta se alarga y alarga con los comentarios sobre un problema que quizás sólo atañe a una o dos personas y a que a las otras no afecta directamente por lo que se aburren y pierden un tiempo en el que podrían estar ya desarrollando.
Aquí el Scrum Master debería mantener bajo control estas reuniones para que no se vayan de tiempo y hagan perder el tiempo a todo el mundo. Siempre que una discusión sobre un problema comience, deberá emplazar esta discusión para otro momento en el que sólo intervengan las personas involucradas y quizás algún tercero que no está en la reunión diaria pero cuya opinión pueda ser importante.
Es esencial también que no olvidemos tener esa otra reunión para resolver el problema ¿Para qué si no se avisó de que había un problema? Si no puede resolverse durante la reunión diaria debe atenderse en algún otro momento del día o días posteriores para ponerle solución.

Error nº 6: Diseñar todo el proyecto desde el inicio

En Scrum es mejor no diseñar todo el proyecto antes de comenzarlo. Analizarlo todo, diseñarlo todo, construir un gran documento de requisitos de proyecto muy detallado es volver a trabajar como en los clásicos proyectos en cascada. Todas las especificaciones han sido declaradas desde el inicio y no hay posibilidad de cambio.

A estos diseños se les llama big up-front design y no permiten adaptarse a los cambios que pueden verse necesarios a medida que se va construyendo porque todo está ya especificado en un gran diseño antes de comenzar a construir una sola línea de código.

Si tienes una lista de producto pequeña al inicio, que puede ir creciendo a medida que se va avanzando en el proyecto y que se va adaptando a las opiniones y necesidades del Interesado, podrás construir un mejor producto que si haces todo o buena parte del diseño por adelantado. Mientras se va construyendo el proyecto, incluso puede que ya lo estén usando. Alguno de los Interesados puede opinar que es mejor crear una exportación a MS Excel de los informes, y esto es algo en lo que nadie había pensado por lo que no se incluyó en el diseño hecho por adelantado al inicio del proyecto.

Puede también que ya no estén tan interesados en la integración con el sistema de contabilidad Contaplus. Es un desarrollo muy complejo para las ventajas que se obtendrían y corre el rumor por la empresa que el sistema de contabilidad será migrado a SAP antes o después, así que para qué desarrollarlo ¿Qué hacemos ahora con todas las horas que usamos para diseñar esa integración con Contaplus? Puede incluso que ya estén preparadas las clases y los esquemas de base de datos con los campos necesarios para esa integración y ahora ya no van a ser usados.

Errores más habituales de Scrum (II)

Error nº 3: Pruebas insuficientes

El proyecto se te ha vuelto una pesadilla, todas las tareas hay que volver a abrirlas cuando se está terminando el proyecto porque el cliente las rechaza en las pruebas de aceptación o porque se convierten en bugs una vez están en producción. Los Interesados están descontentos y tu equipo está más tiempo buscando y corrigiendo incidencias que desarrollando nuevas funcionalidades que den más valor al producto. Para colmo de males todos están perdiendo los nervios con la situación.

Esto es señal de que en cada Sprint se han estado entregando las cosas sin estar realmente terminadas y sin ser suficientemente probadas. Una forma de probar más y mejor es automatizando los tests con pruebas unitarias, o tests de regresión y de integración con herramientas como JUnit, o de record&play como Selenium IDE. Irás creando unos pocos tests más cada Sprint para probar las historias de usuario desarrolladas en ese Sprint y el núcleo de la aplicación pero añadirás más el siguiente Sprint mientras se siguen probando automáticamente las pruebas de todos los sprints anteriores.

Los tests automatizados difícilmente sustituirán totalmente a los testers y a las pruebas manuales. Resérvate los dos o tres últimos días del Sprint para que se pare el desarrollo de funcionalidades y todos los miembros del equipo comiencen a probar las funcionalidades ya hechas para asegurarse de que están completamente libres de errores. Cada uno puede probar sus propios tickets y al terminar pueden coger las tarjetas de otros y comenzar a probar las funcionalidades de los demás miembros del equipo.

Error nº 4: Todos los entregables están grabados a fuego hasta el día del juicio final

Esto sucede cuando la Lista del Producto ha sido dividida en fases coincidiendo los sprints con una serie de entregables definidos desde el inicio del proyecto. Es decir, que si tenemos que entregar 80 funcionalidades en un proyecto de un año, se definirá desde el arranque del proyecto que debemos entregar 3 funcionalidades en los 26 sprints del año (suponiendo sprints de dos semanas) y además se definirá qué tres funcionalidades en concreto se van a entregar y éstas son inamovibles.

Esto puede convertir al proyecto en un terror de noches sin dormir porque en este Sprint hay que entregar las funcionalidades P, Q y R y en los sprints pasados no pudieron terminarse E, H, J y L. El trabajo se nos acumula. Además no estamos dando la oportunidad de redirigir el proyecto dando más peso a unas funcionalidades, quitándoselo a otras para añadir o quitar funcionalidades según lo que se demuestre más efectivo o importante.

La Lista del Producto se ha convertido en un contrato y cada Sprint en otro del que además arrastramos errores y deuda técnica dejada en el anterior. No se deja hueco para trabajar más en unas funcionalidades que llevaron más tiempo del previsto inicialmente. Todo está fijado y anclado a una estimación que se hizo al inicio del proyecto cuando no se tenía idea de qué iba a ser más fácil, qué más difícil o que podía obviarse por resultar irrelevante. Cumpliremos el ‘contrato’ de nuestra estimación diga lo que diga aunque el tiempo haya demostrado lo equivocado que estábamos cuando la hicimos.

Ya a la venta el libro Curso Práctico de Scrum

Ya está a la venta en Amazon las versiones en papel y electrónica del libro Curso Práctico de Scrum: Algo más que teoría. Puedes comprarlo aún a un precio reducido mientras esté en promoción.

Se trata de eso, de un curso de Scrum en el se explica al teoría de Scrum de forma práctica. En buena parte del libro se sigue la estructura que tiene la guía de Scrum de Jeff Sutherland y Ken Schwaber siguiendo su mismo orden pero evitando las palabras y tecnicismos que son sólo una traducción literal y aderezando las explicaciones con un caso real o ejemplo que te ayude a entender y poner en práctica luego lo que aquí trato de explicarte ¡Espero que te guste!
Curso práctico de Scrum: Algo más que teoría por Antonio Martel
Curso práctico de Scrum: Algo más que teoría

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad