La forma en que se ejecuta su proyecto de software determina cuánto cuesta cambiar de opinión más adelante. El desarrollo de software agile mantiene ese precio bajo. Con un plan waterfall tradicional, un nuevo requisito en el cuarto mes implica una solicitud de cambio y una nueva estimación. En agile, el equipo lo añade al siguiente bloque de trabajo de dos semanas. Unas pocas reuniones y un nuevo plan de sprint bastan para que las funcionalidades o los cambios de proyecto que necesita se implementen rápido, con interrupciones mínimas.
El desarrollo de software agile construye un producto en ciclos cortos, normalmente de una a cuatro semanas. Cada ciclo termina con algo que funciona y que usted puede ver, así que el plan se adapta a medida que aprende. Encaja en proyectos cuyos requisitos van a moverse y encaja mal cuando el alcance queda cerrado por contrato o por normativa desde el primer día.
Esta guía explica en términos claros qué significa agile, cómo se compara con waterfall y qué son realmente Scrum y Kanban. También recorre día a día cómo son dos semanas de trabajo. Nosotros mismos construimos software así, normalmente con un equipo de desarrollo dedicado que se integra en el proceso ya existente del cliente, por lo que los ejemplos de aquí vienen de proyectos que hemos entregado y no de la teoría.
Qué significa realmente el desarrollo de software agile
Encontrará la metodología agile explicada de docenas de formas distintas. Por debajo de los frameworks y la terminología, todo se reduce a un hábito que se repite. El equipo construye una pequeña parte del producto, la muestra a las personas que la van a usar y deja que su reacción defina lo que viene después. Ese bucle continúa hasta que el software está terminado.
Tres cosas sostienen ese hábito:
- Ciclos cortos, para que un giro equivocado cueste dos semanas en lugar de un año
- Algo que funciona al final de cada ciclo, en lugar de un informe de estado
- Un plan actualizado de forma abierta y deliberada, con usted presente
Merece la pena desmontar un mito antes de seguir. Agile no elimina la planificación, sino que la revisa cada pocas semanas a la luz de lo que el último ciclo enseñó a todos. Los equipos que se saltan ese paso por completo no son agile, simplemente están desorganizados, y la diferencia se nota al tercer mes.
Lo que agile no es:
- Una regla que convierte la documentación en algo opcional
- Permiso para empezar a construir antes de que alguien acuerde qué significa el éxito
- La promesa de que los plazos se moverán siempre que le convenga al equipo
En la mayoría de nuestros proyectos, la definición estructurada del alcance sigue viniendo primero. Una fase de discovery establece el objetivo, los usuarios, las restricciones y la forma aproximada del trabajo. Agile decide después cómo se rellena esa forma, y acepta que algunas de sus suposiciones iniciales resultarán equivocadas.
Lo que los clientes suelen valorar más es que no necesitamos una especificación terminada para ser productivos. Muchas de las empresas que acuden a nosotros saben exactamente qué resultado quieren. El software que lo consigue es la pregunta abierta, así que la resolvemos juntos a medida que avanza el proyecto. Nadie tiene que inventar respuestas solo para rellenar un documento.
Agile vs waterfall: cuándo tiene sentido cada uno
Waterfall ejecuta un proyecto en una sola línea larga. Se acuerda el alcance completo, luego se diseña, luego se construye, luego se prueba y luego se libera. Cada etapa termina antes de que empiece la siguiente, y por eso normalmente se ve software funcionando cerca del final.
Ese enfoque no es absurdo y no ha desaparecido. Las licitaciones públicas a precio fijo, la certificación de seguridad y las fechas de lanzamiento de hardware premian todas ellas conocer la respuesta completa por adelantado. Lo que waterfall gestiona mal es el descubrimiento. Los problemas empiezan cuando algo que se aprende tarde en la construcción contradice una decisión tomada al principio. Deshacerlo implica más papeleo, un precio revisado y una conversación incómoda.
Alcance
Acordado por completo antes de empezar el desarrollo
Acordado a alto nivel y luego detallado ciclo a ciclo
Cuándo ve software funcionando por primera vez
Cerca del final
Cada una a cuatro semanas
Coste de un cambio en el cuarto mes
Alto, normalmente una solicitud formal de cambio
Normal, entra en el siguiente ciclo
Qué necesita de usted
Requisitos detallados por adelantado
Unas pocas horas por semana, todas las semanas
Mejor encaje
Contratos fijos, productos certificados, plazos de hardware
Productos que siguen evolucionando con su mercado
Mayor riesgo
Construir correctamente el producto equivocado
Un alcance que se desvía cuando el objetivo es vago
Elegir entre el desarrollo de software agile y waterfall pocas veces depende de qué método suene más moderno. Se reduce a una pregunta: ¿cuánto de este producto conoce ya de verdad? Si la respuesta honesta es casi todo, waterfall no le hará daño. Si la respuesta es aproximadamente la mitad, los ciclos cortos le ahorrarán dinero.
¿Le piden una especificación completa antes de que alguien le dé un presupuesto? Nuestra guía sobre especificaciones y estimación de proyectos explica qué puede y qué no puede comprarle ese documento, y de dónde salen las cifras que contiene.
Scrum vs Kanban: los dos frameworks de los que oirá hablar
Agile es la idea. Scrum y Kanban son dos formas habituales de ponerla en práctica, y la mayor parte de la jerga con la que se encontrará pertenece a una de las dos.
Scrum organiza el trabajo en ciclos fijos llamados sprints, normalmente de dos semanas cada uno. El equipo se compromete con un conjunto de elementos al principio, revisa el resultado al final y repite. También define unas pocas responsabilidades, entre ellas alguien que es dueño de las prioridades y alguien que mantiene el proceso honesto. La Guía Scrum oficial ocupa alrededor de una docena de páginas, lo que indica lo ligero que es en realidad el framework por debajo de la industria construida sobre él.
Kanban prescinde del ciclo fijo. El trabajo se sitúa en un tablero visible, avanza de izquierda a derecha según progresa y un elemento nuevo empieza solo cuando el equipo tiene espacio para él. La Guía Kanban es todavía más corta. Su regla central es un límite sobre cuántas cosas pueden estar en curso a la vez, y esa es la disciplina que a la mayoría de los equipos más cuesta mantener.
Ritmo
Ciclos fijos, normalmente de dos semanas
Continuo, el trabajo nuevo empieza cuando se libera capacidad
Planificación
Comprometida al inicio de cada ciclo
Repriorizada cada vez que se toma el siguiente elemento
Roles
Definidos, incluidos un responsable de prioridades y un facilitador
Ninguno obligatorio, cada persona mantiene su puesto actual
Encaja con
Construir un producto siguiendo una hoja de ruta
Soporte, mantenimiento y colas de peticiones impredecibles
Métrica principal
Cuánto termina el equipo por ciclo
Cuánto tarda un elemento desde la petición hasta quedar terminado
Fallo habitual
Las reuniones sobreviven y el feedback se detiene sin más
Sin límite de trabajo en curso, así que todo se atasca a la vez
Muchos equipos combinan las dos, y no hay nada malo en ello. Nosotros tendemos a usar sprints mientras se construye un producto, porque un ritmo de dos semanas da a todos un momento predecible para mirar, decidir y corregir. Para el mantenimiento de larga duración, donde los tickets llegan cuando llegan, un tablero basado en flujo encaja mejor con la realidad.
Cómo es en realidad un sprint de dos semanas
La palabra sprint suena a prisa, pero no lo es. Un sprint es simplemente una porción fija de tiempo con un objetivo acordado, y dos semanas es la duración que la mayoría de los equipos acaba adoptando. Eso son 10 días laborables, y funcionan así:
- El día 1 es de planificación. El equipo y quien sea dueño de las prioridades acuerdan qué se entregará el día 10 y escriben qué significa terminado para cada elemento. Todo lo que resulte demasiado vago para probarse se divide o se devuelve.
- Los días 1 a 10 empiezan todos con un breve standup. Dura 15 minutos y cada persona responde a tres preguntas: qué avanzó ayer, en qué estoy hoy, qué me está bloqueando. No es una reunión de estado para los mánagers, sino una forma de sacar a la luz un obstáculo el mismo día en que aparece y no una semana después.
- Los días 2 a 9 son el trabajo en sí. Desarrolladores y testers trabajan al mismo tiempo en lugar de en secuencia, así que nada cuenta como terminado hasta que se ha verificado. Esa única regla evita el montón de código sin verificar que convierte el último mes de un proyecto waterfall en una crisis.
- El día 10 hay dos conversaciones. Primero el equipo muestra qué funciona de verdad, en pantalla, con datos reales. Después revisan cómo fue el proceso y eligen una cosa que cambiar.
Los equipos que se saltan esa segunda conversación mantienen las reuniones pero dejan de mejorar, así que acaban haciendo desarrollo de software agile solo de nombre.
Qué necesita un sprint de su parte
Agile no es una manera de comprar software sin prestar atención. Necesita unas pocas horas por semana de alguien de su lado que pueda responder preguntas y tomar decisiones. Esa persona también tiene que ver cada demo. Si le da a un equipo un stakeholder ausente, el ciclo sigue girando mientras el producto se desvía.
La recompensa es que nada permanece oculto mucho tiempo. Ve el progreso cada dos semanas y puede cambiar de dirección al inicio de cualquier ciclo. Un calendario que se retrasa también se manifiesta con tiempo para actuar. Ese feedback se afina cuando el trabajo llega a personas reales, y nuestro artículo sobre involucrar a los usuarios finales desde el principio recoge las formas prácticas de hacerlo.
Este ritmo escala más de lo que la gente espera. En el proyecto Justin Alexander fusionamos cuatro sitios web independientes en una única plataforma multimarca para una empresa de moda nupcial que vende a través de más de 1.500 minoristas autorizados. Diez desarrolladores, tres project managers y cuatro ingenieros de QA trabajaron con ese mismo ritmo sobre un stack de Python y Django. El sitio atiende ahora a más de 30.000 visitantes al mes.
Agile y los MVP: construir la versión más pequeña que le enseñe algo
Un MVP, o producto mínimo viable, es la versión más pequeña de su idea con la que usuarios reales pueden hacer algo de verdad. No un prototipo ni una presentación, sino software funcionando con la única tarea para la que existe. Su propósito es decirle si sus suposiciones son ciertas antes de comprometer el resto del presupuesto.
Agile y un MVP encajan de forma natural, porque ambos tratan sus conjeturas como cosas que hay que probar y no como hechos. Construya el núcleo, póngalo delante de los usuarios y deje que su comportamiento ordene lo que viene después. La mayoría de las listas de beneficios del desarrollo de software agile empiezan en el mismo punto: el dinero que no se gasta en funcionalidades que nadie usó.
Nuestros servicios de desarrollo de MVP entregan un lanzamiento en 12 semanas, un plazo lo bastante corto para mantener el alcance honesto. Decidir qué pertenece a esa primera versión es la parte difícil, y es donde se produce la mayor parte del debate. Nuestra guía sobre cómo construir un MVP explica cómo recortar una lista de deseos hasta algo que se pueda lanzar y de lo que se pueda aprender.
Dónde falla agile y qué hacer al respecto
Agile no encaja en todos los proyectos, y cualquier proveedor que le diga lo contrario le está vendiendo algo. Tres situaciones lo complican de verdad, y cada una tiene una solución razonable:
- Un contrato a precio fijo cierra el alcance. Como se llame el proceso de entrega, acordar todo por adelantado es un trato waterfall. Todavía puede trabajar en ciclos dentro de él, pero ha renunciado a la libertad de cambiar de dirección. Cuando los clientes quieren las dos cosas, acordamos el objetivo y el presupuesto, dejamos los detalles abiertos y los revisamos juntos cada pocas semanas.
- El trabajo regulado exige una traza de auditoría. Un proceso informal no la produce, aunque eso no descarta los ciclos cortos. Los organismos públicos aplican desarrollo de software agile a gran escala, y la GAO Agile Assessment Guide existe para ayudar a los auditores federales a evaluarlo. Trabajamos en Current con la Change & Innovation Agency. Es una aplicación web que gestiona las solicitudes de los ciudadanos para programas administrados por el estado, construida sobre Angular, ASP.NET Core y Azure. La lógica de negocio de Current siguió evolucionando en ciclos mientras se cumplían en paralelo las obligaciones de documentación.
- Nadie de su lado puede revisar el trabajo. Un equipo sin nadie a quien hacer la demo tomará sus propias decisiones, y algunas serán equivocadas. Si su organización no puede liberar a una persona con capacidad de decisión unas pocas horas por semana, dígalo antes de que empiece el proyecto. La respuesta honesta puede ser un compromiso más corto, un analista de negocio por nuestra parte o un retraso hasta que alguien pueda asumirlo.
Cómo gestiona Redwerk la entrega agile
Nuestro modelo por defecto es un equipo dedicado que trabaja en sprints de dos semanas, con una demo a la que usted asiste al final de cada uno y acceso directo a los desarrolladores entre medias. Los clientes nos dicen que la comunicación es lo primero que notan, y eso es deliberado. Sin resúmenes semanales escritos por alguien que no estuvo en el código.
La diferencia mayor está en dónde estamos dispuestos a empezar. Muchos de los proyectos que nos llegan no tienen una especificación completa, y unos pocos llegan como una base de código a medio terminar que otro abandonó. Ninguna de las dos cosas nos detiene, porque un primer sprint puede producir igual de bien una evaluación de lo que ya existe que una porción funcional de software nuevo. Nuestro trabajo de consultoría de desarrollo de software suele empezar exactamente ahí, con una mirada clara al terreno antes de que nadie se comprometa con un plan.
Agile funciona porque asume que usted no tendrá todas las respuestas el primer día. Veinte años construyendo productos nos han enseñado a planificar justamente para eso. Un proceso que mejora a medida que se aprende supera a uno que se rompe cuando cambian los requisitos. Los ciclos cortos solo ayudan si se mira el resultado y se actúa en consecuencia. Para hablar de qué forma de trabajar encaja con su próximo proyecto, cuéntenos qué está construyendo.
FAQ
¿Qué es el desarrollo de software agile?
El desarrollo de software agile es un enfoque que entrega software en ciclos cortos, normalmente de una a cuatro semanas, con una versión funcional revisada al final de cada uno. Se espera que los requisitos cambien, así que el plan se revisa con regularidad en lugar de fijarse al principio. Scrum y Kanban son los dos frameworks que los equipos usan con más frecuencia para aplicarlo.
¿Es agile mejor que waterfall?
Agile es mejor para productos cuyos requisitos van a cambiar, lo que cubre la mayor parte del software comercial actual. Waterfall sigue encajando en contratos a precio fijo, productos certificados y proyectos ligados a fechas de hardware. La pregunta decisiva es cuánto del producto conoce realmente antes de empezar. Si es casi todo, waterfall no le cuesta nada.
¿Deberíamos usar Scrum o Kanban?
Use Scrum cuando esté construyendo un producto siguiendo una hoja de ruta y quiera un ritmo predecible de dos semanas para planificar y revisar. Use Kanban para soporte, mantenimiento y cualquier cola donde el trabajo llegue de forma impredecible y las prioridades cambien a diario. Muchos equipos usan ambos, con sprints para el desarrollo nuevo y un tablero de flujo para los tickets entrantes.
¿Cuáles son los beneficios del desarrollo de software agile?
Los principales beneficios del desarrollo de software agile son la visibilidad temprana, correcciones de rumbo más baratas y menos dinero gastado en funcionalidades que nadie usa. Ve software funcionando cada pocas semanas en lugar de al final, así que una suposición equivocada cuesta un ciclo y no un proyecto. Los retrasos también afloran pronto, cuando todavía tiene margen para reaccionar.
¿Podemos empezar sin una especificación completa?
Sí, y la mayoría de nuestros clientes lo hace. Una fase de discovery establece el objetivo, los usuarios y las restricciones, lo que basta para empezar a construir sin un documento de requisitos terminado. El detalle se resuelve ciclo a ciclo, a medida que el software real sustituye a las conjeturas. Sí requiere que alguien de su lado esté disponible para responder preguntas cada semana.
Descubra cómo ayudamos a AWE Learning a migrar de las instalaciones a la nube y a llegar a usuarios fuera de EE.UU. mediante la implantación de una solución SaaS escalable.
