Agile, Scrum y Kanban: ¿Qué diablos significan realmente estas palabras?

Cuando un desarrollador de software escucha noticias sobre un "nuevo marco de JavaScript" o un "nuevo IDE", no necesita hacer más preguntas para aclarar de qué se trata. Pero si se entera de un "nuevo marco ágil", probablemente asentirá con la cabeza como Homero-Simpson, fingiendo que sabe de qué se trata, pero tendrá una, y solo una, pregunta: ¿Qué diablos hace el "marco ágil"? ¿significar?

En el entorno de desarrollo de software moderno, escuchamos cada vez más palabras como "ágil", "scrum" y "kanban", y a menudo se usan de manera incorrecta. En este artículo, intentaré explicar y aclarar algunos de estos términos.

Ágil

Si quiere ser el sabelotodo de la multitud, debe usar la palabra "ágil" en cada oración cuando hable sobre el proceso de trabajo. Tiene un rango bastante amplio, no te obliga a saber mucho sobre el tema del que estás hablando, y es un adjetivo o adverbio realmente agradable: "pensar ágilmente", "enfoque ágil", "de acuerdo con principios ágiles". Pero, ¿qué significa realmente “ágil”?

"Ágil" se refiere al "desarrollo de software ágil", el enfoque de desarrollo que sigue los principios ágiles. Pero, ¿qué diablos son los "principios ágiles"? Eche un vistazo al Manifiesto Agile y a los 12 principios de Agile, que sientan las bases del desarrollo ágil. Del Manifiesto:

Los principios ágiles fomentan la entrega continua de software en funcionamiento, una comunicación estrecha entre los equipos y una alta adaptabilidad a las necesidades cambiantes. Si sigue estos valores y principios en su trabajo, puede decir que está trabajando en un entorno ágil. Entonces, el desarrollo ágil de software no es una metodología, es solo un conjunto de diferentes metodologías, marcos y técnicas que siguen los mismos principios. Se puede decir que “ágil” es un marco para pensar y tomar decisiones.

Pero, ¿por qué es tan importante seguir estos principios en nuestro trabajo?

El Manifiesto y los principios son el resultado de la búsqueda de las mejores soluciones que han evolucionado durante décadas en respuesta a los desafíos del desarrollo de software. A lo largo de los años 70, 80 y 90, diferentes desarrolladores y equipos de todo el mundo experimentaron con métodos de trabajo y enfoques para la resolución de problemas, inventaron diferentes marcos y técnicas (como scrum y Programación extrema), e incluso llegaron a lo mismo. ideas en paralelo. Finalmente, en febrero de 2001, diecisiete desarrolladores se reunieron y encontraron los denominadores comunes para todas estas ideas y experiencias diversas. Así se creó el manifiesto.

Melé

Si hablas de métodos “ágiles” sin saber lo que significan, puedes cometer un desliz y decir cosas que te destapen frente al interlocutor que conoce el tema: “Scrum y otras metodologías ágiles”.

Scrum no es una metodología, aunque todos hemos oído llamarlo así con más frecuencia que el número de asesinatos en Game of Thrones . Scrum no dará una respuesta a todas las preguntas y no le proporcionará el procedimiento preciso para responder a cada situación que enfrente. Y probablemente como resultado de esta interpretación incorrecta, la mayoría de las implementaciones de scrum también están equivocadas: los equipos no obtienen valor. Esto da como resultado probablemente la declaración más tonta sobre scrum: "Scrum no funciona".

¿Qué es scrum? La Guía Scrum define Scrum como:

Por lo tanto, es un marco , y como cualquier otro marco, puede ser, y regularmente se usa, de manera incorrecta. El uso efectivo de scrum requiere no solo adoptar la estructura establecida por scrum, sino tener una comprensión profunda y una apreciación de los principios ágiles en todo el equipo.

Scrum consta de los siguientes roles: Product Owner, Scrum Master, Development Team.

También hay cuatro ceremonias de Scrum: reunión de planificación, Scrum diario, revisión de Sprint, retrospectiva de Sprint.

Y los tres artefactos: Product Backlog, Sprint Backlog, Product Increment.

Los proyectos de Scrum se organizan en marcos de tiempo regulares, a los que llamamos sprints. Suelen durar dos semanas.

