Propuesta de cómo las ramificaciones de Git favorecen los procesos de desarrollo Scrum.

1. ¿Cómo Git favorece los
procesos de desarrollo Scrum?
Ing. Ramon González De la Calle
Web: El Catalejo de Rami
vs

2. Punto de partida
Las metodologías de desarrollo ágiles
provocan:
 Una rápida evolución en el proyecto.
 Muchos cambios en los requerimientos,
funcionalidades y en el código.
 Despliegue de varias versiones del
producto, en ocasiones
simultáneamente.

3. ¿Qué es Scrum?
 Framework de gestión de proyectos para el
desarrollo incremental de productos en uno o
más equipos auto-gestionados de alrededor
de 7 personas cada uno.
 Guiado por iteraciones llamadas Sprints
 Cada Sprint debería entregar software
funcional.

4. ¿Qué es un Sprint?

5. ¿Qué propone Scrum?
MVP
Version: 1.0
Ver.: 1.5
Ver.: 2.0
Ver.: 3.0

6. Artefactos de Scrum
Chasis
Amortiguadores
Motor
Sistema Eléctrico
Ruedas
Carrocería
Product Backlog
Item:
• Especifica el “Qué” de un
requerimiento del usuario
• Definición clara de “Terminado”
• Tiene criterios de “Aceptación”

7. Sprints & Product Backlog
Amortiguadores
Motor
Sistema Eléctrico
Carrocería
Ruedas
Chasis
Sprint 1 MVP
Minimum Valuable Product
Ver.: 1.0
Nuevo

8. Amortiguadores
Motor
Sistema Eléctrico
Carrocería
Ruedas
Chasis
Sprint 2 Nuevo
Sprints & Product Backlog
Ver.: 1.5 (actualización)
Mejora

9. Amortiguadores
Motor
Sistema Eléctrico
Carrocería
Ruedas
Chasis
Sprint 3
Ver.: 2.0 (nueva versión)Nuevo
Nuevo
Nuevo
Sprints & Product Backlog
Nuevo
Mejora

10. Amortiguadores
Motor
Sistema Eléctrico
Carrocería
Ruedas
Chasis
Sprint 4
Ver.: 3.0 (nueva version)
Mejora
Mejora
Mejora
Sprints & Product Backlog
Navegación GPS
Mejora
Mejora
Mejora
Nuevo

11. Problemas
• Cada Sprint introduce nuevos componentes.
• Muchos de los componentes ya desarrollados
son mejorados constantemente.
• Nuevas versiones de productos son creadas aún
cuando seguimos manteniendo por algún
tiempo las versiones antiguas.

12. ¿Qué pasa si no gestionamos el
cambio correctamente?
Dependencias
Desarrollador

13. Manifiesto por el Desarrollo de
Software Ágil
Estamos descubriendo mejores formas de desarrollar software
haciéndolo y ayudando a otros a hacerlo. Y hemos aprendido a
valorar:
Individuos e iteraciones sobre procesos y herramientas
Software funcional sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación de contratos.
Responder al cambio sobre seguir un plan
Esto quiere decir que, valoramos los aspectos a la derecha,
pero los de la izquierda los valoramos aún más.

14. ¿Qué necesito?
1. Recordar uno de los principios del desarrollo
Ágil:
 Integración Constante
2. Una herramienta efectiva:
 Git

15. ¿Qué es Git?
• Sistema de Control de Versiones Distribuido
• Origen:
 Es desarrollado para el trabajo en el kernel de
Linux
 Está diseñado para ser usado vía línea de
comandos.

16. ¿Qué es Git?
• Highlights
 Software libre
 Favorece los desarrollos no lineales y
distribuidos
 Gestiona eficientemente proyectos de
larga duración.
 100% funcional en local (offline)
 Usa SHA-1 para escribir la historia

17. ¿Quién usa Git?

18. Sistema Centralizado
• Subversion
• Perforce
• CVS
• ClearCase

