Archivos por Etiqueta: SCRUM

La Lista del Producto o Product Backlog

miércoles, 02 agosto 2017 20:07

antoniomartel

0 Comentarios

La Lista o Pila del Producto es una lista ordenada por prioridad de todas las funcionalidades que pueden ser necesarias para incorporar al producto. Tendremos ahí todos los requisitos del proyecto y de esa lista tomaremos un subconjunto para los requisitos que implementaremos en un Sprint. Ese subconjunto de tareas es la que compondrá la Lista del Sprint.

El Dueño del Producto, que es quién paga o quien representa a quien paga el producto, es quién conoce lo que quiere para su producto y quién, por tanto, nos dirá lo que hay que hacer. El definirá los requisitos del proyecto por lo que es él el responsable del contenido de la Lista del Producto y de su priorización.

La Lista del Producto no tiene que estar completa desde el principio, de hecho, nunca está completa. Más requisitos pueden ir llegando a medida que se va avanzando en el proyecto. Al principio sólo contendrá los requisitos conocidos y que están más claros o mejor entendidos.

Si nuestro proyecto proviene de un contrato con nuestro cliente en el que ya se definen las funcionalidades que tendrá el producto podremos comenzar con estas funcionalidades como germen de nuestra Lista del Producto. Pero no de sólo funcionalidades viven los proyectos, hay muchas otras tareas que deberemos realizar y que también van en la Pila del Producto. Tareas como estas compondrán nuestra lista:

Funcionalidades o características del software, por ejemplo: Permitir pago con Paypal
Bugs: Corregir error de certificado no autorizado al acceder a la aplicación
Trabajo técnico: Instalar la base de datos o Preparar los entornos de desarrollo y pruebas con Docker
Adquisición de información: Tomar requisitos más detallados sobre cómo se debe recoger la información de los clientes que pagan a crédito.

La forma habitual en la que se expresan los requisitos en cada una de las tarjetas o elementos que componen la Lista del Producto es como historias de usuario que son descripciones breves del requerimiento. Por ejemplo: «Cómo usuario de la banca online, quiero poder ver una lista de las transferencias periódicas que ya tengo creadas para poder revisarlas antes de crear una nueva«.

Cada poco tiempo y de forma continua el equipo de trabajo deberá acometer una revisión de estas tarjetas o historias de usuario de la Pila del producto para añadirles el detalle suficiente para poder comenzar a trabajar. Esta tarea de revisión se llama Refinamiento (refinement). Podemos tener una tarjeta que diga «Permitir el pago con Paypal» pero no podemos pasar esto así a los desarrolladores, deberemos analizar esto un poco más para añadir «Cuando un cliente está en el sitio web, quiero tener la opción de pagar con PayPal después de haber establecido el pedido, de forma que pueda confirmar la compra«.

Pero aún así, cuando lleguemos al Sprint en el que queramos acometer este trabajo, deberemos de tener esta historia de usuario descompuesta en otras más pequeñas:

«Como usuario de la banca online, quiero tener un enlace a registrarme como usuario de PayPal después de haber realizado el pedido«
«Como usuario de la banca online, quiero poder introducir mi número de tarjeta, fecha de caducidad y número CCD para identificar mi tarjeta después de haberme registrado como usuario de PayPal«
«Como usuario de la banca online, quiero poder hacer clic en un botón ‘Pagar con Paypal’ debajo del subtotal de mi compra para poder confirmar mi pedido«

Los elementos de la Lista del Producto de prioridad más alta estarán normalmente más detallados y más refinados mientas que los de prioridad más baja tienen un nivel de detalle más bajo y son más vagos en su descripción. Debemos trabajar más en el refinamiento de las funcionalidades de más alto nivel que son las que van a ser acometidas en los próximos sprints y evitar dar un detalle muy alto en tarjetas de muy baja prioridad que no sabemos si van a ser acometidas o si tenemos ya toda la información que necesitamos para acometerlas.

