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.