miércoles, 12 de diciembre de 2018

Kanban paso a paso: evolucionando de las 3 columnas a tableros flexibles

La popularidad del Kanban está creciendo cada día; por ser aplicable a todos los tipos de industria, de la construcción civil al marketing, miles de personas están entregando mejores resultados gracias a este método.

Aunque la implementación de Kanban parece bastante simple, obtener lo mejor del método sólo es posible para aquellos dispuestos a probarlo en su flujo de trabajo e ir más allá, reflexionando sobre los resultados de la prueba en etapas reales.
En los párrafos siguientes, veremos los pasos más comunes en la implementación de Kanban y aprenderemos cómo mejorar la visualización y el control del flujo de trabajo según su habilidad con el método aumente.
Manténgase firme hasta el final para ver lo que se puede optimizar en cada etapa de cada proceso distinto de cada equipo en un tablero de equipos, sin dejar confuso.

Comience por donde usted está

Si el equipo acaba de comenzar con Kanban, no hay que ser demasiado rápida dibujando un tablero complejo y la creación de un WIP ( work in progress ) que los límites no se pueden cumplir. Utilizar el tiempo para llevar al equipo a bordo de un espacio para la práctica de los fundamentos del método.
La variación más simple de un tablero Kanban consiste en tres columnas:
(Haga click en la imagen para ampliar)
  • pedido - To do
  • En desarrollo - Doing
  • hecho - Done
Un tablero de diseño básico es fantástico para los equipos sin experiencia con Kanban porque es más fácil involucrar a la gente con el flujo de trabajo de visualización. Es un buen punto de partida para construir el hábito de mover las tarjetas de acuerdo con el estado de los trabajos escritos en ellos. Sin embargo, también es óptimo para establecer la gestión del flujo orientando al equipo a seleccionar su trabajo por cuenta propia.
El diseño de esta herramienta no requiere mucho esfuerzo para mantenerse al día y tiene una base sólida para comenzar con los límites de WIP (una piedra angular de Kanban), especialmente para los equipos que utilizan pizarra física para el Kanban.

Limitaciones del board básico del Kanban

Normalmente, una implementación básica de Kanban es suficiente para entregar mejoras visibles en la forma en que los equipos trabajan, pero pronto alcanzará el estancamiento en su productividad.
Después del periodo de familiarización, comenzamos a notar algunas limitaciones en el Kanban tablero de la columna 3, especialmente si el Kanban se practica en un ambiente de trabajo centrado en el conocimiento .
Para principiantes, habrá un límite para la cantidad total de trabajo en progreso (WIP), y verá todas las tareas iniciadas por el equipo. Sin embargo, no tendrá idea del estado de cada tarea.
La tarea que una persona estará trabajando será evidente, sin embargo, a menos que alguien pregunte por el informe de estado, no habrá información si esta persona está realmente trabajando en la tarea o esperando algo.
Sin embargo, es justo decir que, excepto por permitir la limitación de la cantidad de trabajo que está en curso, la implementación más básica de Kanban proporciona una visibilidad limitada tanto del flujo de trabajo y la orientación a la mejora.
Cómo iniciar una asignación precisa del flujo de trabajo
Cuando el equipo se siente cómodo con Kanban, algunas columnas y divisiones (los rayos) deben añadirse en el Kanban bordo para obtener una visión más precisa del flujo de trabajo.
Haciendo esto, será posible ver las posibilidades de mejoras potenciales en el modo en que el equipo trabaja y experimenta diferentes etapas en su proceso.

Columnas posibles

Usando como ejemplo el escenario de desarrollo de software , puede dividir la columna "en curso" en varias columnas que representan los pasos más importantes de su proceso como:
(Haga click en la imagen para ampliar)
  • Diseño de la solución Tech Design )
  • codificación
  • Listo para la revisión de código
  • En revisión
  • Listo para implementar
Al dividir la columna "en curso" en cinco pasos, puede comprobar el progreso de cada tarea sin salir de la junta demasiado complejo de entender el equipo. Además, será posible ver las etapas donde el trabajo más se acumula durante el proceso de desarrollo - la etapa de revisión.

Divisiones (Rayos posibles)

Después de evolución del diseño de la heramienta con columnas adicionales, que sería apropiado para añadir un poco de sol y dejar que el flujo de trabajo de visualización más objetiva.
Una division (raya) típica puede ser separada tanto por prioridad como por actividades. Es común observar equipos de TI Ops dividir sus tableros en divisiones (rayas) utilizando prioridades. En tal escenario, un diseño patrón vertical podría ser:
(Haga click en la imagen para ampliar)
  • acelerar
  • SLA de 24 horas
  • SLA de 48 horas
