JIRA

Un JIRA para cada grupo

0 comments. Top.

JIRA72

A fines del 2015 Atlassian lanzó la versión 7 de JIRA. La principal novedad de esta versión es un cambio fundamental en el empaquetamiento: lo que hasta la versión 6 eran los addons (o plugins) Jira Service Desk y Jira Agile, se transformaron en productos: Jira Service Desk y Jira Software respectivamente. Y lo que hasta la versión 6 se llamaba JIRA, se cambia de nombre a Jira Core.

Dicho de otra forma, lo que hasta la versión 6 conocíamos genéricamente como JIRA, a partir de la versión 7 se abre en 3 nuevos productos usables y licenciables de manera independiente.

La idea detrás de este empaquetamiento es diferenciar a los usuarios de JIRA en 3 grupos: los que solo usan la funcionalidad de flujos (Jira Core), los que usan flujos y tableros Scrum/Kanban (Jira Software) y los que usan flujos junto con la funcionalidad de SLA para atender mesas de ayuda (Jira Service Desk).

En una misma instancia (i.e. servidor) se pueden combinar estos 3 tipos de usuarios en forma simultánea. Así puedo tener 100 usuarios con Jira Software (el área de desarrollo), 50 usuarios con Jira Core (áreas que usan flujos para procesos operacionales) y 25 usuarios (agentes) que atienden una o más mesas de ayuda con Jira Service Desk. Si tengo los tres productos instalados entonces al crear un proyecto se ofrecen 3 tipos, tal como muestra la imagen (hacer click para agrandar):

JIRA 7 ofrece 3 tipos de proyectos.

El tipo de proyecto define la funcionalidad que se ofrece al usuario licenciado para el producto respectivo. Así si tengo licencia para Jira Software y tengo privilegio de administrador, puedo crear un proyecto de Software o de Negocio. Esto es porque Jira Core es la base de los otros dos, por lo tanto siempre tendré la opción de crear proyectos de tipo Negocio. Pero si solo tengo licencia de Jira Core, no puedo crear un proyecto de Software o Service Desk. Un usuario con licencia de Jira Software podrá ver y usar los tableros que tienen la misma funcionalidad que actualmente ofrece el addon Jira Agile.

Esta nueva versión también trae cambios en las licencias. Así por ejemplo los usuarios actuales de JIRA podrán renovar su licencia a Jira Software (el sugerido por Atlassian cuando corresponda renovar la mantención) o a Jira Core. Las nuevas licencias son compatibles con JIRA 6 de manera que no es necesario migrar a JIRA 7 inmediatamente (ACTUALIZACION IMPORTANTE: La versión 6 ya no está oficialmente soportada por Atlassian).

Con este nuevo modelo de licenciamiento el Administrador deberá relacionar usuarios (o grupos de usuarios) con la aplicación que corresponda, ya que al poder tener las 3 en forma concurrente, esta relación usuario/aplicacion permite controlar el uso de las licencias de cada una.

Hasta antes de este cambio si contaba con una licencia de JIRA para 100 usuarios y quería usar tableros ágiles para un grupo de solo 25, debía licenciar el addon Jira Agile para 100 usuarios. Con este nuevo empaquetamiento puedo contar con Jira Software para 25 usuarios y Jira Core para 100. Esto da más flexibilidad para reservar licencias de cada tipo a los usuarios que las necesiten.

En el futuro se espera que aparezcan funcionalidades y addons orientados a cada uno de estos tres productos.

El siguiente video ofrece una visión de este anuncio:

5 malas prácticas en JIRA

0 comments. Top.

proibidoMucho se habla de las buenas o mejores prácticas. Pero casi nunca se cuentan las malas (o peores), que en la realidad son las que más se ven. De hecho cualquier mejor práctica tiene que tener como contraparte una mala práctica.

JIRA no se queda fuera de esta realidad: se trata simplemente una herramienta de software. Es su uso lo que va a determinar el valor real que entrega a un grupo de personas y finalmente a la organización. Y su uso está determinado por la experiencia, habilidades y actitudes de sus usuarios. Al igual que con un martillo o un taladro, los clavos quedarán firmes y derechos y los hoyos no agrietarán la pared si las personas que las usan lo hacen correctamente.

A continuación presentamos una lista con las peores prácticas que he me ha tocado ver reiteradamente como Atlassian Expert y la cura que se puede aplicar para cada una.

1. Compromisos vencidos

Juan crea una tarea, ingresa la fecha de compromiso (duedate) y la asigna a José.
Llega la fecha de compromiso y la tarea no está resuelta. Al día siguiente Juan se da cuenta que el compromiso solicitado no se cumplió. Agrega un comentario exigiendo una explicación y así pasan varios días más entre comentarios y réplicas.
Sin embargo la fecha de compromiso de la tarea sigue siendo la misma, aunque ya no aporta ningún valor, porque el compromiso no se cumplió!

Comentario: José debería haber modificado la fecha de compromiso el mismo día que debió haber quedado resuelta o antes, si ya sabía que no iba a poder cumplir en la fecha solicitada. No actualizar la fecha de compromiso de un issue es una de las peores prácticas en JIRA: rápidamente se pierde la confianza en esta fecha clave y si esto ocurre JIRA deja de tener utilidad, ya que recordemos que su rol último es ser un issue tracker, hacer seguimiento, pero cómo puedo hacer seguimiento de un dato del cual ya no confío?

Aunque se pueden usar ayudas para monitorear cuántos días quedan antes de cumplir la fecha de compromiso (como programar un customfield que calcula la diferencia en días hábiles entre el duedate y la fecha actual y mostrarlo con colores de alerta), es finalmente responsabilidad de cada uno vigilar que los duedates de los issues que tenga asignados representen fielmente su compromiso de atenderlos o resolverlos antes de esa fecha.

Regla: No se aceptan compromisos vencidos.

2. Abuso de adjuntos

Juan crea una tarea que pide la corrección de un programa y la asigna a José.
José siente que la manera de demostrar que está de lleno dedicado a la corrección es comenzar a adjuntar la mayor cantidad de archivos posibles: requerimientos (Word), datos/casos de prueba (Excel), comunicaciones con usuarios (emails), código (zips), etc.
Más aun, algunos de estos archivos se versionan en el mismo issue con sufijos o fechas en el nombre para representar diferentes versiones.
El resultado final es que el issue termina con 10,15 o más adjuntos.

Comentario: JIRA no es un document manager ni tampoco un version control. José podría usar Confluence para guardar documentos y en el issue guardar solo el link a la pagina Confluence. Los beneficios de la integración de JIRA y Confluence son conocidos (ver Referencias). También podría usar GIT/SVN y en el issue guardar el link al repo o usar un addon que integre a JIRA con GIT/SVN.

Existen addons que permiten restringir los tipos de archivos que se pueden adjuntar a un issue. Así se podría permitir adjuntar solo imágenes, dejando el resto en otros repositorios como Confluence o GIT/SVN.

3. Quién es el responsable?

Juan crea una tarea y la asigna a José.
José ve que falta información e ingresa un comentario, mencionando a @paula.
A partir de este momento la tarea no tiene un responsable real, se diluyó, ya que José se queda esperando la respuesta y Paula no es la asignada, sigue siendo José.
El responsable se diluye más aún con cada nuevo mencionado en los comentarios que sigan.

Comentario: José debió haber asignado la tarea a Paula junto a su mención en el comentario. De esta manera Juan, José, Paula y cualquiera que vea la tarea sabe quien está efectivamente a cargo. Si Paula pide información a otra persona, además de usar menciones debe asignar la tarea, y así sucesivamente.

3 y 1 están muy relacionados: cuando veo un issue necesito confiar que la persona que está actualmente asignada se hace responsable de cumplir el compromiso dado por el duedate, aunque esta persona no sea quien creó o a quien originalmente se le asignó el issue.

Regla: Si estoy asignado entonces soy el responsable de cumplir el compromiso.

4. Una sola gran tarea

Juan crea una tarea y la asigna a José. Pasan los días y muchos otros se incorporan, registran y comentan en la (misma) tarea. Al final tenemos varias páginas de comentarios, algunos con varios niveles de réplica.
A esta altura se nos hace difícil entender qué está pasando con esta tarea si no estamos directamente involucrados.

Comentario: José debió haber creado subtareas, asignarlas a si mismo (o a quien corresponda) y dejar todo registro y comentarios en el contexto de cada una.

