Mi primer BackLog con Trello

cap-5-1

Imaginemos que deseamos realizar un proyecto sobre una tienda on-line para la venta de gafas de sol importadas. Para ello se definen una serie de tareas principales en forma de historias de usuario

 

  1. Como jefe Comercial quiero poder dar de alta productos con sus precios
  2. Como jefe Comercial quiero poder definir campañas de ofertas
  3. Como Jefe Comercial quiero poder crear usuarios que puedan comprar en la tienda o modificar la lista de productos de venta
  4. Como jefe Comercial quiero que los usuarios se puedan dar de alta a través de la web
  5. Como jefe Comercial quiero poder conocer el estado de las ventas en cada momento
  6. Como jefe Comercial quiero que exista una aplicación móvil para que los usuarios puedan comprar en la web

Lo primero que haríamos es dar de alta todas las tareas en forma de tarjeta y las introduciríamos en la columna del Product Backlog

 

La apariencia del tablero sería la siguiente

 

cap-5-2

Ilustración 2 Producto Baclklog relleno

 

En esta primera iteración sería suficiente con identificar y escribir las tareas, es sólo el primer paso pero muy importante en el sentido que nos permitirá hacer una primera estimación, muchas veces necesaria, y nos permitirá conocer todas las tareas cuyo desarrollo puedo iniciar.

 

 

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

 

Scrum. Historias de Usuario

cap-3-1La comunicación

El proyecto software que un equipo de desarrollo va a realizar en la mayoría de los casos no responde a una idea suya sino más bien a las necesidades que alguien (los usuarios) tienen. Los usuarios deben indicar lo que quieren resolver a otra persona (en el modelo tradicional un analista), éste a su vez captura lo que él ha entendido como requisitos del usuario y describe en forma de análisis de requisitos o funcional u algún modelo similar, lo que él ha entendido. Ese trabajo acabará finalmente en unas indicaciones más o menos concretas para que el equipo de desarrollo finalmente implemente el proyecto.

Una de las mayores preocupaciones es que el analista que capta las peticiones del usuario, suele terminar transmitiéndolas en un documento de difícil compresión para éste. Así en general los completos documentos de análisis de una aplicación rara vez suelen ser entendidos por los usuarios, que en general suelen basarse en lo que ellos aseguran que dijeron más allá de lo que especifique el documento de análisis.

Además, otro de los problemas del modelo en cascada es que requiere de un análisis completo de los requerimientos para generar un documento completo antes de iniciar las posteriores fases de diseño y desarrollo.

Una alternativa a estos modelos es utilizar las Historias de Usuario, como mecanismo para ser mucho más ágil a la hora de captar los requisitos, así como acercar la definición final de los mismos al último momento que se pueda, para conseguir captar cualquier cambio en las ideas iniciales.

Según Mike Cohn, las Historias de Usuario describen la funcionalidad de algo que es valioso para un usuario de un sistema o software.

Las Historias de Usuario se componen de tres elementos:

  • Una descripción escrita de la historia usada para la planificación y como un recordatorio.
  • Conversaciones sobre la necesidad de la historia que sirven para profundizar en los detalles de la misma
  • Elementos de prueba que permiten determinar cuando las tareas que va a cubrir la historia está completa.

Así una historia debe permitir conocer la base de las necesidades del usuario, así como los detalles que después permitan fijar la batería de pruebas  para poder determinar si un desarrollo es correcto o no.

Inicialmente se fijaba que esas historias de usuario se escribieran en unas tarjetas en vez de en una libreta, lo que hizo que Ron Jeffries lo llamara CCC Card, Conversation, Confirmation (Tarjeta, Conversación y Confirmación). Así la tarjeta almacenaba la historia del usuario, y a través de la Conversación y la confirmación. Hay autores que afirman que las tarjetas son la mejor forma de almacenar las Historias de Usuario.

Otro de los aspectos fundamentales es que la historia de usuario debe estar expresada en un lenguaje  que el usuario pueda entender y que refleja una descripción sintetizada de lo que el usuario desea.

La descripción puede ser libre, aunque es generalmente el modelo propuesto por Mike Cohn es el aceptado.  En él que se indican tres cosas, ¿Qué tipo de usuario es el que solicita? ¿Qué se quiere? ¿Por qué se quiere?

Un ejemplo de Historia de Usuario podría ser:

“Como responsable de almacén quiero conocer cuando se alcanza el stock mínimo para poder realizar más órdenes de compra.”

 

Atributos de las historias de usuario

Las Historias de Usuario son peticiones muy sencillas y claras que definen cuales van a ser los requisitos del proyecto. Es preferible tener un número mayor de historias simples que uno menor de historias más complejas.

