ALM la parte olvidada de la arquitectura

Jose Bonnin. @wasat
Technical Evangelist Manager
Foro de Arquitectos
Julio 2014
Arquitectos
Julio

VSANYWHERE.COM @VS_ANYWHERE
Luis Fraile, CTO, MVP Visual Studio ALM
ALM … la arquitectura olvidada

VSANYWHERE.COM @VS_ANYWHEREVSANYWHERE.COM @VS_ANYWHERE
luis.fraile@vsanywhere.com
CTO / Co-founder
MVP Visual Studio ALM
@lfraile - @vs_anywhere
Luis Fraile

Arquitectura …

VSANYWHERE.COM @VS_ANYWHEREVSANYWHERE.COM @VS_ANYWHERE

¿ALM?

Application Lifecycle Management
Todo lo que pasa en la vida de la aplicación
TODO, desde el principio hasta el fin

Planificar Desarrollar OperarDespliegar
Procesos modernos de ALM

12 preguntas de Spolsky
http://www.joelonsoftware.com/articles/fog0000000043.html
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

La arquitectura de ALM
1. Control de código fuente
2. Builds automatizadas
3. Builds frecuentes: integración continua y/o (al menos) frecuente
4. Información de requisitos, bugs, …
5. ¿Cómo vamos a iterar?¿qué podemos esperar?
6. Herramientas, si, people and interactions first, pero ayúdate de herramientas
7. CALIDAD, en el código, con pruebas cuantas más mejor,
Y también hay que pivotar …

¿Por qué Visual Studio ALM?
Estamos en las oficinas de Microsoft no????
Disponemos de todas las herramientas en un único punto
Es nuestro “único punto de consulta (truth)”
Tenemos dos posibilidades
Cloud (Visual Studio Online)
On-premises (Team Foundation Server)
Hay otros sistemas, buscad y escoger …
Ah bueno y soy MVP de Visual Studio ALM

Control de código fuente

¿De qué tipo?
Ahora se habla mucho de DVCS, especialmente Git
En Team Foundation
TFVC
Git
¿Cuál escoger?
Git: muy potente, especialmente en equipos distribuidos, pero más complejo
TFVC: cualquiera que venga de VSS sabra usarlo
No hay una respuesta concreta

Estrategia de ramas
NO es necesario hacer algo al detalle inicialmente
Pero si algo que nos permita crecer
p.ej.: siempre empezar con un main
Una vez necesitada: NO la compliques
Los merge suelen doler
Y sobre todo
Merge frecuentes, alivian el dolor
Estrategia clara y sencilla de entender por todos

One more thing …
Reglas básicas …
1. Nadie se va a casa con código desprotegido (bueno en Git …)
2. Nadie protege código que no compila
3. Git Stash o Shelvesets (suspend mejor) son tus amigos

¿Un poco de código?

Builds automatizadas
Integración continua, frecuente, …

Compilación automatizada
¿A quién no le ha pasado ir a desplegar y no poder compilar?
Es algo a tener desde el principio
Podemos hacer de dos tipos:
Continua: cada checkin, mi preferida
Frecuente: cada x tiempo, ideal para pruebas o despliegues complejos
Empezando desde cero:
Integración continua básica, solo compilar
Introduce conjuntos de pruebas
Despliega
Continous delivery …

NO es complicado,
no hay excusas
Y si la build se
rompe: se arregla
One more thing

Team Build

Visibilidad y planes

Sabéis responderme
¿cuantos bugs tenéis?
¿cuanto os queda por implementar?
¿cuál es el estado del arte?
¿Cómo va el sprint?
…
Necesitamos esta visibilidad, aunque sea a alto nivel

Esto NO implica
Complicadas estructuras de tareas
Planificaciones detalladas a 6 meses
Estimaciones en minutos de tareas
El gantt de la muerte …

Esto SI implica
Decidir como vamos a trabajar en base
Sprints, duración??
Plan inicial básico de expectativas
Información que vamos a necesitar, burndown? Kanban?
Sobre todo: estar dispuestos a inspeccionar y adaptar

One more thing
Mantenerlo actualizado, sprint plannings, reviews, daily’s ….
Usarlo como algo descriptivo, no prescriptivo.
No está escrito en piedra, está vivo

Un poco de planificación

Calidad

La calidad NO es opcional
Desde el principio, criterios de aceptación, DoD, DoR
Pasando por código, buenas practicas, TDD, BDD, …
Hasta el final con pruebas de UI, manuales, exploratorias …

Definition Of Ready
¿Cuándo está listo un PBI/US/Bug para empezar?
Definir criterios de aceptación
Base para pruebas
Cobertura de pruebas:
TDD, BDD, …
Casos de prueba automatizados

Cuadrantes Agile testing
Unit tests
Components tests
Automated
Functional tests
Examples
Prototypes
Simulations
Automated
Manuals
Exploration tests
Scenarios
Usability testing
User acceptance tests
Manuals
Load tests
Performance tests
Security tests
Tools
Facing the technology
Facing the business
Programminghelps
Criticismoftheproduct

Calidad a vista de pájaro

Conclusiones
Partir de un mínimo de arquitectura ALM
Permitidla crecer durante el proyecto
Inspeccionar y adaptar
NO abandonarla nunca (dolor al recuperarla)
Tiene que ser clara para toda persona involucrada en el equipo
Que proporcione ayuda al equipo día a día

ALM la parte olvidada de la arquitectura

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Similar a ALM la parte olvidada de la arquitectura

Similar a ALM la parte olvidada de la arquitectura (20)

Más de Luis Fraile

Más de Luis Fraile (12)

Último

Último (20)

ALM la parte olvidada de la arquitectura

Notas del editor