Será el equipo de trabajo el que se encargue de proporcionar una estimación para los elementos de la Lista del Producto ya que son quienes van a hacer el trabajo y quienes se están comprometiendo a tenerlo terminado para el final del Sprint. No será necesario que estimen todos los elementos de la Pila del Producto de una sola tacada sino que estimen los que se van a acometer ahora. De este modo tendremos estimaciones más precisas porque los elementos de la lista están más claros y detallados y evitamos perder el tiempo estimando elementos muy abajo en la lista para los que no tenemos suficiente información y que puede que ni siquiera se lleven a cabo.

Retrospectiva del sprint

domingo, 30 julio 2017 20:03

antoniomartel

0 Comentarios

Esta reunión se realiza después de la reunión de demo con el cliente y tiene una duración de tres horas para sprints de un mes. Se trata de una reunión en la que queremos que el equipo Scrum se revise a si mismo y dé feedback de cómo han ido las cosas, por qué no pudieron conseguirse todos los objetivos del sprint, si fue así, y qué podemos hacer para mejorar en el siguiente sprint.

A esta reunión asistirán el Dueño del Producto, el Scrum Master y el equipo de desarrollo. El Scrum Master como siempre se encargará de que la reunión tenga lugar. de que se mantenga dentro de los tiempos máximos definidos y que se traten al menos los siguientes aspectos en la reunión:

Qué cosas han funcionado bien
Qué cosas no han funcionado tan bien y evitaron que pudiéramos demostrar al cliente todo lo que se esperaba de este sprint que acaba de terminar
Qué problemas han impedido o pueden impedir que no consigamos nuestra meta del sprint y que el cliente por tanto no obtenga lo esperado. El Scrum Master se encargará de anotarlas para luego ponerse a resolverlas.

De esta reunión de retrospectiva debería salir un plan, ordenado por prioridad, con las distintas mejoras que podrían implementarse para evitar los problemas detectados.

Existen diversas causas por las que las reuniones de retrospectiva resultan poco provechosas o no todo lo útiles que deberían:

Las reuniones son aburridas y monótonas

La gente puede perder la confianza en las retrospectivas y verlas como una perdida de tiempo si no se toma ninguna acción después de analizados los problemas que se están teniendo. Se están identificando los problemas y se están declarando pero no se hace nada al respecto o tarda mucho en tomarse consciencia de lo que están suponiendo. Debemos tomar buena nota de cada una de las mejoras propuestas y de los impedimentos que están impidiendo avanzar y hacer algo con ellos. Tener una reunión de retrospectiva para luego no tomar ninguna medida va a hacer que se pierda la fe en estas reuniones.

La gente tiene miedo de las retrospectivas

Miembros del equipo de desarrollo pueden sentirse temerosos de comentar los problemas reales que están viendo y sólo dicen vaguedades o pequeños impedimentos pero no la causa que ellos ven como la más importante y por la que no se consiguen los objetivos del sprint. Quizás por temor a herir los sentimientos del Scrum Master o del Dueño del Producto si no están haciendo bien su trabajo, quizás por no molestar al analista que no recoge bien los requerimientos, quizás por temor a ser represaliados si son demasiado directos con lo que se piensa.

Recordemos que la reunión de retrospectiva no es una reunión formal en la que buscar culpables a lo que está pasando. Debe crearse un ambiente en el que todos deben sentirse libres de dar su opinión sin temor a que alguien se moleste. Se trata de una reunión para aprender no para echar las culpas. De ella deberemos salir con un listado de mejoras y no de nombres. Es bueno recordar estos puntos antes de comenzar cada reunión si comenzamos a pensar que el equipo de trabajo no se siente libre para decir lo que piensa.

Demo del sprint o sprint review

miércoles, 26 julio 2017 19:16

antoniomartel

0 Comentarios

