Sunday, 23 July 2017

Scrum diario o Daily Scrum

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.

Saturday, 22 July 2017

Mi libro, de nuevo bestseller

Ya van más de tres años desde que mi libro Gestión práctica de proyectos con Scrum salió a la venta. Desde entonces ha alcanzado numerosas veces el puesto número 1 en ventas en diversas categorías a a las vez, y en dos ocasiones, el número 1 en ventas en todo Amazon.

Hoy, sobre las 9:00, ha vuelto ha alcanzar un puesto como número 1 en ventas en la categoría Internet y web de la tienda Kindle de Amazon España alcanzando también el número 2 en la categoría de libros (todos, electrónicos y de papel) de Programación y desarrollo de software.

Les dejo imágenes de las posiciones en Amazon España:

Libro Gestión práctica de proyectos con Scrum bestseller en Amazon
Número 1 en categoría Internet y web

Libro Gestión práctica de proyectos con Scrum bestseller en Amazon
Libro como bestseller en Amazon España


Wednesday, 19 July 2017

El objetivo del sprint

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.

Sunday, 16 July 2017

Reunión de planificación del Sprint

Durante esta reunión, mantenida al inicio del Sprint o poco antes de empezarlo, se planifica el trabajo a realizar durante el Sprint. Participarán en ella el Scrum Master, el equipo de desarrollo y el Product Owner.

Para sprints de un mes esta reunión durará un máximo de ocho horas durando menos si el Sprint es más corto de un mes. El Scrum Master se encargará de que la reunión se lleve a cabo, de que todos entiendan para qué es la reunión y que ésta se mantenga dentro de las ocho horas de margen de tiempo.

En esta reunión de planificación calcularemos qué puede entregarse al finalizar el Sprint que va a comenzar y cómo haremos el trabajo para conseguir este objetivo:

Qué puede entregarse al finalizar el Sprint

Con la vista puesta en los objetivos definido por el Dueño del Producto discutiremos con el equipo de Desarrollo qué funcionalidades deberemos desarrollar y si caben dentro del Sprint. Escogeremos de la Lista de Producto esas funcionalidades y las pasaremos a la Lista del Sprint. Si logramos acabar esta selección de elementos de la Lista de Producto dentro del Sprint habremos conseguido el Objetivo del Sprint.

Sólo el equipo de desarrollo puede decir cuantos elementos de la lista de producto entran a formar parte de la lista del sprint. Con la vista puesta en esa lista de producto y en el rendimiento obtenido en sprints pasados, el equipo de desarrollo hará una proyección de hasta donde puede llegar en este sprint.

Cuando el equipo de desarrollo ha finalizado este cálculo de cuantos elementos de la lista de producto puede terminar en el sprint, el equipo Scrum al completo (Scrum Master, Dueño del producto y equipo de desarrollo) deciden cuál será el Objetivo del Sprint (Sprint Goal). Este objetivo estará presente durante todas las semanas de implementación del Sprint y servirá como guía al equipo de desarrollo para saber por qué y para qué se está trabajando en ese sprint

Cómo haremos el trabajo para conseguir el Objetivo del Sprint

 Los elementos de la Lista de Producto (Product Backlog) seleccionados para este Sprint componen la Lista del Sprint (Sprint Backlog) y son los elementos que el equipo de desarrollo implementará para entregarlos al final del Sprint.

El equipo de desarrollo diseñará las funcionalidades y el trabajo necesario a realizar para completar el Sprint y concluirá la reunión con éste trabajo descompuesto en unidades o tareas de un día o menos. A partir de ahí el equipo de desarrollo se auto-organizará para tomar estas tareas y llevarlas a cabo a lo largo del Sprint.

Durante la reunión de planificación el Dueño del Producto explicará lo que hay que desarrollar para poder hacer las nuevas funcionalidades de la Pila del Sprint. El equipo de desarrollo tomará más elementos de la Pila del Sprint si no tiene suficiente trabajo para el Sprint o renegociará con el Dueño del Producto los elementos de esta lista si tiene demasiados.

Al finalizar esta reunión del planificación del sprint tendremos:

  • La Lista o Pila del elementos del Sprint (Sprint Backlog)
  • El Objetivo del Sprint
  • La descomposición de la Lista del Sprint en tareas de 1 día o menos.

Sunday, 9 July 2017

Ceremonias de Scrum

En Scrum existen diversas reuniones o eventos, también llamadas ceremonias, que tratan de crear regularidad y reducir al mínimo la necesidad de reuniones fuera de las definidas en Scrum. Todas estas reuniones tienen una duración máxima (timeboxing) con el objetivo de que estos eventos no se conviertan en eternos llevándonos por disquicisiones que no van a ningún lado o a la pérdida de tiempo.