La lógica es simple: el equipo inicia un nuevo trabajo de acuerdo con la prioridad. Por ejemplo, si una tarjeta de 'acelerar' los requisitos, se detendrán todas las demás tareas que se están realizando (a menos que otra tarjeta de 'velocidad') y el trabajo de esta tarea se inicia inmediatamente. Siguiendo la línea de pensamiento, tarjetas SLA 48 horas son pasado.
Dividiendo el tablero Kanban de puestos de trabajo es una práctica común para los equipos de desarrollo de software. Por ejemplo, algunas divisiones del equipo de desarrollo aquí en Kanbanice funcionan así:
(Haga click en la imagen para ampliar)
  • Problemas en el cliente
  • insectos
  • Deuda técnica
  • Características de cliente o negocio
  • Características técnicas
Al igual que en las prioridades de los rayos (divisiones) en el diseño de tablero , en este caso los puestos de trabajo se extraen del tablero por nuestros desarrolladores de la raya  (division) con la posición más alta. La lógica es muy similar: la parte superior de los rayos (divisiones) contiene los tipos de tarjetas más importantes, donde trabajan nuestros desarrolladores.
En este punto plantea una pregunta importante: si las tarjetas se toman en función de su prioridad en ambos casos, lo que es el punto de agrupar las tarjetas según el tipo de trabajo?
La respuesta se esconde en la palabra planificación. Aunque el Kanban no es un mecanismo específico para la planificación , el desarrollo de software es algo necesario en cierta medida.
Por ejemplo, es importante tener pocos errores en el producto y poco o ningún débito técnico. Sin embargo, no se puede parar completamente el desarrollo de nuevas funcionalidades si quiere sobrevivir en un mercado dinámico.
Por simplicidad, la agrupación de las tarjetas de acuerdo con el tipo de responsabilidad y (division) rayos permite la capacidad del equipo para optimizar y mantener el flujo de trabajo de una manera beneficiosa para el cliente y para su empleador

VER MAS DETALLES EN LA FUENTE AL FINAL :-).

Puntos clave

  • Apresurarse en una implementación compleja de Kanban puede resultar en problemas a largo plazo.
  • Es necesario asignar un flujo de trabajo detallado para optimizar los procesos después de unirse a Kanban.
  • Los procesos más importantes deben incluirse en columnas en el Kanban board.
  • Actividades similares se pueden agrupar con la ayuda de rayos ( Swimlanes- carril de natación), dirigiendo el flujo de trabajo de acuerdo con las prioridades.
  • Al diseñar un flujo de trabajo flexible con diferentes columnas para cada carril de natación , se puede optimizar el flujo de trabajo y el uso de todo su potencial.

Sobre el autor

Alex Novkov es el líder de contenido Kanbanize , una empresa que desarrolla software de Kanban. Practicante experimentado del Kanban, dedica su tiempo a enseñar al mundo como ser más eficiente.
FUENTE https://www.infoq.com/br/articles/kanban-step-guide 

miércoles, 5 de diciembre de 2018

Mezclando marcos ágiles para el éxito del proyecto

Las herramientas de proceso ágil como Scrum, Lean Kanban, Extreme Programming XP y otras aportan sus propias características y ventajas a la mesa. Por ejemplo, Kanban se enfoca en mejorar cualquier metodología que se esté utilizando en lugar de proporcionar su propio marco, mientras que Scrum proporciona un marco definido con artefactos esenciales. El enfoque del método Agile es entregar valor en lugar de fijarse en el método en sí. Por lo tanto, las organizaciones pueden personalizar varias metodologías de marco Agile para satisfacer sus necesidades, permitiéndoles entregar el máximo valor.

Las organizaciones pueden tener en cuenta factores como la estructura organizativa, los objetivos de negocio, el nivel de experiencia y el tamaño del equipo cuando se combinan los marcos ágiles. La idea subyacente es completar la oración: "Mi cliente se beneficiará más si se usa _________".
Las metodologías solo deben mezclarse después de que se lleven a cabo extensas discusiones entre los coaches ágiles y otras partes interesadas en el proyecto. En la mayoría de los casos, las organizaciones modifican las metodologías ágiles hasta un punto en que no hay ningún elemento de ágil evidente en la nueva versión. Cuando el proyecto falla, la organización culpa a las metodologías ágiles.
Al mezclar metodologías, se debe tener en cuenta que los métodos ágiles no se pueden mezclar con la cascada o los métodos tradicionales. Las metodologías de cascada son más útiles en proyectos lineales que no tienen impredecibilidad, mientras que los proyectos ágiles son generalmente impredecibles y están sujetos a cambios constantes.
fuente : http://blog.scrumstudy.com/blending-agile-frameworks-for-project-success/