Gestión de proyectos ágil con herramientas open source

Gestión de proyectos ágil con

herramientas open source

Raúl Sanz de Acedo Blanca Esther Cubas Cruz Centro de Excelencia Software Java y Open Source CEIN, S.A. 2010

2 | P á g i n a

Índice

30/09/2010

–

A

GILO

(1/7)

4

V

ERSIONES

/

LICENCIAS

4

E

NTORNO

4

I

DIOMA

5

V

IDA

5

D

OCUMENTACIÓN

5

C

OMUNIDAD

5

S

OPORTE COMERCIAL

5

F

UNCIONALIDADES GESTOR DE PROYECTOS

5

F

UNCIONALIDADES PROPIAS DE

S

CRUM

6

21/10/2010

–

I

CE

S

CRUM

(2/7)

7

V

ERSIONES

/

LICENCIAS

7

E

NTORNO

7

I

DIOMA

7

V

IDA

7

D

OCUMENTACIÓN

7

C

OMUNIDAD

8

S

OPORTE COMERCIAL

8

F

UNCIONALIDADES GESTOR DE PROYECTOS

8

F

UNCIONALIDADES PROPIAS DE

S

CRUM

8

22/10/2010

–

A

GILE

F

ANT

(3/7)

10

L

ICENCIA

/

VERSIONES

10

E

NTORNO

10

I

DIOMA

10

V

IDA

10

D

OCUMENTACIÓN

11

C

OMUNIDAD

11

S

OPORTE COMERCIAL

11

F

UNCIONALIDADES DE GESTOR DE PROYECTOS

11

F

UNCIONALIDADES PROPIAS DE

S

CRUM

11

08/11/2010

–

R

EDMINE

(4/7)

13

L

ICENCIA

/

VERSIONES

13

E

NTORNO

13

V

IDA

14

D

OCUMENTACIÓN

14

C

OMUNIDAD

14

S

OPORTE COMERCIAL

14

F

UNCIONALIDADES DE GESTOR DE PROYECTOS

15

F

UNCIONALIDADES PROPIAS DE

S

CRUM

15

24/11/2010

–

R

ETROSPECTIVA

(5/7)

19

V

ERSIONES

/

LICENCIAS

19

E

NTORNO

19

3 | P á g i n a

V

IDA

19

D

OCUMENTACIÓN

19

C

OMUNIDAD

20

S

OPORTE COMERCIAL

20

F

UNCIONALIDADES GESTOR DE PROYECTOS

20

F

UNCIONALIDADES PROPIAS DE

S

CRUM

21

16/12/2010

–

S

CRUM

F

ACTORY

(6/7)

22

L

ICENCIA

/

VERSIONES

22

E

NTORNO

22

I

DIOMA

22

V

IDA

22

D

OCUMENTACIÓN

22

C

OMUNIDAD

23

S

OPORTE COMERCIAL

23

F

UNCIONALIDADES DE GESTOR DE PROYECTOS

23

F

UNCIONALIDADES PROPIAS DE

S

CRUM

23

20/12/2010

–

E

XPRESS

(7/7)

25

V

ERSIONES

/

LICENCIAS

25

E

NTORNO

25

I

DIOMA

25

V

IDA

25

D

OCUMENTACIÓN

25

C

OMUNIDAD

25

S

OPORTE COMERCIAL

26

F

UNCIONALIDADES GESTOR DE PROYECTOS

26

F

UNCIONALIDADES PROPIAS DE

S

CRUM

26

Gestión de proyectos ágil con herramientas open source por Raúl Sanz de Acedo y Blanca Esther Cubas Cruz se encuentra bajo una Licencia Creative Commons Reconocimiento 3.0 Unported.

This work is licensed under the Creative Commons Attribution 3.0 Unported License.

To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

4 | P á g i n a

30/09/2010 – Agilo (1/7)

Hace unos meses nos toco analizar una serie de aplicaciones orientadas a la gestión de proyectos desde la perspectiva SCRUM.

En este estudio abarcamos 7 aplicaciones open source. A través de los artículos del boletín iremos viéndolas de una en una.

Empezamos con Agilo: http://www.agile42.com/cms/pages/agilo/.

Es una aplicación basada en el gestor de incidencias Trac, http://trac.edgewall.org/, se trata de un plugin en Python, muy bien integrado y que oculta de forma magnífica la existencia de Trac.

Como heredero de Trac, tiene una serie de características de las que destacaría:

 Mono-proyecto,

 Trata todo como “tickets”, que son muy configurables, lo cual da mucha flexibilidad.

Los “artefactos” de la aplicación se organizar y estructuran de la siguiente manera:

 Proyecto

o Milestone(s)  Sprint(s)

 Ticket(s)

o Requerimiento(s): estimado en valor de negocio y asociado a un Milestone

o Historia(s): estimado en puntos y asociado a un Sprint o Task(s): estimado en horas y asociado a un Sprint o Bug(s): no se estima, asociado a un Sprint

 Relaciones entre Tickets

o Los Requerimientos tienen Historias

o Las Historias tienen Tasks y se pueden asociar a Bugs o Los Bugs tienen Tasks y se pueden asociar a Historias

 Backlog(s)

o De Proyecto o De Milestone o De Sprint

Se puede observar que contienen todos los artefactos usados en Scrum aunque en algunos casos la implementación sea un poco particular.

Versiones / licencias

 Agilotm _{Open: versión open source, Apache 2.0 Licence. (hay que registrarse}

para descargase una copia)

 Agilotm _{Pro: versión profesional, Agilo for Scrum End User License}

Agreement. Se puede probar la versión Pro durante 30 días activándola desde la propia instalación de Open.

Entorno

Basado en Trac, por lo tanto, tiene los mismos requerimientos:

 Servidor web (opcional):

o Apache (CGI, FastCGI, mod_wsgi and mod_python) o ISS (con AJP)

 Lenguaje: Python

5 | P á g i n a

Idioma

Parece que tan solo está en inglés, aunque hay iniciativas para traducir Trac al Español: http://trac.edgewall.org/wiki/TracTermsEs

Vida

En el caso de Trac, la base, es un proyecto bastante activo. Cada 3 o 4 meses hay una versión nueva, la última, en el momento de redactar este documento, es del 1 de mayo del 2010. En el caso de Agilo, no están muy claras las versiones y actualizaciones. Quizás se trate de un proyecto reciente.

Documentación

Trac tiene bastante documentación (wiki del proyecto) y mucha gente lo emplea con lo que es fácil encontrar información al respecto. No obstante, el propio proyecto de Agilo parece más oscuro, hay menos documentación, por no decir nada, aunque quizás tenga poca importancia al tratarse de un plugin de Trac.

Comunidad