El propio Sprint es el evento central dentro de Scrum y contiene al resto de eventos y ceremonias. Todos estos eventos están diseñados para permitir la inspección y la adaptación de lo que está pasando en el proyecto. Cada uno de ellos es una oportunidad de mejorar el proyecto y darle transparencia a todos los participantes. Si falta alguno de ellos podría estar faltando transparencia al proyecto y perderse esa oportunidad de adaptarse a los cambios para mejorar.

El Sprint

El Sprint es el corazón de Scrum, es un bloque de tiempo de un menos o menos, suele ser de dos semanas, durante el que se crea un incremento del producto Terminado, Utilizable y Potencialmente desplegable. Estas tres características son importantes:

  • Terminado: Se dice así cuando por consenso de los participantes del proyectos, las funcionalidades, nuevas características o errores corregidos durante el Sprint están completamente hechos o terminados. Es decir que no faltan fases de test o que las funcionalidades están incompletas a falta de uno o más sprints para finalizarlos.
  • Utilizable: Las nuevas características que estamos añadiendo en este Sprint son utilizables por el usuario final que las puede comenzar a usar tan pronto como hayan sido desplegados. No se trata de características a las que les falte alguna otra funcionalidad a ser desarrollada más adelante para poder ser utilizada.
  • Potencialmente desplegable: Puede que decidamos no subir a producción tan pronto como terminemos el Sprint y que esperemos a tener un conjunto mayor de funcionalidades a hacer esta subida pero lo que entreguemos al final el Sprint estará listo y podría ser desplegado en producción si así lo hubiéramos decidido.

Dentro de cada Sprint encontraremos las siguientes reuniones y ceremonias que se explicarán con más detalle a lo largo de este capítulo:

  • Reunión de planificación del Sprint (Sprint Planning Meeting)
  • Reuniones de Scrum Diario (Daily Scrums)
  • Reunión de demo o revisión del sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)

El Sprint tiene las siguientes características:

  • Cada Sprint comienza justo después de la finalización del Sprint anterior.
  • El Sprint se ajusta a un Objetivo del Sprint que es la meta que quiere alcanzarse cuando se acabe el Sprint. Por ejemplo: Desarrollar el sistema de login de la aplicación.
  • No se disminuyen los objetivos de calidad para llegar al objetivo del Sprint.
  • El alcance del Sprint puede ser clarificado con el Dueño del Producto y el Equipo de Desarrollo para renegociarlo con ellos a medida que sucede el Sprint y vamos conociendo más durante el Sprint. 

Podemos considerar al Sprint como un mini proyecto que tiene un horizonte de un mes o menos (por ejemplo dos semanas). Un proyecto que tiene un objetivo y unas etapas en las que se va a definir qué se va a construir, se diseña y se trabaja un plan para la construcción del producto resultante al finalizar esas dos semanas.

El objeto de dividir el proyecto en todos esos mini proyectos de un mes o menos es el del clásico divide y vencerás. Con proyectos tan pequeños podemos mantener acotada al complejidad, evitar que cambie lo que se está construyendo y evitar que aumente el riesgo de proyecto durante ese tiempo. Además al ser proyectos tan pequeños podemos adaptarnos al finalizar y comenzar un nuevo Sprint a lo que hayamos aprendido en el Sprint anterior. Por todo esto el riesgo de estos mini proyectos estarán limitados al costo de un mes de trabajo como máximo.

¿Se puede cancelar un Sprint?

Sí, un Sprint puede ser cancelado antes de que llegue a su fin. El Dueño del Producto y sólo él puede decidir que no merece ya la pena el Objetivo del Sprint por lo que puede concluirlo.

Algunas cosas pueden ocurrir en el plazo máximo de un mes que puede durar un Sprint: la dirección cambia de estrategia, a los interesados en el producto ya no le interesan las funcionalidades a desarrollar en este Sprint, o las condiciones del mercado o de la tecnología cambian y ya no tiene sentido el objetivo del Sprint.

Debido a la corta duración del Sprint las cancelaciones normalmente no tienen lugar porque no tantas cosas pueden cambiar de repente. Es algo que debemos de evitar porque cancelar un Sprint tiene un coste: Hemos estado preparando y planificando el Sprint y debemos reunirnos de nuevo para planificar el siguiente. Casi todo ese esfuerzo se tira a la basura para comenzar un nuevo Sprint. Podemos dar además la sensación de estar actuando sin una clara dirección o estar tomando los objetivos de los sprints muy alegremente, sin pensarlos demasiado.

