AGILE

 

Atlassian lanza GreenHopper 6

0 comments. Top.

Atlassian acaba de lanzar la ultima versión de Greenhopper, el plugin para Jira orientado al manejo ágil de proyectos. En el último año Atlassian ha introducido importantes mejoras a Greenhopper, sobre todo en la interfaz de usuario. La versión 6 continua con esta tendencia y agrega nuevos reportes.

Las principales caracteristicas de Greenhopper 6 se pueden resumir en:

Tableros Rápidos

En un solo tablero, un team ágil puede planificar, ejecutar y hacer seguimiento de una iteración (o sprint en jerga Scrum, ver este post). La novedad es que en esta versión se pueden planificar más de un sprint futuro :

(hacer click en la imagen para ver completa)

Nuevos Reportes

La velocidad de un team representa la capacidad del grupo para completar las tareas asignadas durante la ejecución de un sprint. Mientras más completa, más velocidad tiene. Grenhopper 6 ofrece un reporte que muestra la velocidad del team exhibida en sprints anteriores así como un reporte que permite explicar las desviaciones en la velocidad del sprint actual producto de nuevas tareas que fueron introducidas durante la iteración y que no estaban comprometidas al inicio:

 

Este video muestra una visión general de las funcionalidades introducidas en Greenhopper 6.

 

Agil con Kanban

0 comments. Top.

Este es el segundo artículo de una serie des­ti­nada a cono­cer los para­dig­mas ágiles para la ges­tión de pro­yec­tos, en par­ti­cu­lar Scrum y Kanban.

Qué es Kanban?

Kanban está basado en una idea muy simple: la cantidad de cosas en la que actualmente estamos trabajando debe estar limitada y cualquier otro nuevo tema podría comenzar recién cuando uno existente sea entregado. El kanban (o señal visual, que es su traducción del japonés) indica que una nueva actividad puede ser abordada, ya que la cantidad actualmente en desarrollo es menor al límite comprometido.  Esto puede no sonar como una idea muy revolucionaria, pero en realidad lo es! El desarrollo de la industria manufacturera de Japón tiene uno de sus pilares en la aplicación de técnicas basadas en este mismo principio: de hecho Kanban fue desarrollado por Toyota para eliminar el desperdicio en la cadena de producción (i.e. tiempos de espera + tiempo para rehacer partes ya terminadas).

Kanban no constituye por sí una metodología de proyectos o de desarrollo. En realidad lo podemos ver como un medio para introducir profundos cambios en un equipo u organización. Para ello es necesario tener claramente definido o “mapeado” una cadena de proceso o flujo de trabajo para luego introducir un concepto clave: el Work In Progress (WIP) o sea, las tareas en las que actualmente estamos trabajando, lo que esta en curso. Kanban limita el WIP para cada fase o etapa de la cadena. El flujo de trabajo comienza cuando a lo largo de la cadena se dan señales (kanban) para que los ítems se muevan entre etapas. Los ítems pueden ser tareas, requerimientos (user stories), defectos, etc.

En este escenario, cualquier ítem que esté bloqueado por algún motivo en alguna etapa de la cadena va a tender a relentizar la cadena completa. Si hay muchos en esta situación, la cadena completa se paraliza. El grupo u organización se va a ver forzado a focalizarse en resolver el problema y restablecer el flujo: este es el cambio que estimula Kanban.

Tablero Kanban

En Kanban se utiliza un dashboard o tablero para visualizar lo que se está ejecutando en la cadena. La transparencia que esto conlleva es otro factor importante de cambio. En este tablero se descubren los cuellos de botella y colas de esperas, factores que afectan el desempeño en términos de la cantidad de trabajo producido y el tiempo de ciclo necesario (i.e. el tiempo total desde el inicio hasta el fin de la cadena). Así el equipo de trabajo y los interesados disponen de un medio para visualizar el resultado de sus acciones (o la falta de estas!), lo cual estimula y promueve la colaboración para encontrar e implementar mejoras en la cadena.

Tablero Kanban con 3 estados y WIP=5

Manejo de compromisos en Kanban

En Kanban se promueve el compromiso tardío tanto para prioritizar un nuevo ítem como para entregar los que están en desarrollo. Esto significa que se posterga lo más posible la decisión de tomar un nuevo ítem de trabajo con grupos o interesados ubicados más arriba en la cadena y asimismo la entrega de un ítem de trabajo a grupos o interesados ubicados más abajo en la cadena.

