Tableros Scrum con Trello

Los artefactos fundamentales de Trello son los tableros, las listas y las tarjetas.

Un tablero es la parte central del proceso Trello y representa la situación y evolución de un proyecto.

Las tarjetas representan la situación de cada una de las tareas que conforman el proyecto que estamos realizando y por último las listas representan los estados por los que se encuentran las diferentes tareas.

Hay múltiples formas de definir un tablero Scrum en Trello en función del uso que quieras darle. Una posible propuesta es crear las siguientes listas que representas los estados siguientes.

Product Backlog. Representan todas las tareas que conforman el proyecto

Sprint Backlog Representan todas las tareas que forman parte del Sprint actual que no se han iniciado todavía

En desarrollo. Tareas del Sprint actual que se están realizando

Terminado Sprint actual Tareas finalizadas en el Sprint actual

Terminado Tareas que se han finalizado en cada uno de los Sprints

Impedimentos Problemas activos que se deben solucionar

 

Para crear un tablero y las listas, debemos inicialmente crear un tablero dándole un nombre y luego ir añadiendo cada una de las listas del tablero.

Trello también permite opciones de copiar definiciones de listas de otros tableros, para no tener que repetir todo el proceso.

 

Esta podría ser la apariencia de nuestro tablero

cap-4-1

Ilustración 1Tablero con listas

 

Trello (y II) Gestionando Equipos conTrello

Los roles de los equipos ágiles

No hay metodología ni modelo de desarrollo, por bueno que sea que sustituya a lo más importante que es el equipo de personas que van a desarrollar el producto. En cualquier entorno de cierta complejidad el equipo es fundamental. Es prácticamente imprescindible que el equipo funcione bien para que el desarrollo tenga un final feliz.

Un equipo trello está formado por todas aquellas personas que tienen que ver con el desarrollo de una tarea, tanto de forma activo como aquellos que deben estar informados del grado de cumplimiento del desarrollo de la misma. Las metodologías ágiles como SCRUM incorporan una serie de roles que definen las acciones que deben o pueden realizar cada uno de ellos

Scrum aporta una serie de aspectos que potencian el grupo, que potencian el trabajo en equipo, porque todo es importante en un desarrollo software, pero no tanto como la gestión de las personas.

En los desarrollos software se identifican una serie de roles que son los responsables de que determinadas tareas se realicen. Las propuestas de Scrum al respecto de la organización del equipo varían en la definición de unos nuevos roles y un nuevo comportamiento entre ellos.

Tradicionalmente habremos escuchado los roles de Project manager, Program Manager, jefe de Desarrollo, gestor de Calidad, responsable de pruebas y gestor de versiones entre otros. Cada uno tiene sus responsabilidades muy específicas dentro del equipo.

Scrum hace una primera división (muy curiosa) de los miembros del equipo en base a su implicación con respecto al proyecto, y lo hace con un chiste sobre las ansias emprendedoras de un cerdo y una gallina, cuenta lo siguiente

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, “Oye, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice, “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta, “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”.

cerdoyhuevo

Ilustración 1 Filetes de cerdo y huevo frito

La diferencia de compromiso es obvia, mientras en el plato de filetes de cerdo y huevos fritos, el cerdo pone su vida, la gallina se limita a poner huevos. Así en SCRUM tenemos equipos (SCRUM team) formados por cerdos y gallinas, o sea implicados e interesados, todos son tienen su importancia en el proyecto pero no la misma.

Dentro de los cerdos o implicados tenemos:

  • Product Owner
  • Scrum Master
  • Development Team

 

Dentro de las gallinas o interesados tenemos

  • Stakeholders (Interesados)

 

El Product Owner (el Dueño del producto)

El sueño de todo analista y/o desarrollador es tener al cliente disponible las 24 horas del día para que le pueda solucionar cualquiera de las dudas que surgen durante el proceso de análisis y desarrollo. Obviamente cuando hablo del cliente me refiero al responsable de la aplicación, no al responsable del equipo de desarrollo. Este es el Product Owner,  la persona responsable de fijar que es lo que es el producto, cuales son las partes que lo van a formar e incluso fijar las prioridades dentro de la Lista de Producto (se verá más adelante).

Es importante destacar que siempre el Product Owner es una única persona, es la persona que asume la responsabilidad de determinar qué es ese producto, aunque obviamente pueda tener que hacer las consultas correspondientes a otras personas. Es decir, si es un comité el que decide los requerimientos de un producto, el interlocutor del comité respecto al resto del equipo  es el Product Owner. La importante ventaja de este modelo es que se aísla al equipo de desarrollo de los pensamientos de cada uno de los miembros de un comité,  pero por otro lado hace recaer todo el peso de la responsabilidad en el Product Owner.

En realidad el Product Owner realmente puede ser un miembro de la empresa que solicita el producto  o puede ser alguien de la empresa de desarrollo que haga de interfaz con el cliente.  En cualquier caso es la persona responsable de fijar los requerimientos del producto. Debe estar accesible por parte del Scrum Team en (casi) cualquier momento y debe formar parte activa de las reuniones en los que su presencia es requerida.

