¡Los equipos de software actuales son, al menos en sus procesos, más ágiles! Están dispuestos a pensar fuera de los parámetros establecidos para seguir lo que les funciona. Están ansiosos por aprender y adoptar nuevas técnicas de gestión de proyectos y procesos de proyectos.
Un método de gestión de proyectos llamado Kanban ha estado dando vueltas en la industria del software durante bastantes años, y ha ganado vigencia en los últimos cinco años. Junto con las metodologías ágiles, la adopción del método Kanban ha dado a las empresas mucho que celebrar.
Pero también existe la crítica de que Kanban no es más que una lista glorificada de tareas pendientes. Entonces, ¿de qué se trata todo eso? Vamos a averiguar.
¿Qué es kanban?
Si su empresa está lista para ir más allá del enfoque tradicional de gestión de proyectos de software, hoy no hay escasez de técnicas de gestión de proyectos.
Por un lado, está el sistema Agile Project Management, que se centra en métodos iterativos no lineales de desarrollo de software. El uso de métodos ágiles es evidente en Scrum, que se centra en un enfoque más flexible para la gestión de proyectos.
Agile también tiene enlaces a otros marcos de gestión de proyectos como Kanban y Extreme Programming. De estos, Kanban ha alcanzado mucha popularidad. Después de todo, ¿quién no quiere un proceso desarrollado por los japoneses?
Kanban es un concepto que evolucionó en la planta de fabricación de Toyota para lograr una producción justo a tiempo (JIT) que reduce los costos y permite una menor utilización de los recursos. En esencia, sigue el principio de "atracción" del trabajo, lo que significa que las tareas o productos deben ser "arrastrados" por los requisitos y la demanda, y no "empujados" desde arriba hacia abajo. Fue desarrollado para garantizar un mejor almacenamiento de componentes de automóviles en las plantas de Toyota, según la demanda. Esto significaba que a medida que aumentaba la demanda, las solicitudes se completarían.
El concepto fue adaptado a la industria del software con algunos cambios por David Anderson, en su libro de 2010, Kanban . Desde entonces, se ha utilizado para varios proyectos con mucho éxito. Puede ser de gran ayuda en proyectos complejos que tienen el potencial de sufrir una sobrecarga en un lado del ciclo de desarrollo.
Básicamente, el sistema Kanban trata el proceso del proyecto de software como una tubería. Digamos que un proceso de software tiene tres tipos de tareas: análisis, desarrollo, pruebas y finalmente, implementación. Digamos que hay veinte tareas que deben completarse.
En el caso de un sistema tradicional de gestión de proyectos si, por ejemplo,
- Hay 25 historias en total
- Los analistas pueden manejar cinco historias por semana.
- Los desarrolladores pueden manejar cinco historias por semana
- Los evaluadores están limitados a tres historias por semana.
En esta situación, el trabajo simplemente se acumula al final de los evaluadores. Al final de la semana 1, la situación será la siguiente:
- Solo tres historias han pasado al despliegue.
- Los desarrolladores y analistas trabajan en tres historias, ya que los evaluadores no pueden tomar el resultado de los desarrolladores y probar lo mismo.
- El trabajo se acumula, dejando a los desarrolladores y analistas y al gerente del proyecto, en una solución.
¡Los analistas y desarrolladores ahora pueden simplemente estar haciendo girar sus pulgares! O su gerente podría darse cuenta de que están inactivos y reasignarlos a otro proyecto, donde puede surgir una situación similar. ¡Entonces hay dos proyectos que ahora están estancados en la fase de prueba!
Los problemas en tal situación no son difíciles de ver. ¿Cuál es el punto en el desarrollo de diez historias (o bits de software) cuando no se van a probar pronto?
Ahora, al método Kanban.
El método Kanban es un concepto extremadamente simple. Sigue una lógica simple de usar un "método de extracción" para eliminar primero los cuellos de botella y limitar los trabajos en curso (WIP) para mejores procesos de trabajo.
En su forma más simple, Kanban, literalmente, "tablero visual" ayuda al "extraer" elementos de una lista de tareas, en lugar de trabajar con líneas de tiempo. El método Kanban ayuda a identificar los cuellos de botella para que el flujo del proceso se gestione mejor.
Un tablero Kanban básico tiene una lista de tareas a realizar, tareas en progreso y tareas completadas.
Sin embargo, en la gestión de software, las tareas pueden ser un poco más complejas. La mayoría de los proyectos ágiles tienen un tablero similar también. En un tablero Kanban, las etapas del despliegue están claramente marcadas, junto con un número para cada columna. Este número representa el número máximo de tareas o historias que un paso en particular puede manejar.
Nuestro ejemplo en un tablero Kanban se vería así, al comienzo de la segunda semana. Esto significa que los desarrolladores y analistas no trabajarán en la cantidad óptima de historias esa semana. Sería obvio que el trabajo se está acumulando al final del probador. Y las organizaciones pueden garantizar que los equipos trabajen juntos para realizar las pruebas. Alternativamente, pueden ver otros modelos de flujo de proceso para que esto no suceda.
Cuando los proyectos se manejan a través del sistema Kanban, hay menos margen para que el trabajo se acumule. Las historias se toman de acuerdo con el ancho de banda máximo disponible.
En una configuración típica de Kanban, el trabajo se realizará de acuerdo con el ancho de banda disponible, y el trabajo será realizado por equipos, de modo que siempre estén a su máxima capacidad. El sistema también permite una vía rápida, para tareas que son urgentes, de modo que se muevan a través del tablero con el mínimo esfuerzo.
Echa un vistazo a este tablero Kanban.
Está claro que todos los pasos están funcionando con la máxima eficiencia. Y también se tiene en cuenta la tarea que se encuentra en la "Vía rápida".
Kanban no es el único método utilizado para aumentar la eficiencia al limitar WIP. Existen otros sistemas que logran el mismo resultado, por ejemplo, CONWIP (Constant Works in Progress) y DBR (Drum-Buffer-Rope), que están destinados principalmente a las industrias manufactureras.
Sin embargo, Kanban es el sistema que mejor se ha modificado para adaptarse a la industria del software.
¿En qué se diferencia Kanban de las metodologías ágiles?
En esencia, Kanban es una metodología que utiliza algunos elementos de la Gestión de proyectos ágiles. Muchos proyectos en el marco ágil tienen raíces en enfoques Lean. La diferencia entre la Metodología Kanban y la Gestión de proyectos ágiles no es tan negra y blanca como los defensores de los dos métodos nos harían creer. Tienen más en común que las diferencias.
El marco ágil no es absoluto. La pregunta no es si los equipos son ágiles o no. Los equipos a menudo tienen agilidad en diversos grados. Uno de los métodos para tener más agilidad en su proceso de desarrollo de software es usar Kanban.
Existen algunas diferencias entre las metodologías Kanban y Agile. Algunas de las características del desarrollo Kanban, que son un poco diferentes de Agile, son:
- Las líneas de tiempo no son un factor significativo . Este es un concepto difícil de entender, ya que parece muy poco intuitivo. "¿Cómo se trabaja sin plazos?", Se pregunta a menudo la gente. Pero si cada miembro del equipo está comprometido con su máxima eficiencia, entonces el tiempo deja de ser un factor.
- Las historias (tareas) son más grandes que en los sistemas Agile típicos. Por lo general, la duración y la complejidad de las historias son más largas que con un proyecto típico de Scrum. Dado que el foco no está en la estimación del tiempo, sino simplemente en hacer avanzar el proceso, Kanban puede permitirse trabajar en historias más grandes.
- No hay cambios significativos en los procesos existentes. Los principios de Kanban para el desarrollo de software, según lo articulado por su fundador, David Anderson, en su blog, incluyen los siguientes principios básicos:
-
- Comienza con lo que haces ahora
- Estar de acuerdo en buscar un cambio evolutivo incremental
- Respetar el proceso actual, roles, responsabilidades y títulos.
- Cada historia se mide en tiempo de ciclo . El proyecto se evalúa no mediante el cálculo ágil tradicional de la velocidad (el número de historias completadas durante un tiempo determinado), sino por el tiempo del ciclo. Esto significa que Kanban pone énfasis en cuánto tiempo se tardó en completar una tarea. A menudo puedes ver un ticker en muchos tableros de Kanban que mencionan cuántos días tarda el equipo en terminar una historia. Esta estimación alimenta el próximo ciclo.
Kanban: Un tablero, pero ¿qué más?
Entonces, Kanban es un tablero que nos muestra cómo están organizadas las historias, es incluso un gran problema, muchos preguntan. De hecho, hay una gran discusión sobre lo que Kanban es y puede hacer.
¿Kanban es solo un método para administrar el flujo de trabajo? ¿O es algo que uno puede usar junto con las metodologías ágiles para obtener la máxima eficiencia? ¿O puede ser una forma completamente nueva de gestión del flujo de trabajo?
Cada equipo usa Kanban según lo considere apropiado, para su situación particular. En cualquier caso, Kanban tiene el potencial de funcionar como una forma de vida para el desarrollo de software, si se utiliza a su nivel óptimo.
Ya sea que se use para administrar el flujo de trabajo o como un nuevo paradigma en el desarrollo de software, no se puede negar que ayuda a administrar los WIP.
Para que Kanban funcione mejor, es importante pensarlo no solo como la gestión de WIP, sino como un marco de gestión de proyectos. Ciertas pautas básicas ayudarán en el proceso.
- Optimice los equipos para que ningún equipo comience algo que no pueda terminar. Esto ayuda al proceso a lo largo.
- No resista los cambios del sistema Kanban original. Si su proyecto funcionará bien con plazos y plazos, incorpore lo mismo que lo haría. Esto crea un entorno de desarrollo más saludable y robusto.
- No rehuyas el trabajo en equipo. Kanban puede parecer, pero no lo es, un modelo basado en individuos que trabajan de forma aislada. El trabajo en equipo debe ser una parte integral del desarrollo de software Kanban.
- Piensa fuera de la caja. Piensa en los cambios en el flujo de trabajo. Muchos equipos ahora optan por el desarrollo basado en pruebas, con el desarrollo basado en pruebas de aceptación, donde las pruebas de aceptación se llevan a cabo primero con casos de uso, que luego controlan las características requeridas y la naturaleza del desarrollo.
Híbridos
A medida que más y más empresas utilizan las herramientas de gestión de proyectos más adecuadas para su situación particular, no es sorprendente que dos de las mejores metodologías de gestión de proyectos: Scrum y Kanban, se hayan integrado con mucho éxito.
El híbrido, llamado Scrumban, está incursionando en muchos proyectos.
Si una organización ya está utilizando Scrum, pero le resulta difícil mantener el proyecto unido, ya sea con los sprints que no funcionan bien, ya que las pruebas no son herméticas, podría ser el momento de considerar Scrumban.
Para explicarlo simplemente, Scrumban implicó llevar una lupa a los sprints. No se trata solo de los sprints como parte del proyecto, se trata de lo que sucede dentro de los sprints. Scrumban ayuda a analizar cómo se procesa una historia dentro de un sprint, y eso podría marcar la diferencia.
Scrumban, o cualquiera de sus variantes, es un cambio mínimo de las prácticas existentes. La belleza de usar Kanban es que se puede usar con prácticamente cualquier tipo de modelo de gestión de proyectos: cascada, ágil o cualquier otro elemento intermedio.
Comenzando con Kanban
Es fácil comenzar con el sistema Kanban. También es posible implementar Kanban de manera mínima como prueba para una parte particular de un proyecto.
- Mapa del proceso de desarrollo de software. Haga un mapa claro de todo el proceso. ¿Cómo funciona el proyecto, desde el diseño inicial, hasta el desarrollo, las pruebas y los cambios en las características, en realidad?
- Enumere los pasos donde se utilizará Kanban. Use los pasos que están completamente bajo su control. Esto típicamente comprende las fases de análisis, desarrollo, revisión y prueba.
- Trabaja en puntos importantes como:
- Límites a las obras en curso para cada paso.
- Procesos para trabajo acelerado / bloqueado
- Estimaciones al final del sobre con respecto al tiempo de ciclo
- Frecuencia de la revisión del tablero / proceso / estimación Kanban
- Compre una pizarra y una pila de notas Post-It.
- Empezar
- Revise según sea necesario.
- Repetir
¡Entonces, adelante, y comience con Kanban!
No se asuste si no resulta de la manera que inicialmente pretendía. ¡La idea detrás de las metodologías ágiles es acomodar los cambios en las personas y los procesos! Háganos saber sus experiencias con el método Kanban.
Artículos recomendados
- 6 Mejor Ayuda Una Oficina de Gestión de Proyectos (PMO)
- 8 pasos útiles para construir sofisticados mapas de historias para su proyecto
- Los 5 valores importantes de la programación extrema (potente)