Por ejemplo, en una reunión del equipo Kanban con usuarios de más arriba en la cadena los primeros preguntarían: Desde nuestra última reunión se han abierto 3 vacantes. Nuestro tiempo de ciclo es de 4 semanas. Cuáles son las 3 cosas más importantes que quieren que entregaremos en 4 semanas más? La decisión sobre qué hacer se posterga hasta el momento en que el grupo tiene efectivamente la capacidad para comprometerse con una cantidad y fecha.

Al igual que una impresora que parte con la siguiente hoja solo cuando ha terminado de imprimir la actual, Kanban se configura estableciendo límites para el trabajo en curso (WIP) dentro de una cadena de proceso y haciendo que los eslabones de más abajo “tiren” a medida que tienen capacidad disponible dado su WIP.                      En Kanban no se empuja, se tira.

Scrum versus Kanban

En el artículo Agil con Scrum revisamos los atributos principales de Scrum. Cuáles son las diferencias que existen entre Scrum y Kanban?

Scrum Kanban
Prescribe 3 roles (master, team y owner). No prescribe roles
Prescribe iteraciones de largo fijo (de 2 a 4 semanas) durante la cual se realizan actividades de planificación, retrospectiva (mejora de proceso) y release. Flujo continuo. No prescribe iteraciones o cadencias.
Limita el WIP por cada iteración o sprint, pero no evita estar trabajando en muchas tareas simultáneamente con diferentes grados de avance en cada una. Limita el WIP para cada estado de la cadena, para todo lo que esté en curso. Promueve completar lo que se esta haciendo antes de aceptar un nuevo compromiso, lo que a la larga reduce el tiempo de ciclo.
El backlog de una iteración debe “caber” (i.e. completarse) en la misma iteración. Si un ítem es muy “grande” para una iteración, debe descomponerse en ítems más chicos. Un ítem puede abarcar un mes y otro un día. Mientras no se viole el limite WIP de la cadena, no se discrimina por tamaño.
No se permiten cambios a la planificación una vez iniciada la iteracion. Se permiten cambios a la planificación de lo que se va a hacer.
Prescribe efectuar estimaciones de las tareas para una iteracion. Se registra el desempeño efectivo, ya que el desempeño pasado es el mejor estimador del desempeño futuro.

Kanban = shock cultural?

Al igual que en el articulo Agil con Scrum, nos preguntamos: cuál es la viabilidad de adoptar un paradigma como Kanban dada la idiosincracia y cultura imperante en un grupo, organización o país? Para estimular la respuesta dejamos planteadas algunas preguntas:

  • Los usuarios de más arriba en la cadena están dispuestos a aceptar que los de más abajo le respondan que su WIP no les permite tomar un nuevo requerimiento?
  • La organización está dispuesta a aceptar la idea de que los compromisos se deben postergar en vez de anticipar?
  • La organización está dispuesta a abandonar elaborados esquemas de planificación del futuro (principalmente basados en Gantts), que quedan obsoletos por la dinámica del cambio, y reemplazarlos en su lugar por tableros y la transparencia que su uso conlleva?
  • La organización esta dispuesta a aceptar la idea que hacer pocas cosas bien (work smarter) es mejor que estar haciendo muchas a medias o mal (work harder)?

En el próximo articulo de esta serie veremos como enfrentar el principal reto para quien quiera introducir Kanban en un grupo: cómo manejar el WIP en la cadena.

Radiadores de informacion

0 comments. Top.

Una técnica muy usada en equipos ágiles es el uso de tableros de pared o Wallboards para promover la comunicación y transparencia de los proyectos de la organización. En estos tableros se puede visualizar información consolidada y relevante de los proyectos y se ubican en lugares públicos para que sean visibles a todos los interesados. Estos tableros están hechos de una manera tradicional, con una pizarra blanca donde se adjuntas tarjetas que representan tareas, o electrónica, aprovechando el bajo precio de los monitores tipo plasma o LCD widescreen. En este último caso se ha acuñado el término radiador de información como sinónimo de tablero.

Un ejemplo de un tablero electrónico aparece en este vídeo:

La siguiente imagen muestra un tablero tradicional, con pizarra y tarjetas que representan tareas, defectos, requerimientos o lo que se haya definido hacer en una etapa del proyecto (hacer click para verla a tamaño completo):

