REALIZADO POR:

ALVARO MERIÑO V

PHLLIS SOLANO M

PRESENTADO A:

WILKIS GOMEZ DE LA HOZ

UNIVERSIDAD REMINGTON

FACULTAD DE INGENIERIA DE SISTEMA VIII SEMESTRE

SABANALARGA – ATLCO

¿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áticoscaminos de las metodologías tradicionalesenfocá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

DE DONDE PROCEDE SCRUM

La palabra SCRUMprocede del vocabulariodel rugby y significamelé; es decir, que loscompañeros del equipose amontonan, formanuna piña y empujantodos en la mismadirección.

QUE ES SCRUM

Scrum es un procesoiterativo e incremental quepuede ser utilizado paradesarrollar cualquierproducto o administrarcualquier trabajo.

SUS PRINCIPALES ATRIBUTOS SON:

Un enfoque orientado a que los equipos desarrollen sistemas yproductos de manera iterativa e incremental cuando losrequerimientos cambian de manera rápida

Un proceso que controla el caos de conflictos de intereses ynecesidades

Una manera de mejorar las comunicaciones y maximizar lacooperació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, entendiendoque cada uno con sus

contribuciones hizo lo mejor que podía hacer

DIFERENCIAS ENTRE

METODOLOGÍAS(1)

Metodologías Ágiles

Basadas en heurísticasprovenientes de prácticas deproducción de código

Especialmente preparados paracambios durante el proyecto

Impuestas internamente (por elequipo)

Proceso mucho máscontrolado, con numerosas

políticas/normas No existe contrato tradicional o

al menos es bastante flexible

Metodologías tradicionales

Basadas en normasprovenientes de estándares

Seguidos por el entorno dedesarrollo

Cierta resistencia a los cambios

Impuestas externamente

Proceso menos controlado, conpocos 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 equipode desarrollo mediantereuniones

Grupos grandes yposiblemente distribuidos

Más artefactos

Más roles

La arquitectura del softwarees esencial y se expresamediante 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 cadaincremento

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

OWNER

Es el nexo entre el cliente y el equipo.

Representa los intereses del cliente

dentro de la empresa.

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 la

Pila 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 unmes.

Se seleccionan los requerimientos del ProductBacklog que entrarán en el sprint.

Se hace un listado de todas las tareasnecesarias 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

25

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.

27

GESTIÓN ÁGIL DE PROYECTOS: SCRUM

Sprint

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 REVIEW4 HORAS

Reunión donde se presenta al product owner y alos implicados todas las funcionalidadesimplementadas.

El Product owner trata con los asistentes y con elteam las posibles modificaciones en la pila deproducto.

Al final de la reunión se interrogaindividualmente a todos los asistentes pararecabar impresiones, sugerencias de cambio ymejora, 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, suproceso de desarrollo Scrum, para hacerlo máseficaz y eficiente para el próximo Sprint.

El ScrumMaster no proporcionarespuestas, sino que ayuda al equipo aencontrar la mejor forma de trabajar conScrum.

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

BIBLIOGRAFIA:

http://www.scrumprimer.org/primers/es_scrumprimer20.pdf

https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fwww.cs.umss.edu.bo%2Fdoc%2Fmaterial%2Fmat_gral_130%2Fscrum_diapositivas.ppt&ei=qvpNUqf-I5HY9QSUsYCACA&usg=AFQjCNEPfEJNswL_huqW8fC-JbyNlMpCGw&bvm=bv.53537100,d.eWU

http://es.wikipedia.org/wiki/Scrum