Upload
phillisdejesus
View
98
Download
3
Tags:
Embed Size (px)
Citation preview
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