2. 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

3. ¿CÓMO SURGE?

4. 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.

5. 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

6. 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

7. DE DONDE PROCEDE 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.

8. QUE ES SCRUM
Scrum es un proceso
iterativo e incremental que
puede ser utilizado para
desarrollar cualquier
producto o administrar
cualquier trabajo.

9. 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
 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

10. 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

11. 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

12.  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

13.  Auto – gestionado
Auto – organizado
 Multifuncional
 Transforman los requerimientos en funcionalidad en cada
incremento

14.  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

16. 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).

17.  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 )

18.  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.

20. SPRINT

21. SPRINT PLANNING MEETING
(REUNION DE PLANEAMIENTO
DEL SPRINT)

22. 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

23. 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

25. 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. 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.

28. EL SPRINT

30. AL FINAL DEL SPRINT, SE REALIZA
UNA REUNIÓN DE REVISIÓN DE
SPRINT, LLAMADA SPRINT REVIEW

31. 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.

33. DESPUÉS DEL SPRINT REVIEW Y
ANTES DE LA PROXIMA SPRINT
PLANNING MEETING, EL
SCRUMMASTER CONVOCAA UNA
SPRINT RETROSPECTIVE DEL
SPRINT
CON EL TEAM.

34. SPRINT RETROSPECTIVE
3 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.

36. Pila de producto: son la funcionalidad del sistema priorizada

38. 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