Architettura e deliveryCome lavora il team
I corsi che cambiano il modo in cui un team prende decisioni, più che il framework che usa. Valgono ovunque: si applicano allo stesso modo che siate su .NET, JVM o Node.
Un’architettura che regge alla realtà
Come tracciare confini che abbiano ancora senso al terzo anno, e come capire per tempo quando uno è nel posto sbagliato.
- Dove mettere un confine, e il caso molto più frequente in cui non aggiungerne
- Proprietà dei dati, consistenza e l’accoppiamento che si nasconde in un database condiviso
- Monolite, monolite modulare e servizi: costi, non ideologia
- Documentare le decisioni perché il team successivo erediti il ragionamento, non solo il risultato
- Leggere un sistema esistente per trovare le giunture che ha già
PerSviluppatori senior, tech lead, architetti
Sprint planning e stime
Perché le stime sbagliano, cosa fare al riguardo e come pianificare uno sprint che somigli ancora alla realtà il mercoledì della seconda settimana.
- Suddividere il lavoro in modo che ogni elemento sia completabile in un solo sprint
- Stimare con intervalli e livelli di confidenza invece che con una falsa precisione
- Capacità, lavoro residuo e l’aritmetica dietro un impegno credibile
- Definition of Ready e Definition of Done, scritte per il vostro team
- Condurre le cerimonie in meno di un’ora senza perderne lo scopo
PerTeam di delivery, product owner, scrum master
Discovery, scoping e roadmap
Trasformare un’idea abbozzata in qualcosa di cui stimare i costi, da mettere in sequenza e da difendere davanti a chi deve firmare.
- Arrivare al requisito reale dietro la funzionalità richiesta
- Fattibilità tecnica e lo spike che risolve per primo l’incognita più costosa
- Suddividere in fasi perché qualcosa di valore arrivi prima che tutto sia finito
- Sviluppare, acquistare o integrare: decidere sul costo totale, non d’istinto
- Scrivere il piano in modo che i compromessi restino visibili anche dopo la riunione
PerProduct, delivery lead, chiunque debba impegnarsi su una data
Standard di ingegneria e flusso
Code review, branching, CI/CD e i test che vale la pena scrivere: le pratiche che decidono quanto velocemente un team può muoversi in sicurezza.
- Code review che intercettano problemi di design invece che di formattazione
- Un modello di branching e rilascio adatto alla frequenza con cui rilasciate davvero
- Pipeline che falliscono per motivi reali e restano abbastanza veloci da meritare fiducia
- Dove i test si ripagano, e dove silenziosamente no
- Rendere lo standard la strada predefinita, perché sopravviva alla prossima scadenza
PerInteri team di ingegneria
Modernizzare senza congelare
Lo strangler pattern applicato al vostro sistema: come sostituire una piattaforma mentre resta in produzione e la roadmap continua ad avanzare.
- Trovare la prima porzione: piccola, di valore e davvero separabile
- Far girare vecchio e nuovo fianco a fianco dietro gli stessi URL
- Librerie condivise e multi-targeting come ponte tra i due
- Mettere in sequenza il livello dati, dove questi progetti di solito si arenano
- Rendere i progressi leggibili per chi li finanzia, sprint dopo sprint
PerLead e stakeholder su una piattaforma legacy