A la hora de cancelar un Sprint revisaremos todos los elementos de la Lista o Pila de Producto y comprobamos cuales de ellos están en estado Terminado y son potencialmente entregables para presentarlos al Dueño del Producto y que éste diga si lo acepta como entrega o no. El resto de elementos de la Lista del Sprint que no estuviesen completados vuelven a la Pila del Producto para volver a ser estimados ya que el trabajo que se haya hecho en ellos pierde valor con rapidez y debe volverse a estimar.

Monday, 3 July 2017

Mi libro número tres entre todos los libros de programación

Mi libro Gestión Práctica de Proyectos con Scrum lleva vendiéndose desde mayo de 2014, más de 3 años en los que el libro ha llegado a bestseller en su categoría varias veces y en todo Amazon, brevemente, en dos ocasiones.

Pero en este tiempo ha seguido vendiéndose a una media de unos 2 a 3 libros diarios en los últimos tiempos lo que lo convierte ahora en un libro longseller. Esta misma tarde se ha colocado en el número 600 de todos los libros más vendidos en Amazon España y en el número 3 de todos los libros, no sólo digitales, en la categoría de Programación y desarrollo de software.

Además, en este tiempo ha cosechado 17 comentarios en Amazon México, 41 en Amazon.com y 56 en Amazon España con opiniones tan buenas como éstas:

"No me esperaba encontrar esto y la verdad que me ha sorprendido gratamente"
-- Iván

"Lo que más rescato es la prioridad que se tuvo para exponer lo realmente importante, logrando así un libro compacto y preciso"
-- Cliente de Amazon

"Claro y eficaz, utiliza un lenguaje sencillo y es una magnifica obra para introducirse en scrum de una forma realista"
-- Cliente de Amazon

"Es la experiencia del autor en su aplicación, ventajas desventajas, lecciones,... Sencillo y ameno"
-- KermitSBD

"Genial: En mi trabajo, vamos a implantarlo y me ha tocado ser Product owner... Ha sido un repaso, muy ameno de lo que vemos en las formaciones. Muy recomendable"

-- Isabel Soler López

"Cumple exactamente lo que promete la sinopsis: Un libro interesante y práctico. Escrito desde la experiencia y el sentido común"
-- Santi

"Genial libro para entender el Scrum de forma practica y util"
-- Cliente de Amazon

"El libro me encanta, es una buena intro para metodología Scrum, y se lee muy bien y rápido. Lo recomiendo"
-- WildWilly

"Una 'novela' real de un técnico: Me ha gustado mucho. Me parece muy fácil de leer y muy didáctico. Se lee como una novela de casos ocurridos al autor"
-- Cliente Amazon

"Realmente bueno: Un libro muy interesante tanto para el que se inicia como para el conocedor de Scrum (es mi caso). En su texto que es muy ameno, -aderezado con dibujos y citas muy útiles-, vas a encontrar consejos y también la esencia de Scrum (...) Es conveniente releerlo otras veces"
-- Cliente de Amazon

Monday, 1 May 2017

El Scrum Master y la organización

¿En qué ayuda el Scrum Master a la organización o empresa en la que trabajamos? En textos anteriores vimos en qué ayudaba el Scrum Master al Product Owner y al Equipo de Trabajo pero ¿y a toda la empresa en su conjunto?

Lo más importante de todo es liderar los cambios en la empresa para poder adoptar Scrum, es decir, ayudar a todos a que entiendan el motivo de las reuniones diarias, las reuniones de demo, la pila del producto, etc. buscar un hueco para estas reuniones y organizarlo todo para poder implementar Scrum en la empresa.

Para hacer esto habrá que planificar la adopción de Scrum en la organización ayudando a poner fechas para una implementación de Scrum gradual y cada vez mayor en la empresa si este es el caso. Por ejemplo podría establecer un calendario para que cada vez más equipos se vayan sumando al uso de Scrum, fijando reuniones de formación previas para explicar cómo se trabaja con Scrum y hacer seguimiento de cómo van estas implementaciones de Scrum en la organización para luego realizar los cambios que sean necesarios que incrementen la productividad de los equipos Scrum.

El Scrum Master tendrá también que ayudar a sus compañeros y empleados en la empresa a entender cómo funciona Scrum y cómo llevarlo a cabo. Debe llevar ese papel de formador o 'profesor' de Scrum para hacer que todos entiendan este cambio de paradigma.

Por último el Scrum Master deberá trabajar con los otros Scrum Masters de la empresa para que en conjunto se incremente la efectividad y la productividad de la aplicación de Scrum que se está haciendo en la empresa. Deberán poner en común las cosas que están funcionando o no en la adopción de Scrum y hacer los cambios necesarios para mejorar la aplicación de Scrum en la organización.