En Trac hay un canal de comunicación a través del IRC y de listas de correos. De entre estas la de usuarios (http://groups.google.com/group/trac-users/topics) tiene actualizaciones diarias y la de desarrolladores (http://groups.google.com/group/trac-dev/topics) una frecuencia de mensajes cada 2-3 días. Las respuestas en ambos casos son muy rápidas. No hay información al respecto para Agilo.

Soporte comercial

Existe soporte comercial para Agilo pero en la versión Pro:

http://www.agile42.com/cms/pages/support/

Hay servicios preferentes para los clientes, además de ofrecer alojamiento de la aplicación, adaptación de la aplicación (plugins) y ayuda en la instalación y configuración:

Adicionalmente, tiene un servicio de formación en la aplicación, en Scrum y en principios ágiles, así como servicios de coaching y consultoría.

Funcionalidades gestor de proyectos

Proyectos

Como se ha adelantado, al estar basado en Trac, es mono-proyecto pero si que cabe la posibilidad de tener varios proyectos independientes en lo que vendría a ser una especie de nueva instalación de Trac (realizada mediante una serie de órdenes por consola).

Existe un fichero global de configuración del cual pueden heredar los ficheros de configuración proyectos individuales. La gestión de usuarios puede ser común a todos los proyectos (basada en Apache). Esto unido a la posibilidad de tener plantillas de ficheros de configuración para los proyectos permite la posibilidad de automatizar el proceso volviéndolo menos engorroso.

No obstante, esto no permite agrupar, ligar o asociar proyectos para compartir recursos u organizarlos en base a temáticas, productos, áreas, etc.

6 | P á g i n a

Gestión de incidencias

Aunque no suele ser el objetivo de un gestor de proyectos, en este caso, se contempla la gestión de incidencias como si fuera un tipo de ticket con lo que queda integrado todo en el mismo sistema.

Ampliación y adaptación

Es una aplicación muy adaptable al igual que Trac puesto que puedes crear tantos tipos de tickets como desees, crear los campos asociados que se deseen así como sus valores (prioridades, puntos...), milestones, versiones, grupos de equipos, etc. Trac se puede ampliar mediante plugins escritos en Python. Agilo parece poder extenderse de la misma manera. Lo que no queda claro es si lo que realmente estás extendiendo es Agilo o Trac.

Funcionalidades propias de Scrum

Como se ha adelantado, posee un Backlog por Proyecto, Milestone y Sprint, siendo además configurable que tickets se ven en cada uno. Así pues, también cuenta con el concepto de Sprints.

Cuenta con Historias y Tareas pudiendo estimarse en puntos y horas. Además añade la posibilidad de introducir requerimientos, entendidos como Historias más globales e Incidencias (Bugs).

Posee los 3 tipos de roles típicos: Scrum master, Team y Product Owner, aunque deja abierta la posibilidad de introducir todos los tipos de perfiles que se deseen. El punto negativo quizás sea la Pizarra Visual (Dashboard). Solamente está disponible en la versión Pro y parece que tan solo se muestra por Sprint, no existe una Pizarra Visual general del Proyecto. Tampoco pueden modificarse los estados dentro de esta Pizarra Visual, son fijos.

A pesar de esto, si que cuenta con un BurnDownChart en la versión Open, tanto para los Sprints Backlog como para el Product Backlog.

Aunque esto no tiene relación con Scrum, más bien con Kanban, se vio interesante la posibilidad de ver si permitía limitar el número máximo de historias o tareas por Sprint, que en este caso no era posible.

7 | P á g i n a

21/10/2010 – IceScrum (2/7)

Seguimos nuestro periplo con el proyecto francés IceScrum: http://www.icescrum.org/ yhttp://www.icescrum.com/

El uso, en general, se hace un poco confuso en el sentido de saber en donde te encuentras en cada momento, aunque es muy cómodo de utilizar y muy visual. Puede que tan solo sea acostumbrarse a él.

Es una aplicación orientada única y exclusivamente a la gestión de proyectos con Scrum.

Cuenta con algunas curiosidades interesantes como chat, conector de Mylin (http://www.eclipse.org/mylyn) para gestionar las tareas desde el IDE Eclipse, informes en PDF, etc.

Además, cuenta con sponsors, lo cual es bueno para la continuidad del proyecto.

Versiones / licencias

GNU General Public License (GPL)

Entorno

Servidor de aplicaciones J2EE (estándar Servlet 2.4). Además se necesita instalar una JRE 1.5. o posterior.

La base de datos por defecto es HSQLDB (que está incluida en la distribución IceScrum2), pero se puede emplear otra RDBMS (MySQL, Postgres, ...). No es compatible con Oracle DBMS.

A parte de todo esto, los usuarios para poder acceder a la aplicación, necesitarán un navegador web compatible:Internet Explorer 7+, Firefox 3+, Safari 3+.

Idioma

Inglés y Español entre otros.

Vida

En el momento de analizar esta aplicación, la última versión del producto (15.1) fue publicada el 7 de mayo de 2010. Hacen al menos una major release al año. Llevan desde antes de diciembre de 2008, fecha en la que publicaron la versión 9, pero no hay información de fechas en versiones anteriores.

Documentación

La documentación es más bien escasa y en algunos casos poco exhaustiva. Al ser un proyecto Francés, mucha documentación está en ese idioma aunque también puedes encontrar cosas en inglés. Esta documentación está disponible dentro del menú F.A.Q.: hay información sobre la instalación, configuración, uso y conexión con Mylyn. Se puede encontrar en forma de página web, documentos pdf, o vídeos.

8 | P á g i n a

Comunidad

Cuenta con cuenta de twitter (http://twitter.com/icescrum) y foros (http://forum.icescrum.org/) con respuestas más o menos rápidas (1-3 días) aunque parece haber poco movimiento, al menos, en el foro inglés.

Soporte comercial

Hay un correo de soporte pero además hay una serie de opciones con servicios profesionales de pago: http://www.icescrum.com/support-icescrum-en y de alojamiento: http://www.icescrum.com/hosting

Funcionalidades gestor de proyectos

Permite crear todos los proyectos que se quieran, pero tan solo se trabaja con un proyecto cada vez. Ademas, tiene la posibilidad de guardar externamente el proyecto y cargarlo, asi como exportarlo, que ofrece mas opciones de guardado. Nos e ha podido comprobar si permite modificar y eliminar proyectos.

En el detalle de los proyectos no permite introducir mas que un nombre y una descripcion, por tanto, parece no existir una forma de distinguirlos, por areas por ejemplo, u organizarlos si crecen de forma indiscriminada.

No obstante, parece que si estan estudiando la posibilidad de manejar un portfolio de proyectos. http://www.icescrum.org/index.php/2009/11/comparing-open-source-agile-project-management-tools-comments/

Gestion de incidencias

Se puede realizar una gestion de incidencias usando el tipo ¡§defecto¡¨ que categoriza una historia de usuario. Por tanto se pueden integrar y usar como historias de usuario.

Ampliacion y adaptación

Puede extenderse la aplicacion modificando el codigo dado que es Open Source mediante el empleo de Maven. Existe un documento (en frances) sobre la arquitectura del mismo que ayudaria a su adaptacion y otro (en ingles) que indica como contribuir al proyecto. No existe sistema de plugins.

Funcionalidades propias de Scrum

Cada proyecto cuenta con un Backlog global. El Backlog por Sprint viene a ser una vista de las historias de usuario asignadas a ese Sprint.

Por tanto, cuenta con una pizarra visual (vista por defecto del proyecto) por Sprint. Se puedeponer en modo de pantalla completa. Desde aqui se puede ver el Burn Down Chart y el Sprint BurnUp aunque no estan visibles por defecto. El Burn Down Chart solamente muestra desde el comienzo del Sprint hasta el dia actual (aunque queden dias para terminar) y se va refrescando. Funciona el Drag and Drop para pasar las tareas de un estado a otro. Parece que los estados no son modificables, siendo: Story, waiting, locked y done.

Tambien Cuenta con un ¡§roadmap¡¨ del producto que subdivide el proyecto en:  Release (s): version de producto creado desde el roadmap. Se trata de un

marco temporal (fechas) y en el se establece el numero de dias que tienen cada Sprint. Tiene un campo llamado Velocidad, que parece ser la capacidad

9 | P á g i n a

en puntos de cada Sprint. No sabemos si posiblemente limita el número de puntos por Sprint en base a esto o simplemente es un indicativo

o Sprint (s): se crean desde la release. Asigna las fechas de manera automática y consecutiva en función de la configuración marcada en el release. Tiene la opción también de generar todos los Sprints de forma automática.

La unidad básica son las historias de usuario, creadas desde el Backlog global de proyecto. No parecen tener asignación de prioridad. estas historias de usuario tienen la siguiente tipología:

 Historias de usuario propiamente dichas  Requerimiento técnico

 Funcionalidad  Defecto (bug)

Se estiman en puntos aunque desde proyecto se puede establecer la política de los mismos, pudiendo elegir entre:

 Número de fibonacci  Números naturales

Estas historias de usuario se asocian al Sprint desde una release. También permite una auto-planificación: autoasignar historias a los sprints. No sabemos la manera en que lo hace, pero posiblemente sea en función de los puntos de cada historia y de la capacidad de cada Sprint.

Por otro lado, también emplea “features”. Estas vienen a ser requerimientos a los que se les asigna diferentes colores para su identificación visual. Se les puede asignar un valor que no está claro si es valor de negocio, puntos o prioridad (los valores son los mismos que los puntos de una historia de usuario). Estas “features” se pueden asociar a las historias de usuario existentes, de modo que estás historias de usuario adquieren su color.

Posee los 3 tipos de roles típicos en Scrum y uno más: Product Owner, Scrum Master, Team Member and Stakeholder. Todos los roles se pueden intercambiar entre si, es decir, un usuario puede “ser” perfil Team Member, cambiarse a “Product Owner”, etc, según placer. Esto puede ser evitado por el Scrum Master. Además, se pueden añadir roles personalizados.

Además de todo esto cuenta con una serie de curiosidades interesantes añadidas como:

 Lista de impedimentos.

 Definición de hecho por Sprint.  Retrospectiva por Sprint.

 Sección específica para la gestión de tests de aceptación de las historias de usuario. Una vez todas las tareas del sprint están finalizadas se puede crear tests para las historias de usuario, que son nuevas tareas. Tiene 2 estados modificables en principio por el Product Owner (aunque con el sistema intercambiable de perfiles, teóricamente cualquier podría “usurparle”): aceptado o fallido. Si se pasan todos los tests, la historia se marca como realizada.

10 | P á g i n a

22/10/2010 – AgileFant (3/7)

Este mes yo también me uno a la moda de la gestión de proyectos ágiles con herramientas Open Source. Yo os voy a hablar de un proyecto finlandés. AgileFant:

http://www.agilefant.org/

Este proyecto, está respaldado por la Helsinki University of Technology y SoberIT (Laboratorio de Software de Negocio asociado a la universidad). Su página web ha cambiado recientemente y ahora la información que se muestra es más reducida que la que se podía encontrar antes. Posiblemente haya que registrarse para poder acceder a más información.

Tiene una demo online.

Licencia / versiones

Licencia de Agilefant (se basa en la licencia del MIT).

Entorno

 Mozilla Firefox 3 y 3.5, Google Chrome y Safari de Apple  JRE 1.5 o JRE 1.6 (preferiblemente de Sun),

 JDK 1.5 o JDK 1.6 (preferiblemente de Sun para desarrollo de la herramienta)

 Tomcat 5.5 o 6

 MySQL 5 (con InnoDB activado)

Parece ser que ya no sólo Mozilla Firefox 3 va a ser el único navegador soportado activamente en el futuro, ahora también lo prueban sobre Google Chrome y Safari. Intentan también que sea compatible con Internet Explorer 7 y 8, aunque esto no lo aseguran. La nueva interfaz de usuario (desde Agilefant 1.4.7) funciona más rápido con Firefox 3 que con versiones anteriores

Es necesaria la JRE versión 5 o 6 para hacer funcionar el servidor. Para desarrollo es necesaria la JDK versión 5 (1.5) o 6 (1.6). Además se recomienda que sean las de Sun.

Se recomienda utilizar Apache Tomcat 5.5 o 6. Agilefant puede trabajar con otros servidores J2EE y versiones de Tomcat, pero han sido informados de errores con Glassfish.

Se requiere MySQL 5 (con el motor InnoDB). Agilefant puede personalizarse para funcionar con otros servidores-SQL, sin embargo no existe ni documentación ni soporte.

Idioma

Inglés

Vida

Al menos desde 2007 (última fecha que aparece en página de descargas) Versión 1.2.0. Desde entonces => En 2009 la versión 1.6.2 y a día de hoy (Octubre de 2010) están por la versión 2.0.4. Las versiones 2.0.x se empezaron a publicar en junio de 2010 y desde entonces a septiembre de 2010 que fue cuando se liberó la versión 2.0.4 ha habido 5 versiones (2.0.0 a 2.0.4).

11 | P á g i n a

Documentación

Sólo existe una guía de instalación en inglés. Las preguntas frecuentes se limitan a una serie de diapositivas haciendo un quick tour y las que puedas encontrar o preguntar en los foros.

Comunidad

Foros activos, los desarrolladores suelen contestar en el día o a lo sumo al día siguiente, canal IRC. Además de esto tienen unos cuantos contribuidores.

Soporte comercial

De momento no hay. Es posible que a futuro lo pongan. De momento el único soporte que se da es en el foro (los desarrolladores suelen responder en el día).

Funcionalidades de gestor de proyectos

El gestor de proyectos es multi-proyecto, permite crear varios proyectos y se puede ver la lista de todos y cambiar de uno a otro. Los proyectos se pueden priorizar y formar parte de un producto mayor mediante el concepto de proyecto - producto. Un producto puede tener uno o varios proyectos asociados. Por otra parte, no existe forma de diferenciar proyectos por áreas, aunque a las historias de usuario sí que se le pueden asignar distintas temáticas.

Gestión de incidencias

No tiene. Se debe usar otro sistema.

Ampliación e integración con otros sistemas

No tiene. Se pueden solicitar nuevas funcionalidades o desarrollarlas directamente.

Funcionalidades propias de Scrum

Las tareas se planifican en horas, las historias de usuario permite planificarlas introduciendo manualmente los puntos. Sólo existe el rol de usuario. Tiene diagrama de burndown por iteración y de burnup por proyecto. Tiene un informe sobre horas dedicadas a distintas tareas por distintos desarrolladores que se puede exportar a excel (es el único informe que ofrece). Permite obtener el informe por proyecto, elegir un intervalo de tiempo y los desarrolladores.

Se pueden crear equipos de personas. Pueden estar en varios proyectos.

Todo el mundo puede tocar todas las opciones administrativas, puesto que no hay permisos por usuario.

12 | P á g i n a

En el backlog se muestran las historias de usuario. Estas historias de usuario pueden depender de otras. También tienen tareas asociadas. Se puede ver por proyecto y por sprint. También se puede ver la lista de proyectos que forman parte de un producto. Se puede priorizar mediante el posicionamiento de los objetivos de la iteración.

No tiene pizarra visual. Tiene 6 estados (no modificables) por ítem.

Estado Color Significado

Sin empezar gris El trabajo en este item no ha comenzado todavía Empezado naranja El trabajo en este item ha

empezado

Pendiente azul No se puede proceder,

pero se sabe que esperando el obstáculo desparecerá

Bloqueado rojo No se puede proceder, y se sospecha que hay que hacer algo para quitar el obstáculo

Implementado verde claro Alcanzará la definición de hecho tras ser revisado en la próxima reunión. Hecho verde oscuro Ha alcanzado la definición

de hecho

Existe una medida de carga por persona (Load), depende de las horas semanales de trabajo y de las horas estimadas en las tareas.

13 | P á g i n a

08/11/2010 – Redmine (4/7)

Siguiendo la estela del mes pasado, vuelvo a comentar un gestor de proyectos, en este caso el francés Redmine: http://www.redmine.org/

Este proyecto empezó como una aplicación sencilla sobre ruby on rails y ha tenido una gran aceptación y apoyo. En sí, es un gestor de proyectos normal, pero ha habido una serie de colaboradores que han desarrollado varios plugins que permiten adaptarlo a la gestión de proyectos ágiles. Las características más destacables del mismo son:

 Soporte multi-proyecto

 Control de acceso flexible basado en roles  Sistema flexible de seguimiento de peticiones  Gráficas de Gantt y calendario

 Gestión de noticias, documentos y archivos  Feeds & notificaciones de email

 Wiki por proyecto  Foros por proyecto  Time tracking

 Campos personalizados para peticiones, entradas temporales, proyectos y usuarios

 Integración con sistemas de versiones (SVN, CVS, Git, Mercurial, Bazaar and Darcs)

 Creación de peticiones por email

 Soporte de autenticación LDAP múltiple  Soporte de auto-registro de usuarios  Soporte multilenguaje

 Soporte de múltiples bases de datos

Una petición está asociada a una persona, sin embargo, puede tener varios seguidores. Estos seguidores pueden actualizarla. Por otra parte, varias peticiones pueden estar relacionadas entre sí. Se pueden definir flujos de trabajo para los distintos roles de usuarios y peticiones.

Licencia / versiones

GNU General Public License v2 (GPL)

Entorno

Sistema operativo: Unix, Linux, Mac y Windows. Ruby & Ruby on Rails:

Versión de

Redmine Versiones Ruby soportadas de Versión requerida de Rails Versión requerida de Rack

current trunk ruby 1.8.6, 1.8.7 Rails 2.3.5 Rack 1.0.1 trunk from r2493

tor2886 ruby 1.8.6, 1.8.7 Rails 2.2.2 trunk before r2493 ruby 1.8.6, 1.8.7 Rails 2.1.2 0.9.x ruby 1.8.6, 1.8.7 Rails 2.3.5 Rack 1.0.1 0.8.x ruby 1.8.6, 1.8.7 Rails 2.1.2

14 | P á g i n a

0.7.x ruby 1.8.6 Rails 2.0.2

Notas:

 Ruby 1.9 no está soportado. Hay que usar Ruby 1.8.x.  Se require RubyGems 1.3.1 o superior

 Se require Rake 0.8.3 o superior Base de datos:

 MySQL 5.0 o superior (es la base de datos recomendada) con C bindings para Ruby

 PostgreSQL (se recomienda usar la versión 8.4.2)  SQLite 3

Opcional:

 Binarios SCM (eg. svn) para la integración con sistemas de control de versiones

 RMagick (para la exportación de Gantt a imagen png)  Ruby OpenID Library (para soporte OpenID)

Idioma

Inglés, Español (tiene traducciones a bastantes idiomas, en el caso de que no esté soportado el que se busca, se puede hacer la traducción de manera sencilla, pues la configuración de idiomas va por ficheros).

Vida

Empezaron con la versión 0.7 en el 2008 y desde entonces han sacado 3 versiones menores y una mayor. Dentro de la 1.0.x, ya van por la 1.0.3 que fue liberada el 31 de octubre, más o menos sacan una versión por año. Dentro de cada versión existen diversas actualizaciones de corrección de errores habitualmente. Por tanto, es un proyecto con bastante vida y que ha madurado mucho desde sus comienzos.

Documentación

Existe mucha documentación en formato wiki dentro de la página web del proyecto y es documentación de bastante calidad. Existe una traducción a español de parte de la documentación. Por otra parte, existe una página de preguntas frecuentes (http://www.redmine.org/wiki/redmine/FAQ).

Comunidad

Cuenta con un apartado (http://www.redmine.org/projects/redmine/boards) donde existen 4 foros, uno no muy utilizado para los desarrolladores, otro dedicado a los plugins con mayor movimiento y 2 más dirigidos a usuarios de la herramienta donde se concentra casi toda la actividad. En general, las respuestas son bastante rápidas. Además, cuentan con un chat IRC (irc://[email protected]). En todo este tiempo muchos proyectos están haciendo uso de redmine (http://www.redmine.org/wiki/redmine/WeAreUsingRedmine) como por ejemplo, Lighttpd (http://redmine.lighttpd.net/) y el sistema de incidencias de Ruby (http://redmine.ruby-lang.org/).

Soporte comercial

No existe soporte comercial. Es posible que empresas externas se dediquen a temas de soporte y consultoría sobre redmine.

15 | P á g i n a

Funcionalidades de gestor de proyectos

El gestor de proyectos es multi-proyecto, permite crear varios proyectos y se puede ver la lista de todos y cambiar de uno a otro. Un proyecto puede depender de otro. Por otra parte se pueden crear varias versiones del mismo proyecto (Roadmap). Así mismo, se puede crear un campo para decir que ciertos proyectos pertenecen a un grupo de proyectos o a un área determinada. Estas dos últimas posibilidades son debidas a que existe la posibilidad de crear campos personalizados que se apliquen a distintos niveles (proyecto, versión…).

Gestión de incidencias

Sí, está integrada dentro de la aplicación. Cuando se crea una petición se puede decir que sea de tipo bug.

Ampliación e integración con otros sistemas

Existe disponibilidad del código y, por tanto, de su posible adaptación. Por otro lado, existen múltiples plugins que añaden funcionalidades y también una guía que da información sobre cómo desarrollarlos. En esta página http://www.redmine.org/wiki/redmine/Plugins se puede encontrar toda la información relacionada con ellos, desde la lista de los mismos con sus funcionalidades hasta tutoriales de cómo realizarla.

Funcionalidades propias de Scrum

La estructura de la información es básicamente la siguiente:

 Proyecto(s) = es multiproyecto y un proyecto puede ser padre de otros. o Milestone(s) = versiones con un marco temporal. Se corresponderían

con los Sprints.

 Peticiones / Issues = engloba cualquier tipo de petición: tarea, bug, funcionalidad, etc, que son configurables. Podría haber un tipo de petición que fuesen las historias de usuario.

 Categorías: se puede asignar una categoría a cada petición configurable por proyecto. Podrían ser los temas de las historias de usuario.

Estas funcionalidades ágiles, ya sean de scrum o de kanban se pueden adquirir mediante el uso de plugins. A continuación, se analizan una serie de plugins que las aportan. Además de estos existen otras posibilidades, el listado completo de plugins se puede ver aquí.

Nota: Los plugins solo están, por defecto, visibles para el administrador. Posteriormente, hay que dar permisos al resto de usuarios para que puedan acceder y trabajar con estos plugins desde la opción de Roles dentro del menú de Administración general. Así mismo, también los usuarios administradores deberán darse permisos para usarlos, aunque puedan verlos.

Nota 2: Estos plugins sólo están disponibles a día 8 de octubre de 2010 para la versión 0.9.x de Redmine dentro de repositorios git. Necesitan ser retocados para ser compatibles con la versión 1.0.x

Kanban

http://www.redmine.org/wiki/redmine/PluginKanban

16 | P á g i n a

Idioma: Inglés, francés y alemán

Añade una entrada nueva en el menú global con lo que engloba a todos los proyectos.

Se trata de un panel kanban donde se muestran las peticiones de cada proyecto en los siguientes grupos de paneles:

 Incoming: aquellas peticiones que están a la espera de ser introducidas en el “Backlog”, generalmente peticiones con estado nuevo, aunque es configurable.

 Backlog: peticiones que van al backlog. Se organizan por prioridad.

 Quick Tasks: peticiones del “Backlog” que no tienen una estimación de tiempo, parecen ser peticiones que no tienen horas asignadas.

 Selected requests: peticiones del “Backlog” seleccionadas para trabajar. Parece redundante porque replica las que aparecen en el “Backlog” aunque puedes coger una de la lista “Incoming” y pasarla a “Selected requests” y está no aparece en el “Backlog”.

 Panel kanban propiamente dicho donde se visualizan las peticiones por cada usuario (asignadas a él) con los siguientes estados:

o Active o Testing

o Finished Requests o Cancel Requests

Tiene un apartado de configuración propio donde se indica que estado de petición es visible en cada panel. Puesto que los estados de las peticiones de Redmine son configurables, permite una gran adaptabilidad. Además permite configurar el número máximo de ítems por estado.

Las peticiones se muestran en diferentes colores según la información introducida en el detalle de la petición pero cuesta entender la lógica:

 Amarillo cuando la petición no tiene el mínimo de la información introducida.  Naranja cuando la petición tiene un mínimo de información introducida.  Verde cuando la petición tiene toda la información introducida.

El panel kanban permite drag and drop que actualiza:  El estado de la petición.

 La persona a la cual es asignada la petición.

Interesante la opción de tener una visualización conjunta de todos los proyectos pero cuesta entender la lógica.

ScrumDashboard

http://www.redmine.org/boards/3/topics/5808

Licencia: GNU General Public License v2 (GPL)

Idioma: Inglés, portugués/brasileño, coreano y noruego

Añade un nuevo módulo dentro del menú propio del proyecto, es decir, es una pizarra visual por proyecto.

Muestra por milestone, todas las peticiones o solamente las asignadas al usuario. La pizarra muestra tantas columnas como estados permitiendo el drag and drop entre ellas que actualiza los estados de cada petición.

17 | P á g i n a

La visualización es, quizás, demasiado sencilla aunque el tooltip muestra información más detallada.

Tanto los tipos de petición (tracker) como estos estados son configurables por Redmine y en este plugin se indica cuales de estos se van a emplear. Además se puede asignar un color según el tipo de petición (tracker).

Plugin limitado por tratarse de una pizarra visual solamente por milestone pero sencillo y configurable.

Charts plugin

http://www.redmine.org/wiki/redmine/PluginCharts

Licencia: GNU General Public License v2 (GPL) Idioma: Español, inglés, polaco y otros

Es un módulo que se añade a cada proyecto. En cada uno de ellos hay distintas opciones de gráficos a mostrar, en total 6 distintas

 Burndown

o Línea temporal con horas estimadas, imputadas y las que faltan. Se puede filtrar por grupos y condiciones y desplazarte temporalmente aunque esto no funciona muy bien.

 Burndown with velocity

o Burndown (horas que faltan) con velocidad. El gráfico muestra los datos para versiones dadas desde la fecha de creación de la versión hasta la fecha actual de la versión.

 Logged hours ratio

o Número de horas imputadas proporcionales a un total, agrupadas y filtradas por usuarios, peticiones, actividades, categorías, versión, prioridades o trackers.

 Logged hours timeline

o Línea temporal con horas imputadas, agrupadas y filtradas por usuarios, peticiones, actividades, categorías, versión, prioridades y trackers.

 Logged hours deviations

o Ratio de horas imputadas y restantes a horas estimadas por cada petición estimada.

 Issues ratio

o Ratio de peticiones según estado. No acabamos de entender su funcionamiento.

Stuff To Do

http://www.redmine.org/wiki/redmine/PluginStuffToDo

Licencia: GNU General Public License v2 (GPL) o siguientes versiones. Idioma: Español, inglés, italiano, francés, japonés y otros.

Da conflictos con ScrumDashBoard.

Añade 1 entrada de menú en el menú global con lo que engloba a todos los proyectos.

18 | P á g i n a

Esta muestra 3 listas que se pueden actualizar mediante drag and drop con las tareas asignadas al usuario logeado.

Las listas son:

o Qué estoy haciendo ahora: aparecen las 5 como máximo que has elegido para hacer ahora,

o Qué voy a hacer después: aparecen las que has elegido para hacer una vez has terminado con las que estás haciendo ahora según el orden de prioridad que has elegido o que el manager ha elegido para ti,

o Qué está disponible: aparecen todas las que están asignadas a ti.

Si no has incluido 5 tareas en la lista "Qué estoy haciendo ahora", no se pueden añadir tareas a "Qué voy a hacer después", aunque permite ordenarlas en todo momento.

No parece existir relación entre las listas y el estado de la tarea a excepción del estado “closed” que la hace desaparecer de las listas.

Dependiendo del rol que tengas, podrás ver y priorizar las listas de otros usuarios. Además hay varias opciones a la hora de filtrar la lista de tareas que están disponibles (por proyecto, por usuario, por estado...). El administrador del proyecto (project manager), además puede definir un umbral de número de tareas recomendadas a partir del cual se le informe por medio de un correo electrónico que se han incluido tareas en esa lista. Se pueden definir, separadas mediante comas, varias direcciones de correo electrónico.

Además existe un calendario, opcional, que parece recoger las horas por cada día de una semana.

19 | P á g i n a

24/11/2010 – Retrospectiva (5/7)

La herramienta a valorar esta vez es Restrospectiva: http://retrospectiva.org/ y

http://github.com/dim/retrospectiva/

Es un sistema que se centra en el uso de blog, wiki y tickets para el desarrollo compartido de un proyecto. Tiene un sabor parecido a Trac y Redmine aunque parece provenir de un proyecto llamado Collaboa (https://www.ohloh.net/p/3827) que ya no existe.

La gestión ágil la proporciona un plugin, AgilePM.

Versiones / licencias

Licencia MIT. Retrospectiva 2.0. La licencia MIT también se aplica a las partes del código tomadas literalmente de la herramienta Collaboa creada por Johan Sorensen.

Entorno

La aplicación está pensada para ser instalada en sistemas Linux y Unix aunque también se puede ejecutar en Windows (no se recomienda para producción) y requiere de: o Ruby o RubyGems o Rails o MySQL / Sqlite3

Idioma

Inglés aunque hay varias traducciones en curso, entre ellas, una traducción parcial a Español. Además, existe documentación que explica como añadir las traducciones que se deseen (http://retrospectiva.org/wiki/Translations).

Vida

El proyecto tiene una trayectoria corta, deriva de un proyecto llamado Collaboa. Sacó su primera versión (1.0) en enero del 2007, y durante ese año se trabajó en una versión evolutiva y correctiva de errores. El 2008 fue un año sin actualizaciones, quizás debido a algún cambio interno fuerte de la aplicación. La última versión (2.0), enero del 2010, parece haberse desarrollado durante el 2009. En definitiva, les ha costado 3 años sacar una nueva versión, aunque dejando de lado el año de sequía 2008, ha habido aparentemente bastante movimiento. Actualmente están trabajando en la versión 2.1 y en una versión "futura" donde parecen echar posibles funcionalidades futuras.

Documentación

Existe bastante documentación en la wiki de la página web del proyecto sobre la instalación y configuración, que por otro lado, parece sencilla. También, hay documentación sobre como extender vistas, crear plugins, traducir, etc. No es excesivamente extensa pero cubre lo imprescindible.

20 | P á g i n a

Comunidad

La página web del proyecto está soportada por la propia herramienta (como sucede en proyectos como Trac y Redmine). Es por eso que la forma de reclamar funcionalidades y errores sobre el proyecto consiste en el mismo sistema que tiene la herramienta, un gestor de tickets que funciona a modo de soporte. Es cómodo en el sentido de que es una especie de foro donde introduces directamente tu petición y los responsables actúan sobre la misma, incluyendo posibles comentarios de otros usuarios, aunque no parece estar pensado para la aclaración de dudas. Tampoco hay una separación entre consultas de usuarios de la herramienta y desarrolladores de la misma. Quizás no tiene sentido porque no parece haber colaboradores (aunque hay agradecimientos al equipo de Collaboa). Es un sistema que parece tener bastantes usuarios, pero al estar soportado por una única persona las respuestas pueden tardar en llegar de 3 días a 3 meses. Te puedes registrar libremente en la herramienta para generar tickets pero no es necesario. Además, hay una lista de correo (http://rubyforge.org/mail/?group_id=2685) en la que existe un goteo constante de mensajes de 2007 a 2009 durante casi todos los meses del año con una respuesta más o menos rápida (1-8 días), pero en 2010 desaparecen. A partir de esta fecha, parece que migraron a otra lista (http://groups.google.com/group/retrospectiva-general) donde hay una frecuencia menor de mensajes y las respuestas parecen también más dilatadas. No queda claro la diferencia de utilidad entre esta lista de correo y el sistema de tickets de la propia página web. Quizás la lista de correos sea para dudas y el sistema de tickets para la resolución de incidencias y petición de funcionalidades.

Soporte comercial

No hay soporte comercial, todo se realiza mediante el sistema de tickets y la llista de correo.

Funcionalidades gestor de proyectos

Es multi-proyecto, consecuentemente, aunque no permite catalogarlos de algún modo para su distinción. Otra curiosidad es que te permite marcar un proyecto como cerrado.

Tampoco se pueden agrupar los proyectos, pero existe una forma de crear grupos de permisos sobre grupos de proyectos, algo parecido a equipos que se asignan a usuarios individuales.

Existe un sistema de grupos que viene a equivaler a los equipos. A estos grupos se les da unos permisos sobre ciertos proyectos y los miembros del equipo se asignan a dichos grupos con lo que heredan los permisos.

Gestión de incidencias

Existe una gestión de incidencias mediante tickets (sirven para notificar bugs y solicitar mejoras), aunque funciona de manera independiente con respecto, por ejemplo, a las historias de usuario, lo cual resulta bastante desconcertante.

Ampliación y adaptación

Puedes mantener la aplicación siempre actualizada a través del repositorio alojado en GIT aparentemente de forma sencilla (http://retrospectiva.org/wiki/Upgrading). A parte de poder disponer del código fuente para modificarlo al gusto, tiene un sistema de plugins para añadir nuevas funcionalidades. Es el caso del módulo "Ágil", AgilePM. Existe uno propuesto pero que está a la espera de recursos relacionado con Kanban.

21 | P á g i n a

Funcionalidades propias de Scrum

Toda la parte "ágil" de la herramienta reside en un plugin de la misma: AgilePM (http://retrospectiva.org/wiki/AgilePM).

La estructura en la que se organiza la información es básicamente la siguiente: o Proyecto(s).

o Milestone(s).  Sprint(s).

 Goal(s) = funcionalidades con una prioridad que no parece configurable.

o Storie(s) (módulo específico del plugin AgilePM) = historias de usuario. Se estiman en horas, pero es simplemente cuestión de nomenclatura. Parece que no se asignan a ningún responsable, posiblemente se haga de forma automática cuando alguien las seleccione para su comienzo.  Tickets = al igual que en Trac y Redmine, engloba cualquier tipo de petición: tarea, bug, funcionalidad, etc. Son independientes de las historias de usuario. Se define una prioridad (configurable y diferente a la de Goal)

No parecen existir roles de scrum, tan solo permisos.

Existe un Backlog por Sprint que tiene una vista bastante interesante, a mitad de camino entre un BurnDownChart y una pizarra visual. Se visualizan las historias de usuario para un Sprint y un panel cuadriculado con todos los días que incluye ese Sprint donde se observa por cada día el remanente de horas (o puntos) que restan para terminar una historia de usuario.También se aprecia visualmente que historias están activas.

Los estados de las historias de usuario parecen configurables aunque habría que estudiar mejor el plugin de AgilePM para verificar si pueden existir otras: active, pending, complete.

Tampoco puede limitarse el máximo número de puntos (historias de usuario) a trabajar de forma simultánea para controlar la capacidad.

22 | P á g i n a

16/12/2010 – ScrumFactory (6/7)

Quiero terminar este año que desde los Centros de Excelencia hemos dedicado a las metodologías ágiles con un último artículo dedicado a otro gestor de proyectos ágiles. Esta vez nos vamos hasta Brasil para encontrar ScrumFactory:

http://www.scrum-factory.com/ http://thescrumfactory.codeplex.com/

Es una arquitectura cliente-servidor. Existe un instalador para servidor y otro para cliente, que tienen diferentes versiones lo que parece implicar que llevan diferentes ritmos de desarrollo. Existe, además, un plugin para soportar subversion como control de versiones dentro de la herramienta.

Licencia / versiones

Microsoft Reciprocal License (Ms-RL):

Entorno

 Mínimo Windows XP Service Pack 2

 .Net framework 3.5

 Internet Information System 4.0

 SQL Express 2005

Tiene problemas para instalarse en Windows Server 2008 y en Windows 7, posiblemente porque se han cambiado las políticas de seguridad. Si se instala sobre Windows Server 2003 hay que tener cuidado con las actualizaciones que se metan porque deja de funcionar. Es mejor no actualizar el Windows Server 2003.

Es necesario instalar aplicaciones cliente (en los distintos puestos de trabajo) y una aplicación servidor.

Si se producen errores debido a que no se encuentra ADODB, la solución está en comentar esa línea de código en la página web que se carga. Una vez hecho esto, parece funcionar. Este error dará si no se le indica donde se encuentra el servidor de correo Exchange.

Idioma

Inglés

Vida

El proyecto es muy reciente, del 14 de marzo del 2010, y se encuentra en versión beta, con lo que su trayectoria ha sido muy corta. Comenzaron con la versión V1 y actualmente, se hallan en la V1a de servidor, de abril, con la corrección de algunos errores. Desde entonces no se han publicado más versiones.

Documentación

Toda la documentación que se ha encontrado consiste en una sección de FAQ (llamada “How do I”) en la página del proyecto principal que debería ampliarse más porque cubre muy pocos aspectos y de manera muy escueta.

23 | P á g i n a

Comunidad

Hay una página dedicada a la comunidad, http://thescrumfactory.codeplex.com/, donde existe un sistema de foros y una gestión de incidencias para informar sobre errores. El foro tiene muy poco contenido aunque las respuestas son bastante rápidas y hay muy pocas peticiones de errores posiblemente se deba a que el proyecto es muy joven (14 de marzo del 2010) y la gente no lo está empleando.

Soporte comercial

No existe soporte comercial. Sin embargo, se da soporte a través de un foro, del sistema de seguimiento de bugs y a través del siguiente correo: [email protected].

Funcionalidades de gestor de proyectos

El gestor de proyectos es multi-proyecto, permite crear varios proyectos y se puede ver la lista de todos y cambiar de uno a otro, aunque sólo el Scrum Master puede crear proyectos. Para dar de alta un proyecto, debe tener al menos un cliente asociado. Se piden datos de nombre de proyecto, cliente, descripción, ciclo de vida del proyecto (actualmente sólo de tipo ágil), plataforma del proyecto, tipo de proyecto, nombre del directorio en red del proyecto. Además se da una fecha de inicio y una fecha de debería finalizar en.

Los proyectos una vez comenzados se pueden pausar, cerrar o cancelar. Además un proyecto puede ser hijo de otro.

Gestión de incidencias

Los bugs son tareas dentro del proyecto y se manejan como tales. Hay dos tipos de bugs: corrección de errores y corrección de errores una vez que la aplicación está en producción. Además también se tienen en cuenta las tareas de controles de calidad.

Ampliación e integración con otros sistemas

Existe disponibilidad del código y, por tanto, de su posible adaptación. Por otro lado, la existencia de un plugin para subversión hace pensar que puedan crearse plugins para extender las funcionalidades.

Funcionalidades propias de Scrum

Hay varios roles dentro de la herramienta (Scrum Master, Developer, Product Owner, Commercial Guy y Team).

Tiene diagrama de burndown. Tiene tambien gestion de riesgos, propuesta y pagos. Ademas en la pagina inicial del proyecto, se pueden ver una serie de indicadores del mismo. En la parte de miembros del equipo, se puede gestionar quien puede trabajar en el (solo los miembros o cualquiera). Ademas en todo momento se puede ver el esfuerzo del equipo realizado en el proyecto mediante una barra que lo contabiliza (esta barra puede ser desactivada en el apartado de configuracion). El proyecto puede conectarse con un repositorio en subversion mediante un plugin. La estructura de “artefactos” de la herramienta es la siguiente:

 Proyecto: Puede ser hijo de otro proyecto. o Iteracion: Es el sprint

24 | P á g i n a

 Item: Son las historias de usuario (Pueden tener 4 estados Required, Working, Done y Canceled). Ademas deben verificarse por el equipo de calidad y validarse por el cliente.

 Tasks: Son las tareas.

Por otra parte, tiene funcion de autoplanificacion de los sprints. El backlog es por sprint, aunque se pueden ver varios sprints seguidos. Se puede exportar a un archivo xml. Las historias de usuario se planifican en puntos (estos puntos estan predefinidos y tienen un valor de referencia de a que pueden corresponderse). Cada historia de usuario, debe verificarse por el equipo de calidad y validarse por el product owner. Ademas pueden cambiar su posicion dentro del backlog del sprint. Tiene una pizarra visual muy sencilla con funcionalidad de drag & drop. Tiene 3 estados, To Do, Working, Done. No pueden modificarse los estados. Es en este punto donde se crean las tareas asociadas a las historias de usuario del sprint. Hay 4 tipos de tareas, tareas en desarrollo, tareas de control de calidad, correccion de errores y correccion de errores en produccion. Cualquier tarea, puede pasar a ser uno de esos tipos. Ademas, tambien existe la opcion de que sean impedimentos. Entonces cambia su color a rojo. Si las tareas son de correccion de errores, aparece un dibujito de una mariquita o de un escarabajo para indicar que son errores. Se puede ver la carga de trabajo del cada miembro del equipo mediante la opcion Team Allocation del menu superior. Ademas, en este mismo menu tambien se puede sacar el esfuerzo en horas de los miembros del equipo.

25 | P á g i n a

20/12/2010 – Express (7/7)

Terminamos el año y los artículos de la serie con la última herramienta, Express:

http://agileexpress.sourceforge.net/

A juzgar por la escasa documentación, parece ser proyecto reciente y según su roadmap, todavía tiene mucho camino que recorrer:

 0.7 (current) - Backlog management, Virtual Wall, Acceptance Criteria, basic impediment management.

 0.8 - Full Impediment Management for tasks and stories with list views by Iteration and Project.

 0.9 - Detailed reporting: developer velocity, advanced burndown y project burnup.

 - Defect, Risk, & Issue management.

Puede que actualmente esté un poco verde, contiene errores de funcionamiento (ej: asignación de impedimentos a tareas no visualizados, componentes gráficos de edición no presentes en determinados momentos, etc.) y resulta bastante compleja de instalar, así que quizás convenga esperar a que madure.

Versiones / licencias

No hay información de las licencias. El código no está disponible con lo que apunta a que por el momento no es Open Source o están decidiendo aún su licenciamiento.

Entorno

 JDK

 Contendor de servlets: Tomcat 6.0.20, Jetty.

 Base de datos: Postgres (defecto), MySQL, HSQL.

 Servidor de correo (SMTP): parece necesitarse para el proceso de confirmación de registro de los usuarios en la plataforma.

Idioma

Sólo está disponible el inglés.

Vida

Aparentemente comenzaron con la versión 0.7.1 en noviembre del 2009, en el momento de analizar esta aplicación, la última versión era de marzo del 2010, la 0.7.5. Han sacado 4 versiones en 4 meses aproximadamente, un buen ritmo si no sería porque desde marzo no habían avanzado nada.

Documentación

Escasa, tan solo hay un documento de instalación y configuración que, de hecho, sirve de poco.

Comunidad

No existe.

26 | P á g i n a

Soporte comercial

No existe.

Funcionalidades gestor de proyectos

Se puede gestionar múltiples proyectos aunque no permite la agrupación de los mismos o identificación por áreas lo que puede acabar por convertirse en un saco inmanejable de proyectos.

Se trata de un gestor de proyectos expresamente enfocado a la gestión ágil así que dentro de este apartado no mucho reseñable, salvo quizás, la forma de acceder. Para tener acceso a la aplicación existe un proceso de registro, por el cual la aplicación verifica tu dirección de correo electrónico. Así pues, es imprescindible configurar el uso de un servidor de correo. (una solución provisional consiste en alterar la base de datos)

Gestión de incidencias

No hay gestión de incidencias.

Ampliación y adaptación

No hay información sobre algún posible sistema de plugins y, aparte, al no disponer de las fuentes en el momento de redactar esta valoración, tampoco se puede modificar para adaptarlo.

Funcionalidades propias de Scrum

La aplicación está claramente orientada a la gestión de proyectos con Scrum, así que implementa los conceptos y artefactos más comunes:

 Project - Es el nivel más alto, define un proyecto sólo con fecha de inicio, no de fin y en el se indica como se va a medir el esfuerzo de las historias de usuario (puntos, días u horas).

o Iteration - El sprint con fecha de inicio y de fin.

 Story – Son historias de usuario, se definen de la manera habitual. Si el proyecto se ha definido el esfuerzo en puntos, las historias de usuario tienen puntos para el valor de negocio y para el esfuerzo. Pueden estar asociadas a un tema (funcionalidad).

 Tasks – Cada historia de usuario tendrá una o más tareas asociadas. Estas tareas se definen en horas. Existe, dos backlog consistente en sendas listas de las historias de usuario, por una parte las que no están asignadas a ningún Sprint y las que si están asignadas al Sprint. Existe una vista en la cual se muestran ambas listas y que soporta el drag & drop permitiendo pasar historias de usuario del backlog general (del proyecto) al backlog del sprint.

Cuenta con una pizarra visual por sprint donde se ven las historias de usuario y sus tareas asociadas con 4 estados posibles no modificables: abierta, en progreso, test y hecha.

También cuenta con la funcionalidad de drag & drop. Se pueden incluir impedimentos, que se identifican en la tarea como una marca roja existiendo la posibilidad de añadir un responsable de subsanar dicho impedimento. En cada tarea aparece el responsable de la misma, el cual es único aunque cualquier otra persona

27 | P á g i n a

puede tomar el control cuando quiera auto-asignándosela. No hay medidas de carga y no hay forma de limitar el trabajo que puede hacer una persona. También tiene una gráfica en la cual se visualizan los puntos (velocidad) conseguidos por iteración y un Burndown Chart por iteración pero que no aporta mucha información. Los roles existentes no son los de Scrum, hay un el rol de propietario del proyecto y de la iteración. El resto de usuarios puede solicitar entrar en un proyecto, y será el propietario del proyecto el que les permita entrar. Cuando el acceso es aceptado, al usuario le llega un correo confirmándolo.