Atlassian patrocinó hace un tiempo un concurso para que distintas empresas mostraran los tipos de tableros que usan, qué tipo de información despliegan, con qué frecuencia y cómo los implementaron. Para conocer estos tableros visite este link.

Agil con Scrum

0 comments. Top.

Este es el primer artículo de una serie destinada a conocer los paradigmas ágiles para la gestión de proyectos, en particular Scrum y Kanban.

Que es Scrum?

Scrum es una ideología o paradigma de procesos ágil para manejar proyectos y que en una frase se podría definir así:

En vez de que muchas personas inviertan mucho tiempo construyendo algo grande, es preferible tener grupos pequeños que en poco tiempo produzcan algo y que se integren regularmente para obtener el todo.

 

Este paradigma prescribe que:

  • Organice equipos de trabajos crossfuncionales, autogestionables  y pequeños.
  • Desagregue un producto en una lista de entregables visibles y pequeños. Ordene la lista por prioridad y estime el esfuerzo relativo de cada ítem. Aborde primero los items de mayor prioridad (esto da origen al nombre scrum, que es la jugada de rugby donde un grupo de jugadores va tras la pelota).
  • Distribuya el tiempo en iteraciones fijas y acotadas (usualmente entre 1 a 4 semanas).
  • Optimice el plan de liberaciones en conjunto con el cliente redefiniendo las prioridades en base los resultados obtenidos al final de cada iteración.
  • Optimice el proceso mediante un analisis retrospectivo al final de cada iteracion.

Al estar catalogada como ágil, Scrum es liviana y menos prescriptiva (i.e. hay menos reglas que seguir) que otras, como RUP por ejemplo. Según el primer principio del Manifiesto Ágil:


Individuos e interacciones por sobre procesos y herramientas


Mientras que RUP prescribe demasiado (70+ artefactos, 30+ roles, etc.), por lo que debemos descartar todo lo que no necesitamos, con Scrum debemos agregar todo lo que falta. Scrum tampoco prescribe prácticas, como la programación de pares o el test unitario en el caso de XP (otro paradigma ágil muy popular). Dentro del rango de paradigmas, desde las más adaptativas (haga lo que sea como sea) hasta las mas prescriptivas (haga lo que esta documentado y documente lo que hace), Scrum se ubica en el rango adaptativo.

Esto tiene enormes implicancias a la hora de implementar Scrum: hay muchas preguntas del tipo cómo que Scrum no responde, por lo que debe adoptarse mediante ensayo, prueba y error hasta dar con una versión que sea compatible con la idiosincrasia de la organización.

Scrum es un paradigma minimalista (“menos es más”). Cuál es el conjunto mínimo de reglas que debemos respetar y adoptar si queremos afirmar realmente que nuestro proceso es (o se basa en) Scrum?

Roles

Scrum prescribe 3 roles: Product Owner, que define la visión y las prioridades, Team que implementa  y Scrum Master que lidera, facilita y remueve impedimentos.

Iteraciones Fijas

Scrum prescribe distribuir las actividades en iteraciones o sprints de largo fijo, de entre 1 a 4 semanas de duración. Dentro de estas se pueden identificar actividades de planificación, donde el team revisa el backlog (lista de ítems por implementar) y define cuáles son las que se van a abordar en la iteración, actividades de ejecución y finalmente actividades de cierre y retrospectiva de la iteración.

Limitar el backlog por iteracion

Scrum limita el backlog a una cantidad fija de ítems por iteracion . Un desafío importante de esta prescripción es qué unidad de medida usar para los ítems. Si los ítems son tareas, la unidad obvia son horas. En Scrum se ha acuñado el termino story points como una unidad de medida de las user stories (i.e. una característica funcional del producto), pero es demasiado ambigua (algunos teams han llegado a usar tallas de ropa, i.e., S, M, L, etc.).

Por otro lado, el product owner no puede alterar ni la cantidad de items comprometidas ni modificar las prioridades definidas al inicio de la iteracion, sin antes acordarlo con  el scrum master. Si se agregan items al backlog de la iteración se deben sacar otros equivalentes y desplazarlos a iteraciones futuras, ya que el principio scrum es que se debe limitar el backlog a una cantidad fija de ítems por iteración.

Para visualizar los items de una iteración y cómo se distribuyen dentro de esta, se usa un tablero. En el tablero se ubican tarjetas (usualmente de diferentes colores para representar user stories, tareas, defectos, etc.) que se distribuyen en columnas que representan los estados del flujo de la iteración; un flujo básico es lo que está pendiente de hacer, lo que se está haciendo y lo que  esta terminado. Cada team debe definir qué significa exactamente cada estado.

