Plataformas holográficas unidas por anillos verdes y dorados, metáfora de la metodología ágil con un proveedor externo
Software / APIs

Metodología Ágil con un Proveedor Externo de Software

Codezone
Codezone Empresa de Desarrollo Web y Software a Medida

Aplicar metodología ágil con un proveedor externo funciona cuando tu empresa designa un product owner con autoridad para decidir y el proveedor entrega software funcionando en sprints de un mes o menos. Antes de empezar, ambas partes pactan cuándo una entrega está terminada y cómo encajan los cambios en el presupuesto. Es el marco que conviene acordar en cualquier proyecto de software a medida con Codezone.

Un proyecto ágil mal planteado con un proveedor externo acaba con el cliente convencido de que puede cambiarlo todo sin coste y el proveedor facturando horas sin compromiso de entrega. Las discusiones de alcance aparecen en la factura, cuando ya no tienen arreglo, y el riesgo final es tener que rescatar un proyecto de software abandonado a mitad de camino.

Al terminar sabrás qué pactar para que sprints y presupuesto convivan, y cuándo te conviene un CTO externo que represente a tu empresa en Madrid frente al proveedor.

Qué es la metodología ágil con un proveedor externo

La metodología ágil con un proveedor externo consiste en organizar el desarrollo en iteraciones cortas en las que el proveedor entrega software funcionando y tu empresa lo revisa y decide qué viene después. Un marco de referencia es la Scrum Guide 2020 de Schwaber y Sutherland, que fija sprints de un mes o menos.

El Manifiesto Ágil de 2001 valora la "colaboración con el cliente sobre negociación contractual". El contrato sigue haciendo falta, y además debe regular cómo se decide durante el proyecto.

Anillo holográfico verde formado por segmentos de luz que giran alrededor de un núcleo dorado sobre un suelo reflectante
Cada vuelta del ciclo termina con software que se puede revisar.

Roles y Reuniones que Debes Cubrir desde tu Empresa

El rol que tu empresa no puede delegar en el proveedor es el product owner. La Scrum Guide 2020 lo define como una persona, no un comité, responsable de gestionar el Product Backlog.

  • Product owner (tu empresa): ordena prioridades y acepta entregas. Llega mejor preparado si antes has mapeado los procesos que el software va a cubrir.
  • Equipo de desarrollo (proveedor): estima y construye el incremento de cada sprint.
  • Planificación del sprint: el product owner trae las prioridades y el equipo compromete lo que cabe.
  • Sprint Review o demo: según la guía, sirve para inspeccionar el resultado del sprint y decidir adaptaciones. Pide la demo sobre el entorno real y no sobre diapositivas.

Definición de Hecho y Criterios de Aceptación

La definición de hecho es la lista común de condiciones de calidad que cumple cualquier incremento, y los criterios de aceptación son las condiciones concretas de cada historia. La Scrum Guide 2020 la describe como la descripción formal del estado del incremento cuando cumple las medidas de calidad requeridas.

Una definición de hecho razonable para un proveedor externo incluye código revisado por otra persona, pruebas automáticas en verde, despliegue en el entorno de preproducción y la documentación técnica que el proveedor debe entregarte actualizada.

Imagina una distribuidora que pide exportar pedidos a Excel. Un criterio de aceptación verificable sería: dado un rango de fechas, el fichero contiene todos los pedidos de ese rango con su importe total, y se genera en menos de diez segundos con el volumen actual.

Puerta holográfica dorada que solo deja pasar bloques de luz verde ya completos, con fragmentos de cristal flotando
La definición de hecho filtra lo que cuenta como entregado.

Cambios de Alcance con Presupuesto Cerrado o Bolsa de Horas

Los cambios de alcance encajan en un presupuesto cerrado si se intercambian por elementos de tamaño equivalente, y en una bolsa de horas si se consumen del saldo con aprobación previa.

  • Presupuesto cerrado con alcance priorizado: Cuándo sí: necesitas precio y fecha para un primer lanzamiento. Cuándo no: el producto aún no está definido. Como referencia, Codezone publica rangos de 6.000 a 15.000 € para complejidad media y de 25.000 a 60.000 € o más para complejidad alta. Revisa también cómo se arma un presupuesto de software pensado para CTOs.
  • Bolsa de horas: Cuándo sí: evolución continua de un producto ya en producción. Cuándo no: necesitas un compromiso de fecha para un hito concreto.
  • Modelo mixto: Cuándo sí: primera versión cerrada y evolución posterior por bolsa. Cuándo no: nadie en tu empresa puede priorizar cada semana.

Para contrastar cifras, consulta cuánto cuesta desarrollar software a medida este año y los tiempos reales por fase de un proyecto a medida. Al elegir equipo, pregunta cómo gestiona estos cambios: es uno de los criterios para valorar a un proveedor de software.

Escalera holográfica verde de barras de luz ascendentes que se abre en un abanico dorado hacia el horizonte
La previsión honesta es un rango de fechas basado en lo que ya ocurrió.
CodeZone Pro Tip: este script calcula la velocidad de los últimos sprints a partir de un CSV y devuelve un rango de fechas de entrega, del escenario optimista al pesimista, para el trabajo pendiente.
import csv
import math
import statistics
import sys
from datetime import date, timedelta

# CSV con columnas sprint,puntos_completados (solo sprints cerrados)
DURACION_SPRINT = 14  # días naturales; ajústalo a la longitud pactada

def prever(ruta, pendiente):
    with open(ruta, newline="", encoding="utf-8") as f:
        historico = [float(fila["puntos_completados"]) for fila in csv.DictReader(f)]
    # Los tres últimos sprints reflejan mejor al equipo actual que todo el histórico
    recientes = historico[-3:]
    if not recientes or min(recientes) <= 0:
        raise ValueError("Histórico vacío o con sprints a cero: revísalo antes de prever")
    escenarios = {
        "Optimista": max(recientes),
        "Media": statistics.mean(recientes),
        "Pesimista": min(recientes),
    }
    for nombre, velocidad in escenarios.items():
        sprints = math.ceil(pendiente / velocidad)
        fin = date.today() + timedelta(days=sprints * DURACION_SPRINT)
        print(f"{nombre:<10} {velocidad:5.1f} pts/sprint -> {sprints} sprints, hacia el {fin}")

if __name__ == "__main__":
    prever(sys.argv[1], float(sys.argv[2]))

La Scrum Guide 2020 recuerda que solo lo que ya ha ocurrido sirve para decidir hacia delante. Con este rango discutes fechas con datos: si el escenario pesimista no llega a la fecha comercial, toca recortar alcance ahora y no en el último sprint.

El Riesgo de Trabajar en Ágil sin Reglas Pactadas

Un proceso ágil sin reglas escritas convierte cada desacuerdo en una negociación desde cero. Dejar por escrito quién decide y cómo se aceptan los cambios es lo que separa iterar de improvisar.

Balanza holográfica dorada equilibrando bloques de luz verde con una esfera de energía blanca sobre un pedestal de cristal
Alcance y presupuesto se equilibran sprint a sprint con reglas pactadas.

Cuando el proyecto entra en producción, la misma lógica se mantiene con un mantenimiento evolutivo por bolsa de horas.

Si vas a contratar desarrollo y quieres pactar estas reglas desde el principio, hablemos de cómo organizar tus sprints.