Gestión de proyectos – SCRUM

[SCRUM] Mi experiencia con el Planning Poker®

12 abril, 2019 43890246 Deje un comentario

En este post me gustaría contarles mi experiencia con la técnica de Planning Poker® usada durante la reunión “Sprint Planning” en el proyecto actual que formo parte.

Antes de comenzar, expliquemos de qué trata el Planning Poker®.

Planning Poker® es una técnica de estimación basada en consenso. Équipos ágiles alrededor del mundo usan esta técnica para estimar las historias de sus Product Backlog. La unidad de estimación puede ser con puntos de historia (story points) siendo el ideal “días” [1]

Pasos del “juego” de Planning Poker® . ¡Let’s play!

Requisitos a la mano:

Lista de funcionalidades a ser estimadas Product Backlog
Baraja de cartas para cada miembro del equipo. Los valores de cartas representan el número de puntos de historia de usuarios (cuya unidad de medida puede ser “días“), estos valores podría ser los números de la secuencia de Fibonacci (recomendada por [1]) o cualquier otra medida que el equipo considere más eficiente. En [5] adicionan los valores “?” (difícil de estimar), “taza de café” (muy fácil), entre otros a la secuencia de Fibonacci. Sin embargo . . .

¡Ojo! Sea cual fuere la unidad seleccionada lo más importante es que todo el equipo esté al tanto de ello

Figura 1: Ejemplo de valores de las cartas de Planning Poker® [1]

Basándonos en [1][4], tenemos los siguientes 7 pasos:

El Product Owner del equipo lee y explica las historias de usuarios/ funcionalidades candidatas a ser implementadas durante el Sprint al resto del equipo que se encargará de estimarlas.
Cada miembro tendrá una baraja de cartas
Los miembros discuten y/o solicitan aclaraciones al Product Owner para así poder tener un entendimiento correcto de lo que será estimado.
Cuando la historia de usuario ha sido totalmente aclarada para todos los miembros, cada uno de ellos selecciona una carta que representa su estimación. La carta de cada uno es revelada al mismo tiempo.
Si todos los miembros eligieron el mismo valor, ese será el valor de estimación de la historia de usuario/funcionalidad. Si los valores son diferentes: Los miembros con los valores más altos y más bajos deben explicar la razón de sus estimaciones. Luego de ello, nuevamente los miembros eligen y muestran su carta.
Si existe un consenso, se empieza el juego para estimar la siguiente historia.
El juego finaliza cuando todas las historias han sido estimadas.

Figura 2: Planning Poker® [1]

Mi experiencia con el Planning Poker® . ¡Ahora sí!

¿Es necesario tener una baraja de cartas físicas? La respuesta es No. En el mercado existen algunas online como ScrumPoker-online o el app Scrum Poker Cards (Agile)

Pero … ¿Será que hay algo más simple?

Nuevamente, la respuesta es Sí. En [2] nos presentan una variación del clásico Planning Poker® llamado The Power of Two la cual nos permite realizar el Planning Poker sin necesidad de cartas físicas u online, en lugar de eso usa “una mano”

Siendo así, nuestro equipo realiza el Planning Poker® – The Power of Two con las siguientes reglas personalizadas

Dedo meñique representa: 0.5 punto
Dedo índice, pulgar, anular, medio: 1 punto
Ningún dedo: 0 puntos (significado: Tarefa muy fácil)
Es posible decir combinar el dedo meñique con algún otro dedo para dar el valor, por ejemplo, de “1.5 puntos”
Nosotros seguimos la secuencia de valores primos: 0, 0.5, 1, 2, 3, 5. Por tanto, el valor “4” no es posible.

Escala entre puntos y días: 0.5 representa medio día de trabajo(4h) y 1 punto un día de trabajo (8h). Definimos de esta manera pues en nuestro equipo algunos miembros trabajan solo medio día algunos días de la semana.

Hemos realizado varios Sprints de esa manera y nos ha ido bien, cumpliendo a tiempo la implementación de las funcionalidades.

¿Ya usas el Planning Poker®? ¿Sí? ¿No?. Te invitamos a que nos cuentes cómo sus equipos estiman sus tareas 🙂

Referencias

[1] Planning Poker

[2] Planning Poker – The Power of Two

[3] Scrum Effort Estimations – Planning Poker®

[4] SCRUM EFFORT ESTIMATIONS – PLANNING POKER®

