La teoria dietro Product Printer
Il software non è più un mestiere artigianale. È una tecnica.
Per settant’anni il software è stato costruito come un mobile in bottega: un artigiano, un pezzo, tutto da zero. Quell’epoca è finita. Quando scrivere codice diventa economico, il valore si sposta sul piano, sui componenti e sulla linea. Per questo costruiamo come una fabbrica.
Dal mestiere alla tecnica
Il costo di scrivere codice è crollato
Gli agenti IA scrivono ormai la maggior parte del codice. La parte costosa di ogni progetto software, cioè la scrittura dell’implementazione, è diventata quasi da un giorno all’altro la parte economica. Il nostro obiettivo: ciò che prima richiedeva a un team un trimestre, una linea di produzione supervisionata lo consegna in una settimana.
La maggior parte del software è un problema risolto
Accesso, fatturazione, multi-tenancy, lingue, monitoraggio: ogni applicazione aziendale ha bisogno di questi elementi, e nessuno di essi merita di essere reinventato. Sono componenti standard, articoli di catalogo, non lavoro di progettazione.
Ciò che resta scarso è il problema stesso
Comprendere un negozio di biciclette, una flotta di noleggio, un servizio di assistenza, e specificare la cosa giusta da costruire. È lì che serve l’essere umano. Tutto ciò che viene dopo una buona specifica può essere industrializzato.
Un mestiere diventa una tecnica nel momento in cui i suoi passaggi possono essere scritti, ripetuti e verificati. Il software ha appena superato questa soglia, e una volta che qualcosa è una tecnica, una fabbrica batte la bottega.
La linea, stazione per stazione
Dalla prima formazione fino al software in esecuzione, stazione per stazione. Ognuna è contrassegnata: «Attivo» indica ciò che funziona già oggi; «In arrivo» indica ciò che stiamo costruendo come prossimo passo.
01Attivo
Si parte dalla formazione
Prima della linea, le persone: i consulenti imparano a consigliare le PMI sull’IA, poi formano i team dei propri clienti con un corso con il proprio marchio, il cui ultimo passo diventa un nuovo progetto o nuovi requisiti.
Scopri di più02Attivo
Prima i requisiti
Nulla viene costruito a partire da una richiesta vaga. Una conversazione diventa requisiti, ciascuno con i propri criteri di accettazione, e la linea costruisce solo ciò che è stato accettato.
03Attivo
Una linea continua
Non appena i suoi requisiti sono accettati, uno step di lavoro passa a un agente di programmazione senza alcun clic: una costruzione alla volta per progetto, in ordine. Ogni step di lavoro esce come pull request.
04Attivo
Controlli su ogni modifica
Ogni pull request supera la CI del progetto e le scansioni di sicurezza, poi una revisione di sicurezza con IA che si blocca in caso di errore: nessun esito, nessun merge, e il merge è vincolato alla versione esatta revisionata. Una protezione sul ramo principale rifiuta il deploy di qualsiasi modifica che abbia aggirato i controlli.
05Attivo
Prova per criterio
Ogni criterio di accettazione ottiene la propria esecuzione del test dalla CI, registrata dopo l'ultima modifica del requisito integrata, e un requisito è considerato verificato solo quando tutti passano. Un criterio verificato da una persona mostra “Controllo umano in sospeso” finché non viene approvato. La parola dell'agente non conta mai.
06Attivo
Prima il test, dal rosso al verde
Il test per ogni criterio di accettazione viene scritto per primo, nel proprio commit, e deve fallire nella CI prima che il codice lo faccia passare. Prima che una modifica venga integrata, il gate verifica che il test di ogni criterio sia passato da rosso a verde e non sia stato modificato nel frattempo; il requisito collega entrambe le esecuzioni.
07Attivo
Un ciclo di correzione
Quando la CI o la revisione di sicurezza respingono una modifica, i rilievi tornano alla stessa sessione dell’agente, che li corregge nella stessa pull request, e tutti i controlli vengono rieseguiti. Per impostazione predefinita sono previste al massimo due correzioni; dopodiché interviene una persona.
08Attivo
Componenti standard
Ogni app parte dal modello di fabbrica con i problemi già risolti: accesso, tenant e ruoli, pagine legali, layout. Costruiti una volta, rafforzati in produzione, mai ricostruiti.
09Attivo
La libreria di fabbrica in ogni fase
Quando un piano di step di lavoro viene approvato, ogni step arriva con i componenti standard scelti dal progetto. Gli step che toccano il database o altre aree sensibili vengono costruiti con le linee guida di sicurezza e del database della libreria, e il registro di costruzione elenca quali e perché.
10Attivo
Rilascio in produzione
Pubblicare una release distribuisce un’app ospitata in produzione: prima le migrazioni del database, in ordine, fermandosi al primo errore; poi la build. La release mostra «Attivo» solo quando l’indirizzo pubblico la serve.
11Attivo
Uno stato onesto
Finché non è rilasciato tutto ciò che è previsto, un progetto mostra «In costruzione — 3 di 6 step rilasciati», e «Attivo» solo dopo. Una nuova app mostra ai visitatori «Prossimamente» e agli utenti registrati i passaggi di costruzione; una pagina «Cosa contiene l’app» elenca i componenti con cui è partita, ciò che è stato costruito e ciò che manca ancora.
12Attivo
Tutto registrato
Ogni job di costruzione, ogni deploy di release e ogni modifica arrivata al ramo principale al di fuori dei controlli viene registrato. Le azioni dei nostri operatori confluiscono in un registro di audit in sola aggiunta.
13Attivo
Chiavi con ambito limitato, hosting UE
Per le app che ospitiamo, ogni build riceve un token a breve durata valido solo per quel repository, eliminato al termine della build. Le chiavi dei Suoi modelli restano nel Suo PP Orchestrator. Le istanze cloud funzionano in Germania (UE).
“Attivo” significa rilasciato in una release di Product Printer e in funzione sulle nostre istanze gestite. Una stazione passa da “In arrivo” ad “Attivo” solo quando la sua release è disponibile.
L’epoca della bottega era bellissima. L’epoca della fabbrica è accessibile.
— Eliminiamo il rumore.
Porti il suo problema →