ALM con Scrum: una guía práctica para equipos .NET

El ALM no son solo herramientas: es una disciplina

La gestión del ciclo de vida de las aplicaciones (ALM, Application Lifecycle Management) es la disciplina integral de gestionar el software desde su concepción hasta su retirada. Para los equipos .NET, el ALM abarca la recopilación de requisitos, la arquitectura, el desarrollo, las pruebas, el despliegue, el mantenimiento y la gobernanza, todo ello coordinado mediante un proceso definido.

Scrum aporta el marco iterativo. El ALM aporta la disciplina. Juntos, ofrecen a los equipos .NET un camino repetible desde la idea hasta la producción, con visibilidad en cada paso.

Esta guía se basa en más de 15 años entregando proyectos .NET con Scrum. Cubre el ciclo de vida completo, las opciones de herramientas (Azure DevOps, GitHub, Visual Studio) y las métricas que realmente predicen el éxito de la entrega, no las métricas de vanidad.

El marco del ALM: cinco fases, un mismo ritmo

El ALM divide la entrega de software en cinco fases interconectadas que se corresponden directamente con la cadencia de Scrum:

La idea clave: las fases del ALM no son cascadas secuenciales. Se ejecutan de forma concurrente dentro de cada sprint. Al final de un sprint tienes software funcional, probado y potencialmente entregable, no solo "código terminado".

Fase 1: requisitos y planificación que de verdad funcionan

El Product Backlog: más que una lista

Un product backlog saludable es la base de un ALM eficaz. Para los equipos .NET, cada elemento del backlog debería incluir:

• Historia de usuario: "Como [rol], quiero [funcionalidad] para [resultado]."
• Criterios de aceptación: Condiciones específicas y comprobables que definen lo que está "terminado". Usa el formato Dado/Cuando/Entonces para mayor claridad.
• Notas técnicas: Decisiones de arquitectura, cambios en el esquema de base de datos, contratos de API, impactos en paquetes NuGet.
• Estimación: Puntos de historia u horas ideales. Recomendamos usar puntos de historia basados en la complejidad, el esfuerzo y la incertidumbre, no en el tiempo.
• Dependencias: Otros elementos del backlog, servicios externos, API de terceros o cambios de infraestructura de los que depende este elemento.

Planificación del sprint: la reunión de compromiso

La planificación del sprint tiene dos partes:

Parte 1 — Qué: El Product Owner presenta los elementos del backlog de mayor prioridad. El equipo formula preguntas aclaratorias y negocia el alcance. Resultado: un objetivo del sprint, un resumen en una frase de lo que entrega el sprint.

Parte 2 — Cómo: El equipo descompone cada elemento del backlog en tareas (normalmente de 2 a 8 horas cada una). En los proyectos .NET, las tareas suelen incluir: migración de base de datos, implementación de endpoints de API, capa de servicios, pruebas unitarias, pruebas de integración, componente de frontend, revisión de código y actualización de la documentación.

Antipatrones de planificación que conviene evitar:

• Tareas como "Escribir el código de la funcionalidad X": demasiado vagas. Descomponlas en entregables concretos.
• Planificar al 100 % de la capacidad: deja un margen del 20-30 % para trabajo imprevisto, errores y colaboración.
• Ignorar la deuda técnica: asigna al menos un elemento del backlog por sprint a la refactorización o a la reducción de deuda.

Fase 2: desarrollo, donde el código se encuentra con el proceso

Estrategia de ramas para equipos .NET

Recomendamos un modelo de desarrollo basado en trunk con ramas de funcionalidad de corta duración:

master (always deployable)
  └── feature/dotnet9-migration (1-3 days)
  └── feature/payment-plugin-pix (1-3 days)
  └── fix/checkout-null-reference (hours)

Reglas:

• Crea la rama a partir del último master y fusiónala de vuelta en un máximo de 3 días.
• Un PR por funcionalidad o error. Los PR pequeños se revisan más rápido y se fusionan antes.
• Cada PR debe superar la CI (compilación + pruebas) antes de la revisión.
• Exige al menos una aprobación. Todos los comentarios de la revisión deben resolverse antes de la fusión.
• Usa squash-merge para mantener limpio el historial de master.

Estándares de revisión de código para .NET

Las revisiones de código deberían comprobar:

• Corrección: ¿El código implementa los criterios de aceptación? ¿Se gestionan los casos límite?
• Seguridad: Sin secretos codificados en el código. Validación de entradas. Prevención de inyección SQL. Comprobaciones de autenticación adecuadas en los endpoints.
• Rendimiento: Sin consultas N+1. Asíncrono de principio a fin. Caché apropiada. Agrupación de conexiones (connection pooling).
• Testabilidad: La lógica reside en servicios inyectables, no en métodos estáticos ni en controladores. Las dependencias se abstraen tras interfaces.
• Convención: Sigue las convenciones de nomenclatura del proyecto, la estructura de carpetas y los estándares de codificación.

Daily Scrum: no es un informe de estado