[5] Planning poker: A técnica baseada no consenso

[Tip] ¿Cómo hago para elegir un software adecuado?

8 enero, 2019 43890246 Deje un comentario

Creo que en algún momento, todos hemos pasado por la difícil decisión de elegir un software para resolver una determinada tarea (desde un básico calendario hasta un complejo software de desarrollo de aplicaciones web). Hoy en día, tenemos muchas opciones disponibles en el mercado para cualquier tarea y entre tantas ¿cuál debería seleccionar?

Me gustaría comentarles cómo suelo buscar y decidir la mejor opción

[SCRUM] Daily Meeting y demás comunicaciones con Slack

23 noviembre, 2018 43890246 Deje un comentario

En artículos anteriores he hablado sobre qué es Scrum, cuáles son sus principios, aspectos y procesos, cómo certificarnos como Scrum Master y más.

De qué trata una Daily Standup Meeting?

Hoy me gustaría comentarles sobre Daily Scrum o Daily standup meeting que como recordarán forma parte del principio “Timeboxing” o “Bloque de tiempo asignado“. La productividad de un equipo ágil se logra usando el tiempo de forma eficiente, es por ello que el principo deTimeboxing es uno de los más críticos pues permite que el equipo se mantenga enfocado en el cumplimiento de sus tareas en el tiempo asignado.

Figura 1 – Timeboxing [3]

Específicamente para la Daily Scrum el tiempo asignado es de 15 minutos por cada 24 horas. En esta reunión cada miembro del equipo, uno por vez, debe responder las siguientes 3 preguntas:

Qué hiciste ayer?
Qué harás hoy?
Cuando crees que terminarás esa tarea? (opcional)
Existe algún impedimento/obstáculo para la realización de tus tareas?

Haciendo esto promovemos la transparencia: Todos sabemos en qué andamos y si tenemos o no algún problema (que no es solo del tipo “tengo X bugs en mi código”). En [1] encontramos ejemplos de impedimentos:

Mi computadora tuvo un problema y necesito un día más
Aún no llego el software/hardware/programa que pedí hace un mes
Me gustaría aprender ___________ y para ello me gustaría trabajar en par con fulanito (el famoso programming pair“)
El jefe del área X me ha pedido apoyarlo “por uno o 2 días”

El Scrum Master es el responsable de resolver dichos impedimentos. En aquellos de tipo técnico en donde el Scrum Master no puede resolverlos directamente, él deberá asegurarse de encontrar alguna persona (ya sea del equipo o externa) que pueda ayudar a resolver ese problema rápidamente.

Recomiendo la lectura de [4][5] para conocer qué es lo que NO debemos hacer en la ‘daily‘ y más tips.

Leí que la daily tiene que ser presencial, el primer evento del día de trabajo, todos de pie y sin discusión. ¿No es un mundo ideal?

Déjame decirte que sí y pues somos humanos y vivimos en un mundo real. El artículo [6] empieza diciendo “Vamos a ahorrar tiempo, evitemos esta ‘ceremonia’ [daily], es demasiado antiguo!” y cuando empecé a leerlo me sentí identificada con los problemas que surgen de la forma tradicional de conducir una daily.

Y no es que la daily tradicional exija que sea presencial, puede ser hasta por videocámara pero algunas veces sucede que aún asi no se da de la forma que esperamos y podría hasta ser contraproducente. Les contaré algunos de los problemas que percibí cuando empecé a participar de dailies:

Las dailies eran programadas a las 9am y hay que decirlo el tráfico de Lima (y la ‘hora peruana’) no permitía que empezáramos a esa hora o si empezaba no estábamos todos al inicio ¿que ocurría entonces?: Algunos miembros perdíamos lo que se había dicho pues no había un registro (y pues tener una persona para redactar una acta de reunión diaria es con certeza improductivo)
Otro problema era que la reunión podía durar más de 15 minutos. Porque sin querer o queriéndolo empezábamos a discutir y analizar las respuestas en ese momento y la daily no es para eso.
Algunos miembros podíamos no estar interesados en escuchar en ese momento a los demás: ¿imagina que eres el último en responder las preguntas?. ¿no te sentirías aburrido?. No voy a mentir, sí a veces.

¿A que hora empezábamos el trabajo real?: 9:30 o 9:40. ¿Cómo podría hacer más eficiente una daily?. Porque ¡ojo! doy fe de los beneficios de una reunión diaria.