Si suponemos que el grupo/organización cuenta con procesos formales y maduros (CMM/ITIL), José debería crear un tipo específico de issue (un upgrade de aplicacion por ejemplo), que tenga etapas y tareas específicas definidas por sus procesos, y asociarla a la tarea que Juan creó (que bajo el mismo supuesto habría sido una solicitud de upgrade). Usar tipos y estructuras de issues JIRA que representen procesos formales de la organizacion es definitivamente una mejor práctica (ver Referencias), ya que permite estandarizar en JIRA estos procesos evitando así saltarse etapas o controles, lo que probablemente ocurra si dejamos que se creen en forma adhoc, y establecer niveles de cumplimiento (SLA).

5. Abuso de links

Juan crea una tarea y se la asigna a José. Pasan los días y si vemos el issue nos encontramos con 10,15 o más links a issues de los más diversos tipos y en diferentes proyectos.
José trató aquí de crear una combinación de Gantt con una WBS (Work Breakdown Structure), usando el único recurso a mano en JIRA: links.
El problema es que en la malla de links que esto produce (imaginemos que todos comienzan a hacer lo mismo) nadie entiende nada, excepto quizás José.

Comentario: Así como vimos en el punto 2 que Jira no es un document manager ni un version control, tampoco fue pensado para Gantts/WBS y otras funciones que encontramos en productos como MS Project y otros similares. El valor de JIRA está dado por su capacidad de definir flujos (que pueden ser muy complejos y sofisticados con la ayuda de un par de addons claves en este aspecto). A esto agregamos la integración con Confluence para manejar entregables tipo documentos (como requerimientos y especificaciones) y con otras herramientas Atlassian para el ciclo de vida (como Bitbucket para entregables de código y Bamboo para control de los ambientes).

José puede elegir usar algún addon que integre JIRA con MS Project y de esta forma mantener la Gantt/WBS allí. O bien optar por alguno que agregan una Gantt/WBS dentro de JIRA (hay varios y de diferente valor). Independientemente de los addons que se puedan usar, definir antes una jerarquía de issues (y links) es esencial para ordenar el trabajo de una persona y de cada grupo. La rapidez con que se adopte esta definición está directamente relacionado al grado de formalidad y madurez de los procesos del grupo o área (ver Referencias).


Esta cinco malas prácticas tienen un alto impacto en las expectativas que el uso de JIRA produce en una organización. Por ello es muy importante que todos los involucrados hagan su mejor esfuerzo en reducir (idealmente eliminar) su uso.

Referencias:

Integración de Jira y Confluence para gestión de proyectos

Manejo de Incidentes con Jira

Gestión de Portfolios IT con JIRA

 

 

Gestión de Portfolios IT con JIRA – Parte I

0 comments. Top.

Hace poco me toco ver un post en Linkedin. Alguien planteaba la cuestión de qué es un “proyecto”, desde la perspectiva de que a cualquier iniciativa fuera de lo común se le asigna rápidamente esta condición, con lo cual la organizacion siempre está llena de “proyectos” que no somos capaces de discriminar la importancia o urgencia de cada uno.

Esto está lejos de ser una cuestión meramente semántica. En cualquier organizacion el lenguaje juega un rol clave que permite obtener resultados y facilitar la colaboración. Por esta razón resulta fundamental contar con una definición compartida de qué entendemos por proyecto y cuáles son sus diferentes categorías y alcances. A partir de esta definición podremos gestionar los proyectos de una organizacion. Para ello vamos a partir con el concepto de Portfolio.

Jerarquía de Portfolios

El siguiente diagrama muestra una visión jerárquica de agrupaciones de iniciativas que se denominan Portfolio. Cualquier iniciativa debe pertenecer a uno de estos 3 portfolios (hacer click para agrandar):

PortfolioITLR

Con este marco, un CIO o PMO debiese tener una respuesta taxativa a estas preguntas:

  • Cuantas iniciativas tengo actualmente en cada portfolio?
  • Qué tipo de documentación se registra para las iniciativas de cada portfolio? En cada uno hay diferentes grados de riesgo, potencial de valor agregado y porcentaje del costo total del área IT. Por lo tanto la documentación tiene que ser diferente en cada caso. También se necesitan diferentes tipos de controles.

Dinámica de Portfolios

El siguiente diagrama complementa la visión jerárquica de portfolios con una visión dinámica, y que nos ofrece un marco para elaborar un proceso real para administrar portfolios (hacer click para agrandar):

PortfolioITCicloLR

El proceso completo, mirado desde una perspectiva amplia del tiempo, se puede dividir en 3 fases, correspondiente al ciclo de vida de cada portfolio. En cada fase tenemos etapas y filtros (controles). Cada etapa representa las acciones que se deben realizar sobre una iniciativa y los filtros definen si autorizar o rechazar el paso a la siguiente etapa.

Notemos también que entre estas fases existen loops de retroalimentación, como por ejemplo al detectar oportunidades de mejora en la mantención de activos se generan iniciativas de proyecto o de exploración. Los objetivos estratégicos de la organizacion, que se traducen en factores críticos de éxito, KPI, planes, roadmaps, etc., se relacionan con la dinámica de portfolios a través del filtro de entrada de cada fase.

Volviendo a la introducción de este articulo, la próxima vez que alguien le pregunte: en cuantos proyectos estamos trabajando?, la respuesta debería ser: en el portfolio de exploración tenemos 3, en el de proyectos 15 y en el de activos 200. Es más larga, pero nos dice mucho mas sobre la situación real de la organización.

Implementación con JIRA

La jerarquía y dinámica de portfolios descritas se pueden llevar a la practica con JIRA. Los pasos son básicamente los siguientes:

  1. Crear 3 proyectos JIRA, uno por cada portfolio. Aunque el portfolio de proyectos y de activos lo abramos en N proyectos JIRA según nos sea conveniente (por ejemplo un proyecto JIRA por cada aplicacion), conceptualmente sigue siendo un solo proyecto en JIRA.
  2. Definir issues JIRA que representen una exploración, un proyecto y el ciclo de vida de un activo (por ejemplo: mantencion correctiva y evolutiva de una aplicacion).
  3. Definir el ciclo de vida de estos issues, que traducen a JIRA los conceptos de etapa y filtro de una fase.
  4. Definir custom fields para cada tipo de issue JIRA que permitan gestionar la iniciativa que representan. Por ejemplo, para el portfolio de proyectos, un campo que indique el desvío en relación a la fecha de plan de la etapa actual en la que se encuentra un proyecto.
  5. Definir tableros JIRA que permitan administrar cada uno de los 3 portfolios a partir de los issues y ciclo de vida definidos.

En la parte II de este articulo vamos a revisar mas detalladamente los pasos 1-5 y su implementación en JIRA.

Referencia: IT (Information Technology) Portfolio Management Step-by-Step: Unlocking the Business Value of Technology

Integración de Jira y Confluence en Video

0 comments. Top.

En post anteriores revisamos los beneficios de integrar JIRA y CONFLUENCE para la gestión de proyectos. Estos dos excelentes videos de Atlassian muestran diferentes facetas de esta integración, desde la captura de requerimientos en Confluence hasta el manejo de ellos en JIRA usando un enfoque Agile.

 

Integración de Jira y Confluence para gestion de proyectos

0 comments. Top.

En posts anteriores hemos visto cómo podemos configurar JIRA para contar con un proceso de administración de proyectos o manejo de incidentes. En ellos existe una dimensión documental (entregables tipo requerimientos o especificaciones), que en JIRA se traduce a solo a poder adjuntar archivos a los issues de un proyecto, lo cual constituye una debilidad.

Afortunadamente contamos con Confluence, que nos permite abordar este importante aspecto de la gestión de proyectos, manejar documentos, de forma mucho más profesional y que además se puede integrar con el correspondiente issue en JIRA.

Confluence Básico

Confluence es una plataforma que complementa muy bien a JIRA, ya que aquí podemos crear contenido en un contexto colaborativo con los integrantes de un proyecto. Esto es especialmente útil para la generación de los requerimientos de desarrollo y documentos técnicos.

En Confluence el contenido se organiza en espacios y dentro de ellos creamos páginas.

La organización es jerárquica, partiendo por una página home o inicial y bajo la cual se ubican las páginas que representan el contenido de un proyecto: requerimientos y documentos técnicos, agenda de compromisos, reuniones, acuerdos, bitácora de proyecto, etc. Un ejemplo de una página (en este caso la inicial de un espacio llamado Anuncios), es el siguiente:

Una pagina de Confluence

Con Confluence podemos definir también templates o plantillas, de manera de que los espacios y las páginas que creamos sean homogéneas y compartan un origen común: la plantilla.

