SCRUM

Es una metodología para la gestión del proceso de desarrollo de software que se apoya del manifiesto ágil. Puedes ver como está compuesto aquí.

Los modelos tradicionales suelen tener muchas deficiencias como:

• Pueden ser lentos en los levantamientos de requerimientos.
• Pueden no considerar todos los escenarios posibles en un proceso.
• Una vez iniciado el desarrollo, los cambios suelen ser dolorosos.
• Existe demasiada documentación para controlar un producto.
• Existen demasiados controles que hacer un cambio es engorroso.

SCRUM trata de eliminar la burocracia, haciendo algunas modificaciones al modelo tradicional y eliminando documentos, incrementando la colaboración entre todos los involucrados (Equipo de Desarrollo, Clientes, Analistas, Ingenieros de Prueba, Arquitectos, Dueños del Producto, Representantes Claves), y ofrece dar una visibilidad mas real del producto por el acercamiento y la constante comunicación que existe entre los involucrados.

Para adaptarse a SCRUM es necesario cambiar:

• Los paradigmas sobre el levantamiento de análisis - En metodologías agiles lo importante es la tendencia al cambio, debemos entender procesos, necesidades, prioridades, valores. Esto es fundamental para aceptar los cambios.
• La manera en como se ve a un cliente - Ya no existe el cliente, existen colaboradores que requieren maximizar su rendimiento, productividad, eficiencia, eficacia, y nosotros nos convertimos en un colaborador mas que trabaja con ellos para hacer esto posible.
• El creer que se vende un producto - El producto no es lo importante, lo importante es la colaboración que existe entre todos los involucrados orientados a un mismo objetivo, son los lazos que se generan en pro de hacer esto posible, el producto es el resultado de los esfuerzos de colaboración entre los equipos de alto rendimiento.
• La barrera de Cliente-Proveedor - Dejan de existir acuerdos legales, cláusulas, penalizaciones y todo aquello que hacen doloroso la colaboración, ya que no debe de existir obligación jurídica, más bien debe existir corresponsabilidad y participación activa.

No sólo la manera de pensar es lo que debe de cambiar, también cambian los documentos ya que SCRUM, elimina la carga de trabajo hacia estos y deja sólo aquellos que son realmente importantes y que generan valor para el proceso de desarrollo de software.

En un modelo tradicional se tienen los siguientes documentos:

Acta de negocio.- Es el documento con el cual se da inicio al ciclo de vida de desarrollo del software, refleja la necesidad y justificación del cliente por obtener un producto y define las reglas iniciales sobre las cuales se gestionará este desarrollo.

Acta de requerimiento.- Es el documento donde se detallan los requerimientos tanto funcionales como no funcionales, declara quiénes son los usuarios claves del proyecto tanto de las áreas de negocio cómo de las áreas de sistema, también declara la matriz de comunicación que se utilizará durante el proyecto, así como los involucrados que deberán ser considerados para la ejecución del mismo, pueden existir varias actas de requerimiento para una acta de negocio.

Documento de análisis.- Es el resultado del análisis realizado de acuerdo a la necesidad estipulada en la acta de negocio, este documento contiene las reglas de negocio, los roles involucrados, los casos de uso, los procesos que afectan, los procesos con los cuales tiene relación, su impacto tanto vertical como horizontal, entre otros datos, tiene una relación directa con los requerimientos funcionales declarados en el acta de requerimiento, pueden existir varios documentos de análisis por cada acta de requerimiento.

Solicitud de cambio.- Es el documento que declara el inicio del proceso de desarrollo, define quiénes son los involucrados que participarán en el proyecto y los roles que cada uno ejecutará, también define las fechas de las diferentes reuniones que se realizarán y declara qué requerimientos funcionales del acta de requerimiento serán desarrollados en este proceso, pueden existir varias solicitudes de cambio por acta de requerimiento.

Casos de prueba.- es el documento en el cual se comprueba que cada uno de los flujos definidos en el análisis fueron desarrollados conforme a los requerimientos dados y que cumple en todos los aspectos con el control de calidad definido por la organización, deberían de existir tantos casos de prueba cómo casos de usos estén definidos.

Aprobación de QA.- Este documento es generado por el Departamento de aseguramiento de calidad y eso aprobación de que cumple con todos los estándares definidos así como el proceso que está definido.

Solicitud de cambio a producción.- este documento contiene la información técnica necesaria, es decir, archivos que sufrieron cambios, archivos nuevos, archivos eliminados, configuración, servidores y ambientes que afectan y las distintas aprobaciones que se requieren para que el cambio sea publicado, además especifica la fecha deseable en la cual deberá ser publicado el cambio y define los mecanismos de retroceso en caso de fallos.

Bitácora de liberación.- este documento lleva un control de las liberaciones realizadas, así como de los fallos que se han presentado Al momento de ejecutar las liberaciones.

En un modelo ágil sólo se definen los documentos que son necesarios para cubrir las necesidades de la empresa sin entorpecer la velocidad de desarrollo.

Minuta de Sprint planning.- Este documento es la evidencia de todo aquello acordado durante el proceso de Sprint planning, entre los datos que podemos ver se encuentran los siguientes:

• número de iteraciones.
• duración de cada iteración.
• calendario de la reunión diaria.
• duración de la reunión diaria.
• calendario de presentación de avances.
• duración de la presentación de avances.
• calendario del Sprint review.
• duración del Sprint review.
• calendario de Sprint retro.
• duración del Sprint retro.
• involucrados en el proyecto.
• rol de cada involucrado.
• herramientas a utilizar.

Sprint backlog.- este documento es la priorización por iteración de las historias usuario a desarrollar, es el resultado del Sprint planning.

Minuta de reunión diaria.- este documento es la evidencia de todo lo que se vio en la reunión diaria, entre los datos que podemos ver se encuentran los siguientes:

• tareas terminadas.
• tareas no terminadas.
• causa de las tareas no terminadas.
• tareas a trabajar en este día.
• tareas a terminar en este día.
• cambio de prioridades de historias de usuario.
• justificación del cambio de prioridades de historias de usuario.
• impedimentos que ponen en riesgo la terminación de alguna tarea.

Minuta de Sprint review.- este documento es la evidencia de lo que se vio en el Sprint review, entre los datos que podemos ver se encuentran los siguientes:

• historias de usuario terminadas.
• oportunidades de mejora.
• necesidades para el siguiente Sprint.
• decisión del product owner sobre la liberación del producto.

Bitácora de liberación.- este documento lleva un control de las liberaciones realizadas, así como de los fallos que se han presentado Al momento de ejecutar las liberaciones.

Minuta de Sprint retro.- este documento es la evidencia de lo que se vio en el Sprint retro, entre los datos que podemos ver se encuentran los siguientes:

• riesgos detectados en la iteración que terminó.
• plan de mitigación de los riesgos detectados.
• oportunidades de mejoras para el siguiente Sprint.