Episódios
-
Sono crossfunzionali quei team che hanno al loro interno tutte le competenze necessarie per disegnare e realizzare un progetto software.
In questa puntata intervistiamo Stefano Zanotti, CTO di Sinapsi (https://sinapsiapp.com/) - con cui collaboriamo ormai da 5 anni per evolvere il loro software Logica web - a cui abbiamo chiesto di raccontare la sua esperienza con il nostro team crossfunzionale. -
L'assessment dell'infrastruttura tecnologica è un'attività propedeutica ad architettare soluzioni migliori ottimizzando infrastruttura e applicazioni, che facciamo insieme al cliente.
In questa puntata raccontiamo in quali situazioni si fa, come si svolge, che risultati dà e alcuni casi reali che ci hanno portato ad adottare soluzioni AWS per l'infrastruttura dei nostri clienti. -
Estão a faltar episódios?
-
In questa puntata parliamo di tempo libero, argomento leggero ma delicato quando si tratta di tempo della giornata lavorativa.
Come gestiamo i periodi di carico e scarico sui progetti? I momenti "extra-progetto" sono una reale perdita di produttività o un'occasione che può essere colta per generare valore? Qui condividiamo lo Slack time alla Flowing :) -
In questa puntata parliamo di come la progettazione e le analisi fatte per un progetto software aiutino a ridurre sprechi di tempo ed energie, e dell'aiuto fondamentale che portano per allineare i risultati attesi agli obiettivi di business.
Attraverso casi reali descriviamo come introdurre queste preziose attività in modo snello all'inizio e durante i progetti. -
In questa puntata parliamo di come abbiamo approcciato due progetti nel campo IoT, utilizzando metodi e attività generative per la raccolta informazioni e ideazione collaborativa, volte ad innovare nella giusta direzione.
-
Flowing è Advanced Tier Services Partner di AWS: come possiamo essere di aiuto nello sfruttare al meglio i servizi che offre?
Parliamo dei vantaggi sulla base delle nostre esperienze maturate negli ultimi anni, e del perché affidarsi ad un partner, invece di agire in autonomia nonostante la semplificazione portata da AWS nel mondo cloud. -
Il committente ha un’idea per il problema che vuole risolvere, una soluzione. E per questa soluzione ci chiede quanto costa realizzarla. Solo con qualche chiacchierata alla spalle, però, conosciamo davvero poco del contesto e delle attese, non possiamo garantire che la soluzione da implementare individuata - quando c'è - sia quella più adeguata.
Per questo proponiamo la lean discovery, un’ attività di esplorazione del progetto, per definirlo, stimarlo e avvialo portando chiarezza e allineamento, senza sprecare tempo, budget ed energie. Come funziona? Quali sono i suoi vantaggi e risultati?
Ne paliamo con Sabrina Onofrio, CEO e founder di Dipendesse da me (https://www.dipendessedame.it/).
Se vuoi approfondire questo tema, partecipa al workshop di mercoledì 22 giugno --> https://eventi.flowing.it/innovare-sistemi-digitali-ux-design/ -
La psychological safety è quella condizione in cui le persone di un'organizzazione si sentono confidenti di poter contribuire o fare proposte senza paura.
Come creare un ambiente che ci permetta di sentirci 'safe'? dipende dall'organizzazione o anche da noi stessi? come influisce sulle performance dei team?
Link per approfondire:
L'errore umano, James Reason: https://www.amazon.it/Lerrore-umano-James-Reason/dp/8863104824/
Normal Accidents, Charles Perrow: https://www.amazon.it/Normal-Accidents-Living-High-Risk-Technologies/dp/0691004129/
How Not to Land an Orbital Rocket Booster: https://www.youtube.com/watch?v=bvim4rsNHkQ&ab_channel=SpaceX
Blameless PostMortems and a Just Culture, Etsy: https://codeascraft.com/2012/05/22/blameless-postmortems/
Postmortem of database outage of January 31, GitLab: https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/ -
In questa puntata ci prendiamo l'onere di rispondere a questa domanda: il codice è un valore o un debito che accumuliamo? Un viaggio tra alcune metafore che ci aiutano a trovare una risposta sensata, a cui diamo forma nelle sessioni di discovery con i nostri clienti.
Link per approfondire: https://www.flowing.it/discovery/ -
Spesso le aziende si trovano nella situazione in cui i loro sistemi diventano troppo costosi da mantenere ed evolvere.
Come guidare l'evoluzione dello status quo? Quali fattori occorre considerare?
Ne parliamo in questa puntata, esplorando l'argomento da molti punti di vista: dal codice al contesto aziendale, dalla paura di apportare modifiche agli approcci possibili per portare risultati. -
Se fossi un cliente, terresti nascosta la data entro la quale il software deve essere online a chi ha il compito di svilupparlo? Sicuramente no, il team ha bisogno di avere questa informazione per gestire il progetto al meglio e rispettarla!
E ha senso che succeda lo stesso anche con il budget che metti a disposizione: esplicitare questi e altri vincoli dà al progetto l’opportunità che merita, per essere disegnato e realizzato nel modo più giusto rispetto a contesto e obiettivi.
Ne parliamo in questa puntata mettendo insieme i nostri punti di vista lato user experience, cloud e commerciale. -
Le deadline sono da sempre uno dei punti di maggior frizione durante lo sviluppo di un prodotto. In questa puntata parliamo di come in Flowing riusciamo a trasformare questo vincolo in un'opportunità per il business abbracciando l'approccio lean.
Con noi c'è anche un nostro cliente - Andrea Carpineti, CEO di Future Fashion - per cui abbiamo realizzato un progetto rispettando una deadline molto stringente. -
Fare una stima, da sempre argomento spinoso nello sviluppo software. Quali fattori entrano in gioco quando c’è da fare una stima? Quali considerare? Una cosa è certa: c’è una grande differenza tra stima e promessa.
Raccontiamo il nostro punto di vista e alcune nostre esperienze, coinvolgendo anche un nostro cliente con cui lavoriamo insieme ormai da sette anni ad un progetto di digital transformation. -
Scegliere il prossimo batch di user stories da implementare è un'attività che spesso viene presa sottogamba: creare feature di poco valore per l’utente, oppure crearne troppo presto o troppo tardi sono alcune delle cause più comuni dell'inefficacia nella gestione di un progetto software. In questa puntata parliamo del mindset necessario per gestire al meglio un backlog.
-
Nello sviluppo software esistono una serie di KPI noti e validati per misurare le performance di un team di sviluppo. Ma concentrarsi solo sull'efficienza non garantisce la creazione di software di valore, che è l'unico modo di soddisfare il cliente.
In questa puntata parliamo dell'efficacia e del modo in cui la garantiamo ai nostri clienti. -
La nostra modalità contrattuale Soddisfatti o Rimborsati nasce per costruire rapporti sani con i nostri clienti. Quali obiettivi ha? Evitare di fissare il prezzo del software nel momento di maggiore incertezza del progetto, l’inizio. Abilitare un rapporto win-win tra le parti.
In questa puntata approfondiamo le sue reason-why parlando di:
- Skin in the game
- Conquistare la fiducia del cliente
- Resistenza dell’ufficio acquisti
- Approccio incrementale e veloci iterazioni
In questa puntata abbiamo ospitato Jacopo Romei, autore di Extreme Contracts (https://jacoporomei.com/extreme-contracts/) -
In questa puntata parliamo di Test Driven Development, partendo da un pensiero di Kent Beck che dice: un test non è nient'altro che una forma di feedback.
Se questo è vero, come può cambiare ed evolvere l'utilizzo di una delle tecniche di sviluppo più famose e discusse degli ultimi 20 anni? Scopriamolo con un gruppo di nostri surfer che parlano dell'argomento. -
In questa puntata parliamo del testing automatico e di come sia uno strumento indispensabile per garantire un'elevata qualità del software. Un elemento che riteniamo imprescindibile e parte integrante della nostro approccio al software.
Libri, Post e Tool citati nella puntata:
- Working Effectively with Legacy Code di Micheal Feathers (https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)
- DesignStaminaHypothesis di Martin Fowler (https://martinfowler.com/bliki/DesignStaminaHypothesis.html)
- SacrificialArchitecture (https://martinfowler.com/bliki/SacrificialArchitecture.html)
- Trade-off Sliders (https://dist.francesco-strazzullo.now.sh/levers.html) -
Cos’è il refactoring? Oggi facciamo due chiacchiere riguardo a questo tema. Quando farlo? Perché? …e se non crea valore per il business? Riscrivere codice da zero o rifattorizzare? Da dove comincio? Una mezz’oretta per affrontare alcuni aspetti di questa pratica tanto utilizzata quanto controversa.
Materiale citato nella puntata:
- On the Spectrum of Abstraction di Cheng Lou (https://www.youtube.com/watch?v=mVVNJKv9esE)
- Clean Code di Uncle Bob (https://www.amazon.it/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)
- Refactoring: Improving the Design of Existing Code di Martin Fowler (https://www.amazon.it/Refactoring-Improving-Design-Existing-Code/dp/0201485672) -
In questa puntata parliamo di decisioni tecnologiche e di come sia importante definire un processo che permette di prendere decisioni che siano consapevoli e che tengano conto del contesto nel quale il software che dobbiamo sviluppare vive.
Libri citati nella puntata:
- Building Evolutionary Architectures: Support Constant Change di Neal Ford, Rebecca Parsons e Patrick Kua - Mostrar mais