Sapete, dopo aver lavorato su più prodotti e costruito le cose per un po ', ho sempre pensato a tutta questa cosa di sprint che tutti fanno. Come ogni azienda, ogni squadra segue questo ciclo di sprint di due settimane perché questo è ciò che tutti gli altri stanno facendo, e mi fa solo pensare molto come cosa si ottiene veramente da fare cose come questa. perché onestamente la maggior parte del tempo questi sprint non hanno davvero alcun impatto sulla tua produttività effettiva o sulla qualità del tuo prodotto, è solo un modo di organizzare il lavoro che qualcuno ha deciso è il "modo giusto" e tutti lo seguono. Hai la pianificazione dello sprint, hai le standups quotidiane, hai le retrospettive, hai tutte queste cerimonie che prendono il tuo tempo quando potresti effettivamente costruire qualcosa.E non sto dicendo che le riunioni siano cattive, ma la maggior parte del tempo questi rituali dello sprint non hanno alcun peso, è come se le persone dovessero farlo perché questo è il processo, non perché li aiuta effettivamente a spedire prodotti migliori. Così ho scoperto alcuni modi per progettare cicli di esecuzione brevi senza tutto questo sprint overhead, e ha funzionato davvero bene per me: Work in Natural Cycles Based on Actual Tasks Il problema più grande con gli sprint è che ti costringono a entrare in questo ciclo artificiale di due settimane indipendentemente da ciò che stai costruendo.Come se una funzione richiede 3 giorni per costruire, perché stai pianificando in uno sprint di due settimane?E se qualcosa richiede 3 settimane, lo stai dividendo artificialmente solo per adattarsi allo sprint. Quello che faccio invece è suddividere il lavoro in cicli naturali in base al compito effettivo. Alcuni compiti richiedono 2-3 giorni, alcuni una settimana, altri più a lungo. E io lavoro su di essi fino a quando non sono finiti, li spedisco e passi alla prossima cosa. Non c'è alcun termine artificiale che non abbia alcuna connessione con il lavoro effettivo. Questa è la parte più importante perché ti consente di concentrarti sulla qualità della spedizione invece di inserire le cose in scatole temporali arbitrarie. Ship Continuously Instead of Batch Releases Gli Sprints ti permettono di imballare tutto in batch in questi cicli di rilascio. Finisci 10 funzionalità in due settimane e li rilasci tutti in una volta.Ma questo non ha senso per la maggior parte dei prodotti, specialmente per i prodotti SaaS in cui puoi implementare in qualsiasi momento. Spedisco le funzionalità non appena sono pronte. Se qualcosa è fatto martedì, lo spingo martedì. Se un'altra cosa è pronta venerdì, esce venerdì. In questo modo gli utenti ottengono valore più velocemente e puoi ottenere feedback più velocemente. E il feedback è la parte più importante perché è così che sai se hai costruito la cosa giusta o meno. Focus on One Thing at a Time Nei sprint, le squadre pianificano come 5-10 cose diverse per lavorare allo stesso tempo.E poi tutti saltano tra le attività, il contesto cambia tutto il tempo e nulla viene fatto correttamente.Ho visto questo accadere tante volte e rende le cose più lente. Ciò che funziona meglio è concentrarsi su una cosa principale alla volta. Scegli la caratteristica o il problema più importante, lavori su di esso, finisci, spedisci e poi passa alla cosa successiva. Questo non significa che non puoi avere piccoli compiti da parte, ma il tuo focus principale dovrebbe essere una cosa. Use Deadlines Only When They Actually Matter Gli Sprints creano queste scadenze artificiali ogni due settimane. Ma la maggior parte delle funzionalità non ha davvero bisogno di una scadenza specifica. Come se stai costruendo una nuova funzionalità dashboard, non importa se arriva il lunedì o il mercoledì? Invece di imporre scadenze su tutto, li uso solo quando c'è davvero una ragione. Come se stai lanciando qualcosa per una conferenza, o hai promesso a un cliente una data specifica, o c'è una ragione competitiva per spedire per un certo tempo. Questi sono termini reali che realmente contano. Tutto il resto può spedire quando è pronto e fatto correttamente. Keep Communication Lightweight Il più grande overhead di sprint è tutte le riunioni. pianificazione riunioni, standups giornalieri, recensioni, retrospettive. Tutto questo aggiunge fino a ore ogni settimana in cui non si sta realmente costruendo nulla. Quello che faccio è mantenere la comunicazione davvero leggera. Se sto lavorando da solo, sto solo tenendo appunti per me stesso su cosa sto lavorando e cosa succederà. Se sto lavorando con un team, facciamo il check-in solo quando è necessario, non su un programma fisso. Qualcuno ha una domanda? chiedono. Qualcuno ha finito qualcosa? lo condividono. Qualcuno è bloccato? parlano. Non richiede un incontro giornaliero alle 10 di ogni giorno in cui tutti dicono su cosa stanno lavorando quando sai già su cosa stanno lavorando tutti. Plan Only What You Need to Plan La pianificazione dello sprint ti fa pianificare due settimane di lavoro in anticipo.Ma la cosa è, non sai davvero cosa verrà fuori in quelle due settimane.Forse appare un bug, forse il feedback degli utenti cambia le tue priorità, forse ti rendi conto che qualcosa è più importante di quello che hai pianificato. Potrei pianificare 2-3 cose in avanti, quindi so sempre cosa arriva, ma non pianifico l'intero mese o l'intero trimestre in dettaglio. Questo mi consente di rimanere flessibile e rispondere a ciò che conta veramente invece di essere bloccato in un piano che è stato fatto settimane fa quando avevi meno informazioni. Measure by Outcomes, Not by Process Gli Sprints ti fanno misurare cose come la velocità, i punti della storia, i grafici di bruciatura.Ma questi sono solo metriche di processo.Non ti dicono se stai costruendo qualcosa di prezioso o meno. Ciò che conta davvero sono i risultati. Hai inviato qualcosa? gli utenti lo usano? ha risolto il problema che stavi cercando di risolvere? sta facendo soldi se questo è l'obiettivo? Queste sono le metriche reali che ti dicono se sei riuscito o no. Il processo non conta se il risultato è buono, e il processo non aiuta se il risultato è cattivo. La cosa principale che ho imparato è che non hai bisogno di sprint per spedire buoni prodotti. Hai solo bisogno di un focus chiaro, loop di feedback rapido e la disciplina per finire le cose prima di passare alla cosa successiva.Tutto questo sprint è solo un processo per il bene del processo, e la maggior parte del tempo non aggiunge valore, aggiunge solo incontri. E questo non significa che la struttura sia cattiva. Hai ancora bisogno di pianificare, hai ancora bisogno di comunicare, hai ancora bisogno di prioritizzare. Ma puoi fare tutto questo senza forzarti in questi rigidi cicli di due settimane che non hanno davvero senso per il funzionamento reale dello sviluppo del prodotto. Basta costruire, spedire, imparare, ripetere. Questo è il ciclo che conta veramente.
