icono_twiter
Alejandro Pérez García

Alejandro es socio fundador de Autentia y nuestro experto en J2EE, Linux y optimización de aplicaciones empresariales.

Ingeniero en Informática y Certified ScrumMaster

Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid).
Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2010-07-08

Tutorial visitado 15.383 veces Descargar en PDF
Gestión de proyectos ágiles con Pivotal Tracker

Gestión de proyectos ágiles con Pivotal Tracker

Creación: 07-07-2010



Índice de contenidos

1. Introducción
2. Entorno
3. Instalación
4. Empezando a probar, creando un proyecto de prueba
5. Qué podemos encontrar dentro de nuestro proyecto
5.1. Pilas
5.2. Tipos de historias de usuario
5.3. Planificación y calculo de velocidad
6. Perfiles de usuarios
7. Conclusiones
8. Sobre el autor



1. Introducción

En este tutorial vamos a ver un poquito de Pivotal Tracker. Esta es una herramienta de gestión de proyectos ágiles, por ejemplo para proyectos con Scrum.

De esta herramienta podemos destacar frente a otras:

  • Es gratis y no tiene ningún tipo de limitación. Es decir no hay licencia “community” y otra “enterprise”, ni nada parecido.

  • Esta en la nube. Con lo que no tenemos que instalar nada en nuestros ordenadores, todo lo haremos a través del navegador.

  • Se centra en algo muy interesante que es la gestión de la pila de producto, y métricas como la velocidad. Es decir, he visto muchas herramientas de este estilo y la mayoría intentan simular los post-it de la pared. Quedan muy monas, pero no son prácticas porque la mejor manera de usar los post-it es ponerlos en la pared.

  • Por supuesto se puede usar para trabajo con equipos descentralizados, puesto que está en internet. Además se puede crear varios perfiles de acceso por lo que podría haber usuarios que, por ejemplo, sólo tienen permiso para ver las cosas, pero no para modificarlas.

  • Guarda histórico de nuestras acciones. Esto es bastante importante si tenemos, por ejemplo, alguna certificación de calidad, como puede ser ISO, que siempre nos exigen trazabiliad de nuestro trabajo (aunque para mi, esto es fundamental tengas o no certificación de calidad ;)



2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 17' (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).

  • NVIDIA GeForce 9400M + 9600M GT with 512MB

  • Sistema Operativo: Mac OS X Snow Leopard 10.6.3 (ingles)



3. Instalación

Esto es lo mejor de todo, como está en la nube, la aplicación no requiere de instalación ni de ningún tipo de mantenimiento. Basta con ir a la página de Pivotal Tracker (http://www.pivotaltracker.com/) y registrarnos totalmente gratis.

Nos mandarán un email para la confirmación del registro. No es inmediato, por lo menos a mi me vino de un día para otro, pero paciencia que llega. Y una vez confirmado el registro ya nos podremos logar en nuestra cuenta y empezar a crear proyectos como locos ;)



4. Empezando a probar, creando un proyecto de prueba

Antes de ponernos en serio podemos crear un proyecto de prueba para jugar un poco y familiarizarnos con la interfaz. Los chicos de Pivotal Tracker han pensado en todo y nos dan la opción de crear un proyecto de prueba de forma automática. Para ello nada mas logarnos entramos en el panel de control (el “Dashboard”) y vemos una opción de “demo project”. Si pulsamos este enlace se nos creará un proyecto con algunos datos ficticios para jugar con ellos.

Al entrar por primer vez en nuestro proyecto de prueba nos mostrará una ventana por si queremos ver un vídeo del uso básico. Es muy corto y bastante explicativo, así que recomiendo que lo veáis.



5. Qué podemos encontrar dentro de nuestro proyecto

Una vez dentro del proyecto veremos algo de este estilo:

Vamos a ir comentando algunas cosas.



5.1. Pilas

