¿cómo surge? metodologías ágiles de desarrollo de software se entiende como desarrollo ágil de...

¿Cómo surge?

Metodologías á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 burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados

Manifiesto por el Desarrollo Ágil de Software

Individuos e interacciones sobre procesos y herramientas

Software que funciona sobre documentación exhaustiva

Colaboración con el cliente sobre negociación 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 compañeros del equipo se amontonan, forman una piña y empujan todos en la misma dirección.

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 rápida Un proceso que controla el caos de conflictos de

intereses y necesidades

Scrum(2)

Una manera de mejorar las comunicaciones y maximizar la cooperación

Una manera de maximizar la productividad Escalable a múltiples proyectos y toda la

organización Una forma que todos se sientan bien con su

trabajo, entendiendo que cada uno con sus contribuciones hizo lo mejor que podía hacer

Diferencias entre metodologías(1)

Metodologías Ágiles Basadas en heurísticas

provenientes de prácticas de producción de código

Especialmente preparados para cambios durante el proyecto

Impuestas internamente (por el equipo)

Proceso mucho más controlado, con numerosas

políticas/normas   No existe contrato tradicional o al

menos es bastante flexible   

Metodologías tradicionales

Basadas en normas provenientes de estándares

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 metodologías(2)

Metodologías Ágiles El cliente interactúa con el equipo

de desarrollo   Grupos pequeños (<10

integrantes) y trabajando en el mismo sitio

 Pocos artefactos Pocos roles Menos énfasis en la arquitectura

del software

Metodologías tradicionales El cliente es parte del equipo de

desarrollo mediante reuniones  Grupos grandes y posiblemente

distribuidos  Más artefactos Más roles  La arquitectura del software es

esencial y se expresa mediante modelos 

Financiación del proyecto Define funcionalidad requerida Retorno de la inversión del proyecto Lanzamiento del proyecto Toma las decisiones de priorización Representa a todos los interesados en el producto final

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

Formación y entrenamiento de procesos Incorporación de Scrum en la cultura del equipo Garantía de cumplimiento de roles y responsabilidades Remueve impedimentos Facilitador Asegura que se cumpla Scrum

Product OwnerRepresenta los intereses del

cliente dentro de la empresa.

Es el nexo entre el cliente y el equipo.

Tiene la visión global del producto buscado..

Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de requerimientos).

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

Selección de laPila de producto (Product Backlog)-- Funcionalidades

Pila del sprint Nueva funcionalidad

• Product Owner(modificar cuidando la

inversión).• Stakeholders (usuario,

soporte técnico, administradores,etc )

Listado con los requisitos del sistema. Listado de todas las a implementar. Es dinámico. Mientras exista un producto, el Product Backlog también 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 entrarán 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

Gestión ágil de proyectos: Scrum

24

Pila del sprint (Sprint Backlog)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 duración comprendida entre las 4 y las 16 horas de trabajo.Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo.

26

Gestión ágil de proyectos: Scrum

SprintSprint

Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas “carreras”.

Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas “carreras”.

Duración máxima: 30 días.Durante el sprint no se puede modificar el trabajo que se ha acordado en

el Backlog. Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede

hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes:

La tecnología acordada no funciona. Las circunstancias del negocio han cambiado.El equipo ha tenido interferencias.

El Sprint

Al final del Sprint, se realiza una reunión de revisión de Sprint, llamada Sprint Review

Fin del sprint: Sprint review 4 horas

Reunión donde se presenta al product owner y a los implicados todas las funcionalidades implementadas.

El Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto.

Al final de la reunión se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia.

Después del  Sprint review y antes de la proxima Sprint planning meeting, el ScrumMaster convoca a una Sprint retrospective del Sprint

con el Team.

Sprint retrospective3 horas

El ScrumMaster hace que el Team  revise, su proceso de desarrollo Scrum, para hacerlo más eficaz y eficiente para el próximo Sprint.

El 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 inspección

empírica y prácticas de la adaptación del Scrum.

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 reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores e impulsores de metodologías de software.

• El punto de partida fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”.

• Según el Manifiesto se valora:

• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.

•  Es más importante construir un buen equipo.• Desarrollar software que funciona más que

conseguir una buena documentación.

• “No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”.

• La colaboración con el cliente más que la negociación de un contrato.

• Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

• Responder a los cambios más que seguir estrictamente un plan.

• Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y abierta.