Un Product Owner es responsable de guiar la dirección del proyecto. A medida que se determinan nuevas tareas y funciones, el propietario del producto las agrega a una cartera de productos. Un sprint comienza con una reunión de planificación en la que el equipo de desarrollo selecciona las tareas del backlog para trabajar y planifica cómo se implementarán. A esto le sigue el desarrollo, durante el cual el equipo de desarrollo utiliza la acumulación para realizar un seguimiento del progreso y se reúne para la reunión diaria a fin de sincronizar actividades y ajustar el plan, si es necesario. El resultado del desarrollo debe ser un incremento del producto, algo que se pueda aplicar al producto y lanzar inmediatamente. Al final del sprint, el incremento del producto se presenta al propietario del producto en la revisión del sprint, donde se aumenta la acumulación de productos si se necesitan más cambios. Posteriormente, todo el equipo asiste a la retrospectiva del sprint donde hablan sobre el proceso de trabajo y cómo se puede mejorar.

Scrum es fácil de aprender y comprender, pero es difícil de adoptar. Hay muchas razones por las que este marco puede o no ser una buena opción para un proyecto. A menudo requiere muchos cambios, no solo en el desarrollo cotidiano, sino también culturalmente. Scrum encaja mejor con el desarrollo de productos complejos, que duran mucho tiempo y que incluyen diferentes tipos de especialistas.

¿Por qué Scrum es tan popular y por qué tiene una ventaja sobre el modelo tradicional en cascada? En pocas palabras, porque ofrece más valor a un producto y a los clientes. Con métodos “pesados” como el de cascada, abundan las historias de terror en las que nadie ve nada del proyecto durante meses. Con scrum, eso no es posible.

Scrum tiene que ver con el valor que se entrega a los usuarios finales. Si realmente utiliza Scrum, debe entregar algo de valor en cada sprint. El valor se puede medir y el equipo también se ve obligado a inspeccionar los impedimentos y adaptarse, con el objetivo de ofrecer más valor en la próxima iteración.

En la mayoría de los desarrollos de software no estamos construyendo un rascacielos; no necesitamos tener todo el plan listo antes de comenzar, y ceñirnos a ese plan hasta el final. Estamos desarrollando software y tenemos la capacidad de adaptarnos a diferentes situaciones y cambiar los requisitos del producto durante el desarrollo. Durante mucho tiempo, muchos desarrolladores vieron esto como el octavo pecado capital, pero desde la perspectiva del producto es un gran beneficio para optimizar la previsibilidad y controlar el riesgo. Scrum se desarrolla en torno a esta capacidad, y su implementación brinda una forma confiable y eficiente de lidiar con los cambios necesarios.

Muchas técnicas se utilizan junto con scrum: planificación de póquer, programación en parejas, desarrollo basado en pruebas (TDD), desarrollo basado en el comportamiento (BDD) y otras. No son realmente una parte de scrum, sino técnicas compatibles. Un método que se menciona a menudo al mismo tiempo que scrum es kanban, y existe mucha confusión sobre lo que significan estas dos cosas en relación entre sí.

Kanban

Cuando habla de scrum y kanban, una pregunta frecuente de la multitud será: "¿Qué es mejor, scrum o kanban?" Y no sabrás qué responder porque es como comparar manzanas y naranjas, o preguntar: "¿Qué es mejor, panqueques o cerveza?" Ambos son mejores.

Kanban es un método simple que tiene como objetivo la entrega justo a tiempo sin sobrecargar a los miembros del equipo. Es similar a scrum en que el objetivo es entregar el máximo valor al final, pero es mucho más flexible que scrum.

Kanban no fue inventado por la comunidad de desarrollo de software. De hecho, tiene su origen en los procesos de fabricación de Toyota y tiene un amplio uso en otros ámbitos. No hay procedimientos estrictos que deba seguir, ni una forma estricta en la que deba implementar y usar kanban; es, más bien, un conjunto de principios y prácticas, y puede elegir entre estas prácticas para satisfacer sus necesidades. Pero hay una implementación de kanban que se usa con más frecuencia en el desarrollo de software que incluye el uso de un tablero kanban , que consta de columnas que representan etapas de trabajo y tareas.

Las columnas representan el estado de una tarea en el proceso de desarrollo. El ejemplo más simple consta de tres columnas: "Por hacer", "En progreso" y "Terminado". Por lo tanto, las tareas se agregan a "Por hacer", se mueven a "En progreso" cuando comienza el desarrollo y se consideran "Listo" cuando se mueven a la última columna. Pero claro, podría ser más complejo:

