Cmo surge?

Metodologas giles de desarrollo de software

Se entiende como Desarrollo gil de Software a un paradigma de Desarrollo de Software basado en procesos giles.

Procesos giles de desarrollo

Intentan evitar los tortuosos y burocrticos caminos de las metodologas tradicionales enfocndose en la gente y los resultados

Manifiesto por el Desarrollo gil de Software

Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin de contratos Responder ante el cambio sobre seguimiento de un plan

SCRUM
La palabra SCRUM procede del vocabulario del rugby y significa mel; es decir, que los compaeros del equipo se amontonan, forman una pia y empujan todos en la misma direccin.

Scrum(1)

Scrum es un proceso iterativo e incremental que puede ser utilizado para desarrollar cualquier producto o administrar cualquier trabajo. Sus principales atributos son: Un enfoque orientado a que los equipos desarrollen sistemas y productos de manera iterativa e incremental cuando los requerimientos cambian de manera rpida Un proceso que controla el caos de conflictos de intereses y necesidades

Scrum(2)
Una manera de mejorar las comunicaciones y

maximizar la cooperacin Una manera de maximizar la productividad Escalable a mltiples proyectos y toda la organizacin Una forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus contribuciones hizo lo mejor que poda hacer

Diferencias entre metodologas(1)

Metodologas giles

Metodologas tradicionales

Basadas en heursticas provenientes de prcticas de produccin de cdigo Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso mucho ms controlado, con numerosas polticas/normas No existe contrato tradicional o al menos es bastante flexible

Basadas en normas provenientes de estndares Seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente
Proceso menos controlado, con pocos principios Existe un contrato prefijado

Diferencias entre metodologas(2)

Metodologas giles

Metodologas tradicionales

El cliente interacta con el equipo de desarrollo Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos nfasis en la arquitectura del software

El cliente es parte del equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Ms artefactos Ms roles La arquitectura del software es esencial y se expresa mediante modelos

 Financiacin del proyecto

Define funcionalidad requerida Retorno de la inversin del proyecto Lanzamiento del proyecto Toma las decisiones de priorizacin Representa a todos los interesados en el producto final

Auto - gestionado Auto organizado Multifuncional Transforman los requerimientos en funcionalidad en cada incremento

Formacin y entrenamiento de procesos Incorporacin de Scrum en la cultura del equipo Garanta de cumplimiento de roles y responsabilidades Remueve impedimentos Facilitador Asegura que se cumpla Scrum

Product Owner
Representa los intereses del cliente dentro de la empresa.
Es el nexo entre el cliente y el equipo.
Tiene la visin global del producto buscado. Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de requerimientos).

Pila del sprint

Nueva funcionalidad

Seleccin de la Pila de producto (Product Backlog) -- Funcionalidades

Pila de producto -- Requisitos priorizados. -- Listado con los requisitos del sistema.

Product Owner (modificar cuidando la inversin). Stakeholders (usuario, soporte tcnico, administradores,etc )

Listado con los requisitos del sistema. Listado de todas las a implementar. Es dinmico. Mientras exista un producto, el Product Backlog tambin existe.

sprint

Sprint Planning Meeting (Reunion de planeamiento del Sprint)

Sprint Planning
Los Sprints duran, idealmente, menos de un mes. Se seleccionan los requerimientos del Product Backlog que entrarn en el sprint. Se hace un listado de todas las tareas necesarias para terminar el sprint backlog, indicando el esfuerzo de cada una. Se asignan responsables a las tareas

Se divide en 2 partes y son:

Las primeras cuatro horas se dedican al Product Owner Las segundas cuatro horas el equipo planea su propio Sprint

Gestin gil de proyectos: Scrum

Pila del sprint (Sprint Backlog)

Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad. Se recomienda que las tareas reflejadas tengan una duracin comprendida entre las 4 y las 16 horas de trabajo. Las de mayor duracin deben intentar descomponerse en sub-tareas de ese rango de tiempo.
24

Gestin gil de proyectos: Scrum

Sprint Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el ncleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeas carreras.

Duracin mxima: 30 das. Durante el sprint no se puede modificar el trabajo que se ha acordado en
el Backlog. Slo es posible cambiar el curso de un sprint, abortndolo, y slo lo puede hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes: La tecnologa acordada no funciona. Las circunstancias del negocio han cambiado. El equipo ha tenido interferencias.

26

El Sprint

Al final del Sprint, se realiza una reunin de revisin de Sprint, llamada Sprint Review

Fin del sprint: Sprint review

4 horas
Reunin

donde se presenta al product owner y a los implicados todas las funcionalidades implementadas. Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto. final de la reunin se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia.

El

Al

Despus del Sprint review y antes de la proxima Sprint planning meeting, el ScrumMaster convoca a una Sprint retrospective del Sprint con el Team.

Sprint retrospective
3 horas
El

ScrumMaster hace que el Team revise, su proceso de desarrollo Scrum, para hacerlo ms eficaz y eficiente para el prximo Sprint. ScrumMaster no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum.
En conjunto, Sprint planning meeting, Daily Scrum, Sprint review, y el Sprint retrospective, constituyen la inspeccin emprica y prcticas de la adaptacin del Scrum.

El

Pila de producto: son la funcionalidad del sistema priorizada

SPRINT

Sala de Desarrollo

El manifiesto gil y su incidencia en el desarrollo de software

En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores e impulsores de metodologas de software. El punto de partida fue el Manifiesto gil, un documento que resume la filosofa gil.

Segn el Manifiesto se valora:

 Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Es ms importante construir un buen equipo. Desarrollar software que funciona ms que conseguir una buena documentacin.

No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante.

 La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. Se debe ser hbil en responder a los cambios y a los fracasos, la planificacin no debe ser estricta sino flexible y abierta.