Si comincia sempre con Agile. Il difficile è farlo reggere.
Ogni azienda parte con le migliori intenzioni: un metodo, una board, delle regole condivise. Poi un cliente mette fretta, una consegna pianificata viene anticipata, un imprevisto scavalca tutto il resto, e chi decide chiede di fare prima. Si fa un'eccezione, poi un'altra, e dopo qualche mese il metodo esiste solo nelle slide del primo giorno.
Non è indisciplina degli sviluppatori: è un metodo che non aveva previsto la pressione. Un metodo regge quando ha una regola anche per l'urgenza, quando chi decide le date lo rispetta per primo, e quando le regole più noiose le fanno gli strumenti al posto delle persone. In trent'anni sul campo abbiamo imparato quali reggono: le costruiamo insieme al vostro team, adattate a come lavorate voi.
A chi è rivolto
A chi guida un team di sviluppo e vuole un metodo di gestione del lavoro che regga anche sotto scadenza, senza dover inventare tutto da zero.
- Project manager e responsabili di progetto Vuoi sapere a che punto è un progetto senza chiederlo alle persone, e dare date di rilascio che reggono. Il metodo ti dà una board che dice la verità e un ciclo di rilascio ripetibile.
- Team leader e tech lead Hai letto di Scrum, Kanban, Git flow e trunk-based, e il tuo team ne applica un pezzo ciascuno. Ti serve un insieme di regole coerente, scritto, che valga per tutti i progetti e che tu possa far rispettare.
- Direzione e CTO Vuoi meno dipendenza dalle singole persone, meno emergenze e un modo di lavorare che sopravviva al cambio di un collaboratore. Il metodo chiede una cosa anche a te: le urgenze entrano dalla porta, non dalla finestra.
- E i programmatori Per loro il risultato è concreto: niente più board da aggiornare a mano, regole chiare su rami e versioni, una procedura per le emergenze invece dell'improvvisazione.
Perché i metodi si sgretolano
Le cause sono sempre le stesse, e nessuna è la cattiva volontà di chi scrive il codice.
La pressione arriva dall'alto
Un cliente chiama e vuole la consegna prima, la direzione promette una data che non era in piano, un bug in produzione entra senza fila e ferma tutti. Ogni volta è un'eccezione giustificata, e ogni eccezione toglie credibilità alla regola. Dopo un po' il piano non lo guarda più nessuno, perché tanto cambia.
Un metodo che regge non vieta le urgenze: le fa entrare da una porta. Una procedura per l'imprevisto, una regola per ripianificare quando una data si sposta, e un impegno di chi decide a passare da lì. Per questo chiediamo che la direzione partecipi all'avvio e alla chiusura dell'intervento, non solo il team.
Il progetto non avanza
Le scadenze slittano una dopo l'altra, ogni rilascio riapre problemi che sembravano chiusi, e nessuno sa dire con precisione a che punto si è. Spesso non è un problema di codice: è un problema di priorità, di responsabilità poco chiare o di un fornitore che va guidato con più fermezza.
Entriamo come technical project leader: fotografiamo lo stato reale, rimettiamo in ordine il backlog, definiamo un piano di rilascio che si possa rispettare e teniamo noi l'interlocuzione tecnica — con il team interno, con i fornitori, o con entrambi. Il committente torna ad avere una risposta chiara alla domanda «quando è pronto?».
Il team c'è ma non gira
Hai sviluppatori bravi e un risultato che non arriva: manca il metodo, non le persone. Ambienti che nessuno sa ricostruire, rilasci che fanno paura, codice che solo un collega conosce, decisioni tecniche prese e poi dimenticate.
Lavoriamo sul come: processo di sviluppo e di rilascio, code review, gestione dei rami e degli ambienti, documentazione di quello che conta, affiancamento tecnico sul campo. Non sostituiamo il tuo team e non ti vendiamo giornate-uomo da riempire: lo mettiamo in condizione di lavorare meglio, e restiamo finché il metodo non cammina da solo.
Le regole non sono di tutti
Agile interpretato in tre modi diversi, nessuno sa da quale ramo parte una feature o dove finisce un hotfix, la Kanban non viene aggiornata e quindi non dice come stanno davvero le cose, roadmap e note di rilascio riscritte altrove e sempre indietro. Regole che il team non ha scelto, o che costano fatica proprio quando la scadenza stringe, sono le prime a saltare. Il risultato: per sapere come procede un progetto bisogna chiedere alle persone.
Uno standard di sviluppo, vostro
Un intervento che lascia all'azienda un proprio standard di sviluppo: definito una volta, insieme al team, e applicato a tutti i progetti, presenti e futuri. Nasce da pratiche già collaudate sul campo e si adatta agli strumenti che usate già: non serve cambiare piattaforma.
Tre livelli, uno sopra l'altro:
- Convenzioni e formazione Cos'è una release, come si numera una versione, come si chiamano i rami, come si scrive un task, come si gestisce un'emergenza. Scritte in un manuale che vale per chi c'è e per chi arriva.
- Strumenti configurati Board, etichette, repository e roadmap impostati secondo le convenzioni, con modelli pronti: ogni nuovo progetto nasce già impostato.
- Automazione Gli eventi Git aggiornano da soli la Kanban, la roadmap e le note di rilascio. Il programmatore lavora solo in Git; tutto il resto si aggiorna da sé. Dallo stesso flusso escono, senza lavoro aggiuntivo, le metriche reali: tempo in sviluppo, in review, fino al rilascio.
A fine intervento il cliente possiede uno standard riutilizzabile, non solo ore di consulenza: manuale, convenzioni, modelli di board e repository, automazione configurata, team formato sul progetto pilota.
Cinque fasi, con un progetto pilota prima di estendere
- Analisi Osserviamo come lavora oggi il team, gli strumenti in uso, i punti in cui il lavoro si inceppa. Si chiude con un breve rapporto e la proposta di standard.
- Workshop con il team Le convenzioni si definiscono insieme, partendo da una base collaudata e adattandola alla vostra realtà. Le regole capite reggono; quelle imposte durano fino alla prima scadenza stretta.
- Progetto pilota Lo standard si applica a un progetto reale, non a un progetto di prova, con board, repository e automazione attivi.
- Affiancamento Alcune settimane di supporto per correggere, rispondere ai dubbi e rivedere le convenzioni che non reggono.
- Estensione e consegna Lo standard passa a tutti i progetti; consegna del manuale definitivo e dei modelli. Da qui in poi è vostro.
Una condizione la mettiamo noi: la direzione o il responsabile tecnico partecipa all'avvio e alla chiusura. Senza uno sponsor interno, alla prima scadenza stretta si torna alle vecchie abitudini.
La parte di workshop e formazione può rientrare nei piani finanziati dai fondi interprofessionali (Fondimpresa, For.Te. e simili): i requisiti vanno verificati insieme, caso per caso.
Come si comincia
- Una chiamata, senza impegno. Mezz'ora per capire come lavora il team, quali strumenti usa e dove si inceppa. Se non siamo il partner giusto lo diciamo subito.
- Un'analisi breve, a costo definito. Qualche giornata dentro il team per guardare board, repository e modo di lavorare, e restituire un documento che dice cosa c'è, cosa non va e in che ordine intervenire. Il documento resta tuo, anche se poi decidi di procedere con qualcun altro.
- Un piano a pacchetto. Workshop, pilota, affiancamento ed estensione con tempi e un prezzo definito: si vende un risultato, non le ore.
Hanno lavorato con noi
Oggi: fondi, assicurazioni e servizi
- Fondo Mario Negri — fondo pensione, in corso
- Wide Care Services — fondi pensione/sanitari, 2017–2023
Prima: industria, servizi ed ecosistema IBM i
- Zend Technologies — PHP in ambiente IBM i, 2015–2017
- Collezione Koelliker — arte, Sviluppo PHP custom
- Roche — farmaceutico, PHP in ambiente IBM i
- Tyco Healthcare — medicale, PHP in ambiente IBM i
Il tuo team
Due righe su quante persone siete, quali strumenti usate e cosa non funziona bastano per una prima valutazione onesta.