Enfrentarse por primera vez al desarrollo de un proyecto software, siempre es un reto que debe plantearnos cual es la mejor fórmula para que el desarrollo avance de forma positiva y sobre todo minimizando el número de cambios. Esto hará que tanto el cliente final, como la empresa desarrolladora, consigan sus objetivos de manera beneficiosa para ambos.
En el momento que iniciamos un desarrollo software tradicional, siempre debemos ceñirnos a un alcance prefijado, es decir, que la aplicación sea finalmente lo que se ha acordado en el análisis. Si lo basamos en una metodología rígida (en cascada, secuencial), puede ser muy usual que una parada en una de las fases, retrase el resto de los desarrollos y lógicamente, será un proyecto donde el cliente no estará del todo conforme con los resultados obtenidos. En este supuesto además, la empresa tecnológica no facilitará que su equipo desarrolle todo su potencial y obtendrá un deterioro de su imagen con toda seguridad. En este escenario es donde es urgente introducir las metodologías ágiles.
Como comentamos en nuestro anterior post sobre metodologías ágiles, precisamente una metodología de este tipo a la hora de desarrollar, trata de eliminar este concepto rígido y se centra en la colaboración e integración de todo el equipo. En este escenario, el desarrollo de las tareas están enfocadas a una mejora continua y a una adaptabilidad de los desarrollos. SCRUM es una de las muchas metodologías ágiles que existen, donde se centra el trabajo en iteraciones realizadas por el equipo Scrum, dirigidas y supervisadas por el Scrum Master, que además es el responsable de asegurar un ambiente de trabajo adecuado y elaborar un backlog (lista de trabajos pendientes), priorizado para satisfacer las necesidades del producto.
SCRUM basa su metodología para el desarrollo en 6 principios.
Desarrollo iterativo. En todas las iteraciones se realiza un trabajo completo que constituye una parte de proyecto final.
Control empírico del proceso. Se realiza un control sobre los procesos, pero siempre teniendo en mente que puede haber alguna modificación.
Auto-organización. El equipo Scrum debe organizarse y permitir que los integrantes tengan iniciativas que permitan ser discutidas y mejoren los procedimientos.
Colaboración. Es necesaria una colaboración y comunicación entre todos los integrantes del equipo Scrum y el cliente. Esto permitirá que los resultados obtenidos se adapten lo mejor posible a las necesidades planteadas.
Priorización. Las necesidades planteadas por el cliente deben ser mapeadas en historias de usuarios y priorizadas atendiendo a su importancia.
Time – boxing. Todas las tareas, reuniones, seguimientos, etc, deben tener obligatoriamente un tiempo máximo de duración.
En un proyecto SCRUM se identifican como mínimo, los siguientes integrantes.
Los 6 principios de Scrum son aplicados en todas las etapas que conforman el proyecto, donde participan todos los integrantes del equipo central de Scrum (Product Owner, Scrum Marster y el Equipo Scrum). Para la correcta aplicación de esta metodología ágil, tenemos que diferencias bien las etapas en las que se divide un proyecto, desde su planteamiento inicial (Creación de la visión de proyecto) hasta el cierre del proyecto con la entrega final (retrospectiva del proyecto). A continuación se detallan las fases que se siguen durante el desarrollo de un proyecto Scrum.
Creación de la visión del proyecto. La visión del producto debe ofrecer de una forma genérica, en que consiste el proyecto y que necesidades va a cubrir. En esta parte se identifica al Product Owner.
Identificación del Scrum Master y Stakeolders. Por parte del cliente y por parte de la empresa desarrolladora, se selecciona al equipo de Stakeholders y el Scrum Master.
Formar equipo scrum. El Product Owner se encargará de identificar a los miembros del equipo Scrum. Para esta elección, puede intervenir el Scrum Master.
Definición de Épicas. La Declaración de visión del proyecto sirve como base para la definición de las épicas. Una épica no es más que un requisito un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, criterios, finalidad, etc. Se tiene en mente una imagen abstracta de lo que se quiere obtener con la épica, pero son las historias de usuario, su implementación en los sprints y el feedback los que terminan de darle finalmente la forma.
Crear backlog priorizado del producto. Se concretan y se crean las épicas y se ordenan en un backlog priorizado.
Realizar planificación del lanzamiento. En este proceso el equipo principal de Scrum revisa las historias de usuario en el Backlog Priorizado del Producto para desarrollar un cronograma de planificación del lanzamiento, que es esencialmente un programa de implementación por fases que se puede compartir con los Stakeholders del proyecto. En este proceso también se determina la duración del sprint.
Crear historias de usuario. Las escribe el Product Owner y tienen que ser diseñadas para asegurar los requisitos del cliente. Para la redacción se puede hacer uso del equipo Scrum.
Estimar historias de usuario. El Product Owner aclara las historias, y Scrum Master y el equipo Scrum estiman los esfuerzos.
Comprometer historias. Se compromete un numero de historias que conformarán un sprint.
Identificación de las tareas. Las historias de usuario se desglosan en tareas.
Estimar tareas. El equipo Scrum estima los esfuerzos necesarios para ejecutar las tareas.
Creación del sprint Backlog. Creación del sprint backlog con todas las tareas a ser completadas en el sprint. Se realiza en la reunión de planificación del sprint .
Creación de entregables. El equipo Scrum trabaja para desarrollar las tareas comprometidas en el sprint backlog.
Daily Standup. Reunión diaria entre los integrantes del equipo Scrum donde se comentan los avances o posibles problemas.
Refinamiento del backlog priorizado del producto. Durante el desarrollo, se puede revisar el backlog priorizado para actualizarlo o modificarlo.
Demostración y validación del sprint. El equipo Scrum muestra los entregables al Product Owner y a los Stakeholders en la reunión de revisión del sprint. El Product Owner debe aprobar y aceptar los entregables del sprint.
Retrospectiva del sprint. Los integrantes del equipo Scrum y el Scrum Master se reúnen para analizar y documentar todas las lecciones aprendidas durante el sprint.
Entrega de los entregables. Una vez aceptados los entregables por el Product Owner y los Stakeholders se procede al envío de los entregables del sprint a los Stakeholders.
Retrospectiva del proyecto. En este proceso, mismo que concluye el proyecto, los Stakeholders y miembros del equipo principal de Scrum se reúnen para hacer una retrospectiva del proyecto e identificar y documentar la información necesaria para la finalización del proyecto.
En tithink apostamos por la implementación de metodologías ágiles en todos nuestros proyectos, algo que desde nuestra experiencia ha mejorado la planificación y desarrollo de todos nuestros productos permitiéndonos recibir un feedback constante del cliente, adaptarnos a sus necesidades y ofreciendo el servicio que realmente están solicitando.