Entre otras sus tareas son:

  • Conseguir maximizar el valor del producto y del trabajo del Scrum Team. O sea maximizar especificaciones del producto al menor coste en número de horas del Scrum Team.
  • Conocer y validar los requerimientos del producto.
  • Asegurarse que los miembros del Scrum Team le han entendido perfectamente.
  • Marcar las prioridades y orden en el que los diferentes componentes del producto deben ser implementados.
  • Hacerse respetar. Si la organización no respeta el criterio del Product Owner los anteriores ítems carecen de sentido, e incluso si perdiera la confianza del Scrum Team sobre la importancia de su criterio, inevitablemente dificultaría las posibilidades de éxito del desarrollo.
  • Ante cualquier duda que surja en el equipo es el que actúa como árbitro.

 

Además se debe cumplir una máxima “Ninguna otra persona que sea el Product Owner puede modificar o añadir requerimientos al producto, el Scrum Team solo puede desarrollar en base al criterio fijado por el Product Owner”.

Scrum Master

Tenemos un equipo preparado (Scrum Team), tenemos al Product Owner que fija objetivos (controla costes) y solo falta el miembro del equipo que debe conseguir organizar al equipo para poder cumplir los objetivos fijados, este es el Scrum Master.

El Scrum Master es el responsable de que el equipo pueda trabajar según las reglas Scrum y también es el responsable de que así sea. Esto debe conseguirlo fundamentalmente:

  • Favoreciendo la auto-organización del equipo impidiendo interferencias y/o distracciones externas.
  • Resuelve problemas e impedimentos que puedan surgir (ya sean informáticos o de intendencia).
  • Debe mantener visibles los artefactos Scrum (más adelante comentaremos lo que son)
  • En cierta forma es el líder del equipo, lo que no implica la autoridad sobre el resto de miembros del equipo. Aunque inevitablemente el concepto de líder conlleva cierta autoridad sobre el resto.
  • Es el responsable de definir (o aplicar) los Timeboxes o límites de tiempo máximos para determinadas tareas.
  • Debe gestionar la Lista de Producto (lista de tareas que engloba un proyecto)  de manera efectiva cumpliendo las peticiones del Product Owner, por ello debe ser capaz de hacerle entender la mejor forma de priorizar tareas.
  • Es el máximo responsable de que todos los eventos Scrum se realicen en tiempo y forma.
  • Debe conseguir que la lista de Producto sea  clara y no tenga ningún tipo de ambigüedad.
  • Debe ser capaz de explicar el modelo Scrum al resto de la organización, haciéndole ver sus ventajas.
  • Y por supuesto, debe motivar al equipo, facilitando que consiga sus metas.

 

Development Team o equipo de desarrollo

El Equipo de Desarrollo está formado por un grupo de profesionales responsables en último plazo de diseñar e implementar el producto a realizar. Son los que llevan el peso de la realización de todos y cada uno de los Sprints, son los responsables de que el trabajo que realizan se pueda poner en producción.

La estructura del equipo de desarrollo les permite organizar y gestionar su propio trabajo. Esto rompe el esquema tradicional en el que cada uno de los miembros del equipo recibía por parte de un superior las órdenes concretas que determinaban el desarrollo que debía realizar. Las características principales que los definen son:

  • Los equipos son autoorganizados y son dirigidos desde el mismo equipo.
  • Los equipos son multifuncionales, es decir tiene miembros con diferentes habilidades desde desarrollo puro a testing e incluso análisis.
  • El equipo es autónomo, no dependen de nadie externo al equipo a la hora de tomar decisiones (algo a veces difícil de asumir). Es el mismo equipo el que toma las decisiones que afectan al proyecto que están desarrollando.
  • Se basa en el trabajo colaborativo. Es fundamental el trabajo en equipo abandonando el concepto de francotirador solitario.
  • Funciona mejor si físicamente se halla en el mismo lugar, lo que favorece además de las relaciones personales, ayudas puntuales y el propio seguimiento del proyecto.
  • Lo ideal es que los equipos Scrum se mantengan en el tiempo, en varios proyectos, lo que contribuye al conocimiento profesional y personal de los miembros del equipo.
  • Scrum no reconoce títulos para los miembros de un equipo de desarrollo, todos son desarrolladores, independientemente del trabajo que realice cada persona. No hay excepciones a esta regla.
  • Cada miembro del equipo puede estar especializado o destacar en algún tema en concreto, pero siempre la responsabilidad recae sobre todo el equipo como un todo.
  • No se deben definir sub-equipos de desarrollo especializados en alguna tarea, no hay excepciones a esta regla. Por ejemplo definir el equipo de análisis o de pruebas.
  • Los tamaños de equipo no deberían superar las 9/10 personas y quizá tengan poco sentido con menos de 4/5 personas.
  • Es ideal que todos los miembros del equipo tengan habilidades transversales imprescindibles en el desarrollo de proyectos informáticos  (análisis, diseño, desarrollo, pruebas, documentación, etc).

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto en el sentido de la financiación o solicitud así como aquellos para quienes el proyecto producirá el beneficio acordado (usuarios de la aplicación). Solo participan directamente durante las revisiones del producto que va finalizando el equipo de desarrollo.

 