El daily scrum es una reunión de coordinación, no una herramienta de microgestión. Cada miembro del equipo responde: qué completé ayer, qué completaré hoy y qué me está bloqueando. Si surge un bloqueo, el Scrum Master lo resuelve fuera del daily scrum. La reunión debería durar 15 minutos, no 45.

Fase 3: integración continua, automatízalo todo

El pipeline de CI para proyectos .NET

Cada commit a una rama de funcionalidad debería desencadenar:

1. Restore: dotnet restore: resuelve las dependencias NuGet. Cachea los paquetes para ganar velocidad.
2. Build: dotnet build --configuration Release --no-restore: compila con optimizaciones. Trata las advertencias como errores.
3. Test: dotnet test --no-build --configuration Release: ejecuta todas las pruebas unitarias y de integración. Haz que la compilación falle si falla una prueba.
4. Analyze: Ejecuta StyleCop, SonarQube o los analizadores de .NET. Bloquea la fusión si se introducen nuevas advertencias.
5. Package: Para bibliotecas: dotnet pack. Para aplicaciones: dotnet publish. Para Docker: docker build.

Ejemplo: pipeline YAML de Azure DevOps

trigger:
  branches:
    include:
      - master
      - feature/*
      - fix/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    version: '9.x'

- script: dotnet restore
  displayName: 'Restore packages'

- script: dotnet build --configuration $(buildConfiguration) --no-restore
  displayName: 'Build solution'

- script: dotnet test --no-build --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"
  displayName: 'Run tests'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Pruebas de verificación de compilación (BVT)

Más allá de las pruebas unitarias, incluye un pequeño conjunto de smoke tests que se ejecuten como parte de la CI: verifica que la aplicación arranca, que la base de datos se conecta, que los principales endpoints de la API devuelven 200 y que los recorridos de usuario críticos funcionan. Estas pruebas detectan problemas de entorno y configuración que las pruebas unitarias no pueden ver.

Fase 4: pruebas y calidad, más allá de "funciona en mi máquina"

La pirámide de pruebas de .NET

Principio de pruebas: Escribe las pruebas en el nivel más bajo que te dé confianza. No todas las funcionalidades necesitan una prueba E2E: una capa de servicios bien probada, con pruebas de integración para la capa de base de datos, detecta la mayoría de los errores de forma más rápida y fiable que la automatización de navegador.

Sprint Review: demostrar software funcional

El sprint review es una demostración de software funcional y probado, no una presentación de diapositivas. Muestra las funcionalidades tal como las verán los usuarios. Recoge feedback directamente. Actualiza el backlog en función de lo que aprendas. Si una funcionalidad no se puede demostrar, no estaba terminada.

Fase 5: publicación y operaciones, de terminado a desplegado

Gestión de versiones para .NET

Las publicaciones deberían ser aburridas: automatizadas, predecibles y reversibles. Este es el flujo que usamos en SplatDev:

1. Incremento de versión: Versionado semántico (MAJOR.MINOR.PATCH). Increméntala durante el sprint a medida que llegan las funcionalidades, no en el momento de la publicación.
2. Rama de publicación: Créala a partir de master con la etiqueta de versión. Solo los hotfixes se fusionan en las ramas de publicación.
3. Despliegue en staging: Despliegue automatizado a un entorno de staging que replica producción. Ejecuta la suite de regresión.
4. Smoke test: Verificación manual de las rutas críticas en staging. Captura evidencias con capturas de pantalla.
5. Despliegue en producción: Despliegue blue-green o canary. Monitoriza las tasas de error, los tiempos de respuesta y las métricas de negocio durante los 30 minutos posteriores al despliegue.
6. Verificación posterior al despliegue: Confirma el despliegue con la lista de comprobación de la publicación. Actualiza las notas de la versión.

Monitorización: entérate antes de que te lo digan tus usuarios

La monitorización de producción forma parte del ALM: no has terminado cuando despliegas, has terminado cuando has confirmado que el sistema está sano. Métricas clave para las aplicaciones .NET:

• Errores de la aplicación: Excepciones no controladas, respuestas 500. Alerta de inmediato.
• Tiempos de respuesta: Latencia P50, P95, P99 por endpoint. Alerta ante degradaciones.
• Throughput: Solicitudes por segundo. Alerta ante anomalías.
• Uso de recursos: CPU, memoria, pausas del GC, agotamiento del thread pool. Vigila las fugas.
• Métricas de negocio: Pedidos realizados, pagos procesados, registros completados. Estos son tus verdaderos indicadores de salud.

Usa Application Insights (Azure), Datadog o Prometheus + Grafana para la monitorización de .NET. Registra en un sistema de logging estructurado (Serilog + Seq/Elasticsearch); nunca depures a partir de la salida de consola de producción.

Métricas de Scrum que de verdad predicen el éxito

La mayoría de las métricas de Scrum son de vanidad. Estas son las que se correlacionan con los resultados de entrega:

Lead time y cycle time

Lead time: Tiempo desde la creación de un elemento del backlog hasta el despliegue. Cycle time: Tiempo desde el inicio del trabajo hasta el despliegue. Cuanto más corto, mejor: significa lotes más pequeños, feedback más rápido y menos trabajo en curso. Objetivo: un cycle time inferior a 5 días para la mayoría de los elementos.

Burndown del sprint (con cautela)

Los gráficos de burndown muestran el trabajo restante frente al tiempo. Un burndown plano durante la primera mitad del sprint seguido de una caída al final significa que tu equipo termina el trabajo tarde y no entrega de forma incremental. El burndown ideal es constante: el trabajo se completa a lo largo de todo el sprint, no solo al final.

Defectos escapados

Errores encontrados en producción que deberían haberse detectado antes. Es la métrica de calidad más importante de todas. Si tu número de defectos escapados no tiende hacia cero, tu Definición de Terminado o tu estrategia de pruebas son insuficientes.

Frecuencia de despliegue

Con qué frecuencia despliegas a producción. Los equipos de élite despliegan varias veces al día. Para la mayoría de los equipos .NET, desplegar al menos una vez por sprint es un buen objetivo. Si despliegas con menos frecuencia, estás acumulando demasiado riesgo en cada lote.

Retrospectiva del sprint: ciclos de feedback que de verdad cambian las cosas

La retrospectiva es la ceremonia de Scrum más importante, y la que se omite con más frecuencia. Hazla en cada sprint. Formula tres preguntas: qué fue bien, qué fue mal y qué cambiaremos el próximo sprint. Después, y esto es crucial, elige UNA acción y llévala a cabo. Nada destruye el valor de la retrospectiva más rápido que discutir los mismos problemas sprint tras sprint sin ningún cambio.

Herramientas: el stack de ALM para .NET

Azure DevOps (recomendado para equipos .NET empresariales)

Azure DevOps ofrece una suite de ALM integrada: Azure Boards (gestión del backlog, planificación de sprints, tableros), Azure Repos (alojamiento Git con políticas de ramas), Azure Pipelines (CI/CD con soporte de primera clase para .NET), Azure Test Plans (pruebas manuales y exploratorias) y Azure Artifacts (alojamiento de paquetes NuGet). Para los equipos que ya están en Azure, la integración es perfecta.

GitHub + GitHub Actions (recomendado para proyectos de código abierto y equipos modernos)

GitHub ofrece Projects para la gestión del backlog, Issues para el seguimiento del trabajo, Actions para CI/CD y Packages para el alojamiento de NuGet. GitHub Advanced Security añade escaneo de código, escaneo de secretos y revisión de dependencias. Para los equipos que no necesitan la profundidad de Azure Boards, GitHub ofrece una experiencia más sencilla y más centrada en el desarrollador.

Visual Studio + VS Code

Visual Studio Enterprise incluye funciones de ALM: diagramas de arquitectura, IntelliTest (generación automática de pruebas), validación de dependencias en vivo y detección de clones de código. Para los equipos que valoran estas herramientas, la licencia Enterprise se amortiza sola gracias al tiempo de depuración que ahorra.

Primeros pasos: un plan de implementación de ALM en 30 días

1. Semana 1: Configura tu cadena de herramientas: Azure DevOps o GitHub, pipeline de CI, framework de pruebas. Define tu Definición de Terminado.
2. Semana 2: Rellena el product backlog. Haz tu primera planificación de sprint. Establece el ritmo del Daily Scrum.
3. Semana 3: Completa el primer sprint. Demuestra software funcional. Haz la retrospectiva. Mide la línea base de tu cycle time y de tus defectos escapados.
4. Semana 4: Despliega a producción (o a staging si las políticas lo exigen). Revisa las métricas. Ajusta el proceso en función de la retrospectiva. Repite.

El objetivo no es un Scrum perfecto, sino un proceso que produzca software funcional de forma predecible y visible. Empieza de forma sencilla, mídelo todo y mejora de forma incremental.

Cómo entrega SplatDev con ALM + Scrum

Llevamos entregando proyectos .NET desde 2009, antes de que Scrum se generalizara y antes de que existiera Azure DevOps. Nuestra práctica de consultoría de ALM ayuda a los equipos a adoptar las prácticas descritas en esta guía: gestión del backlog, disciplina de sprint, configuración de pipelines de CI/CD, automatización de pruebas y gestión de versiones.

Ofrecemos consultoría de ALM para equipos .NET de cualquier tamaño, desde una startup de 3 personas hasta un equipo empresarial de 50. Nuestros proyectos suelen incluir: evaluación del proceso, configuración de herramientas, coaching de sprints (ejecutamos 2 o 3 sprints junto a tu equipo) y una transición hacia la autosuficiencia.

¿Quieres entregar software .NET más rápido, con menos errores y menos estrés? Hablemos de tu proceso actual y de dónde ALM + Scrum pueden tener el mayor impacto.

Solicita consultoría de ALM

O contáctanos: [email protected]