Todas las historias de usuario se ordenan en varias pilas que podemos ver en la zona principal de la aplicación:

  • Current: Son las historias de usuario que tenemos planificadas para el sprint en el que estamos.

  • Backlog: Son las historias de usuario que tenemos planificadas para sprints futuros. Vemos como Pivotal Tracker nos va marcando donde empiezan los sprints. Esto lo hace de forma automática en función de nuestra velocidad media. Por ejemplo si insertamos una nueva historia de usuario en mitad de un sprint, en función de la estimación de esta nueva historia, moverá las historias posteriores para ajustarlas a los sprints en función de nuestra velocidad. Esto por ejemplo me encanta porque podemos ver de un vistazo una estimación a largo plazo de nuestro proyecto.

  • Icebox: Son historias de usuario que todavía no tenemos planificadas. Digamos que aquí meteríamos la lista de los reyes magos, pero que todavía no tenemos pensado cuando las vamos ha hacer.

  • Done: Esta pila por defecto no se muestra, pero si la activamos nos enseñaría los sprint que ya han pasado, aquí podemos ver cuándo se hizo qué.

Podemos determinar que pilas son las que se muestran con los botones que encontramos arriba a la izquierda.

Las historias de usuario las vamos moviendo entre estas pilas, tan fácil como pinchar y arrastrar. Tanto para cambiar la prioridad (el orden en la pila) como para cambiarlas de una pila a otra.



5.2. Tipos de historias de usuario

  • Feature: son las representadas por una estrella. Son las que representan requisitos de usuario y las únicas que se estiman (es decir podríamos decir que son lo que Scrum entiende como “Historia de Usuario”). Bueno, esto no es del todo cierto, porque podemos cambiar la configuración para que no sean las únicas que se estiman, pero desde Pivotal Tracker nos recomiendan que no lo cambiemos, no por un tema técnico sino porque el resto de historias no aportan valor de negocio al usuario y estimarlas rompería un poco con la idea de Scrum (nuestra velocidad se debería medir en funcionalidad de negocio que somos capaces de hacer en un sprint).

  • Bugs: Son las representadas por la mariquita. Son deuda técnica, cosas que hemos hecho mal :(

  • Chore (faena, trabajo rutinario): Son las representadas por una rueda dentada. Representan tareas que tenemos que hacer pero que ni aportan valor de negocio ni son errores, por ejemplo montar un servidor de integración continua, preparar el entorno de producción, ...

  • Release: Son las representadas por una bandera. Marcan hitos en el tiempo y se tienen en cuenta en la planificación y cálculo de velocidad. Por ejemplo, cuando se crea una Release, se le indica la fecha, si todo va bien saldrá en azul (como se ve en la imagen de arriba), pero si según nuestra velocidad no nos va a dar tiempo a terminar todas las historias que hay por delante nos la marcará en rojo.

Cualquier tipo de historia de usuario lo podemos convertir a cualquier otro tipo. Esto lo hacemos desde el detalle de la historia de usuario, que podemos ver si hacemos doble click sobre la historia, o un solo click sobre el triángulo que tenemos a la izquierda.

En general vemos como en el detalle de la historia de usuario podemos cambiar cualquier propiedad, meter una descripción, comentarios, adjuntar fichero... Y también podemos ver como abajo del todo tenemos un enlace que nos lleva directamente a esta historia. Esto es especialmente útil para integrar con otras herramientas.

Además las historias de usuario tienen un pequeño workflow. Por ejemplo, los estados para una historia de usuario de tipo Feature (las representadas por la estrella) serían:

  • Not Yet Started: Cundo todavía no se ha empezado a trabajar sobre esta hitoria. Puede estár en cualquier pila menos en la de “Done” que es la de cosas terminadas. La historia de usuario mostrará un botón “Start” que pasa la historia la estado siguiente.

  • Started: Sólo puede haber histotias en este estado en la pila “Current” ya que es en lo que actualmenten estamos trabajando. Si desde la pila Backlog o Icebox se da al botón “Start” de una historia, esta pasará automáticamente a la pila de “Current”.

  • Finished: Es cuando hemos terminado de resolver la historia. Podríamos decir que corresponde con el estado FIXED del Bugzilla. Es decir, ya hemos hecho commit en el repositorio, pero todavía no está en ninguna release que se pueda entregar.

  • Delivered: Es cuando ya está entregada, es decir cuando está en una release que se puede entregar al cliente. Podría compararse con el VERIFIED de Bugzilla.

  • Accepted: Es cuando el cliente acepta la historia como buena (por ejemplo en la demo al final del sprint). En este caso la historia acabará yéndose a la pila de “Done” cuando termine este sprint. Podría compararse con el CLOSED de Bugzilla.

  • Rejected: Es cuando el cliente no acepta la historia como terminada. En este caso nos aparecerá un botón de “Restart” que si lo pulsamos es como si volviéramos al estado “Started” indicado más arriba. Podría compararse con el REOPEN de Bugzilla.

Nota: Esta es la interpretación que hacemos nosotros de los estados, pero es abierto, por lo que cada uno podría entender los estados de forma diferente.

Aquí vemos un diagrama que representaría el camino natural (recordar que, como ya dijimos antes, manualmente podemos poner cualquier historia en cualquier estado, esto lo haríamos desde dentro del detalle de la historia).



5.3. Planificación y calculo de velocidad

En principio la longitud de los sprints es de 1 semana, pero esto lo podemos cambiar en las configuraciones del proyecto, desde 1 semana hasta un máximo de 4.

La estimación de las historias de usuario se hace en puntos de historia (cómo es recomendable), por defecto tenemos los valores 0, 1, 2, 3, y son los cuadraditos azules que vemos a la derecha de la historia de usuario.

Si estos valores nos parecen insuficientes, los podemos cambiar en la configuración del proyecto y podemos optar por potencias de 2 (0, 1, 2, 4, 8), o por Fibonacci (0, 1, 2, 3, 5, 8).

En función de la longitud del sprint y de la velocidad media (cuantos puntos de historia hacemos en un sprint), Pivotal Tracker planificará las historias que somos capaces de hacer en los siguientes sprints. La velocidad se calcula, por defecto, como la media de las 3 últimas iteraciones; pero lo podemos configurar para que sea le media 1, 2, 3, o 4 iteraciones.

Además hay otra cosa bastante interesante y es que podemos hacer un simulacro de cmabio de velocidad: arriba a la derecha tenemos la etiqueta "Velocity: x" y justo debajo un enlace "project default", si pinchamos este enlace podremos cambiar la velocidad y ver como se ajustan las historias de usuario. Ojo, porque esto sólo es un cambio local y temporal, es decir, tan sólo es una simulación.



6. Perfiles de usuarios

Por último comentar un poco que podemos añadir al proyecto todos los miembros que queramos, esto lo haremos desde el apartado “Members”. Y tenemos a nuestra disposición los siguientes perfiles:

  • Owner: Sólo estos pueden añadir o quietar miembros o cambiar la configuración del proyecto.

  • Member: Estos y los anterioreso pueden crear, editar mover, y borrar historias, y pueden añadir comentarios.

  • Viewer: Estos no pueden hacer ningún cambio y sólo pueden ver las historias.

Puede que no sea todo lo flexible que nos gustaría y se hecha de menos un perfil tipo “Product Owner”, que sólo pueda cambiar cosas en la pila de “Backlog” y de “Icebox”, y aceptar o rechazar historias. Pero desde luego es más que suficiente para cubrir la mayoría de los casos; y que más se puede pedir por este precio ;)



