DavaFlow di Endava porta OpenAI in ogni fase dello sviluppo software

Cosa ha davvero cambiato DavaFlow

Il racconto di Endava, riportato dal CTO Matthew Cloke, descrive una sequenza precisa. La scrittura di codice assistita dall'IA ha accelerato per prima cosa la produttività degli ingegneri. Questo ha fatto emergere un nuovo collo di bottiglia: raccolta dei requisiti, analisi di business, pianificazione e coordinamento con gli stakeholder non riuscivano più a tenere il passo con la velocità con cui veniva prodotto il codice.

La risposta è stata DavaFlow, una metodologia di delivery che fa passare la tecnologia OpenAI attraverso tutto il ciclo di vita: preparazione delle riunioni, pianificazione di business, discovery di prodotto, ingegneria e deployment. L'affermazione di Cloke è insolitamente categorica.

Non c'è una sola parte di DavaFlow che non usi la tecnologia OpenAI.Montana Labs

Questa impostazione conta perché tratta l'IA come un cambiamento nella sequenza del lavoro di delivery, non come uno strumento aggiuntivo. Cloke descrive l'essere AI-native come il ricorrere all'IA per primo per risolvere un problema, non per ultimo.

L'app per i prezzi è il dato interessante

Gran parte dell'annuncio elenca categorie di adozione familiari: il legale che semplifica la ricerca, i project manager che usano Codex per i report di governance, il management che usa gli agenti per riassumere progetti e gestire le caselle di posta. Sono cose reali, ma generiche.

Il momento concreto è la discussione interna sui prezzi. Invece di lavorare con i fogli di calcolo, i dipendenti hanno costruito una single-page app per i prezzi con cui i team potevano interagire immediatamente. Cloke dice che ha "cambiato completamente la conversazione".

Il cambiamento qui è il passaggio da dati statici in celle a una piccola interfaccia interattiva generata al momento. Quando un foglio di calcolo diventa un'app, l'artefatto smette di essere un file che le persone leggono e diventa una superficie che le persone manipolano insieme. Che team commerciali non tecnici riescano a produrre un frontend funzionante senza il supporto dedicato dell'ingegneria è la capacità più significativa nascosta in questa storia.

Chi costruisce il frontend quando l'ingegneria non è il collo di bottiglia

Endava descrive questo fenomeno come un'adozione che si estende oltre gli sviluppatori, arrivando al legale, alla finanza e alle operazioni. È l'aspetto del frontend che rende possibile questa diffusione: interfacce leggere e usa-e-getta che un team commerciale può generare per sostituire un esercizio pieno di fogli di calcolo.

Questo inverte un vincolo di lunga data. Gli strumenti interni normalmente restano in coda all'ingegneria perché costruire anche una semplice interfaccia richiedeva qualcuno capace di scriverla. Nei risultati di Endava, "aver permesso ai team di costruire strumenti e applicazioni interne senza il supporto dedicato dell'ingegneria" viene elencato come un esito distinto, separato dall'ingegneria più rapida.

La domanda aperta a cui la fonte non risponde: cosa succede a queste app dopo la riunione. Una single-page app per i prezzi che cambia una conversazione è utile; cento single-page app senza governance sparse in un'azienda di 11.000 persone sono un problema di manutenzione e correttezza. L'annuncio celebra la creazione ma non dice nulla sul ciclo di vita di ciò che viene creato.

L'implicazione: le interfacce interattive diventano un medium di pensiero usa-e-getta

Il principio dichiarato di Endava è trattare l'adozione dell'IA come un cambiamento comportamentale, non come il rilascio di un software, e coinvolgere presto i team non tecnici. L'aneddoto dell'app per i prezzi mostra come si presenta quel cambiamento comportamentale in superficie: le persone ricorrono a una piccola interfaccia personalizzata come prima ricorrevano a un foglio di calcolo.

Per i team applicati, la lezione è precisa e pratica. Quando generare un frontend utilizzabile costa pochi minuti, l'interfaccia smette di essere un deliverable e diventa un modo per portare avanti una conversazione: costruita per prendere una decisione, poi scartata. Questo abbassa la soglia di ingresso per chi può progettare interazioni software, e apre una nuova questione di governance su quali di queste app usa-e-getta finiscano, silenziosamente, per diventare strutturali.