Actualmente estoy utilizando Slack como medio de comunicación y colaboración con mi equipo de trabajo. Al inicio me pareció que era whatsap para empresa. Luego de casi 1 año de usarlo, lo ¡recomiendo fuertemente!. Inclusive realizamos nuestras dailies en Slack gracias a un bot llamado Limitbot.io

Cómo funciona Limitbot como daily? (sin detalles técnicos)

Configura las 3 preguntas indicadas líneas arriba
Configura el horario en que avisará a cada miembro del equipo para responder las preguntas del paso anterior
En el horario indicado, Limitbot enviará una notificación como por ejemplo “Hello Pamela! It’s time for our standup meeting *Standup*. When you are ready please answer the following question:”
Es hora de responder una a una las preguntas. Al finalizar el pequeño cuestionario, las respuestas son almacenadas en un “channel” (equivalente a un grupo) que podríamos llamar #dailies.
Ese channel estará disponible para todos en cualquier momento: ¡cumplimos con la transparencia!. El Scrum Master podrá revisar las respuestas y buscar soluciones a los impedimentos registrados.

Figura 2 – Preguntas configuradas usando Limitbot [3]

Tú que opinas? estás a favor de las dailies tradicionales o te animarías por alguna herramienta como um bot de Slack? 🙂

Referencias

[1] Daily Scrum Meeting – Mountain Goat

[2] 21 Ways to Use Slack Bots to Simplify Everyday Tasks

[3] What is timeboxing?

[4] Daily Scrum meeting: tips

[5] Scrum Daily Meeting

[6] What if we do daily scrum stand-up over slack?

[7] Limitbot.io

[8] Stop the meeting madness

Imagen principal del post tomada de [5]

[SCRUM] Ser Scrum Master Certified y ¡no morir en el intento! (Parte 2)

14 septiembre, 2018 43890246 24 comentarios

En la parte 1 de este artículo, mencioné donde encontrar los recursos/material de preparación para los exámenes Scrum Fundamentals Certified (SFC^™) y Scrum Master Certified (SMC^™) disponibles por la empresa SCRUMstudy, bajo la cual yo me certifiqué. Durante mi revisión de artículos para la elaboración del presente, me encontré con algunas preguntas para certificación como Scrum Master que me parecieron “extrañas” pues utilizaban algunos términos diferentes a los que había aprendido con el SBOK, fue ahí que recordé que existen 3 grandes empresas certificadoras de Scrum:

SCRUMstudy
Scrum.org
Scrum Alliance

En el artículo de Scrum Alliance vs SCRUMstudy se muestra un cuadro comparativo de ambas empresas. Uno de los puntos que concuerdo con dicho artículo totalmente es que un verdadero Scrum Master (sin importar por cuál empresa obtuvo su certificación) podrá responder a qué se refiere el Manifiesto Ágil: “Hemos llegado a valorar …:

A los individuos y su interacción, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.”

Dejando ese punto en claro, seguiré enfocada en el Scrum Master Certified (SMC^™) de SCRUMstudy.

[SCRUM] Ser Scrum Master Certified y ¡no morir en el intento! (Parte 1)

3 septiembre, 2018 43890246 27 comentarios

Entre los días 1 y 2 de julio de 2017 llevé un Curso Oficial de Scrum en el Instituto Gesap en Lima y cuya experiencia relaté en un post anterior.

Para recordar qué es Scrum: Es uno de los métodos ágiles más populares. Es un framework adaptable, iterativo, rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma rápida a lo largo del proyecto [1]. Así que vale la pena aplicarlo en la gestión de nuestros proyectos.

Figura 1 – Flujo Scrum para un sprint (SBOK)

El objetivo de este post es sugerirte material para que inicies su aprendizaje de Scrum para luego estar preparado para rendir el examen de Scrum Master Certified. Quizás te estés preguntando ¿debería certificarme? Personalmente te recomendaría que sí

¿Por qué?

Actualmente, en el mercado laboral, tanto en Perú como el mundo, existe una demanda de profesionales certificados en Scrum, pues ellos ayudarán a las organizaciones a obtener un mejor nivel en la gestión de proyecto y por tanto incrementar el indicador ROI (Retorno de la Inversión) [2].

