Introducción de Metologías Ágiles y SCRUM

1. Introducción a
SCRUM
Ing. Eddie Malca Vicente
@emalca emalca@iluminatic.com
emalca@concytec.gob.pe
/iluminatic emalca@gmail.com

2. Problemas existentes en los
proyectos de Software
• Requerimientos del usuario fuera de control
• No se cumplen los tiempos planificados inicialmente
• Estimaciones deficientes
• Trabajo excesivo
• Baja calidad del producto final
• Costos excedidos en lo original
• Clientes insatisfechos
• Miembros del equipo insatisfechos

3. Metodologías Ágiles
• Se entiende como Desarrollo ágil de Software a un
paradigma de Desarrollo de Software basado en procesos
ágiles.

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

5. El Manifiesto Ágil
• El 17 de febrero de 2001, 17 críticos de los modelos de mejora
del desarrollo de SW bajo la batuta de Kent Beck, se reunieron en
Snowbird, Utah para tratar sobre técnicas y procesos para
desarrollar software.
• En la reunión se acuñó el término “Métodos Ágiles” para definir a
los métodos que estaban surgiendo como alternativa a las
metodologías formales a las que consideraban excesivamente
“pesadas” y rígidas por su carácter normativo y fuerte
dependencia de planificaciones detalladas previas al desarrollo.
• Los integrantes de la reunión resumieron los principios sobre los
que se basan los métodos alternativos en cuatro postulados, lo
que ha quedado denominado como Manifiesto Ágil.
www.agilemanifiesto.org

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. 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.
www.scrumalliance.org

8. SCRUM
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.

9. SCRUM
• 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
Metodologías Ágiles Metodologías tradicionales
• Basadas en heurísticas • Basadas en normas provenientes
provenientes de prácticas de de estándares.
producción de código.
• Seguidos por el entorno de
• Especialmente preparados para desarrollo.
cambios durante el proyecto.
• Cierta resistencia a los cambios
• Impuestas internamente (por el
equipo). • Impuestas externamente.
• Proceso mucho más controlado,
con numerosas políticas/normas. • Proceso menos controlado, con
pocos principios.
• No existe contrato tradicional o al
menos es bastante flexible. • Existe un contrato prefijado.

11. Diferencias entre metodologías
Metodologías Ágiles Metodologías tradicionales
• El cliente interactúa con el equipo • El cliente es parte del equipo de
de desarrollo. desarrollo mediante reuniones.
• Grupos pequeños (<10
• Grupos grandes y posiblemente
distribuidos.
integrantes) y trabajando en el
• Más artefactos.
mismo sitio.
• Más roles.
• Pocos artefactos. • La arquitectura del software es
• Pocos roles. esencial y se expresa mediante
• Menos énfasis en la arquitectura modelos.
del software.

12. Roles
• 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. Roles
• Auto - gestionado
• Auto – organizado
• Multifuncional
• Transforman los requerimientos en funcionalidades.

14. Roles
• 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.

15. Product Owner
• Representa 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).

16. Product Backlog
Pila del sprint Nueva
funcionalidad
Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades
• Product Owner
(modificar cuidando la
inversión).
Pila de producto
• Stakeholders (usuario,
-- Requisitos priorizados.
soporte técnico,
-- Listado con los requisitos
administradores,etc )
del sistema.

17. Product Backlog
• 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.

18. Product Backlog

19. Sprint Planning Meeting
(Reunion de Planeamiento del Sprint)

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

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

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

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

26. El Sprint

27. El Sprint

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

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

31. Fin del Sprint: Sprint review
4 horas
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.

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

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

36. SPRINT

37. Sala de Desarrollo

40. 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:

41. El manifiesto Ágil y su incidencia en
el desarrollo de software
• 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”.

42. El manifiesto Ágil y su incidencia en
el desarrollo de software
• 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.

43. Introducción a
SCRUM
Ing. Eddie Malca Vicente
@emalca emalca@iluminatic.com
emalca@concytec.gob.pe
/iluminatic emalca@gmail.com