Pero hay una serie de atributos mucho más concretos que las Historias de Usuario deberían cumplir.  Bill Wake en su libro Programming Explored and Refactoring las denomina con el acrónimo INVEST que se basa en las iniciales de los seis atributos recomendables para las Historias de Usuario.

  • Independent
  • Negotiable
  • Valuable to users or customers
  • Estimatable
  • Small
  • Testable

 

A.        Independendientes (Independent)

 

Es razonable evitar la existencia entre dependencias entre las historias, es decir historias que para estar finalizadas dependen de la finalización de otras. Esto añade un punto más de complejidad a la planificación de realización de tareas, obligando a estar muy pendiente de estar interrelaciones y definir una priorización en la realización de las mismas.

Imaginemos las Historias de Usuario a definir para que un cliente pueda realizar el pago con diferentes tarjetas de crédito:

 

  • Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
  • Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard
  • Como Jefe de ventas quiero que mis clientes puedan pagar con American Express

 

Las tres historias están muy relacionadas, además el coste en horas de implementación de cada una de ellas es dependiente de las otras. Es decir el tiempo para construir  la primera puede ser 4 horas y una vez realizada la primera, implementar las otras dos, tendrían un coste considerablemente menor. Existen dependencias entre las tres historias. La forma de evitarlas podría ser construir una historia que las englobe:

  • Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjetas Visa, Mastercard y American Express

 

Si las historias todavía tienen un tamaño elevado, se puede hacer una subdivisión, más equivalente cuanto a coste

  • Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
  • Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard y AmericanExpress

 

Otra alternativa es que en la estimación de tiempo de cada historia se especifique el coste si se realiza antes o si se realiza después que otra (Aunque es un mecanismo algo complicado ya que añade un elemento más a los cálculos de costes).

 

B.        Negotiable (Negociables)

Es una de las bases de la programación ágil, las Historias de Usuario no son unos requisitos cerrados que permiten cerrar un contrato que no se puedan cambiar. Una Historia de Usuario es una breve descripción de la funcionalidad que muchas veces se puede utilizar como un recordatorio. Los detalles de la historia se suelen retrasar hasta los últimos momentos para precisamente evitar cambios de última hora.  Eso no impide que si en el momento de redactar la base de la historia, se conoce algún detalle se pueda anotar en la misma tarjeta toda la información que se conozca (aunque suele ser sensato contrastarla en el momento que sea necesario).

En este caso el cliente (el jefe de ventas) puede considerar en el momento de la entrevista que solo se admitan dos tarjetas aunque es razonable contemplar en la implementación que es posible que se incorporen  más.

Si se dispone de más información del requisito es bueno tomar nota de él. El reverso de la tarjeta es un lugar ideal para acompañar detalles útiles en la implementación.

La tarjeta es un recordatorio, personalmente yo recomiendo apuntar detalles que generan duda o incertidumbres a contrastar directamente, hay que olvidar el famoso dicho de “no hace falta apuntarlo ya que ya lo recordaré”. Es bueno tomar nota, e incluso subrayar si es necesario realizar una consulta a otras personas.  Estas pequeñas notas en el reverso pueden ayudar en la segunda entrevista al usuario.

 

 

 

C.        Valuable (Con valor para el usuario)

Es uno de los aspectos más controvertidos sobre las Historias de Usuario. Hay quién indica que las historias deben aportar valor al usuario y por eso es razonable que el usuario las pida directamente. Yo considero que todas las historias que se implementen deben tener valor para el usuario aunque éste inicialmente no lo sepa.

El usuario debería estar seguro que todas las historias le aportan valor. En general, temas de seguridad a muchos niveles no les preocupan (no porque no lo consideren importante, sino porque a veces lo dan por hecho). Las Historias de Usuario deben aportar valor, en general se definen en base a peticiones del usuario, no obstante cabe la posibilidad de definir historias de usuario a partir de criterios técnicos por parte del equipo. Es estos casos es necesario que se explique correctamente al usuario los motivos de necesidad de estas.

 

D.       Estimatable (Estimable)

El equipo de desarrollo debe poder estimar el coste (al menos aproximado) de desarrollar cada una de las Historias de Usuario. Es un requisito fundamental para poder planificar de manera razonable las historias que se pueden desarrollar dentro de un Sprint. La forma de medir el coste puede ser las horas de desarrollador  o los puntos de historia (tratados en capítulos anteriores)

