1. Ingeniería del software y
metodologías ágiles
Rodrigo Corral
rcorral@plainconcepts.com
http://geeks.ms/blogs/rcorral
MVP Team System / CSM / CSP
Plain Concepts

2. Ingeniería del software
Integración TDD
ATDD
continua
Mock
Gated
Checkins
SCM Documentación
Comunicación
Calidad Testeo Unitario
ROI
Gestión de la
Construcción
configuración Gestión del
automatizada cambio

3. SOCORRO !
Pruebas unitarias
Gestión de la configuración
Integración continua
Más en próximos capítulos… ;)

4. ¿Qué es la ingeniería del software?

5. ¿Es posible la agilidad sin buenos
fundamentos de ingeniería del software?
Posible, quizás…
Probable… ¡NO!

6. Pruebas unitarias
• La detección más temprana posible
• Demostración de que no hemos roto nada
• Documentación
• Marcador claro de que una tarea está
completada
• Mejora el diseño
• Verifica la correcta corrección de errores
• El tiempo de depuración se reduce

7. Pruebas unitarias
• ¿Cómo son las buenas pruebas unitarias?
– Se ejecuta rápido, se ejecuta rápido, se ejecuta
rápido
– Tiene escasas dependencias
– Su alcance es claro y limitado
– Se ejecutan y pasan de manera independiente.
– Revelan claramente su intención
– Tienen la mayor cobertura posible
– No alteran el estado del sistema

8. Gestión de la configuración
• Desarrollo concurrente y en equipo
• ‘Aislar’ el entorno de pruebas
• Lograr incrementos de funcionalidad
potencialmente entregables
• Habilitar mecanismos ágiles y operativos para
la corrección de errores

9. Desarrollo concurrente y en equipo
Estructura de ramas Estructura de carpetas
DEV-401 $ PROJECT
Antes de comenzar DEV-402 + DEV
a trabajar en una
historia de usuario
creamos una rama
- FEATURES
Branch
Branch
+
RI
RI
sobre la que DEV-401
realizamos el
desarrollo
DEV
+ DEV-402
Concluido el desarrollo de la
historia de usuario, integramos el
código en la rama principal de
desarrollo

10. ‘Aislar’ el entorno de pruebas
Estructura de ramas Estructura de carpetas
DEV-401
$ PROJECT
DEV-402
+ DEV
RI
-
Branch
FEATURES
Branch
RI + DEV-401
DEV
+ DEV-402
Branch
RI
MAIN
+ MAIN
Cuando se cumplen las
Cuando se cumplen las
condiciones de calidad el código
condiciones de calidad el código
en desarrollo se integra en la rama
en desarrollo se integra en la rama
MAIN para que los testers
MAIN para que los testers
comiencen el trabajo de
comiencen el trabajo de
estabilización
estabilización

11. Incrementos de funcionalidad
potencialmente entregables
Estructura de ramas Estructura de carpetas
DEV-401
$ PROJECT
DEV-402
+ DEV
RI
-
Branch
FEATURES
Branch
RI + DEV-401
DEV
+ DEV-402
Branch
RI Fin de Sprint
MAIN
+ MAIN
Usar ramas de característica
Realizar el desarrollo de nuevas
garantiza que a la rama principal,
funcionalidades sobre ramas
sobre la que realizamos la
dedicadas permite que si una
estabilización del software, solo
funcionalidad no se completa a
contendrá características
tiempo para incluirla en el Sprint
completas y que han alcanzado un
Review el resto de la base de
mínimo de calidad que permita
código principal siga siendo
que el trabajo de los testers sea
coherente y no incluya
productivo
características incompletas

12. Corrección de errores
Los errores que no son
urgentes se corrigen
sobre la línea principal
de desarrollo y se llevan
Estructura de ramas a las ramas de release, Estructura de carpetas
si es necesario,
DEV-401 haciendo merge del $ PROJECT
changeset asociado a la
corrección del error
DEV-402
+ DEV
RI
-
Branch
FEATURES
Branch
RI
+ DEV-401
DEV
+ DEV-402
Branch
RI
RI
FI
MAIN + MAIN
Branch
RI
V1.0.1
FI + RELEASE
RELEASE 1.0
Contar con una rama de V1.0 (hotfix) + RELEASE x.y.z
RELEASE nos permite liberar
parches de emergencia, para
‘showstopers’, minimizando los
posibles impactos sobre el entorno
de producción y minimizando las
necesidades de validación por
parte de los testers

13. Construcción automatizada
• Construcción automatizada: patrón ‘one command
complete build’
• ¿Qué es completo?
– Define tu nivel de completo para tu ‘build’.
• Automatiza, automatiza, automatiza.
• Se puede compilar un kernel luego se puede compilar
automáticamente tu proyecto.
• ¡No hay escusas!
• Entorno neutral
– En mi máquina compila.
– En mi máquina pasan los test.
– En mi máquina funciona.

14. Integración continua
• Precondición: construcción automatizada.
• Detección más temprana posible de:
– Errores de integración.
– Regresiones en las pruebas unitarias.
• Evita que la ejecución de los test unitarios se
supedite a la voluntad del desarrollador.
• Debe proteger todas las ramas donde se integra
código.
• Ocurre en cada check-in.
• Si se rompe una build la prioridad es corregirla.

15. Integración continua
Source Control
Client 6
Build
Service Execute Build
1
Check In
Build
Build Drop
Scripts and
Site
Targets
7
2 Store changeset
Source Build Server Copy Binaries
Control Repository
Service
5
Start Build
Source Control
3 8
Poll for changes Build Finished
4
Retrieve latest version
Continous Integration Service Build
Store
9
Continuous Integration Server Store Build Data

16. Integración contínua
• Ventajas:
– Los problemas de integración se detectan y
corrigen continuamente.
– Alerta temprana de código erroneo/incompatible.
– Test unitario inmediato de todos los cambios.
– Disponibilidad total de una build “actual” para una
demo de pruebas o para ser liberada.
– El impacto inmediato del check in de código
erroneo actua como actua como incentivo para no
meter la pata.

17. Integración contínua
• Inversiones:
– Necesita mucho mantenimiento.
– Necesita servidores de compilación.
– El impacto de los fallos actua como incentivo
negativo para hacer check-ins frecuentes (backup
check-in).
– El código erroneo solo se detecta una vez
añadido al repositorio.

18. Gated check-ins
• Cuando se rompe la build
– Es tarde el código ya está integrado
• Todo el equipo se ve afectado
• Alternativa: gated check-ins.

19. ¿Preguntas?