Otras virtudes de Confluence que lo hacen muy conveniente para el manejo documental de los proyectos son:

  • Control de acceso y edición de espacios y páginas.
  • Customizable via macros y addons.
  • Manejo de versiones.
  • Capacidad de búsqueda dentro del contenido (sean páginas o adjuntos tipo MS Office o PDFs).
  • Edición de contenido, muy similar a un editor de MS Word.

Plantilla de Proyecto

Para la integración con JIRA, definimos los siguientes objetivos:

  • Contar con una plantilla de espacio de proyecto, con una estructura de páginas que representan el contenido del proyecto.
  • Contar con una ficha de proyecto, que es una página del espacio con una vista resumen del contexto y estado del proyecto.
  • Integrar la ficha con JIRA, de manera de que los datos del proyecto (estado y fechas relevantes principalmente) se actualicen automáticamente en la ficha, sin necesidad de edición manual.

Un ejemplo de plantilla de espacio de proyecto es el siguiente:

Plantilla Espacio

Aquí vemos que la plantilla define 5 secciones: Ficha Proyecto, Requerimientos, Arquitectura, Minutas Reunion y Documentos. Veamos dos de ellas.

La Ficha del Proyecto es la página del espacio que resume los objetivos, estado y eventos relevantes del proyecto:

Plantilla Proyecto

Aquí la tabla Resumen se actualiza automáticamente a partir de la integración que se define entre JIRA y Confluence dado el identificador del correspondiente proyecto JIRA (REQ-216). El jefe de proyecto solo actualiza las otras secciones de la ficha.

Todos los proyectos conllevan reuniones. Para que estas sean realmente efectivas, debemos llevar un registro de sus compromisos. En este caso todas las minutas de reunión se crean a partir de una plantilla de página y se guardan bajo Minutas Reunión:

Minutas de Reunion

Beneficios de la Integración

Al complementar JIRA integrándolo a Confluence para manejar los documentos de un proyecto se observan los siguientes beneficios inmediatos:

  • Visibilidad de los entregables del proyecto, ya que ahora no son adjuntos de JIRA sino páginas en Confluence que se desarrollan aprovechando las opciones de colaboración que ofrece Confluence en sus nuevas versiones.
  • Visión de alto nivel y actualizada de cada proyecto o de grupos de proyectos, mediante fichas que se visualizan individualmente o en grupo (usando opciones de reporting de Confluence). Parte de los datos de la ficha están además sincronizados con el correspondiente proyecto en JIRA.
  • Otros beneficios propios de usar la plataforma Confluence, como el manejo de versiones y la búsqueda dentro del contenido.

Referencias:

Integracion de Jira y Confluence en video

 

Manejo de Incidentes con JIRA

0 comments. Top.

En un post anterior, comentamos cómo el potencial de configuración de JIRA era muchas veces sub-utilizado y por ello revisamos una customización especifica orientada al manejo de proyectos de mantención de aplicaciones.

En esta ocasión vamos a revisar otra configuración de JIRA aplicada a incidentes que surgen del uso de aplicaciones. Este proceso busca enmarcarse dentro del modelo ITIL, práctica Incident Management, cuya definición establece:

“El primer objetivo del proceso de manejo de incidentes es restablecer la operación normal de un servicio tan rápido como sea posible      minimizando el impacto en procesos de negocio.

Objetivos

Los objetivos concretos que se buscan con esta configuración son:

  1. Controlar el avance de cada incidente individual y de grupos de incidentes.
  2. Gestionar una estructura estándar para todos los incidentes. En este caso, como se trata de incidentes de aplicaciones, tiene que haber actividades de analisis, diseño, construcción y pruebas que intervengan en la resolución.
  3. Utilizar linea base de fechas de plan junto con controles de cambio cada vez que se necesite modificar la linea base de la planificación de la resolución de un incidente.
  4. Incorporar el concepto de problema para asociar incidentes que tienen un síntoma común.

Jerarquia de issues

Para lograr los objetivos propuestos lo primero es definir una jerarquía de issues en JIRA. Un issue es el elemento básico para almacenar información. Los genéricos son bug, tarea, story, mejora, etc., pero aquí vamos a crear issues específicos con atributos específicos:

Jerarquia Mantencion Correctiva

En esta configuración el concepto de incidente lo hemos representado en un issue que se llama Mantención Correctiva. Lo podríamos haber llamado incidente, pero se usó este nombre para homologarlo con el de Mantención Evolutiva que revisamos en el post anterior. De esta forma las correctivas (incidentes) se hacen cargo de las acciones urgentes necesarias para volver a la operación normal de una aplicación, mientras que las evolutivas se focalizan en aumentar su funcionalidad.

Las acciones que se deben realizar para corregir un incidente se representan como una serie de tareas asociadas a la mantención correctiva: en efecto, cada vez que se crea una mantencion correctiva, automáticamente se generan 8 subtareas que representan las actividades de análisis, corrección, pruebas y liberación que es necesario ejecutar para completar el ciclo de un incidente.

Flujos

El flujo de una mantención correctiva se resume en el siguiente diagrama:

Estados Mantencion Correctiva

En JIRA cada issue está asociado un flujo. En esta configuración el flujo es relativamente simple: el incidente se abre por una mesa de ayuda (que recibió el reclamo del cliente de la aplicación) y se asigna a un gestor quien realiza un análisis (eventualmente puede solicitar más información a la mesa de ayuda). Si es efectivamente un incidente se corrige, lo que implica completar todas las subtareas definidas. Cuando la corrección está disponible se considera resuelto por el gestor, pero es la mesa de ayuda (o un representante del cliente) quien determina si la corrección se acepta (y se cierra el incidente) o se rechaza, con lo cual el ciclo de análisis-corrección empieza una nueva iteración.

En la práctica el flujo es un poco más elaborado que el de la figura, si tomamos en cuenta que podemos incorporar el concepto de problema donde una o mas incidencias se relacionan entre si, de manera que si una se resuelve las relacionadas se deben resolver también. Además hay otras transiciones posibles, como cuando la corrección del incidente no implica efectuar actividades de construcción y pruebas, etc.

Cada subtarea de la mantención correctiva tiene también su propio flujo. La mayoría son simples (abierto, en progreso, cerrado), pero en el caso de las actividades de QA estos son más elaborados.

Otro aspecto relevante de esta configuración es obligar el uso de la jerarquía de issues definida, de tal forma que no se modifique en cada instancia de una mantención correctiva. Para esto se establecen permisos y restringen opciones que por default están abiertas en JIRA.

Resultado

La imagen muestra un ejemplo de un issue tipo mantención correctiva tal como luce en JIRA:

Ejemplo Mantencion Correctiva

En la parte inferior (sección Sub-Tasks) están todas las actividades que se realizaron para resolver el incidente. Uno de los objetivos establecidos fue que todas las mantenciones correctivas tuvieran la misma estructura: si abrimos cualquier mantención que haya sido corregida, veremos siempre las mismas 8 subtareas.

En la parte derecha (sección Dates) aparecen una serie de fechas de planificación asociadas a cada actividad de análisis y corrección. Solo el Gestor puede modificar estas fechas, lo cual queda registrado en la mantención como un evento de replanificación.

También se usan una serie de campos ad-hoc (customfields de JIRA), como categoria (incidente o problema) y varios contadores, que registran las veces que una mantención fue rechazada en las actividades de QA y auditoría de código.

Conclusion

Hemos revisado cómo configurar JIRA para hacernos cargo de atender incidentes asociados al uso de aplicaciones. Al establecer una estructura estándar de issues JIRA, todos los incidentes son iguales desde el punto de vista del proceso que siguen para su corrección.

Un complemento óptimo a un flujo de mantenciones correctivas es el uso de JIRA SERVICE DESK, ya que así podemos relacionar la atención que ofrece la mesa de ayuda (en JIRA Service Desk) con las actividades de corrección ejecutadas por el área de desarrollo (en JIRA), cuando los incidentes son escalados desde la primera a la segunda.

Jira Service Desk

0 comments. Top.

La siguiente es una presentación de Jira Service Desk, el software de Atlassian que facilita la implementación de mesas de ayuda integrado a JIRA.

Gestion de Ambientes con Bamboo: Conceptos

0 comments. Top.

bamboo_logo_landingUno de los problemas más complejos de las áreas de TI es lograr tener un control de sus ambientes de desarrollo, testing y producción mediante un flujo que asegure que los artefactos producidos se muevan al ambiente que corresponda, por quien corresponda y cuando corresponda. Además, se busca poder conocer qué está en cada ambiente en un momento dado y qué cosas nuevas se modificaron entre una entrega y otra.