Sunday, 23 April 2017

El Scrum Master y el Equipo de Desarrollo

El trabajo del Scrum Master no es el de jefe de proyectos ni es sólo el de servir de ayuda al Product Owner (que tampoco es el jefe de proyectos). En el trabajo diario del Scrum Master también debe ofrecer servicios de ayuda al Equipo de Desarrollo además de al Product Owner.

El más importante quizás sea el de eliminar impedimentos para el progreso del Equipo, es decir, ayudar en lo que el equipo necesite para tener su trabajo preparado y no tener que estar esperando por nada. Si por ejemplo se necesita solicitar una exportación de la base de datos antes de realizar algún trabajo, será trabajo del Scrum Master realizar estas gestiones para que el Equipo de Desarrollo lo tenga preparado a tiempo y no tenga que quedarse esperando a que esto se resuelva.

Otro de los puntos importantes en los que debe trabajar el Scrum Master es en el de guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional. Los equipos de desarrollo normalmente esperan que alguien les asigne las tareas y a encargarse sólo de aquellas tareas que pone el título de su contrato. El Scrum Master debe intentar cambiar este paradigma haciendo que cambie esta mentalidad para que el Equipo de Desarrollo sepa elegir sus propias tareas (de acuerdo por supuesto a la priorización hecha por el Product Owner) y a encargarse de todas las tareas sin derivarlas a otros departamentos porque ellos son los especialistas (departamentos de administradores de bases de datos o de analistas para que ellos hagan el análisis o un import o export de bases de datos).

Entre los trabajos del Scrum Master también está el de organizar los eventos o reuniones de Scrum para facilitar que éstas sucedan. Deberá organizar la reunión diaria, la reunión de demo, la reunión de retrospectiva, procurar que todos asistan y que sea del máximo provecho para todos los interesados.

También deberá servir al Equipo de Desarrollo para ayudarlo a crear productos de alto valor que no quiere decir que tengan un nivel de calidad alto, que se da por supuesto, sino a que el Equipo de Desarrollo esté centrado en producir funcionalidades y características que le aporten el máximo valor o utilidad al producto que se está construyendo.

Por último, y no menos importante, el Scrum Master deberá guiar al Equipo de Desarrollo cuando éste no ha trabajado nunca con Scrum para ayudarles en su adopción y en que sea completamente entendido por todo el equipo.

Sunday, 16 April 2017

El Scrum Master y el Product Owner

El rol de Scrum Master en un equipo Scrum no es el de jefe de proyecto como suele suponerse equivocadamente. Es más bien el de un guía que ayuda a todos a entender cómo funciona Scrum y que intentan asegurar que las prácticas de Scrum son bien entendidas y funcionan de la mejor forma posible.

El Scrum Master ayudará a los Interesados y a otras personas fuera del equipo Scrum a entender cuáles con las mejores formas de interaccionar con el Equipo Scrum, por ejemplo, si un Interesado tienen una solicitud de mejora que hacer, el Scrum Master deberá hacerle saber que es mejor si se la comunica al Product Owner para que este la meta en la pila de trabajo y la priorice si así lo cree necesario.

El Scrum Master es un líder al servicio del Equipo Scrum. En concreto, el trabajo que realizará el Scrum Master para el Product Owner será:

  • Ayudarle a gestionar la Pila del Producto de manera efectiva, por ejemplo, facilitándole herramientas para gestionar los elementos de la pila (MS Excel, Trello, JIRA, etc.) o indicándole cómo y cuando debe priorizar entre las tareas.
  • Explicarle cuando debe entrar en más detalle en ellas para que el Equipo de Desarrollo las pueda entender correctamente con especificaciones claras y concisas.
  • Ayudarle a entender las estimaciones empíricas que haga el Equipo de Desarrollo, es decir las basadas en datos reales y experiencias pasadas y no sólo en predicciones.
  • Asegurarse de que el Dueño del Producto sabe cómo priorizar las tareas y funcionalidades a realizar basándose en el Retorno de Inversión y en el coste que tienen. Es decir si una funcionalidad tiene un coste o tiempo de realización de 5 y un valor para la organización de 8 quizás convendría hacerla después de una funcionalidad de coste 2 y valor 6 porque conseguiríamos un valor similar para la organización (6) en menos de la mitad de tiempo, tan sólo 2 (y la organización la disfrutaría antes también).
  • Entender y practicar la agilidad, es decir, explicarle las principios ágiles que hay detrás de Scrum como los del manifiesto ágil. Algunos de ellos son: Nuestra mayor prioridad es la de satisfacer al cliente, Aceptamos que los requisitos cambien, Entregamos software funcional frecuentemente entre dos semanas y dos meses, Los responsables de desarrollo y el equipo de desarrollo colaboran juntos estrechamente durante todo el proyecto, etc.
  • Facilitar los eventos Scrum según se requiera: Organizarlos, reservar las salas, convocar las reuniones, llevar los artefactos que sean necesarios, comunicar el orden del día y los puntos de la reunión, etc.
