Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

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 está en preventa mi libro Curso práctico de Scrum: Algo más que teoría

Mi nuevo libro, Curso práctico de Scrum: Algo más que teoría ya está en preventa en Amazon.es, Amazon.com y Amazon.com.mx. Puedes pedir una copia ya, que te será entregada en tu ebook el próximo domingo 10 de septiembre.

En este libro encontrarás capítulos como:
  • Scrum funciona y te explicaré cómo lo hace
  • Los valores que están detrás de Scrum
  • Teoría de Scrum
  • El equipo de trabajo de Scrum
  • Ceremonias de Scrum
  • Herramientas de Scrum
  • Kanban con Trello
  • Los errores más habituales en Scrum
  • Ventajas y desventajas de Scrum
Ya sabes, no lo pienses más y adquiere ya tu copia de Curso práctico de Scrum: Algo más que teoría.

Los valores que están detrás de Scrum (II)

Responding to change over following a plan
Si al inicio del proyecto trazamos un plan inmutable por el cual en el primer mes tendremos una funcionalidad A, en el segundo mes las funcionalidades B y C, en el tercer mes la funcionalidad D y seguimos así hasta el final del proyecto tendremos una planificación reluciente que, aparentemente, nos conducirá sin un solo problema hasta el final del proyecto.
Pero la realidad es tozuda y en algunas funcionalidades tardamos más de los previsto, en otras menos. En otras ocasiones nos pedirán que modifiquemos una o dos de las funcionalidades o que quitemos una tercera porque ya no hace falta. El resultado se traducirá en un millón de modificaciones al diagrama de Gantt y mucha presión para que las funcionalidades estén listas en el mes prefijado sin tener en cuenta la gran cantidad de cambios que han habido.
Es necesario hablar constantemente con el cliente, explicarle los cambios y volver a colaborar con él para reajustar la planificación o roadmap previsto. Puede que termine con una lista de funcionalidades distintas pero será las que él ha pedido y no las que se grabaron a fuego al inicio del proyecto y que se terminaron haciendo sean ya útiles o no.
De este Agile Manifiesto salió también una lista de doce principios a seguir por todas las metodologías ágiles. Uno de estos principios es:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Parece obvio que esto es lo que debe hacerse en cualquier desarrollo, y con ese ánimo comenzamos cada nuevo proyecto, pero pronto comienzan las prisas. Nuestro director nos pregunta cuántas horas llevamos empleadas (y llevamos ya muchas), nuestro cliente nos pregunta cuándo va a tener listas todas las funcionalidades y nuestros compañeros de trabajo nos preguntan si ya pueden cogerse las dos semanas de vacaciones que les debemos.
Empieza a pintar feo. Ya nos hemos vuelto a meter en un jaleo. Tenemos que volver a rehacer el diagrama de Gantt con las nuevas fechas de entrega programadas, tenemos que buscar otras fechas para las vacaciones (incluso las nuestras) y tenemos que dar un montón de explicaciones al director: ‘Es que nos han pedido cambios, es que las tecnologías eran nuevas, es que estimamos mal’.
A partir de aquí es cuando tendemos a ponernos firmes, a exigir un esfuerzo adicional al Equipo de Trabajo y a negar cualquier pequeño cambio al cliente. Si no está exactamente escrito así en el contrato que firmamos o en el acta de una reunión que tuvo lugar hace ocho meses, lo siento, pero no lo haremos.
El caso es que el cliente también hizo esto. Redactó un contrato muy claro en el que te dijo cada una de las funciones que quería (o las que quería en el momento de redactarlo). Quizás ya no las necesite o se haya dado cuenta de que hay otras más importantes pero están en el contrato y hay que hacerlas. El proyecto no puede acabar y dejar un 30% de funcionalidades por hacer.
En este momento ya hemos perdido de vista la que debe ser la máxima prioridad en nuestro trabajo. Entregar de forma continua software que funcione y que aporte valor. A partir de aquí ya no quedan sino duras negociaciones y un contrato que trataremos de cerrar cuanto antes con el menor daño posible.
El contrato podrá tener muchos artículos y estipulaciones pero, ponga lo que ponga, cuando el cliente lo redactó lo que quería era una solución a su problema, no una discusión sobre si se debe o no implementar esa función o la otra.
Pero, si vamos entregando cada poco tiempo el software que vamos haciendo, lo dejamos para que lo pruebe y lo use, que nos diga su opinión. Dejemos que encuentre lo que echa en falta o lo que podría mejorar. Va a querer que le implementemos esto que ahora ha visto que necesita y estará encantado de quitar a cambio esa funcionalidad para exportar a ficheros .rpt que ya ni se acuerda de quién se lo pidió ni por qué.
Al finalizar el proyecto el cliente tendrá un producto que de verdad resuelve sus problemas, que ha ido evolucionando a medida que él mismo aprendía y que ha podido usar y probar desde las primeras semanas del proyecto. Suena mejor para cliente y proveedor ¿no?
Otro de esos principios que rigen Scrum es:
Working software is the primary measure of progress.
Cuántas veces no nos habremos puesto a escribir software y sin enseñárselo a nadie ni que nadie lo use hemos ido poniendo cada semana o cada mes que íbamos por el 30, 40 o 50% del software hecho ¿Cómo podíamos haber sabido esto si nunca estuvo todo el software funcionando junto ni lo vió ningún responsable para saber que eso era en verdad lo que ellos requerían?

Esos porcentajes eran una simple estimación, una medida de progreso que no se basaba en una realidad constatable. Por esto se definió este principio: El software funcionando es la principal medida de progreso. Si hemos hecho 10 de las 20 funcionalidades que nos han solicitado, éstas son de tamaño similar, las hemos probado, hemos recibido la aprobación del cliente, entonces, y sólo entonces, podremos decir que nuestro proyecto está completado en un 50% (mejor aún si ese 50% ya ha sido subido a producción y ha sido usado por usuarios reales que son la verdadera prueba de fuego).

Suscríbete