Para hacer mas fácil la administración de esta compleja tarea está Bamboo. Definido principalmente como un servidor de integración continua (CI build management), Bamboo incluye además la funcionalidad para la administración de deployments (entregas) dentro de diferentes ambientes. Al ser de la misma familia Atlassian, Bamboo se integra y complementa estrechamente con JIRA y BITBUCKET (administrador de repositorios git).

Para entender cómo usar Bamboo para gestionar ambientes, es necesario primero entender los conceptos sobre los cuales se organiza su funcionamiento: artefactos, releases, ambientes y planes.

Artefactos, Releases y Ambientes

En el contexto de un proceso de integración continua, un commit (i.e. checkin) que ejecute un programador gatilla un proceso de compilación y ensamblaje del código en algún tipo de binario susceptible de instalarse y ejecutarse en un servidor. A estos binarios se les conoce como artefactos.

Un release es un “foto en el tiempo” de un grupo de artefactos (jars, zips, archivos). Es inmutable y Bamboo le asigna un identificador unido. Un release incluye ademas metadata tal como los commits del sistema de control de versión, los issues JIRA asociados y los id de los builds que fueron usados para construir los artefactos. Un release contiene la información para obtener la diferencia entre uno y otro release. Un release registra ademas los ambientes donde ha sido instalado mediante un proceso controlado por Bamboo que veremos mas adelante (proyectos de deployment).

Los servidores donde los artefactos deben ser instalado definen un ambiente. Típicamente se agrupan en Desarrollo, Testing, Certificación (staging) y Producción. Los ambientes deben tener controles de acceso que permitan definir quien puede efectuar entregas en el.

La figura muestra la relación entre estos 3 conceptos claves de Bamboo:

BambooDeploymentProjects

Planes

En Bamboo, los procesos de integración continua se especifican mediante un Plan.

Un plan es una serie de instrucciones que especifican cómo se debe llevar a cabo un proceso, desde la compilación y generación de ejecutables hasta las pruebas de certificación. Una buena analogía es comparar un Plan con una linea de ensamblaje.

El plan define también donde se encuentra el repositorio de código disponible para el proceso. Como muestra la figura, un Plan se divide en Etapas, las Etapas incluyen Jobs y los Jobs contienen Tareas:

BAM_52_BambooPlanAnatomy

Bamboo provee una lista de tareas básicas, tales como extraer código del repositorio definido en el plan, ejecutar test unitarios, efectuar deployments, ejecutar scripts, copiar archivos, etc. Algunas de estas son genéricas a cualquier plataforma y otras especificas a frameworks como Maven o Ant.

Para unir la función de integración continua con la de gestión de ambientes, Bamboo implementa el concepto de “proyecto de deployment” de una aplicacion.

Proyecto de Deployment

En Bamboo los ambientes y releases de una aplicacion se organizan en un proyecto de deployment. El proyecto define cual es el plan que provee los artefactos que se instalarán en los distintos ambientes definidos para la aplicación en el proyecto.

Los proyectos de deployment en Bamboo permiten cerrar el circuito desarrollo-pruebas-deployment, tal como muestra la figura:

BambooDeploymentProjectArtifacts

Por ejemplo, a partir de un flujo de mantenciones correctivas (i.e. defectos)  organizado en JIRA, el programador modifica y hace commit de sus cambios en el repositorio asociado al plan de Bamboo, lo que gatilla un ciclo de integración continua. Este proceso produce una serie de artefactos, los cuales con asociados a un release, junto con los issues JIRA, los commits del repositorio de código y metadata asociada al proceso de integración continua. El release se marca con un identificador único lo que permite ubicarlo en los diferentes ambientes por los que se mueva definidos en el proyecto de deployment que controle el proceso.

Finalmente, los proyectos de deployment permiten definir la rama del Plan a usar para un determinado release. Esto es muy ventajoso, ya que un programador puede hacer una prueba en un ambiente (que el no controla) de los cambios que ha hecho en su rama del repositorio de código. Después de hacer las pruebas en este ambiente, puede decidir promover sus cambios a la rama principal, lo que gatilla un proyecto de deployment que finalmente lleve sus cambios al ambiente de producción.

Esta idea se muestra en la siguiente figura, donde la rama “feature” representa un linea aislada de la rama principal (“master”), que sirve de base para un deployment en un ambiente de test (círculos amarillos). Cuando los resultados del ambiente de test son satisfactorios se promueven los cambios a la rama Master, lo que gatilla un proceso normal de deployment en producción (círculos rojos):

BranchDeploymentsProcessFlow

En conclusión, Bamboo representa una buena alternativa para controlar un proceso de CI build management, con el agregado de ofrecer ademas importantes facilidades para el la gestión de ambientes e integración con JIRA y BITBUCKET, para así tener una visión completa de como se están modificando los ambientes en una plataforma IT.

Configuracion de JIRA para administrar proyectos

0 comments. Top.

En muchas organizaciones el potencial de JIRA suele no estar bien aprovechado. Me ha tocado ver en más de una ocasión que se usa prácticamente igual a como cuando se instaló.

La principal causa de esto es el desconocimiento del alto grado de customización o configuración que es posible alcanzar en JIRA, principalmente cuando se recurre al uso de sus APIs, ya sea directamente o a través de algún plugin. Este potencial se puede orientar tanto a procesos operacionales como a los que se encuentran dentro del área IT.

En este post se muestra un ejemplo de este último tipo: configurar JIRA para la administración de proyectos, en particular mantenciones, que son las que casi siempre se dan en mayor número en esta área.

Introducción

Si bien se suele asociar el uso de JIRA con el manejo de proyectos, en realidad JIRA no fue diseñado para manejar proyectos, cuando por proyectos entendemos lo que define el PMI en el marco del PMBOK, esto es:

Un conjunto de actividades acotadas en el tiempo y destinadas a producir un único resultado o producto

De hecho JIRA tampoco cumple con la definición de un software para PPM (Project Portfolio Management). Como ya lo mencionamos en este articulo, JIRA administra issues mediante flujos que permiten mover cada issue a través de sus diferentes estados. En JIRA un proyecto es un mero “contenedor de issues”.

No obstante lo anterior, si es posible configurar JIRA y crear un proceso de administración de proyectos. Para esto hay 2 maneras:

  • Configurar JIRA aprovechando la amplia gama de posibilidades de customización que ofrece.
  • Recurrir a plugins (como JIRA PORTFOLIO o TEMPO FOLIO entre otros).

En este post vamos a abordar un modelo basado en el primer enfoque.

La Jerarquía de issues

Lo primero que tenemos que hacer es definir qué tipos de issues vamos a usar para gestionar nuestros proyectos. En este caso vamos a usar el contexto de un área de TI, pero el modelo es perfectamente aplicable a iniciativas de otros grupos o áreas.

La jerarquía de issues es la siguiente (click en la imagen para agrandar):

Tenemos en primer lugar issues que representan INICIATIVAS que se desarrollan en una área de TI: mantenciones evolutivas de aplicaciones, desarrollos orientados a plataformas web o móviles, renovación o ampliación de infraestructura, etc. Cada una de estas iniciativas tiene características que la distinguen entre ellas, pero en general podemos suponer que todas se ejecutan siguiendo una serie de ETAPAS especificas.

Cada una de estas etapas contiene TAREAS donde se gasta nuestro tiempo: reuniones, programación, pruebas, etc. Como en la realidad las estimaciones y planificaciones siempre cambian, tenemos que tener una forma de organizar y controlar los cambios: para ello hay un CONTROL DE CAMBIO que veremos cómo usarlo en la siguiente sección.

En resumen, tenemos que una Iniciativa la podemos dividir en muchas Etapas y dentro de cada etapa ejecutamos Tareas. Para controlar los cambios a las planificaciones de las etapas (y por ende de la iniciativa), tenemos controles de cambio. En JIRA esta jerarquía se implementa usando la funcionalidad de links.

Lo que hacemos ahora es configurar en JIRA todos estos tipos de issues, lo que implica definir atributos específicos para cada uno de ellos. Uno de estos atributos dicen relación con el manejo de las fechas, ya que un proyecto es una serie de actividades acotadas en el tiempo, es obvio que necesitamos manejar fechas. Aquí podemos definir dos tipos de fechas: de plan y real. O sea, para cada tipo de issue tenemos fecha de inicio y termino planificada y de inicio y termino real.

Usando controles de flujo de JIRA podemos restringir quién y cuándo se actualizan estas fechas. Por ejemplo, solo el JP puede cambiar las fechas de plan de las etapas de una iniciativa, pero no las reales. Estas últimas se actualizan automáticamente cuando damos inicio a la primera tarea en una etapa (inicio) y cuando cerramos la etapa (termino).