Les voy a contar un poco de mi experiencia durante mi búsqueda de trabajo en Lima – Perú. Luego de participar del taller de Scrum, inicié mi búsqueda de puestos de trabajos que envolviera Scrum. Encontré que las principales empresas del Perú estaban/están optando por un enfoque ágil y por tanto requerían de profesionales con la misma visión y con conocimientos de Scrum. En algunos casos como requisito “deseable” y en otros como “obligatorio”. Admito que perdí posibles oportunidades por no certificarme. ¡Ahora ya no! … ¡y tú tampoco!

[SCRUM] Aplicando Scrum en Trello

12 marzo, 2018 43890246 5 comentarios

En un post anterior, expliqué cómo aprendí Scrum y los aspectos/principios/procesos de este framework. En este nuevo post, hablaré sobre 3 elementos importantes que forman parte de Scrum:

Kanban
Product Backlog
Sprint Backlog

Además les comentaré sobre una herramienta de colaboración online : Trello.

Recordemos que Scrum busca entregar resultados de forma rápida y con menor costo, enfocándose en entregar productos y/o servicios que se alineen las necesidades del cliente. Cuando una organización decide implementar Scrum, es importante que todas las partes interesadas tengan mente que “el cliente está en primer lugar” [1]

Scrum se rige de 3 grandes pilares: Transparencia, Inspección y Adaptación

Transparencia: Cada aspecto del proceso debe definirse por un estándar común a todos los integrantes del equipo
Inspección: El avance hacia el objetivo fijado es responsabilidad de todos los integrantes del equipo
Adaptación: La inspección constante, garantiza la capacidad de respuesta y la subsiguiente adaptabilidad del framework

Trello es un software que permite organizar proyectos en tableros. Permite ver cuáles son las tareas que se llevan a cabo, quién trabaja en una tarea determinada y cuál es el estado de un proceso [3]. La característica de Trello de trabajar con tableros permite automatizar el Kanban Board, el cual es utilizado frecuentemente en proyectos Scrum.

El Kanban Board es una herramienta que permite la visualización de nuestro trabajo y flujo de trabajo (workflow) para así optimizar dicho flujo. Por ejemplo en la imagen siguiente se muestra un Kanban Board básico con 3 pasos de nuestro flujo de trabajo, representados por columnas o “lanes” [4]

“To do”, “Doing” o “In progress”, “Done” (Por Hacer, En Progreso, Hecho)

Las tareas son representadas por “Kanban cards” (tarjetas, en tableros físicos son comúnmente post-it). Estas tarjetas son colocadas en los lanes de acuerdo a su estado actual de trabajo.

El Kanban Board es un gran aliado en la promoción de la transparencia del Scrum. Pues, cuando un equipo Scrum posee un Kanban Board, todos consiguen fácilmente visualizar el flujo de trabajo, cuales tareas están siendo ejecutadas, quién es responsable de qué, en que situación se encuentra cada tarea, etc. Existen mayores posibilidades de éxito cuando existe mayor transparencia en el proyecto ya que el equipo se siente más involucrada y aumenta su nivel de confianza. [5]

Ahora, profundizaremos en los artefactos de Scrum y cómo reflejarlos en Trello para ya dar inicio a nuestro proyecto Scrum

[SCRUM] Aprendiendo SCRUM

19 enero, 2018 43890246

Todo cambia, de eso no se escapa la gestión de proyectos. Pasamos de un enfoque tradicional a un enfoque “ágil”, hablamos de SCRUM.

Scrum es uno de los marcos ágiles de trabajo más populares. Es un framework adaptable, iterativo, rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma rápida a lo largo del proyecto. Debe quedar claro que SCRUM no es una metodología. Además se basa en en los principios del Manifiesto Ágil:

El framework de la Guía SBOK™ (SCRUM BODY OF KNOWLEDGE) está formado por 3 partes: Principios, Aspectos y Procesos

Scrum puede aplicarse en forma efectiva a cualquier proyecto en cualquier industria, desde proyectos pequeños o equipos con tan solo seis miembros, hasta proyectos grandes y complejos con varios cientos de integrantes.

Este post no pretende replicar la guía oficial SCRUM, sino mencionar los principios que rigen SCRUM, sus aspectos y sus procesos. Luego de ello, comentaré mi experiencia en la clase donde aprendí SCRUM de forma práctica e innovadora pues se hizo uso de LEGO® Serious Play® y puedo confirmar que mediante esta técnica conseguí entender e interiorizar la teoría impartida al inicio de clase.

¿Listos? Ahí vamos