Es posible que el coste de una historia no pueda ser calculada con un nivel de precisión razonable, los motivos habituales por los que esto pueda ocurrir son

  1. El equipo de desarrollo no conoce el dominio. Ya se comentará en el tema de la entrevista. Obviamente el equipo de desarrollo no puede pretender tener el mismo conocimiento que tiene el cliente del entorno de trabajo de éste. Aun así, es conveniente adquirir unas bases que permitan, en primer lugar dar confianza al cliente, y en segundo lugar abordar con el suficiente conocimiento los desarrollos a realizar.
  2. El equipo de desarrollo no tiene conocimientos técnicos del entorno. También puede ocurrir que el equipo de desarrollo deba trabajar en un entorno de programación o base de datos novedoso (al menos para ellos) que puede hacer que estimen sin un nivel de confianza lo suficientemente alto. Es este caso se agradece la aportación de expertos en el entorno que pueden hacer ver las comparaciones de costes con entornos mejor conocidos por el equipo de desarrollo. Si no se dispone de ningún experto, es razonable que algunos miembros del equipo profundicen de manera rápida en el tema. Esta profundización debe contar como una historia más, ya que tiene su coste en horas.
  3. La historia es demasiado compleja o tiene un tamaño muy grande. Este caso es el más sencillo de resolver, se debe dividir la historia en dos o más historias de menor tamaño que puedas ser estimadas con mejor precisión.

E.        Small (Pequeña)

El concepto pequeña es muy relativo, pero entendemos como que la Historia de Usuario debe tener una duración que la haga lo suficiente manejable para el equipo. Pequeña no debe confundirse con microscópica, ya que tener un sinfín de cientos de historias microscópicas puede convertir en un infierno la planificación y la integración de todas en el proyecto final.

Es razonable que el equipo de desarrollo defina un coste razonable para las Historias de Usuario estándar con las que van a trabajar. Algunos hablan de semana/programador como el tiempo máximo, mientras otros equipos prefieren definir como un día/programador como un coste medio razonable.

Una historia que fuera como jefe de ventas quiero una “gestión web de las ventas para incrementarlas” tiene una dificultad considerable para ser estimada.

Debiera poder dividirse inicialmente en gestión de usuarios, de productos y en sí de la venta. Aun así cada una de ellas tiene una complejidad elevada. Es posible que la gestión de usuarios al ser bastante estándar pudiera (quizá no debiera) quedar como una historia.

Es más razonable definir historias del tipo:

  • Como jefe de ventas quiero poder dar de alta un producto para venta
  • Como jefe de ventas quiero poder modificar características de un producto o eliminarlo
  • Como jefe comercial quiero poder añadir campaña comerciales que afecten al precio de venta del producto

Un modelo de historias de este tipo es que permite de manera sencilla estimar el coste de cada historia e incluso permite que el cliente pueda priorizar entre las mismas. Así podemos iniciar una página de venta con productos y más adelante permitir la incorporación de campañas comerciales de diverso tipo.

 

La gestión de usuarios, bastante estandarizada puede ser considerada como una única historia de usuario más allá de historias del tipo:

  • Como jefe de ventas quiero poder dar de alta un usuario
  • Como jefe de ventas quiero poder modificar un usuario
  • Como jefe de ventas quiero poder dar de baja un usuario
  • Como jefe de ventas quiero poder consultar un usuario

Pero no hay que olvidar que el concepto de Small (pequeño) es muy dependiente de como el equipo de desarrollo se sienta cómodo. En sí lo que si debe garantizar al cien por cien es que toda historia de usuario debe ser estimable y deba tener un coste mínimo algo más alto que el tiempo que se pierda en hablar de ella.

F.         Testable (Se puede validar)

Otro de los conceptos que hemos visto como un tema fundamental es el de terminado. Una historia debe tener unos objetivos claros, y deben ser tan claros que deba ser posible comprobar que el trabajo ha cumplido las expectativas, es decir que se pueda validar el trabajo realizado.

Otro de los objetivos es que el mayor número de historias se pueda validar de forma automática, por lo que es muy interesante utilizar conjuntos de aplicaciones de prueba que así lo permitan. En ocasiones, esto es complicado, pero hay que definir claramente una batería de pruebas que pueda ser realizada para verificar lo correcto de un programa o módulo. El coste de realizar las pruebas se debe incluir en el coste de la historia de usuario, a menos que haya alguna historia que tenga como objetivo la realización de una serie de pruebas de conjunto.

Sólo los requisitos no funcionales como pueda ser “conseguir un Interfaz amigable o facilidad de uso para usuario novel” pueden evitar la definición de esas baterías de prueba. No obstante se pueden definir tareas más complejas que exceden al equipo de desarrollo y que permitan hacer una estimación del grado de resolución de algunos requisitos no funcionales.

 

Conclusiones

Las Historias de Usuario son una forma de acercar el lenguaje del usuario al desarrollador, de forma que se permita hablar un mismo lenguaje ambos y se eviten ambigüedades que puedan suponer pérdidas de tiempo notables.

Lo importante de las historias es que reflejen de forma sencilla lo que el usuario quiere, “El qué” y no “el cómo”.  Es importante que sean muy claras y  con criterios de validación muy concretos. Durante el proceso, las historias pasarán a ser grandes trabajos a realizar muy generalmente especificados, hasta ser tareas concretamente detalladas, pero es un proceso por fases, que permite detallar la tarea junto con el cliente cuando se van a implementar.

 

 

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¡¡