Otra característica de la configuración es que debe hacer roll-up o totalizar desde las tareas hacia la etapa y desde estas a la iniciativa los datos de planificación, reales  y estimación.

El schema de workflow

Las posibilidades de customizacion de flujos que ofrece JIRA son muchas, más aun si se usan algunos plugins como por ejemplo Jira Workflow Toolbox. En este modelo que estamos construyendo se estiran al máximo estas posibilidades de customización, ya que hay una serie de acciones que queremos que sean controladas y automáticas.

En el caso de las Iniciativas el flujo va a reflejar la metodología o paradigma que explícita (o implícitamente) siga la organización o grupo para ejecutar sus proyectos. Si usamos un modelo tradicional de “waterfall”, las iniciativas van a moverse por análisis, diseño, construcción, pruebas y entrega. Si usamos un modelo tipo RUP, estas se mueven en fases de Inicio, Elaboración, Construcción y Transición.

Los paradigmas agile que están de moda hoy en día se ubican dentro del contexto de una etapa en esta jerarquía, ya que estos paradigmas privilegian iteraciones (o sprints) de corta duración (2-3 semanas), al final de la cual se pueden mostrar entregables concretos. Lo que nos interesa en este modelo es controlar el desarrollo de la Iniciativa y sus Etapas, las tareas que incluye un sprint se pueden gestionar usando tableros disponibles en JIRA SOFTWARE o mediante simples filtros JQL.

En el caso de las Etapas el flujo es simple: una etapa esta abierta mientras creamos y planificamos tareas, en progreso apenas comenzamos a registrar horas en alguna tarea y finalmente cerrada cuando el JP así lo establece (previamente todas las tareas tienen que estar completadas o cerradas). Pero como en la realidad las estimaciones y planificaciones cambian, hay un estado adicional, en control de cambio, que refleja el hecho de que estamos modificando las estimaciones de una (o mas) etapa mediante un control de cambio. Sólo mientras la etapa se encuentre en este estado se puede modificar sus atributos de planificación como fecha planificada de inicio/término o la estimación de horas: para ello el control de cambio debe estar en estado aprobado, de lo contrario no se permite modificar las estimaciones de la etapa, y su aprobación está restringida sólo a un grupo de personas.

El flujo de una Etapa de un proyecto es el siguiente:

Etapas

Para las Tarea el flujo refleja la manera específica de trabajar que tiene cada grupo. En su versión mas genérica el flujo de una tarea está ya sea en progreso cuando una o más personas comienzan a registrar horas o cerrado, cuando se alcanzó el objetivo de la tarea. Pero una tarea de tipo programación puede incluir estados de auditoria o revisión de código, por ejemplo. O una tarea de corrección de defectos puede tener estados de aprobación previos a dar por corregido el defecto. Esta es la gran ventaja de usar un enfoque de configuración versus recurrir a plugins: tener control completo de cómo deseamos que sea nuestro proceso en JIRA y no estar sujetos a restricciones.

Un ejemplo real

El siguiente es un ejemplo de cómo se visualiza una iniciativa del tipo mantencion evolutiva de aplicaciones, con todas sus etapas y fechas de plan/real de cada una:

Mantencion

Mientras que aquí podemos ver el estado de una etapa específica (planificación) y sus tareas:

Planificacion

Finalmente una vista resumen de un conjunto de mantenciones, que en JIRA se implementa como un tablero. Se muestra en la columna Status la etapa actual de cada mantencion, seguida de las fechas de plan y real y del porcentaje de avance de la etapa actual. La última columna advierte sobre la diferencia en días habiles de cada mantencion (fecha actual − fecha planificada de termino para la etapa actual):

Tablero

Beneficios del enfoque

Al usar un enfoque de customización, tenemos un control total de la forma en que queremos administrar los proyectos. Algunos de los beneficios más relevantes son:

  • Los usuarios que ejecutan las actividades del proyecto solo se preocupan de abrir y cerrar tareas. Las fechas de inicio y término real de las etapas se ajustan automáticamente.
  • Las planificaciones que hacen los gestores solo se pueden rehacer mediante un control de cambio asociado al proyecto, lo que implica un nivel de supervisión. Del mismo modo las etapas que ya se han cerrado solo se pueden reabrir si existe un control de cambio aprobado.
  • Permitir que ciertas etapas sean concurrentes mientras que otras sean secuenciales. Por ejemplo, tener en paralelo actividades de diseño, construcción y pruebas, mientras que la liberación a ambientes mas restringidos se debe hacer de manera secuencial.
  • Definir qué tipos de tareas son válidas para cada etapa.
  • Relacionar el proceso de desarrollo con el de definición del requerimiento, de manera que cuando el primero avanza en su flujo, el segundo se actualiza automáticamente de acuerdo a ciertas reglas que relacionan los estados del primero con los del segundo. De esta manera el grupo que gestiona requerimientos tiene una visión de lo que ocurre con estos cuando entran a “la fabrica”.

Conclusión

Hemos delineado cómo usar las facilidades de configuración de JIRA para definir un proceso de administración de proyecto. Este modelo ha sido implementado en escenarios reales y ha permitido facilitar el trabajo de los grupos de desarrollo y QA y de los que controlan la marcha de los proyectos. Para los primeros ofrece una forma estándar para el manejo de sus actividades diarias mientras que para los segundos entrega la información y mecanismos de control que permiten que los proyectos no se salgan de cauce por no seguir un proceso regular.

En suma SI, es posible administrar proyectos con JIRA, pero luego de un proceso de configuración que puede ser simple o complejo dependiendo de las expectativas e intereses de cada grupo involucrado.

Artículos relacionados: Project Management con Confluence y Integración de JIRA y Confluence para Gestion de Proyectos.

Usando Jira para actualizar datos

0 comments. Top.

concurrencyUn problema recurrente dice relación con actualizar una base de datos cuando las personas que saben qué datos hay que modificar están repartidas en diferentes áreas. La idea es generar una consulta y que todos los involucrados tengan la oportunidad de hacer los cambios de manera transparente, sin que unos “pisen” los cambios de otros.

Este escenario es ideal para JIRA, ya que la principal funcionalidad que ofrece es la gestión de flujos de trabajo o workflows. Entonces podemos crear un flujo para administrar las consultas y respuestas.

Pero cómo accedemos y modificamos la base de datos? Aquí recurrimos a Table Grid Editor.

Este es un plugin de JIRA que permite desplegar datos en grillas asociadas a los issues de JIRA. En nuestro escenario, la data proviene de la base de datos que es necesario mantener actualizada por varias áreas. Recordemos que un plugin (o addon) es una extensión de la funcionalidad base de JIRA.

Beneficios de usar Table Grid Editor con JIRA

Al usar Table Grid Editor podemos relacionar un issue en JIRA con los datos contenidos en una base de datos RDBMS estándar. Y como los issues siguen un flujo, tenemos la solución al problema de manejar la actualización de datos usando JIRA.

Para mostrar una aplicacion concreta de esta integración, hice este video que muestra una experiencia real relacionada con la mantención del uso de posiciones (o puertos) de racks de comunicaciones:

Aquí los datos de los racks y la ocupación de sus puertos están almacenados en una base de datos central. Las diferentes áreas operacionales que modifican la ocupación de los puertos de los racks usan un flujo JIRA para actualizar la base de datos. Esto permite controlar aspectos como notificaciones, definición de tiempos de respuesta, escalamiento, etc. Para leer la base de datos se usa un customfield aportado por el plugin, donde se especifica cómo seleccionar la información de ocupación de los puertos de un rack especifico. Este customfield esta asociado a la consulta, que en JIRA se representa como un tipo de issue. Los involucrados de cada area hacen las modificaciones directamente en la grilla.

Cuando todos han hecho los cambios necesarios, se graban de vuelta los datos de la grilla a la base de datos. Para esto se aprovecha la API Java de JIRA y se crean rutinas en lenguaje groovy que realizan la grabación de los cambios.

Este enfoque permite además aprovechar otras ventajas de JIRA como filtros y gadgets para visualizar las consultas (y sus respuestas) de acuerdo al perfil de cada usuario.

Otros usos posibles de Table Grid Editor son:

  • Generación y envío de cotizaciones, donde cada línea de la grilla es un producto cotizado (que guarda en una BD) y las columnas son cantidad, precio unitario, descuentos, totales, etc.
  • Mantención de equipos, donde cada línea de la grilla es un equipo que se guarda en una BD.
  • Mantención de clientes, donde cada línea de la grilla es un cliente que se guarda en una BD.

 

