git with scrum en español

¿Cómo Git favorece los

procesos de desarrollo Scrum?

Ing. Ramon González De la Calle

Web: El Catalejo de Rami

vs

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.

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

¿Qué es un Sprint?

¿Qué propone Scrum?

MVP

Version: 1.0

Ver.: 1.5

Ver.: 2.0

Ver.: 3.0

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”

Sprints & Product Backlog

Amortiguadores

Motor

Sistema Eléctrico

Carrocería

Ruedas

Chasis

Sprint 1 MVP

Minimum Valuable Product

Ver.: 1.0

Nuevo

Amortiguadores

Motor

Sistema Eléctrico

Carrocería

Ruedas

Chasis

Sprint 2 Nuevo

Sprints & Product Backlog

Ver.: 1.5 (actualización)

Mejora

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

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

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.

¿Qué pasa si no gestionamos el

cambio correctamente?

Dependencias

Desarrollador

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.

¿Qué necesito?

1. Recordar uno de los principios del desarrollo

Ágil:

Integración Constante

2. Una herramienta efectiva:

Git

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

¿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

¿Quién usa Git?

Sistema Centralizado

• Subversion

• Perforce

• CVS

• ClearCase

Sistema Distribuido

• Git

• Mercurial

• Fossil

• Bazaar

Áreas de trabajo de Git

Á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

Áreas de trabajo de Git

• Para pasar los archivos al área de preparación se

usa el comando:

$ git add home.html

Áreas de trabajo de Git

• Para crear confirmaciones (commits) se usa el

comando:

$ git commit –m “Página home diseñada y lista”

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

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

¿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

Branching (ramas)

El puntero HEAD apunta a la rama en

la que te encuentras actualmente.

Branching (ramas)

Para cambiar de rama se usa el comando:

$ git checkout testing

Branching(ramas)

Avanzando en una rama creando nuevos

commits.

$ git commit –m “User Story 1 Tests Passed!”

Branching(ramas)

Volviendo a la rama master

$ git checkout master

Branching(ramas)

Avanzando un poco más en la rama master

$ git commit –m “User Story 2 ready!”

Merging (ramas)

$ git merge testing

• Fusión a tres bandas: las dos puntas de

las ramas y el ancestro en común.

Merging (ramas)

• Una nueva confirmación es creada avanzando la rama

destino hasta ella. En este caso master

Uso de Git con Scrum

Ver.: 1.5

Ver.: 2.0

Ver.: 3.0

MVP

Version: 1.0

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

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

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

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

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.

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

Muchas Gracias.