19. Sistema Distribuido
• Git
• Mercurial
• Fossil
• Bazaar

20. Áreas de trabajo de Git

21. Áreas de trabajo de Git
• Al crear un archivo este se marca como untracked
• Si editas un archivo este se marca como modified
• Para registrar los cambios es necesario pasarlos al
área de preparación

22. Áreas de trabajo de Git
• Para pasar los archivos al área de preparación se
usa el comando:
$ git add home.html

23. Áreas de trabajo de Git
• Para crear confirmaciones (commits) se usa el
comando:
$ git commit –m “Página home diseñada y lista”

24. Modelo de datos
• Instantáneas de todos los archivos en cada confirmación
• Para mantener la integridad de los datos se usa el
mecanismo de comprobación hash SHA-1

25. Branching (ramas)
• El Branching es la característica más popular de Git
• Diseñado para trabajar de manera modular y aislado.
• Ligero y rápido para crear y mezclar ramas
• La rama por defecto de Git es Master

26. ¿Qué es una rama?
• Una rama es simplemente un puntero móvil que apunta
a una de las confirmaciones.
• Para crear una nueva rama se usa el comando
$ git branch testing

27. Branching (ramas)
El puntero HEAD apunta a la rama en
la que te encuentras actualmente.

28. Branching (ramas)
Para cambiar de rama se usa el comando:
$ git checkout testing

29. Branching(ramas)
Avanzando en una rama creando nuevos
commits.
$ git commit –m “User Story 1 Tests Passed!”

30. Branching(ramas)
Volviendo a la rama master
$ git checkout master

31. Branching(ramas)
Avanzando un poco más en la rama master
$ git commit –m “User Story 2 ready!”

32. Merging (ramas)
$ git merge testing
• Fusión a tres bandas: las dos puntas de
las ramas y el ancestro en común.

33. Merging (ramas)
• Una nueva confirmación es creada avanzando la rama
destino hasta ella. En este caso master

34. Uso de Git con Scrum
Ver.: 1.5
Ver.: 2.0
Ver.: 3.0
MVP
Version: 1.0

35. Flujo de trabajo ramificado
master
Sprint 1 Sprint 2 Sprint 3
Ver.:1.0 Ver.:1.5
Ver.:2.0
Mantener siempre la
rama master “limpia”
No mezclar hasta alcanzar
los criterios de aceptación
Abrir una rama por
cada nueva versión
Proceso Scrum lineal

36. Flujo de trabajo ramificado
master
Sprint 4
Ver.:2.0
Bug 15
La rama master ha sido
“contaminada” con una
mezcla no asegurada.
Ver.: 3.0
Fix merge
Ver.:2.1
Atraso en el tiempo de
entrega.
Ramificaciones imprevistas

37. master
Sprint 4
Ver.:2.0
Bug 15
El objetivo de la rama de
integración es resolver los
conflictos y pasar las pruebas de
integración.
Ver.: 3.0
Ver.:2.1
Integración
Flujo de trabajo ramificado
Ramificaciones imprevistas
Solución

38. Uso de Git con Scrum
Ver.:1.0
master
Sprint 1
Team 1
Sprint 1
Team 2
Ver.:2.0
integración
Cuando se trabaja en equipos en
paralelo la rama de integración
adquiere mas relevancia.
Equipos en paralelo

39. Conclusiones y recomendaciones
1. Prepararse para el cambio es la mejor forma de
responder a él.
2. Los flujos de trabajo ramificados son una de las
ventajas que ofrece Git para trabajar
metodologías ágiles.
3. En procesos Scrum deberíamos crear una rama
para cada Sprint.

40. 3. Es saludable mantener la rama master limpia
de confirmaciones no seguras.
4. No debemos mezclar nuestro trabajo hasta
alcanzar los criterios de aceptación.
5. Crear una rama para cada versión o release.
6. Una rama de integración nos brinda seguridad
en el trabajo.
Conclusiones y recomendaciones

41. Muchas Gracias.