Estos son los servicios que el Scrum Master presta al Product Owner, en próximos posts explicaré los servicios que el Scrum Master presta al equipo de desarrollo y a la organización en su conjunto.

Sunday, 9 April 2017

El tamaño del Equipo de Desarrollo

Lo que nos indica la guía de Scrum como mejor tamaño del Equipo de Desarrollo (no el Equipo de Trabajo, sólo el Equipo de Desarrollo, es decir, sin contar con Scrum Master y Product Owner) es de tres miembros cuando menos y nueve como tamaño máximo.

La idea es tener un equipo lo suficientemente pequeño para ser ágil pero que puedan entregar al final de cada Sprint una cantidad de trabajo que merezca la pena como para ponerlo en producción. En cambio no se quiere que tenga un tamaño tan grande, mayor de 9, que haga que se multipliquen las interacciones en el equipo y que haga difícil la coordinación entre ellos.

¿Para un Equipo de Desarrollo de sólo una o dos personas merece la pena Scrum? Estaríamos añadiendo un overhead o sobrecarga de reuniones y ceremonias que podría dificultar la normal marcha del trabajo haciendo perder tiempo al equipo. En mi caso personal, para equipos de estos tamaños aún así he intentando ser ágil siguiendo sólo cuatro principios básicos de Scrum para obtener el máximo de sus ventajas sin sobrecargar de reuniones que podrían ser inútiles al ser tan pequeños. Por ejemplo, mantener la reunión diaria, la reunión de demo, el Sprint y las Pilas de Producto y de Sprint.

En cambio, yendo hacia el lado contrario, tener 10, 11, 12 o más miembros en un Equipo de Desarrollo podría requerir demasiada coordinación y demasiadas reuniones para ponerse de acuerdo entre todos. Si se van a auto-organizar ese tamaño va a llevar demasiada complejidad como para repartirse tareas y coordinarse sin que haya un seguimiento estricto de qué hace cada uno o las dependencias entre el trabajo entre unos y otros y qué tiene que estar listo primero para que el otro pueda avanzar.

El Dueño del Producto y el Scrum Master no cuentan como miembros del equipo de desarrollo a menos que también estén trabajando en la lista de cosas pendientes a acabar dentro del Sprint. En ese caso sí son contados como miembros del Equipo de Desarrollo sumando una o dos personas más según sea el caso.

Hay estrategias para el escalado de Scrum (estrategias para cuando el proyecto es tan grande que un sólo equipo no puede con todo) como DAD (Disciplined Agile Delivery) que no son tan estrictos con los tamaños de los equipos y no prescriben unos tamaños límites mínimo o máximo tan cerrados como estos.

Sunday, 2 April 2017

El Equipo de Desarrollo

Son las personas que trabajan en el producto durante el Sprint para entregar una versión Terminada al final del mismo. Deben trabajar para que esa versión lista al final de cada Sprint pueda ser subida a producción. No quiere decir que al final de cada Sprint haya que subir obligatoriamente una nueva versión sino que está lista, probada y preparada (Terminada) para que potencialmente pueda ser desplegada en producción si alguien así lo decidiese. Son los miembros del Equipo de Desarrollo los que trabajan en la creación de esa nueva versión o Incremento del producto que se prepara cada Sprint.