Atlassian anuncia JIRA Service Desk 2.0

0 comments. Top.

Atlassian anuncio en su conferencia anual Summit 2014, una nueva versión de su portal de clientes para mesa de ayuda y atención de pedidos, Service Desk 2.0. Este producto esta orientado a atender requerimientos de soporte de clientes externos a una organización de desarrollo y soporte técnico.

La principal novedad de esta nueva versión es el cambio en el modelo de licenciamiento: ahora los clientes externos ya no necesitan licencia. Solo los agentes encargados de atender los pedidos necesitan una licencia, tanto de Service Desk como de Jira.

Service Desk es un add-on de JIRA, esto significa que es necesario tener Jira para poder usar Service Desk. En esta nueva versión se introduce el concepto de colaborador, que es un usuario Jira que puede participar de un pedido haciendo comentarios que son invisibles a los clientes. Típicamente este puede ser un programador o un asistente de soporte.

Service Desk: portal del usuario

El escenario típico de deployment de Service Desk es una organización de desarrollo y soporte de aplicaciones y plataforma (soporte técnico) que debe atender a un gran numero de usuarios, donde los agentes juegan un rol facilitador entre ambos. Esto es posible hacerlo enteramente con Jira, pero en este caso los usuarios externos deberían contar con una licencia. Con Service Desk, los usuarios externos ya no requieren licencia para reportar pedidos, con la ventaja de contar con su mesa de ayuda donde están todos los pedidos que ha ingresado.

Otra novedad de esta versión es que los usuarios externos pueden usar el email para ingresar pedidos y recibir actualizaciones sobre sus pedidos.

Atlassian anuncia JIRA DataCenter

0 comments. Top.

Atlassian anuncio la semana pasada la disponibilidad de una nueva versión de JIRA, la 6.3, que viene con la novedad de soportar una configuración de High Availability (HA). Para esto Jira ofrece una opción de deployment que permite implementar un cluster activo-activo de instancias Jira.

stack

Esta opción esta orientada a configuraciones con mas de 1.000 usuarios activos.

Jira DataCenter complementa las opciones de deployment Cloud y Server de Jira.

Modos de deployment para Jira

Atlassian libera JIRA 6.2

0 comments. Top.

Atlassian acaba de anunciar la liberación de la ultima versión de JIRA, la 6.2. La novedad mas importante de este release es la “Visualización del Desarrollo”  a través de una integración entre Jira y el mundo GIT para la gestión del código asociado a un issue:

tis_jira_hero

Las integraciones incluidas son: Bamboo (un producto Atlassian para build management de código), Bitbucket o Github/Stash (repositorios GIT: los primeros están en la nube y el segundo detrás del firewall, o sea, se debe instalar para usar). El siguiente video muestra las funciones asociadas a esta visualización:

Otra novedad de este release es la total migración del antiguo al nuevo workflow designer:

1000x650-enhanced_workflow

y una nueva (y muy necesaria) vista de auditoría, que permite conocer quien efectuó cambios a la configuración de un schema Jira:

1000x650-auditing

Mas detalles de esta nueva versión de JIRA en los Release Notes.

Nuevos anuncios de Atlassian

0 comments. Top.

Coincidente con la realización del Atlassian Summit 2013, Atlassian anunció importantes novedades sobre nuevas versiones y productos.

Nuevos productos:

  • Jira Service Desk es un nuevo add-on de JIRA para los equipos de soporte y mesa de ayuda que gestiona los tiempos de SLAs de cada cliente.

Jira Service Desk

  • Confluence Questions es un nuevo add-on para Confluence que permite crear una plataforma de Preguntas y Respuestas para que la empresa pueda mantener su propio repositorio de consultas y expertos.

Confluence Questions

Confluence Questions

Junto con estos nuevos productos se presentaron nuevas versiones de Jira y Confluence:

Jira 6.1

La principal novedad de esta nueva versión de Jira es el rediseño para el editor de workflows, que ahora es 100% compatible con HTML5 lo que permite que lo que se ve es lo mismo que lo que se diseña:

Jira 6.1 nuevo editor de Workflow

Confluence 5.4

En esta nueva versión de Confluence se incluye una plantilla de espacio para crear y administrar una KnowledgeBase corporativa:

KB en Confluence

KB en Confluence

Todos estos nuevos productos y versiones ya se encuentran disponibles en Atlassian.

Atlassian lanza Jira 6.0

0 comments. Top.

Atlassian acaba de lanzar la ultima versión de Jira, la 6.0. El principal cambio que introduce esta versión es el rediseño de la interfaz de usuario:

Interfaz de usuario Jira 6.0

Otra novedad es la vista de detalle del Issue Navigator, con lo cual es posible en una misma ventana ver y editar un ítem de una lista de issues:

Vista de detalle issues Jira 6.0

La interfaz móvil también fue optimizada en esta nueva versión:

Interfaz movil Jira 6.0

Junto al rediseño de la interfaz de usuario, Jira 6.0 introduce una serie de mejoras que facilitan el uso de los usuarios y la labor de administración de la aplicacion. Atlassian también anuncio el cambio de nombre de Greenhopper, el plugin de Jira que agrega funcionalidades orientadas a equipos ágiles con Scrum o Kanban, pasándose a llamar ahora Jira Agil.

Este video muestra las nuevas caracteristicas de la versión Jira 6.0:

Planificacion y Gestion de proyectos con Tempo

0 comments. Top.

Tempo es un popular plugin de Jira para planificar y administrar el tiempo (planning/time tracking). Si bien Jira incluye funcionalidades para la planificación e ingreso del tiempo trabajado en un issue, estas son simples y se limitan a registrar el tiempo estimado para cerrar un issue e ingresar worklogs (registro de horas trabajadas en un determinado issue, como una tarea o un defecto). Con estos dos datos se podría gestionar el factor tiempo de un proyecto de alguna manera. Sin embargo, en la práctica es necesario contar con una serie de funciones mas avanzadas tanto para la planificación como la ejecución de un proyecto y es aquí entonces donde entra a jugar Tempo.

Si usamos el PMBOK como referencia, Tempo da soporte a los grupos de procesos de: planificación, ejecución, monitoreo y control.

Planificación

Aunque muchas veces no se hace formalmente, en todo ciclo de proyecto es necesario contemplar la planificación, de manera de poder responder a la pregunta: cuánto tiempo se espera que una persona trabaje en un proyecto en un determinado periodo? Esto permite establecer una lineabase para comparar la ejecución del proyecto versus un presupuesto.

Con Tempo, la planificación se realiza asignando tiempo (generalmente de personas, pero también pueden ser otro tipo de recursos como salas o equipos por ejemplo) a nivel de issue, proyecto, componente o versión (estos dos últimos son conceptos  Jira que permiten descomponer un proyecto desde una perspectiva de entregables y de tiempo, respectivamente). En otras palabras, en Tempo hay hasta 4 niveles de detalle (el mas fino es el issue y el mas grueso el proyecto) y que se pueden manejar de manera independiente dependiendo de los requerimientos de monitoreo y control que se establezcan.

El tiempo asignado se puede visualizar mediante reportes, planillas de tiempo (timesheet), gadgets que se ubican en tableros (dashboards) y en el panel People de un proyecto Jira.

La siguiente figura muestra la interfaz de planilla de tiempo para la planificación de un recurso (hacer click para ver completa):

John Steel tiene para la semana del 3 al 7 Septiembre planificado:

  • 15 horas para el proyecto Aka Control System
  • 8 horas para una actividad interna (Employee issues)
  • 6 horas para el proyecto Paradigm Cloud
  • 4 horas para el proyecto Wikiea Cloud

Adicionalmente, la hoja muestra que en el proyecto Custom Development ha trabajado 4 horas en el issue 14, Sprint Planning and Review. En total hay 33 horas planificadas distribuidas tal como muestra la ultima fila.

Tempo permite definir un workflow de aprobación de la planificación, de manera que un supervisor revise la planificación ingresada por una persona, aprobándola o rechazándola:

Ejecucion

En Tempo la ejecución se lleva mediante el ingreso de un worklog o registro de trabajo. En la siguiente figura se visualiza una planilla de tiempo para un periodo (1 al 31 de Enero) de un Team (o conjunto de personas que se administran como una unidad dentro de Tempo):

Lo indicado en verde es tiempo efectivo registrado mediante worklogs, lo que esta en rojo destaca que el tiempo imputado es menor al comprometido para el periodo que corresponda (8 hrs. al día por ejemplo). La planilla muestra también las horas planificadas, si existen (destacadas en color rosado).

