ALM la parte olvidada de la arquitectura

VSANYWHERE.COM @VS_ANYWHERE

Luis Fraile, CTO, MVP Visual Studio ALM

ALM … la arquitectura olvidada

VSANYWHERE.COM @VS_ANYWHEREVSANYWHERE.COM @VS_ANYWHERE

[email protected]

CTO / Co-founder

MVP Visual Studio ALM

@lfraile - @vs_anywhere

Luis Fraile


Arquitectura …





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

http://www.joelonsoftware.com/articles/fog0000000043.html


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 posibilidadesCloud (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 FoundationTFVC

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 automatizadasIntegració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 preferidaFrecuente: cada x tiempo, ideal para pruebas o despliegues complejos

Empezando desde cero:Integración continua básica, solo compilarIntroduce conjuntos de pruebasDespliegaContinous 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

Pro

gram

min

g h

elp

sC

riticismo

f the

pro

du

ct


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


¡¡¡ Gracias !!!

CONTACTOVS Anywhere

[email protected]

https://vsanywhere.com

TWITTER

@vs_anywhere

TWITTER

Luis Fraile

[email protected]

@lfraile

Technology

ALM la parte olvidada de la arquitectura