Al finalizar el sprint se realiza una revisión de lo entregado en el sprint para poder ver lo que se ha estado haciendo durante el mismo y tener la oportunidad de adaptarse si hubiese que hacer algún cambio. No se trata de una reunión de seguimiento en la que se va a juzgar al equipo de desarrollo sino de tener la posibilidad de presentar el trabajo y comprobar cómo de cerca o de lejos estamos del objetivo y si necesitamos hacer cambios para que el producto esté más orientado a las necesidades del cliente.

El tiempo máximo establecido para esta reunión de demo o presentación del trabajo del sprint es de 4 horas para sprints es de un mes o la mitad si el sprint es de sólo dos semanas. Es trabajo del Scrum Master el que la reunión se lleve a cabo y se mantenga dentro de los tiempos establecidos.

A esta reunión de demo asistirán el Scrum Master, el Dueño del Producto, el equipo de trabajo y los interesados que el Dueño del Producto invite a la reunión y en ella se explicarán qué elementos de la pila del producto se han terminado y cuales no para poder acabarlos. Tras esto el equipo de desarrollo demostrará ante todos los asistentes cómo funcionan los elementos terminados de la lista del sprint.

Esta reunión servirá para que el cliente pueda ver cómo se han desarrollado los requisitos que ha dado, si se están entendiendo estos requisitos, sus objetivos generales para el producto y comprobar si se cumplen sus objetivos. El equipo, desde su punto de vista, puede comprobar si realmente está entendiendo estos requisitos y mejorar la comunicación con el cliente. Estas reuniones en las que se presenta el producto poco a poco servirán para ir entregando el trabajo e ir obteniendo feedback del mismo sin esperar meses y meses antes de presentarlo al cliente que podría no estar contento con las decisiones tomadas en todo ese tiempo.

Algunos de los problemas más habituales de las reuniones de demo del sprint son:

Demos indemostrables

Habrá ocasiones en las que los miembros del equipo de desarrollo pueden pensar que no tienen nada que mostrar en esta reunión de demo o que lo que han hecho en este sprint no tiene una interfaz gráfica que pueda ser mostrada. En casos como estos deberemos buscar una demo mínima que pueda presentarse.

Por ejemplo, si tenemos una funcionalidad que se trata de montar el entorno de desarrollo para poder comenzar a trabajar, en la reunión de demo mostraremos el Eclipse funcionando con el jetty configurado para las pruebas, el cliente de Subversion instalado y la herramienta de conexión a la base de datos correctamente configurada para establecer la conexión.

Si tenemos otra tarjeta que nos indica que debemos montar una estructura de tablas de bases de datos y sus relaciones podremos crear una página Hello World mínima que se conecte a esta base de datos y muestre un listado de las tablas que acabamos de crear.

Demos vacías

Hacemos demos pero en estas se muestran sólo powerpoints y no trabajo real que demuestre que no estaremos avanzando a través de los sprints y cuando alcanzamos el final del proyecto nada funciona, los módulos no están bien integrados entre sí y nada pinta tan bien como lo hacían en los powerpoint.

Deberemos mostrar trabajo real en las demos que presenten lo que se ha estado haciendo. Los powerpoint están prohibidos en estas presentaciones. Será necesario buscar la manera de presentar nuestro trabajo y que sea éste el verdadero valor de lo que estamos haciendo.

Temor a las demos

A veces el equipo de trabajo acude con miedo estas demos. Va a estar el cliente, el dueño del producto, quizás más representantes del cliente y no hemos terminado todos las funcionalidades previstas para el sprint, o lo que es peor, algo puede fallar en la presentación y verse mal. Bueno, no pasa nada, la reunión de demo no es una reunión de seguimiento, se trata de mantener una reunión intencionalmente informal.

Se mantiene esta reunión cada poco tiempo para que no haya grandes dramas o grandes sorpresas en ellas. Se trata de tomarle el pulso al proyecto y ver cómo va, no de apretarle las tuercas al equipo de desarrollo. Si algo salió mal en la reunión de demo será nuestra prioridad en el siguiente sprint y como seguramente sólo será la corrección de un bug podremos sumar puntos fácilmente en la reunión de demo del siguiente sprint.