Al igual que en el caso de la planificación, el registro de la ejecución de horas trabajadas por una persona en un periodo puede estar sujeto a un workflow de aprobación de manera que un supervisor revise el detalle del registro y apruebe o rechace la planilla completa.

Monitoreo y Control

Tempo ofrece reportes y gadgets para el monitoreo y control del uso del tiempo en los proyectos.

La figura muestra un ejemplo de un reporte de un recurso en un periodo de tiempo (1 al 31 Enero), que aun no ha sido enviado para aprobación (el estado es  Pending User) desglosado por proyecto , versión/componente , issue y el worklog respectivo en horas:

 

 

 

 

 

 

Esta otra figura muestra un gadget con un desglose de horas trabajadas y facturadas por cuenta. Tempo permite definir cuentas, categorías (desarrollo, soporte, mantencion, etc.) y clientes (internos o externos), de manera de imputar el tiempo de los recursos  a un coste interno o externo (eventualmente facturable). Esto es especialmente útil para empresas que venden horas de recursos a otras en base a proyectos (desarrollo, mantencion).

 

 

 

 

 

 

En resumen, Tempo es un plugin de Jira necesario para aquellas organizaciones donde el control del uso del tiempo de sus recursos incide de manera determinante en la gestión de sus proyectos, en particular aquellas que venden servicios de programación y soporte.

Nueva version de Jira

0 comments. Top.

Atlassian acaba de anunciar el lanzamiento de la versión 5.2 de Jira.

Cuales son las novedades de esta nueva versión?

Webhooks

Para facilitar la integración de Jira con terceros, especialmente aplicaciones basadas en la nube, Jira 5.2 introduce el concepto de webhook, que permiten gatillar una acción en la forma de URL a otra aplicacion (preparada para interpretar la notificación). Por ejemplo, cada vez que se cierra una incidencia se puede notificar por SMS a la persona que lo registró mediante el servicio de mensajería en nube que ofrece Twilio. Hay una gran cantidad de aplicaciones en nube que se pueden integrar a Jira mediante webhooks, disponibles a través de Zapier. Por supuesto también se pueden usar webhooks para integrar aplicaciones propias que expongan servicios vía alguna API de web, como REST por ejemplo.

Mas información sobre webhooks aquí.

Issue Navigator

Una de las actividades mas comunes en Jira es buscar incidencias (o issues): las asignadas a mi, las reportadas por alguien, las que se deben cerrar hoy, etc.

Jira 5.2 incorpora mejoras a la funcionalidad e interfaz del Issue Navigator que se utiliza para definir y realizar tales búsquedas:

También el organizar y compartir filtros (que son búsquedas del issue navigator guardadas) viene mejorada en esta versión:

Usted puede descargar Jira 5.2 usando este enlace.

 

Testing con Bonfire

0 comments. Top.

Bonfire es un plugin para Jira que permite documentar la ejecución de pruebas dentro del contexto de una sesion de prueba. Al estar integrado a Jira, es posible ubicar estas sesiones dentro de un contexto. Una secuencia típica es identificar requerimientos que requieren la ejecución de pruebas formales como parte de su elaboración, ejecutar las pruebas e identificar issues – como defectos o mejoras – a partir de los resultados de la ejecución de las pruebas. Una sesión de prueba puede responder a una planificación, a través de casos de prueba, en la cual contamos con una secuencia definida de pasos y resultados esperados, o puede corresponder a una actividad no planificada o test exploratorio, durante la cual el tester se dedica a explorar sin un script previo la aplicacion buscando descubrir resultados no esperados.

(hacer click para ver completa)

En este ejemplo vemos como una nueva funcionalidad (“Requerir autentificación de usuarios vía pantalla de login”) tiene asociadas varias sesiones de prueba que buscan validar el cumplimiento de la funcionalidad:

Bonfire permite documentar una sesión de prueba mediante una secuencia de actividades (activity stream) donde el tester puede agregar la información de la prueba ejecutada, datos empleados, crear issues (como defectos por ejemplo) y asociarlos a la sesión. Una característica importante de las sesiones de prueba es que pueden ser compartidas con otros testers, de manera que ellos participen en la ejecución y documentación de los resultados. Una sesión de prueba tiene una fecha de inicio y de cierre, pero el tester puede suspender y retomar su ejecución, ingresando en cada ocasión el tiempo total invertido:

Bonfire provee extensiones para browsers como Firefox y Chrome que facilitan la relación entre el tester, la aplicación y Bonfire. Esto permite la captura y anotación de pantallas para documentar una sesión.

En resumen, las sesiones de prueba son un mecanismo ágil y simple para ampliar la funcionalidad de Jira a los testers y al área QA dentro del ciclo de vida de una aplicación.

Atlassian anuncia Jira 5.1

0 comments. Top.

Atlassian ha anunciado la liberación de la más nueva versión de Jira: la 5.1. Entre las nuevas caracteristicas de esta versión destacan:

a) Edición directa de los atributos de un issue en la misma página, lo que evita page reloads cada vez que se requiera modificar un atributo de un issue.

 

b) Mejoras en el desempeño para manejar miles de issues.

c) Issue Collector, que permite capturar defectos o comentarios desde cualquier aplicacion web y registrarlos en Jira.


d) Mejoras en la interfaz de administración.

Ceptah Bridge: uniendo Project y Jira

0 comments. Top.

Muchas personas se sienten cómodas con Microsoft Project para planificar y gestionar el avance de los proyectos. Por otro lado, muchas organizaciones optan por la agilidad de Jira para la gestión de tareas, ya sea directamente o a través de Greenhopper. Cómo unir ambas herramientas de forma efectiva de manera de potenciar sus ventajas?

Ceptah Bridge es un plugin para Project que permite realizar esta unión. Al instalarse se agrega un Menú a Project que permite definir reglas de sincronización entre un proyecto Project y un proyecto Jira. Estas reglas definen un mapping de campos entre ambas herramientas. Una vez definidas, se pueden sincronizar ambos proyectos. La dirección de sincronización esta determinada  por la modalidad de gestión de proyectos usada: esto es, en cual repositorio (Project, Jira o ambos) se pueden crear tareas y modificar sus parámetros claves como fecha término, estimación de esfuerzo, reporte de avance, etc.

La siguiente figura (hacer click para ver completa) muestra el esquema de sincronización que se establece a través de Ceptah Bridge:

Un caso de uso típico de Project + Ceptah Bridge es:

  1. JP crea una planificación y establece una linea base en Project.
  2. JP crea un proyecto en Jira a partir de la linea base usando Project + Ceptah Bridge. Esto crea una estructura de tareas en Jira a partir de las reglas de sincronización definidas para el proyecto.
  3. Los recursos asignados a las tareas establecen estimaciones más precisas del esfuerzo y fecha de término en Jira.
  4. JP actualiza la planificación en Project + Ceptah Bridge realizando una sincronización.
  5. JP eventualmente modifica la planificación (y la linea base) y actualiza las tareas en Jira con Project + Ceptah Bridge efectuando una sincronización.
  6. Los recursos asignados actualizan el avance de sus tareas en Jira, modificando su estado dentro del flujo de trabajo que se haya definido y registrando la cantidad de trabajo gastado en cada una. Si es necesario pueden modificar la fecha de término.
  7. JP transfiere el avance real usando Project + Ceptah Bridge realizando una sincronización, con una periodicidad definida (diaria o semanal). También puede importar nuevas (sub)tareas que hayan sido creadas directamente por los asignados en Jira.
  8. JP compara el estado actual del proyecto contra la linea base establecida en 1 o 5. A partir de esto puede decidir mantener o generar una nueva la linea base. El procedimiento se repite hasta que se hayan cerrado todas las tareas definidas para el proyecto.

Ceptah Bridge se instala en los PCs de los jefes de proyecto que usan Project.

Con Ceptah Bridge se potencian tanto Project como Jira, ya que permite complementar las ventajas que ofrecen cada una: flujos de trabajo, notificaciones y tableros en el caso de Jira y gestión de tiempo, recursos y costos en el caso de Project.

Structure para Jira

0 comments. Top.

Jira no implementa el concepto de tareas anidadas, muy familiar para los que usan Gantts en MS Project (en realidad se soporta pero hasta un solo nivel, o sea, podemos tener un issue que se divide en n subtareas). Esto no es por que Atlassian no lo quiera hacer: hay diferencias conceptuales sobre cómo administrar los issues de un proyecto que explican esta “falencia”.