Trabajo pendiente → Especificación de definición → Listo para el desarrollo → Desarrollo → Revisión de código → Prueba → Implementado (→ Nadie lo usa realmente → Eliminado por completo).

Cada columna puede tener subcolumnas; por ejemplo, “Desarrollo” se puede dividir en “Planificación” y “Codificación”; Las "pruebas" se pueden dividir en "pruebas unitarias" y "pruebas de integración", y así sucesivamente. Las columnas pueden estar dedicadas a especialistas, si corresponde. El equipo define las columnas y etapas de acuerdo a sus necesidades. Según la filosofía de "extracción", las tareas solo deben ingresar al flujo de trabajo cuando la demanda de ellas es inmediata.

El propósito de este tablero es visualizar el flujo de trabajo, que es la primera práctica clave en kanban. De hecho, ¡kanban se puede hacer sin un tablero! Puede ser una simple lista de tareas en una hoja de Google con diferentes colores de fondo indicando el estado de la tarea, o pueden ser diagramas de Gantt, diagramas, tablas… Incluso podría ser un conjunto de cubos en tu oficina, donde cada uno representa el estado de la tarea y dónde se usan las pelotas como tareas. Simplemente visualice el flujo de trabajo y brinde transparencia a todo el proceso.

Otro principio importante es reducir el tamaño del lote de sus esfuerzos . Simplificado, esto significa evitar la multitarea. Eso puede significar reducir el volumen de tareas en las que trabaja al mismo tiempo. Si tiene tres diseñadores en un equipo, el equipo puede establecer el número máximo de tareas en la columna "Diseño" en tres.

Al igual que scrum, kanban también ve al equipo como la figura más importante del proceso. Pero no sugiere roles como lo hace Scrum, y puede mantener los roles existentes para evitar realizar cambios en su proceso existente. Lo mismo significa mejora continua: Kanban generalmente lo alienta a aprender y mejorar continuamente, pero no prescribe un evento específico solo para ese proceso, como lo hace la Retrospectiva de Sprint de Scrum.

¿Cuál debo usar?

Scrum y Kanban no se excluyen mutuamente y no son realmente comparables. En scrum, hay roles definidos, mientras que kanban dice: "Qué demonios, mantén tus roles y responsabilidades actuales". Scrum te obligará a cambiar tu forma de trabajar; kanban le permite comenzar con su proceso existente. En scrum, el marco prescribe un cronograma claro para los eventos; en kanban no tienes eventos. Sin embargo, tienen muchas similitudes: ambos se centran en el valor, los miembros del equipo son respetados como "jefes" del sistema y, esencialmente, tienen la misma misión: eliminar continuamente el desperdicio y eliminar los obstáculos.

Pero la pregunta, “¿Qué debo usar en mi proyecto particular y con mi equipo particular?” tiene mucho más sentido. Kanban no requiere mucho del proceso y los cambios culturales y, en la mayoría de los casos, será más fácil de adoptar que scrum. Scrum, por otro lado, ofrece una estructura significativamente mayor para guiar el proceso, lo que puede eliminar una gran cantidad de gastos generales siempre que todos estén en la misma página.

Pero la belleza de ambos es que ninguno es un conjunto estricto de reglas. No hay nada que le impida elegir los mejores elementos de scrum para usted, como una reunión o revisión diaria. Y no hay razón por la que no pueda incorporar un tablero kanban en scrum.

Scrum ha demostrado ser un marco altamente efectivo cuando todo el equipo lo entiende bien. Sin embargo, en mi experiencia, encuentro difícil trabajar en scrum con algunos clientes. El proceso y los cambios culturales necesarios para la implementación adecuada de scrum pueden ser demasiado (¡especialmente cuando se trata de alguien que cree que está creando un nuevo Google!). Por otro lado, Kanban es más flexible y no obliga a las personas a cambiar. Algunos autores también dicen que kanban es un buen camino hacia la agilidad y ofrece una implementación más fácil de scrum. Otros dicen que usar scrum debería conducir a kanban al final.

La verdad es que cada proyecto es diferente y no existe una solución única para todos. Como gerente de proyecto, depende de usted determinar qué funciona mejor para su equipo.