Si las cosas salen mal repetidamente en las reuniones de demo o muchas funcionalidades previstas para el sprint quedan marcadas como no terminadas porque no pasan los tests, deberemos reducir la carga de trabajo prevista para nuestros sprints. Nuestra velocidad está siendo más baja de lo que pensábamos y necesitamos algo más de tiempo para que más cosas sí queden bien terminadas en la reunión de demo.

Scrum diario o Daily Scrum

domingo, 23 julio 2017 19:42

antoniomartel

0 Comentarios

La reunión diaria de Scrum es una reunión de 15 minutos en la que el equipo Scrum se reúne siempre en el mismo sitio y a la misma hora para comentar sus actividades diarias. Cada uno de los miembros del equipo contesta a las siguientes preguntas:

¿Qué hice ayer?
¿Qué haré hoy?
¿Qué me impide avanzar?

Con estas preguntas se sincroniza todo el equipo de trabajo que cada día sabrá qué es lo que han estado haciendo sus compañeros de trabajo y en qué van a trabajar hoy. También sabrán si sus compañeros tienen alguna dificultad o la prevén para un futuro cercano y si pueden ayudar. Esto favorece que surjan cuestiones, dudas y ofrecimientos de ayuda que nos hagan avanzar más rápidamente. Algunas de las frases más útiles que pueden surgir durante estas reuniones son:

«No sé cómo añadir la autoridad certificadora a nuestra KeyStore de Java» a lo que otro compañero responde «Yo he hecho esto antes, luego nos vemos y te explico«.
«Se me están acabando las tareas antes de ejecutar los nuevos scripts, pronto necesitaré un backup de seguridad de producción» a lo que el Scrum Master podría responder «Le pediré al cliente que realice un export de producción con fecha de mañana a las 03:00 AM«.
«Hoy voy a acabar con las historias de usuario para las transferencias periódicas. Pronto se necesitará analizar nuevas historias de usuario con el Dueño del Producto» a lo que el analista responde «Me veré con el Dueño del Producto lo antes posible para que las tengas preparadas antes de comenzar el trabajo«.

A menudo, después de esta reunión, el equipo de desarrollo o algunos de sus miembros se reúnen inmediatamente después para resolver las cuestiones que han surgido. En los ejemplos anteriores se reunirían los dos desarrolladores para explicar cómo añadir la autoridad certificadora al KeyStore, el analista y el Dueño del Producto para describir nuevas historias de usuario y el Scrum Master iría a llamar por teléfono al cliente para programar una exportación de la base de datos de producción.

El trabajo del Scrum Master en esta reunión consistirá en asegurarse de que tenga la reunión todos los días, de cumplir la regla de que sólo los miembros del equipo de desarrollo participan en el Scrum Diario y de que esta reunión se mantenga en los límites de tiempo de 15 minutos por reunión.

Es habitual que en muchas organizaciones esta reunión de Scrum diaria se haga de pie (Daily stand-up meeting) para evitar que los asistentes hablen más de la cuenta y la reunión dure más de 15 minutos. Yo en cambio las prefiero organizar sentados alrededor de una mesa de reunión y escribir en una hoja de papel o en un documento de Google Docs las respuestas a las tres preguntas de la reunión. Luego, una vez terminada la reunión, revisaba cada una de las respuestas y a modo de checklist comprobaba que no quedasen cuestiones sin resolver o que se dijeron en la reunión y no queden en el olvido.

Un problema habitual en muchos equipos Scrum es que las reuniones diarias duren mucho más de los 15 minutos programados, reuniones de pie que duran más de una hora consumiendo el tiempo productivo de los desarrolladores y que llegan a ser temidas por los miembros del equipo de trabajo. Es frecuente también que algunos opinen que 15 minutos no son suficientes para mantener la reunión diaria. Hay diversas razones por las que pasa esto. Algunas de las más habituales son:

Reuniones dentro de la reunión diaria

Dentro de la reunión diaria se quieren mantener las reuniones detalladas para resolver problemas específicos que deberían mantenerse después de la reunión diaria. El equipo de trabajo no debe entrar en cómo añadir la autoridad certificadora a la KeyStore en Java sino que ésto debe quedar para otra reunión inmediata posterior, en la que estén sólo los implicados, para ahondar en esta explicación.

Las cosas no están claras

Falta un objetivo del sprint claro o falta refinamiento en el backlog. Cuando no hay un claro objetivo del sprint es habitual que surjan muchas dudas durante la reunión diaria. Del mismo modo cuando los requisitos de las historias de usuario no están suficientemente bien refinadas y recogidas vuelven a surgir muchas cuestiones en la reunión diaria. Si trabajas en resolver estos puntos, el trabajo diario de los desarrolladores será mucho más claro y conciso por lo que estarán deseando acabar la reunión para continuar con su desarrollo.

Se explica hasta el último detalle

Se entra en especificar hasta el último detalle de la tarea que se está haciendo. Si la reunión dura 15 minutos y en el equipo trabajan 4 desarrolladores tendrá menos de 5 minutos cada uno para responder a las 3 preguntas. Aproximadamente 1 minuto 15 segundos por pregunta. Es realmente muy poco tiempo por lo que hay que ser muy conciso. Hay personas que con esto tienen tiempo suficiente pero otras que realizan un repaso tan completo a cada uno de los detalles en los que están trabajando que requieren al menos el triple de tiempo. Hay que explicarles que se trata de ser breves, explicar a grandes rasgos en qué están trabajando y del límite de tiempo que se tiene para que la reunión sea productiva y para que los demás no se aburran o desconecten de la reunión.

El objetivo del sprint

miércoles, 19 julio 2017 19:04

antoniomartel

0 Comentarios

El objetivo del sprint es la meta que definiremos durante la reunión de planificación del sprint y que nos permite tener una idea clara, en palabras, de qué es lo que conseguiremos si acabamos de implementar todas las funcionalidades definidas para este Sprint. Se trata de dar una función coherente a los elementos de la lista del producto seleccionados para este sprint.

Si por ejemplo desarrollamos una web para la banca online podríamos tener un sprint en el que habría que desarrollar los siguientes elementos:

Desarrollar formulario que permita definir transferencias periódicas de dinero (mensuales, trimestrales, anuales).
Desarrollar vista que permita ver, anular y modificar transferencias periódicas.
Desarrollar módulo backend que permita que las transferencias periódicas programadas se ejecuten a su debido momento.

Para que, a medida que se trabaja, el equipo mantenga el objetivo del sprint en mente podríamos definir la meta del sprint la siguiente:

Permitir crear al usuario transferencias periódicas de dinero.

Sin embargo, con frecuencia tendremos para el sprint una serie de funcionalidades o bugs a resolver que juntos no permiten dar un objetivo o meta clara en común. Pensemos por ejemplo que estamos desarrollando una web de eCommerce en la que, durante la reunión de planificación del sprint, decidimos que las historias de usuario a desarrollar sean:

Implementar la forma de pago con PayPal.
Añadir varios productos a la vez a la cesta de la compra.
Proporcionar sugerencias útiles a los usuarios registrados que ya compraron algo.
Corregir bug en producción por el que no se muestra el último elemento de la cesta de la compra cuando éste contiene más de 200 caracteres en su descripción.
Corregir bug en producción por el que no se muestran correctamente los caracteres especiales como tildes y acentos del idioma francés.

Para un caso como este en el que no tenemos una narrativa común que defina un objetivo claro para el sprint podríamos definir lo siguiente como meta del sprint:

Objetivo del Sprint: Implementar 3 historias de usuario y corregir todos los errores de producción.

Página 5 de 22