Para aquellos que necesitan contar con una organización de los issues en una jerarquía de muchos niveles, el plugin Structure es la solución.

El plugin permite crear una o más estructuras y dentro de cada una se pueden organizar una lista de issues en forma jerárquica, donde los issues de la lista pueden provenir de uno o más proyectos Jira. Así por ejemplo podemos tener una estructura que toma una lista de requerimientos y bajo cada uno crear una jerarquía de tareas, donde algunas son hitos y otras más anidadas son tareas actuales. Podemos tener muchas estructuras, cada una representando una vista diferente de un grupo de issues (por ejemplo todos los issues que pertenezcan a una misma iteración).

Definida la estructura o jerarquía, Structure se encarga de hacer muchas cosas automáticamente, como por ejemplo agregar los tiempos de trabajo asignados a las tareas de un nivel y traspasarlo al issue padre, y así recursivamente hasta llevar al tope de la jerarquía. El plugin ofrece otras funcionalidades muy útiles, como sincronizar los estados de los issues padre en función de los estados de los issues hijos (por ejemplo si todas las tareas o issues a un nivel están cerradas, la tarea o issue que las contiene debe estar cerrada también) o exportar la estructura formateada a Excel.

Un sitio en vivo para probar y usar estructuras se encuentra aqui.

GreenHopper: Rapid Boards

0 comments. Top.

GreenHopper es un plugin que convierte a Jira en una herramientas ágil de proyectos, orientada a equipos que funcionan bajo paradigmas tipo Scrum o Kanban.

En Marzo pasado Atlassian lanzó la versión 5.9 de GreenHopper, la que incorpora mejoras significativas en la interfaz de usuario, Rapid Boards y nuevos Reportes.

En este articulo revisaremos lo referente a los Rapid Boards, dejando para otro lo relativo a los nuevos reportes.

Rapid Boards

Rapid Boards es una manera ágil y flexible de gestionar y reportar el trabajo en estado de ejecución (en inglés Work In Progress, WIP).

En esta versión se introduce una nueva vista llamada PLAN en la que podemos priorizar el backlog (conjunto de issues listos para comenzar a trabajar), planificar el siguiente sprint (nombre dado a una iteración en jerga Scrum), o tener una vista rápida de un issue (nota: en Jira un issue es un termino genérico que representa una incidencia, pedido de cambio, tarea, etc.).

Otra novedad con los RapidBoards es que se pueden crear tantos como se requieran, cada uno con su propia combinación de proyectos (o sea los issues pueden provenir de diferentes proyectos Jira), columnas (estados) y filtros.

En la figura (hacer click para visualizarla completa) se aprecia lo siguiente:

  • Existe un sprint en curso (Sprint 3). Actualmente solo se puede planificar una iteración y tener otra en curso, en las próximas versiones de GH se podrán tener múltiples iteraciones en planificación y/o curso.
  • Para definir la cantidad de issues a incluir dentro de la iteración que se está planificando, se tiene un Sprint Marker móvil. Dentro de este grupo se puede cambiar la prioridad arrastrando hacia la parte superior los que sean más prioritarios.
  • En el lado derecho hay una vista que muestra detalles de un issue seleccionado. En particular se nota como se pueden crear subtareas.

La vista WORK por otro lado, permite visualizar donde se encuentra un issue dentro de un flujo predefinido en Jira (workflow).

En la figura se aprecia lo siguiente:

  • Las columnas representan los nombres de los estados del workflow.
  • Al arrastrar un issue entre columnas se cambia su estado.
  • Los issues están ubicados en el tablero según su ranking de importancia asignado en la planificación (para el caso Scrum) o por algún criterio de criticidad (caso Kanban). Cabe hacer notar aquí que el paradigma Kanban se enfoca primordialmente en administrar el WIP. Se pueden definir restricciones que alertan cuando se está llegando al limite del WIP definido para un estado.

En la figura se muestra un ejemplo del tablero Work y el flujo de issues entre estados. En el estado In Progress existe una restricción de 12 issues (destacada en rojo), ya que se ha definido este número como la capacidad máxima del proyecto. El poder determinar este número es uno de los objetivos de la metodología Kanban y que obviamente depende de las circunstancias de cada proyecto, pero en general la idea es minimizar el tiempo de ciclo promedio de un issue, o sea, el tiempo total de trabajo dedicado al issue (en el ejemplo de la figura, el tiempo que este permanece en el estado In Progress).

Jira 5.1 EAP disponible

0 comments. Top.

Atlassian ha anunciado la disponibilidad de una versión EAP (Early Access Program) de Jira, la 5.1

Un anticipo de lo nuevo que traerá esta versión se encuentra en esta pagina.

10 Claves para implementar Jira

0 comments. Top.

logoJIRAPNGJIRA es una popular plataforma para administrar diferentes tipos de issues, término genérico que JIRA da a conceptos como incidencias, pedidos de cambio, tareas, requerimientos, etc. Estos issues tienen un ciclo de vida dado por un flujo, que es la funcionalidad principal de JIRA.

En base a mi experiencia en la implementación de JIRA para diferentes usos, a continuación presentamos una lista con 10 recomendaciones:

  1. Conocer lo que se tiene. JIRA no es un software de PPM. En JIRA un proyecto es solo un contexto para gestionar issues. Dicho esto, es posible implementar una estructura de issues  – Work Breakdown Structure o WBS – que permita la gestión de iniciativas que generalmente denominamos proyectos. Ver Configuracion de JIRA para Administrar Proyectos.
  2. Documentar los requerimientos de la implementación JIRA – o Modelo de Uso – donde se defina con precisión: los tipos de proyectos, estructura de issues y sus respectivos flujos (con estados y transiciones). Como cualquier proyecto de desarrollo, la implementación JIRA requiere contar con requerimientos claros.
  3. Definir inicialmente flujos simples. Posteriormente estos se pueden refinar mediante validaciones, condiciones y post-funciones mas complejas y sofisticadas.
  4. En lo posible integrar JIRA con Confluence, donde este último se encarga de la administración de documentos y la organización del contexto del proyecto (ya que JIRA no ofrece esta capacidad de forma nativa). Ver: Pro­ject Mana­ge­ment con Confluence.
  5. Maximizar el uso del lenguaje de consulta o query JQL (Jira Query Language), que es una de las características mas potentes que ofrece JIRA para gestionar issues. El resultado de estos queries se pueden desplegar en gadgets (tableros visuales) o recibir por email si se cuenta con suscripciones habilitadas.
  6. La funcionalidad de JIRA puede ampliarse considerablemente recurriendo a extensiones o plugins. Por ello conviene identificar los plugins que se necesiten para cumplir con los requerimientos de la implementación, ya que hay una gran cantidad disponible y que abarcan una amplia gama de funcionalidades. No obstante, hay un grupo de 2-3 plugins que son esenciales para implementaciones avanzadas. Ver: Atlassian Marketplace.
  7. Recurrir a la API Java/REST de JIRA para satisfacer requerimientos complejos de validación y/o integración con otras aplicaciones. Esto implica programar la API para implementar acciones especificas asociadas a los cambios de estado en un flujo.
  8. Documentar los schemas JIRA a medida que se van implementando y modificando. Esta documentación debe formar parte del modelo de uso mencionado anteriormente.
  9. Documentar Guías Rápidas para que cada grupo de usuarios sepa lo que necesita para usar efectivamente la configuración de JIRA.
  10. Restringir y cuidar el acceso dado por el rol de administrador. De lo contrario la instancia se va a desordenar al no haber control de cambios sobre los schemas y la creación de proyectos. Esto se complementa con la habilitación de un proyecto JIRA para organizar todos los pedidos de cambio de la instancia, desde la habilitación de usuarios/grupos hasta los cambios a los schemas.

Finalmente es importante indicar que JIRA ofrece 3 modos de deployment: Cloud, Server y Data Center. La mayor parte de las opciones de configuración están abiertas para los dos últimos modos principalmente.


Video: Tres aproximaciones a PPM con JIRA

Atlassian lanza Jira 5.0

0 comments. Top.

A comienzos de Marzo Atlassian lanzó la versión 5.0 de Jira. Entre las principales funcionalidades que incluye esta versión destacan:

  • Introducción de API remota basada en REST, para hacer Jira mas integrable con otras aplicaciones
  • Mejoras al lenguaje JQL para hacer consultas sobre cambios ocurridos en el pasado a un issue (como sus cambios de estado por ejemplo)
  • Mejores funciones para la facilitar la comunicación del team.

Para conocer mas detalles de esta nueva versión de Jira, visite esta pagina.