Los Equipos de Desarrollo se estructura y organizan de tal forma que puedan gestionar su propio trabajo. Para conseguir esto los equipos de desarrollo deben cumplir estas características:
  • Son autoorganizados: Ellos mismos se asignan las tareas según su conocimiento y la preparación o la disponibilidad que tenga cada uno. No es el Scrum Master ni el Product Owner quién reparte las tareas, ni les indican cómo deben hacer su trabajo. Son ellos los profesionales que trabajan en esto y quienes mejor conocen cómo hacer las cosas para terminar el Sprint con una versión que podría ser subida a producción.
  • Son multifuncionales: Esto suele causar confusión con frecuencia. Equipos multifuncionales son aquellos en los que se pueden encontrar en su interior a miembros del equipo con todas las habilidades necesarias para trabajar en la nueva versión, es decir, que tendremos dentro del equipo a alguien capaz de realizar análisis funcional si es necesario analizar algún aspecto en este Sprint y a alguien con conocimientos de DBA si es necesario realizar alguna tarea de administración de base de datos. Tener un equipo completamente multifuncional es una cosa difícil pero nos dará bastante ventaja a la hora de desarrollar ya que no habrá que asignar la tarea a otro departamento, que tendrá sus propias prioridades, para luego mantener a la espera todo el trabajo del Sprint hasta que este departamento pueda llevarla a cabo y entregarla.
  • No existen títulos dentro del Equipo de Desarrollo: Todos son desarrolladores, no existe un miembro que tiene el título de Analista y por tanto sólo desarrolla esas tareas. Lo mismo para el Tester y sólo él o ella testean, podrían hacerlo todos aunque haya miembros del equipo que por sus habilidades y conocimientos estén más especializados para hacer algún tipo de tareas sobre otras pero la responsabilidad cae dentro de todo el Equipo de Desarrollo.
  • No hay sub-equipos dentro de los Equipos de Desarrollo: Esto quiere decir que no hay un sub-equipo de testers o de analistas que sólo se encargan de esto, tampoco los hay de dominios específicos dentro del producto, por ejemplo, no hay un sub-equipo que trabaje sólo con las funcionalidades que tienen que ver con la facturación y otro con las funcionalidades de control de almacén. Todos trabajan en todas las partes del producto.

Monday, 27 March 2017

Los Interesados

Los Stakeholders tienen un nombre bastante feo en su traducción al español para Scrum: Los Interesados. Se les llama así por que tienen algún interés en el producto que se está construyendo. Pueden que sean los dueños o accionistas de la empresa que está pagando por el desarrollo, el jefe del departamento de ventas que quiere un nuevo módulo para la facturación o simplemente los usuarios de la aplicación que se está desarrollando y que tienen particular interés (de ahí lo de Interesado) en que la aplicación o el producto (recordemos que Scrum no se usa sólo para el desarrollo de Software) funcione lo mejor posible.

Estos Interesados han nombrado a un Dueño del Producto para que los represente y a él deben dirigirse siempre que quieran alguna modificación, recordarle alguna prioridad o añadir nuevas características al producto. No deberían dirigirse directamente al equipo de desarrollo para explicarles lo importante que es que la nueva exportación a Excel esté incluida en la próxima versión que se lance. De priorizar estas cosas y darles el valor oportuno debe encargarse el Dueño del Producto. En él estarán centralizados todas las peticiones de cada Interesado.

El jefe de ventas está interesado en la integración de la facturación con los móviles, el jefe de almacén quiere un nuevo sistema de avisos cuando cae el stock, un usuario de administración quiere que los listados puedan exportarse a Excel con sólo un botón porque le ahorraría un montón de clics de ratón. Todos tienen interés en que el producto salga lo mejor posible pero alguien tiene que decidir qué se construye ahora. Los presupuestos tampoco son infinitos y hay algunas cosas a las que hay que decir 'No, ahora no puede hacerse' o simplemente 'No'.

De esta gestión de los Interesados y sus intereses debe hacerse cargo el Dueño del Producto que tendrá que anotar o tener en cuenta cada solicitud y ver si es factible hacerse o no y si va a dar mayor valor al producto final construyendo eso antes que cualquier otra cosa.

Si el Equipo de Desarrollo está en una empresa externa habrá que gestionar también los cambios en la Lista de Producto y los nuevos requerimientos. Será necesario hacer caer de esa lista de cosas por hacer otras funcionalidades ya acordadas que ahora se estiman menos importantes pero que tendrían un coste de desarrollo similar, o bien aumentar el presupuesto (pero recordemos que los presupuestos no son infinitos).

Monday, 20 March 2017

El Dueño del Producto

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

Sunday, 12 March 2017

El equipo de trabajo Scrum

En un proyecto gestionado con Scrum el equipo de trabajo estará formado por tres perfiles: el Dueño del Producto (Product Owner), el Scrum Master y el Equipo de Desarrollo (Development Team).

Ninguno de esos perfiles es el de jefe de proyectos o rol similar ya que estos equipos Scrum son autoorganizados. Esto quiere decir que ellos mismos deciden cómo llevar a cabo el trabajo y se reparten las tareas ¿Quién mejor que el Dueño del Producto para saber lo que hay que hacer y lo que se quiere conseguir? ¿Y quién mejor que el Equipo de Desarrollo para saber cómo hay que las tareas? Ellos dividirán las funcionalidades en tareas más pequeñas, las priorizarán y se las asignarán a si mismos. Ellos mismos se organizan el trabajo cada dos o tres semanas, lo que dure el Sprint.

