REALIZADO POR:

ALVARO MERIÑO VPHLLIS SOLANO M

PRESENTADO A:WILKIS GOMEZ DE LA HOZ

UNIVERSIDAD REMINGTON

FACULTAD DE INGENIERIA DE SISTEMA VIII SEMESTRE

SABANALARGA – ATLCO

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

Intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados

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 

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 es un proceso iterativo e incremental que puede ser utilizado para desarrollar cualquier producto o administrar cualquier trabajo.

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

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

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  

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

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 laPila de producto (Product Backlog)-- Funcionalidades

Pila del sprint Nueva funcionalidad

• Product Owner(modificar

cuidando la inversión).

• Stakeholders (usuario, soporte

técnico, administradores,et

c )

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.

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

Las primeras cuatro horas se dedican al Product Owner

Las segundas cuatro horas el equipo planea su propio Sprint

25

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.

27

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.

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.

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

BIBLIOGRAFIA:

http://www.scrumprimer.org/primers/es_scrumprimer20.pdfhttps://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.eWUhttp://es.wikipedia.org/wiki/Scrum