Nasce da un spin off di unimore 2001, 2004 sono praticamente solamente 4 persone e dal 2014 arrivano 100 clienti. Ora sono anche a Milano, Palermo, Modena. Si parla di clienti e di fornitori insieme perché implementano soluzioni che mettono in contatto aziende con tutto il parco dei loro fornitori e diamo loro una soluzioni di supply chain collaboration. Il fornitore interagisce col cliente tramite la IUNGO mail. Il cliente opera su un portale web in cui sono evidenziate le criticità. IUNGO può interagire coi fornitori in modalità diverse. Il portale interagisce con il gestionale della società cliente e poi integra tutte le sue API: Company ERP →IUNGO →Supplychain, IUNGO BDI, …
Soluzioni business to business e voglio diventare lo standard di riferimento per il mondo manifatturiero meccanico. Citata da Gartner nel magic quadrant come migliori aziende peer to pay. Sono anche citati dal sole24 ore https://www.ilsole24ore.com/art/supply-chain-finance-arriva-piattaforma-basata-ai-AEwv03KC, https://www.ilrestodelcarlino.it/premio-mascagni/modena/iungo-clienti-e-fornitori-piu-vicini-un-software-migliora-gli-affari-1.8144568,
Una cosa molto carina è che hanno letteralmente una piattaforma per la gestione del welfare. Hanno dei percorsi di crescita aziendali praticamente e dei percorsi di scuola essenzialmente. Fanno percorsi di formazione continua essenzialmente.
All’inizio c’era uno stack legacy e praticamente il software veniva manualmente installato a casa del cliente. C’erano del PM che avevano dei dev sotto e praticamente si andava dal cliente, si raccoglievano i task da fare e gli si davano ai dev che sviluppano, facevano test, validation, rilascio. Finito così si passava ad un nuovo progetto. Questo portava a non avere molta collaborazione tra gli sviluppatori ed ogni PM era concentrato sulla sua pipeline di clienti. Ogni pezzo custom per ogni cliente è inserito in iungo facendole crescere in maniera disarmonica. Nel 2018 iungo entra in contatto con una azienda appena nata: jelly5 che prendono delle aziende che hanno delle buone idee per andarle a trasformare in azienda strutturate. Abbiamo introdotto i primi processi agili mano a mano soprattutto sulla parte di costruzione del prodotto in modo da poter rilasciare qualcosa che fosse utile per più clienti. Siamo partiti da questo processo iterativo che partiva dal fedback dei clienti che veniva discussi nel product board, si sceglievano le feature e si faceva un backlog da dare in pasto ai clienti. Tutto quanto in maniera iterativa. L’altro passo è stato fare il cambio di prospettiva rispetto all’uso del software iungo, per cui si è pensato di non andare ad installarlo manualmente ma fare una cloud platform direttamente. Questo ha creato non pochi problemi perché una parte dell’azienda è rimasta sui processi vecchi e si è creata una divisione: team prodotto e team delivery, praticamente la contea e Mordor. Su Mordor era davvero un macello, perché si lavorava con specifiche poco chiare, dev allocati su singolo task anche per mezza giornata e si lavorasse per tattica e non per strategia pensando di un’ora alla volta. Ci siamo chiesti se ci fosse una soluzione per questa situazione. Ci si è provato a rifare a quello che è il manifesto delle metodologie agili.
Praticamente ora hanno cross functional team. E la parte sys admin e installazione è tutto quanto su devops. Si è iniziato a pianificare con più respiro e praticamente l’idea non è fare planning su singolo dev, ma lavorare su team. Si è praticamente implementato una sorta di scrum, ma rimangono i problemi del customer support con i ticket che hanno problemi importanti e vengono dati direttamente al team di sviluppo. Abbiamo tenere deciso di tenere queste attività con priorità. Le squadre una volta al mese si incontrano per discutere come sia andata e vedere come si possa migliorare il tutto. Si tengono squadre piccole, max 8 persone e si fanno degli shuffle di 6/12 mesi per lavorare sempre un po’ con tutti. Si sono create anche delle gilde, che hanno degli interessi comuni. Sono delle community interne alle aziende e sono autogestite e sono fatte per fare autoformazione e studiare. Si condividono pratiche, tools, conoscenze, si va insieme agli stessi seminari. Tutta la azienda dovrebbe avere un focus sul portare a termine i progetti end to end, da quando viene immaginato alla implementazione effettiva. E’ stato cambiato anche il software life cycle, è stato prodotto un branching model come GitFlow e ci sono delle pipeline di Continuous Integration e Delivery.
Capo del reparto engineering se ne è andato e si è deciso di riseparare i team e avere dei SM che sono diventati degli engineering manager, sono responsabili dei piani carriera, assunzioni, etc. …
prima ora ero con nonna a casa
Architettura clean sono dei principi, il portavoce è un americano che si è inventato il nome. Le dipendenze vanno verso l’interno, praticamente una onion architecture, quindi nella classe che implementa il mio controller devo avere dipendenze solamente verso users cases e entities. Praticamente ho una gerarchia di dipendenze. La entity sono i nostri oggetti.
Praticamente dobbiamo andare a creare una classe per ciascuna Scritta che vediamo in questo schema. Il primo problema è cercare di convertire questi tipi di oggetti.