Los equipos de trabajo también son multifuncionales. Esto significa que dentro del mismo equipo de trabajo encontraremos todos los perfiles necesarios para hacer el trabajo. Si hay que analizar algo lo hará algún miembro del equipo de trabajo. Si hay que realizar una tarea de administración de base de datos lo hará algún otro miembro del equipo (como en DevOps).

Por ejemplo, si necesitamos que se realicen frecuentemente este tipo de tareas de base de datos en el trabajo diario tendremos que contar con alguien con formación de DBA en el equipo. De esta forma el equipo de trabajo puede también autoorganizarse al no depender de otro departamento que tendrá sus propias prioridades y por el que habría que esperar a que realice la tarea. Mientras espera el equipo de desarrollo tendría que dedicarse a otras cosas, quizás menos importantes, hasta que se lleve a cabo la tarea por otro departamento o área de negocio.

Este modelo de equipos de trabajo de Scrum mejora la flexibilidad y la productividad al no estar tan encorsetado y tener un equipo más creativo e independiente.

Al realizar entregas iterativas e incrementales, es decir, realizar una entrega del producto cada vez mayor al finalizar cada Sprint, el equipo de trabajo obtiene feedback de la opinión de los usuarios y los interesados de forma frecuente. Este feedback le permitirá priorizar las próximas tareas y corregir la línea a seguir si es necesario. Estas entregas incrementales son de producto "Terminado" y probado. De esta forma siempre hay disponible una versión plenamente funcional del producto lista para ser usada.

Sunday, 5 March 2017

Teoría de Scrum

Scrum es un marco de trabajo basado en el control de procesos empírico y por tanto no basado en predicciones o suposiciones. Esto quiere decir que el conocimiento procede de la experiencia, la observación de los hechos y de tomar decisiones basándose en lo que se conoce. Las decisiones se toman en base a los resultados que se están viendo en el proyecto y no en base a planificaciones a largo plazo y a fechas de entrega supuestas al principio del proyecto.

Si en un proyecto tenemos que decidir si eliminamos o no una característica nueva de un producto o si es necesario dedicar más esfuerzo al desarrollo de una parte del proyecto para llegar a cumplir los límites establecidos, esta decisión la tomaremos basándonos en los datos sobre el esfuerzo que ya nos ha costado construir esta característica o similares o en los datos reales del tiempo que nos ha llevado construir las tareas ya realizadas. No nos basamos en un diagrama de Gantt con la predicción realizada al inicio del proyecto con lo que supuestamente iba a costarnos realizar estas tareas y con los límites que tenemos para cumplir la planificación, sean estos ya reales o no.

Todos los proyectos intentarán ser lo más previsibles posible y predecir cuando estarán acabadas las cosas pero, si con el objetivo de mejorar la previsibilidad usamos diagramas de Gantt, estimaciones y fechas de entrega a largo plazo con la información que teníamos al empezar el proyecto, podríamos estar teniendo el efecto contrario y volver al proyecto más imprevisible de lo que debería.

Si en lugar de trabajar y trabajar para que los planes sean exactos, asumimos que esos planes pueden estar equivocados y que son sólo eso, planes, podemos tomar las decisiones basándonos en los datos reales que vamos conociendo del proyecto para intentar ser lo más previsibles posible con los que tenemos actualmente.

Para mejorar la predictibilidad del proyecto y poder prever más fácilmente cuando vamos a acabar un conjunto de tareas o todo el proyecto, Scrum se basa en tres pilares:

Transparencia

Scrum entrega de forma iterativa pequeños incrementos del producto de forma que va añadiendo nuevas funcionalidades o características al producto final. La lista de cosas pendientes de terminar es pública, la lista de cosas terminadas y su estado es pública también. Se comparte además un lenguaje común entre todos los participantes en el proyectos de forma que sea claro y transparente para todo el mundo en qué estado está todo.

Cuando se dice que algo está 'terminado' debe significar lo mismo para todo el mundo y que no se barren dejabo de la alfombra con tal de hacer una marca en su casillero funcionalidades hechas pero que no han sido lo suficientemente probadas o no son prácticas. Las cosas están en estado 'Hecho' o 'Terminado' de forma transparente para todo los usuarios de Scrum sin ocultar nada a ninguno. Por eso se habla de tener una definición de 'Hecho' o de cuando algo puede decirse que está terminado.

Inspección

Otro pilar básico de Scrum, lo que se ha entregado y el estado en el que están las cosas se puede inspeccionar por los interesados en el proyecto o el dueño del producto (Product Owner) de forma que compruebe que está en perfecto funcionamiento y que el estado es real. Esto se hace en parte con la reunión de demo, con la transparencia de los entregables que se entregan de forma iterativa para que puedan ser probados y con las revisiones de lo que queda por hacer.  Estas revisiones no deben realizarse de forma tan frecuente que la inspección ralentice el trabajo.

