Con el paso del tiempo, llegan nuevas tecnologías, nuevos paradigmas y nuevas formas de trabajar. Pero hay algo que siempre ha permanecido intacto: el SDLC (Software Development Life Cycle o ciclo de vida del desarrollo de software). En este contexto, la IA en el SDLC (Software Development Life Cycle) está empezando a transformar cómo se diseñan, desarrollan y mantienen las aplicaciones. La IA ha irrumpido fuerte en este ciclo, pero ¿cómo?
El cuello de botella del desarrollo de software en el SDLC
Desde hace décadas, el mayor cuello de botella de este ciclo siempre ha sido la parte de ingeniería o desarrollo. Donde se escribe el código. Es el motivo principal por el que hay que priorizar el qué se desarrolla. Además, con el uso de IA, esta fase aumenta su capacidad y su velocidad, pero… no parece que estemos acelerando el ciclo completo.
Entonces ¿qué está ocurriendo?
No, no vamos más rápido. Y es que el cuello de botella que antes estaba en desarrollo no ha desaparecido. Simplemente se ha mudado. Ahora está en otra fase en la que me temo, a día de hoy, nadie está poniendo el foco.
Cómo se gestiona el SDLC en equipos de desarrollo de software
Hasta ahora, la función de las capas de management y el objetivo de hacer más eficientes los procesos era clara: encajar la demanda (a veces infinita) de features o necesidades con la capacidad actual de desarrollo. Es el motivo principal por el que hay tantísimos frameworks y metodologías que nos indican cómo trabajar para, realmente, solucionar este problema y priorizar mejor (Scrum, LeSS, SAFe, MoSCoW, etc). Pero si la fase de desarrollo ya no es un problema, y la razón histórica principal para priorizar se ha debilitado. ¿Dónde está el problema entonces? Os lo cuento desde mi experiencia.
Caso real de IA en el SDLC (Software Development Life Cycle) en equipos de desarrollo
En mi experiencia como Engineering Manager, he podido ver como en varios equipos que he tenido el placer de trabajar en el último año hemos ido adoptando IA desde cero en nuestro día a día. Todo empezó por supuesto con simples asistentes de código. Eso ya fue un salto cualitativo, poder preguntar sobre líneas de código, aceptar propuestas, etc. Nos ayudaba a ir más rápido, de forma controlada.
Seguimos avanzando y empezamos a crear agentes. El primer agente revisaba tu código. Nosotros, que trabajábamos con sistema de Pull Requests (fase en las que se nos iba muchas veces el tiempo), vimos como los tiempos de revisión y de «pimponeo» entre el owner y el revisor de la PR, se redujeron. Este trabajo ya se había hecho entre la persona que había realizado el código y el agente revisor. La revisión por parte de un humano se ha convertido en un mero trámite.
Con el tiempo, dimos el paso al diseño de skills e hicimos más eficiente todo el flujo de desarrollo, donde ya el código era implementado por un agente (incluyendo una gran capa de tests), luego revisado por otro, se hacía el commit, la PR… empezamos a ir muy rápido. El siguiente salto natural, fue el paso a SDD (Spec-Driven Development), en el que seguimos aprendiendo cada día.
En todo este camino, por supuesto fui midiendo. Pusimos el foco en el lead time. El tiempo de codificación y de revisión de PR había disminuido consistentemente, pero… no así el lead time. No era proporcional. Entonces ¿dónde estaba ahora el problema? ¿Qué nos frena? Pusimos el foco en otro artefacto del ciclo: las historias de usuario y la definición per se dé la funcionalidad a desarrollar.
El nuevo cuello de botella del SDLC: requisitos y especificaciones
Teníamos varios candidatos para analizar e identificar la causa del freno: entender el problema, revisión, integración y mantenimiento. En nuestro caso el problema estaba en el primer paso (siendo los otros tres puntos de dolor para otros equipos seguramente). Un dolor que, en mayor o menor medida, siempre han sufrido todos los equipos, son historias de usuario que, o bien ni eran historias, o eran muy ambiguas o con un nivel de detalle muy bajo. Lo que hacía que luego hay que dar muchas vueltas.
Es imposible entender el problema correctamente si el problema no está contado y detallado correctamente.
Lo mismo le pasa a la IA. Unos malos o vagos requisitos (vamos a empezar a usar la palabra specs de especificaciones) harán que nuestro código sea vago. Unos specs deficientes crearán funcionalidades deficientes, aún con IA.
Qué son los PRDs y por qué son clave en el SDLC con IA
Es por ello que ahora hay que gastar más tiempo en escribir estos specs (por ejemplo, mediante el uso de PRDs). Un PRD (Product Requirement Document) es un documento funcional estructurado que una IA entiende y ejecuta de forma mucho más fiable. Es aquí donde deberíamos echar más tiempo, no solo perfiles como Product Owner/Manager, también desarrolladores haciendo challenge a la propia definición, aumentando así el conocimiento de producto. Es más, podemos apoyarnos en la IA para hacer estos documentos que, posteriormente, podemos traducir a épicas e historias de usuario.
Cómo usar la IA en el desarrollo de software más allá del código
Bajo mi punto de vista seguimos usando IA para perfeccionar, o hacer aún más eficiente, una fase que ya es muy eficiente. ¡Ojo! Esto pasa porque los equipos, con todo el sentido del mundo, miran donde siempre se les ha dicho que miren, que, para ir más rápido, hay que desarrollar más rápido. Yo propongo parar y respirar. Lleguemos a un punto donde nos sintamos cómodos a la hora de desarrollar apoyándonos en la IA (hablo de la escritura de código) y pongamos el foco, y esfuerzos, en otros puntos:
- Test exhaustivos (es la gran oportunidad para hacer TDD real).
- Documentación viva (una única fuente de verdad, los specs).
- Análisis de incidentes.
- Grandes refactors (que sea la IA quien hace el trabajo duro, luego revisaremos).
- Specs a partir de conversaciones (usar transcripciones de refinamiento entre negocio e IT para generar specs de alto valor).
El futuro de la IA en el SDLC (Software Development Life Cycle)
Estamos, de nuevo, ante un cambio de paradigma. Usemos la IA para optimizar, potenciar y mejorar el SDLC. Pero usémosla donde realmente se necesita.
Si en tu equipo ya estáis incorporando IA en el desarrollo, pero no estáis viendo un impacto real en el ciclo completo, probablemente el reto no esté en el código, sino en cómo estáis definiendo, priorizando y estructurando vuestro SDLC.
En Profile trabajamos con equipos para integrar la IA de forma práctica en su día a día, mejorar la definición de producto y optimizar el delivery de principio a fin. Si te interesa revisar cómo está funcionando vuestro proceso y dónde puede estar el freno, ¡contáctanos!
Síguenos en redes sociales para estar al tanto de las últimas novedades en Inteligencia Artificial y desarrollo de software.