Teams crossfuncionales

Scrum prescribe que los team sean crossfuncionales, o sea, que incluyan todas las habilidades necesarias para completar una iteración. Diariamente los integrantes del team se juntan en reuniones de no más de quince minutos (parados frente al tablero) para revisar las tareas ejecutadas ayer, las que van a ejecutar hoy y cualquier impedimento que exista para ejecutar las tareas para hoy. En Scrum el rol de jefe de proyecto se diluye y pasa a ser adoptado por el team en su conjunto y en parte por el scrum master en su rol de facilitador y líder del proceso Scrum.

Estimación y Velocidad

Scrum prescribe que los teams deben estimar el tamaño relativo (=cantidad de trabajo) de cada ítem que comprometen en una iteracion. La suma del tamaño de todos los items completados al final de una iteracion define la Velocidad, que es una medida de la capacidad del team: cuánto podemos completar por iteración.

Burndown Chart

Scrum prescribe el uso de gráficos burndown diarios (que muestran cuanto trabajo queda pendiente en la iteracion actual) como herramienta principal de control. Su objetivo es determinar lo antes posible si vamos a poder completar todos los ítems comprometidos en la iteracion o no.

En la figura la linea recta representa la velocidad que debe seguir el team para completar al final de la iteracion el backlog comprometido. Si se permanece bajo esta linea el avance es positivo, en caso contrario el team debe tomar medidas si quiere completar el backlog al termino de la iteración.

• • • • • •

Bueno, estos son los conceptos básicos de Scrum. Naturalmente que hay muchos más detalles, mejores prácticas, experiencias y casos que se pueden encontrar buscando por scrum, agile, etc. en Google o YouTube (ver video introductorio más abajo).

Que utilidad práctica tiene Scrum en Chile? La respuesta es muy simple: depende. Uno de los principios básicos de cualquier paradigma o ideología ágil de proceso es la necesidad de experimentar, probar y ajustar hasta tener una versión que sea compatible con la idiosincrasia y cultura organizacional. Saque usted sus propias conclusiones ….o deje un comentario acerca de este articulo.

 

Administracion centralizada para Git

0 comments. Top.

Atlassian acaba de anunciar un nuevo producto.

Stash ofrece un manejo centralizado de los repositorios (o repos) Git que existen en servidores dentro del firewall. Es como tener su propio GitHub, pero al interior de la empresa.

Recordemos que Git es un DVCS (Distributed Version Control System) que rápidamente gana popularidad entre la comunidad OpenSource, desplazando el uso de Subversion (ver este post). Al ser distribuido, no se requiere un repositorio central, lo que ofrece muchos beneficios, pero abre un tema relacionado con la administración y control de acceso de estos repos.

Esto es justamente lo que ofrece Stash: facilitar la administración centralizada de los repos Git. Esto implica definir usuarios y permisos de acceso, pero Stash también ofrece funciones que van mas allá, como la integración con Jira para relacionar issues de Jira con commits de código en los repos Git.

Para conocer mas sobre Stash, visite esta página.

Presentando a GIT

0 comments. Top.

GIT es un software para control de versiones, pero a diferencia de Subversion , tiene un diseño distribuido. Esto tiene importantes consecuencias en el uso de git para el control de versiones:

  • No se requiere conexión a un servidor para manipular los archivos ya que la base de datos (o repositorio) se reproduce localmente en el equipo de cada usuario.
  • El traspaso (o sincronizacion) de los repositorios se realiza mediante operaciones de push (para actualizar un repositorio remoto con los cambios de uno local) y pull (viceversa).
  • El uso de ramas (branching) y merge es muy simple y rápido  ya que toda la información es local. El concepto de rama y el uso de merging es fundamental para definir y mantener ambientes dentro de un sistema de control de versiones.
  • Al ser distribuido, permite utilizar repositorios en red y trabajar así con terceros de manera colaborativa usando el modelo push/pull. Uno de los mas famosos es GITHUB . En github se puede abrir una cuenta para tener repositorios públicos o privados.

GIT esta ganando muchos adeptos, principalmente de la comunidad Subversion que están migrando hacia Git:

La siguiente es una presentación introductoria sobre GIT:

Un tutorial sobre diferentes modelos de uso con Git está disponible aqui.