Adaptación

Si en las revisiones de la inspección se comprueba que el producto, el plazo para construir o la nueva característica que se está construyendo se desvían de límites aceptables, o que el producto resultante no será aprobado, deben hacerse cambios para intentar volver a límites dentro de lo aceptable. Estos ajustes deberán hacerse cuanto antes para evitar mayores desviaciones sobre lo que quede por realizar.

Adaptaciones o ajustes como estos son los que hacen que Scrum no sea predecible y no puedan darse largos plazos de predicción porque siempre se está adaptando el producto para mejorarlo y evitar mayores desviaciones sobre el producto ideal con el presupuesto que tenemos.

Para poder realizar estas inspecciones y sus correspondientes adaptaciones Scrum prescribe cuatro eventos o sucesos dentro de cada Sprint. Estos eventos son descritos con más detalle en otros post de este blog:
  • Reunión de Planificación del Sprint (Sprint Planning Meeting)
  • Scrum Diario (Daily Scrum)
  • Revisión del Sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)


Wednesday, 4 January 2017

Curso práctico Scrum - Agile 101

Publico en esta entrada los posibles contenidos que tendría el curso sobre Scrum/Agile 101. Los que me conocen o han leído mi libro saben que no será un curso de Scrum para seguir al pie de la letra, para eso ya están las guías de Scrum que publican Scrum.org o Scrum Alliance.

Será una guía práctica que te permite saber cómo implementar el Scrum que ya conoces de oídas o del que incluse ya tienes un certificado pero no sabes muy bien cómo llevarlo al día a día de tus proyectos.

El contenido estarían divididos en unidades y capítulos como los que pongo a continuación. Sólo falta que ustedes voten por añadir o incluir nuevos capítulos (aún faltan algunos):
  • Introducción y fundamentos de Scrum
  • Descripción reuniones, artefactos, participantes y roles de Scrum (con cheat list o hoja de resumen)
    • Tres capítulos: El rol de Product Owner, El rol de Scrum Master, El rol de los interesados o stakeholders.
    • Tres capítulos: El product backlog, el sprint backlog y la gráfica burndown
  • Cómo implantar Scrum en tus proyectos (con checklist para comprobar que se está haciendo lo importante)
  • Sección cómo… o qué hacer cuando… con Errores y dudas más habituales.
    • Capítulos Buenas prácticas del software (todo no es Scrum en un proyecto).
  • Qué certificación Scrum elegir
  • Scrum ventajas e inconvenientes
  • Estimaciones ágiles en tus proyectos
  • Lecciones aprendidas
  • Kanban
  • Entender y cómo usar la gráfica burndown.
Será un curso fácil de seguir en el que cada capítulo o unidad contaría con:
  • Uno PDF con texto explicando el contenido de la unidad
  • Otro PDF con texto y contenidos adicionales que no son estrictamente temario pero que ayudarán a completar y entender la información del temario.
  • Un vídeo en el que explico de viva voz los contenidos de la unidad siguiendo gráficas o slides de presentaciones.
  • Un ejemplo práctico basado en un caso real en el que pongo en contexto el contenido de la unidad.
  • Una batería de tests de 10 preguntas sobre la unidad y un ejercicio propuesto sobre el contenido de la unidad. En el siguiente paso a estos tests se darían las soluciones o claves al ejercicio propuesto.
La idea es que el contenido del curso pueda completarse con unas 40 o 50 horas de trabajo de forma que puedas terminarlo en 4 o 5 semanas si le dedicas unas 10 horas a la semana (1 hora diaria y un par horas más el fin  de semana podría ser un ejemplo).

Al final del curso habría un test con preguntas abiertas y cerradas junto a un ejercicio práctico que corregiría personalmente. Este test sería diferente para cada alumno y si se suspende se tendría derecho a otro intento (con otro examen diferente). Se entregaría a los aprobados un PDF con mi firma y un logo del curso que podría descargarse desde mi web con un enlace como el siguiente https:\\antoniomartel.com\certificados\manuel-echevarria-agile101.pdf para que puedas entregar el link a cualquier empleador o jefe tuyo y pueda comprobar por el mismo que el PDF es original.

El contenido del curso está aún abierto. Si te gusta lo que vas leyendo del curso y te animas a contestar unas preguntas para saber qué te puede interesar y qué no, pásate por el enlace a la encuesta del curso Scrum - Agile 101 y me ayudarás a saber qué puede ser más interesante para los alumnos del curso.