En la actualidad, cuando se desarrolla un producto utilizando la metodología Agile, la salvaguardia de la calidad se lleva a cabo al final de cada periodo de tiempo fijo o también denominado sprint. Un ingeniero de control de calidad trabaja en paralelo con los desarrolladores con una Maestría en Metodologías Ágiles de Gestión de Proyectos y Transformación Digital, lo que acelera el desarrollo de cualquier proyecto.
Antes del desarrollo del software Agile, las empresas utilizaban waterfall, un enfoque lineal y secuencial de un proyecto. Sin embargo, esta metodología ralentizaba el trabajo, ya que el equipo de desarrollo no podía continuar con la siguiente fase antes de terminar las tareas anteriores. Es decir, se presentaba la imposibilidad de retroceder o saltar de paso. Asimismo, el producto solo podía probarse cuando se completaran todas las tareas y se desarrollaran las características.
A continuación, profundizamos en las características de las metodologías ágiles, y su creciente importancia en el desarrollo de software.
Manifiesto del desarrollo ágil de softwareLa metodología ágil empezó a sustituir a los métodos tradicionales. Las especificaciones detalladas pasaron a mejor vida, mientras que la comunicación con los clientes y los plazos se volvieron una prioridad.
Después de varios años, Agile evolucionó hasta convertirse en un manifiesto del desarrollo ágil de software que contiene todos los principios de la metodología.
Las empresas ya utilizaban este método, pero no se generalizó hasta la redacción del manifiesto, el 12 de febrero de 2001. Con el tiempo, Agile obtuvo sus propios marcos de trabajo: Lean, XP, Scrum, Kanban. En este artículo nos centraremos en las metodologías Scrum y Kanban.
Kanban trata de la visualización de las tareas, la limitación del tiempo y el proceso de trabajo continuo. El tablero es un elemento obligatorio de Kanban, se utiliza para capturar las tareas actuales. Cada tablero tiene columnas que representan las etapas del desarrollo, a su vez, cada tarjeta en las columnas encarna una tarea. Cuando obtiene un nuevo estado, se mueve secuencialmente de una columna a otra (en Kanban, esto se llama flujo). Si no se sigue esta regla, el enfoque no funciona.
El equipo de proyectoNormalmente, un equipo Scrum está formado por hasta nueve desarrolladores. Además, un Product Owner y un Scrum Master. Si un equipo incluye menos de tres personas, no se considera productivo, ya que tales integrantes carecen de comunicación.
Los grupos basados en Scrum son capaces de autoorganizarse: los miembros del equipo eligen cómo completar una tarea por sí mismos. Así es como funciona en teoría.
Sigue leyendo para saber cómo funciona en la práctica.
El Product OwnerEs el responsable de generar la idea y el resultado. En la mayoría de los casos, este papel es asumido por un cliente: dan una idea, encuentran el dinero y escriben las especificaciones. Sin embargo, no todos los usuarios saben cómo debe ser su producto. Junto con otros participantes del equipo, guían el producto en la dirección correcta.
El Scrum MasterInicia y mantiene la comunicación dentro del equipo. Ayudan a superar los problemas y a comunicar los principios básicos de la metodología. La gestión de proyectos Scrum no funciona si las personas no creen en ella.
El equipo de desarrolloGeneralmente, incluye de cinco a siete personas. Cada uno tiene su propia área de responsabilidad, pero trabajan de manera conjunta para alcanzar los objetivos de un sprint. Para aquellos que no entienden por qué hay tantas personas en el equipo de desarrollo: un "desarrollador" aquí no es necesariamente una persona que trabaja con el código, un desarrollador es cualquier especialista que trabaja en un producto, ya sea un ingeniero de control de calidad o un diseñador.
Mantener el backlog del proyectoEl equipo discute la idea, crea un mapa mental y elige una pila tecnológica. Las tareas se forman en una lista, conocida como backlog del proyecto. En la parte superior del backlog, colocamos la parte más importante que debe hacerse primero. Paso a paso, esta lista cambiará: habrá nuevas características o dejará de haberlas.
Todas las tareas de la cartera de pedidos se priorizan: el equipo da vueltas a los objetivos del proyecto y encuentra la forma óptima de ofrecer un resultado de alta calidad. Las grandes empresas, como Google o Amazon, utilizan criterios de priorización. Por ejemplo, impacto/esfuerzo, cubos de características, mapeo de historias de usuario y MoSCoW.
ConclusiónEs difícil predecir todos los problemas. Sobre todo, en el mundo digital y al tratarse de un proyecto grande y técnicamente complicado. El enfoque waterfall ignora los cambios, lo cual resulta contradictorio en un plan. En cuanto se tienen las especificaciones y los requisitos, es difícil ampliar la funcionalidad. Cualquier cambio que se requiera tiene que ser discutido con el cliente y aprobado por él.
La metodología SCRUM se adapta al 100% al desarrollo de MVPs y startups. El orden estricto de las etapas de desarrollo se sustituye por sprints. Así, el equipo puede cambiar rápidamente la lista de tareas: añadir detalles a las existentes o descartarlas. El backlog del proyecto cambia constantemente: en el lanzamiento, el producto gana nuevas características y se deshace de las innecesarias. El cliente supervisa el desarrollo desde el primer sprint, lo que le ayuda a decidir sobre las características, continuar el desarrollo según lo previsto o cambiar el rumbo.