Creando el equipo Trello

 

En la esquina superior derecha, justo al lado de nuestra foto aparece un signo “+” que nos permite acceder a una serie de opciones. Una de ellas es la creación de equipos. Si la seleccionamos nos pedirá el nombre del equipo y una pequeña descripción del mismo.

 

cap-2-2

Ilustración 2 Menú de opciones

cap-2-3

Ilustración 3 Dando de alta el equipo

 

Como no podía ser de otra manera, el equipo podemos configurar los aspectos gráficos de la foto que lo ilustre, así como lo importante de indicar las personas que forman parte de él.  Para ello de vemos o bien introducir su nombre o (si no están dados de alta en trello) realizar una invitación a su correo para que así lo hagan.

Cada vez que se incorpora a un nuevo usuario al equipo, éste recibe un correo en el que se le informa de tal acción. Un usuario puede abandonar un equipo siempre que lo desee.

Todos los usuarios pueden actuar como usuario administrador o usuario normal. El primero es el único que puede gestionar los cambios en el equipo.

cap-2-4

Ilustración 4 Equipo Trello

 

Ya tenemos el equipo, ahora ya sólo toca empezar a trabajar.  3, 2 1, ya¡¡

Mi libro “Guerreros Ágiles seleccionado por Amazon para su promoción de Octubre

guerreros-agiles

Me acaba de llegar un correo de Amazon que dice

“Durante el mes de octubre, desde Amazon queremos celebrar el fenómeno de la autopublicación independiente. Como autor de KDP, usted sabe lo importante que es que su libro tenga visibilidad, por eso mismo nos complace comunicarle que ha sido seleccionado para participar en nuestra promoción especial, “Publica con Kindle”, que celebraremos en octubre.

Nosotros nos encargaremos de realizar el descuento en su libro para facilitarle y garantizarle la inclusión en este evento.”

Así que a partir del 1 de octubre y sólo durante ese mes, mi libro Guerreros Ágiles tendrá una promoción de precio especial.

Si deseáis adquirirlo entonces o ahora nada más debéis pinchar aqui 

Trello. Post 1. Empezando con Trello

Nos damos de alta en Trello

Como en casi cualquier herramienta informática actual, el primer paso que debemos dar de realizar es el darnos de alta. Para ello deberemos en nuestro navegador introducir la dirección www.trello.com.

cap-1-1

Ilustración 1 Accediendo a la web de Trello

 

Únicamente debemos registrarnos la primera vez, y podemos hacerlo dando de alta nuestra dirección de correo y la consabida contraseña. También podemos hacerlo directamente utilizando nuestro usuario de Google.

cap-1-2

 

Ilustración 2 Registrándonos en Trello

 

El sistema nos pedirá verificar la dirección de correo electrónico enviando un correo para que simplemente dando un click podamos empezar a trabajar.  La primera pantalla con la que nos encontramos tiene una apariencia parecida a la siguiente :

 

cap-1-3

Ilustración 3 Pagina inicial de Trello

 

Cabe destacar una serie de aspectos que iremos explicando en los sucesivos capítulos, a destacar los tableros y equipos (también veremos lo que son las listas) y la consabida ficha de usuario personalizable.

Definimos nuestro perfil

Si hacemos click sobre nuestro nombre que aparece en la esquina superior derecha de nuestra pantalla podemos acceder a nuestra ficha de usuario. En la pestaña de Configuración aparece por un lado toda nuestra información personal, con  el resto de pestañas podremos acceder al trabajo que hemos realizado con la herramienta.

cap-1-4

Ilustración 4 Definiendo perfil de usuario

 

Mucha de la información de nuestro trabajo se irá actualizando a medida que vayamos interactuando con la herramienta, obviamente nuestra información personal la deberemos introducir nosotros explícitamente.

Una de las primeras cosas que deberíamos gestionar es la inevitable foto o avatar que nos acompañará a nosotros y a los miembros de nuestro equipo cuando empecemos a interactuar. La foto la podemos captar directamente o subir una que tengamos en nuestro escritorio. Habitualmente siempre se trata de captar una instantánea con la propia cámara del ordenador, de la misma forma suele ser habitual que tras tres o cuatro intentos debido a la escasa iluminación, la mala cara que uno lleva tras muchas horas de trabajo o simplemente porque uno es feo, siempre acabas acudiendo a una que tienes archivada. La otra alternativa es utilizar la foto de un avatar o un famoso, no lo recomiendo si no quieres acabar con dos o tres John Nieves en el grupo sin poder saber quién es el responsable del último desaguisado en la aplicación.

Recomiendo que activéis desde el mismo menú de Configuración, que activéis la opción que permite a Trello enviarte notificaciones, suele facilitar enormemente la comunicación entre los miembros del equipo.

Una vez dados de alta, toca empezar a trabajar, y empezamos en 3,2,1….