7. Conclusiones

Todavía quedan muchas más cosas por ver, como gráficas de avance, dividir una historia en tareas, exportar la información, búsquedas, etiquetas para las historias, histórico de acciones tomadas en una historia, api de desarrollo, integración con otras herramientas (por ejemplo Subversion), ...; pero sin duda creo que se puede apreciar la potencia de la herramienta. Sobre todo por su facilidad de uso y la gran cantidad de funcionalidades que nos ofrece.

Ya no es excusa no usar una herramienta para la gestión de nuestros proyectos ágiles. Antes podíamos alegar el coste, o que nos daba pereza instalarla o que era muy complicada o ... pero los chicos de Pivotal Traker consiguen tirarnos por tierra todas estas excusas; ole por ellos!!!



8. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. - "Soporte a Desarrollo"

http://www.autentia.com



A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL:

Fecha publicación: 2011-01-31-11:06:52

Autor: Rafa

Ya se puede dividir una historia en tareas. Lo tienes al mirar el detalle de una historia. También tiene API externa en : https://www.pivotaltracker.com/help/api

También se puede integrar con bastantes herramientas. https://www.pivotaltracker.com/help/integrations

Por último decir que en breve será una herramienta de pago. En el momento de escribir este artículo era totalmente gratuito ;) Solo para que conste a la gente que busque por aquí.