Jy weet, nadat ek vir 'n rukkie op verskeie produkte gewerk het en dinge gebou het, het ek altyd gedink aan hierdie hele sprint ding wat almal doen. Soos elke maatskappy, volg elke span net hierdie twee-week-sprint siklus, want dit is wat almal anders doen, en dit laat my net dink baie soos wat hulle regtig kry deur dinge soos hierdie te doen. Want eerlik, die meeste van die tyd het hierdie sprints nie regtig enige impak op jou werklike produktiwiteit of jou produkkwaliteit nie, dit is net 'n manier om werk te organiseer wat iemand besluit is die "regte manier" en almal volg dit net. Jy het sprint beplanning, jy het daaglikse standups, jy het terugblikke, jy het al hierdie seremonies wat jou tyd neem wanneer jy eintlik iets kon bou. En ek sê nie vergaderings is sleg nie, maar die meeste van die tyd hierdie sprint rituele het geen gewig nie, dit is asof mense dit moet doen omdat dit die proses is, nie omdat dit hulle eintlik help om beter produkte te stuur nie. So ek het 'n paar maniere uitgevind om kort uitvoering siklusse te ontwerp sonder al hierdie sprint oorhead, en dit het regtig goed vir my gewerk: Work in Natural Cycles Based on Actual Tasks Die grootste probleem met sprinte is dat hulle jou in hierdie kunsmatige twee-week siklus dwing, ongeag wat jy eintlik bou. Soos as 'n funksie 3 dae neem om te bou, waarom beplan jy dit in 'n twee-week sprint? Wat ek in plaas daarvan doen, is ek breek werk af in natuurlike siklusse gebaseer op die werklike taak. Sommige take neem 2-3 dae, sommige neem 'n week, sommige neem langer. En ek werk net op hulle totdat hulle klaar is, stuur hulle, en beweeg na die volgende ding. Daar is geen kunsmatige termyn wat geen verband met die werklike werk het nie. Dit is die belangrikste deel omdat dit jou toelaat om te fokus op verskaffingskwaliteit eerder as om dinge in willekeurige tydbokse te pas. Ship Continuously Instead of Batch Releases Sprints laat jou alles in hierdie vrylatingssiklusse batch. Jy voltooi 10 funksies in twee weke en vrystel hulle almal op 'n keer.Maar dit maak nie sin vir die meeste produkte nie, veral SaaS produkte waar jy op enige tyd kan implementeer nie. Ek verskaf funksies sodra hulle gereed is. As iets op Dinsdag gedoen word, druk ek dit op Dinsdag. As iets anders op Vrydag gereed is, gaan dit op Vrydag uit. Op hierdie manier kry gebruikers waarde vinniger, en jy kan vinniger terugvoer kry. En die terugvoer is die belangrikste deel, want dit is hoe jy weet of jy die regte ding gebou het of nie. Focus on One Thing at a Time In sprinte beplan teams soos 5-10 verskillende dinge om op dieselfde tyd te werk. En dan spring almal tussen take, konteks verander die hele tyd, en niks word reg gedoen nie. Wat beter werk, is om net op een belangrikste ding op 'n keer te fokus. Kies die belangrikste funksie of probleem, werk daarop, voltooi dit, stuur dit, en beweeg dan na die volgende ding.Dit beteken nie dat jy nie klein take aan die kant kan hê nie, maar jou belangrikste fokus moet een ding wees. Use Deadlines Only When They Actually Matter Sprints skep hierdie kunsmatige tydperke elke twee weke. Maar die meeste funksies het nie regtig 'n spesifieke tydperk nodig nie. Soos as jy 'n nuwe dashboard-funksie bou, maak dit nie saak of dit op Maandag of Woensdag kom nie. In plaas daarvan om deadlines op alles te dwing, gebruik ek hulle slegs wanneer daar eintlik 'n rede is. Soos as jy iets vir 'n konferensie begin, of jy 'n kliënt 'n spesifieke datum belowe het, of daar is 'n mededingende rede om deur 'n sekere tyd te stuur. Keep Communication Lightweight Die grootste oorhead van sprinte is al die vergaderings. Planning vergaderings, daaglikse standups, resensies, retrospektiewe. Dit alles voeg tot ure elke week toe waar jy eintlik niks bou nie. Wat ek doen, is om kommunikasie regtig lig te hou. As ek solo werk, hou ek net notas vir myself oor wat ek werk en wat volgende. As ek met 'n span werk, kyk ons net in wanneer dit nodig is, nie op 'n vaste skedule nie. Iemand het 'n vraag? Hulle vra. Iemand het iets klaar? Hulle deel dit. Iemand is geblokkeer? Hulle praat op. Dit benodig nie 'n daaglikse vergadering by 10 AM elke dag waar almal sê wat hulle werk wanneer jy reeds weet wat almal werk. Plan Only What You Need to Plan Sprint beplanning laat jou twee weke van werk vooraf beplan.Maar die ding is, jy weet nie regtig wat sal kom in daardie twee weke nie.Miskien verskyn 'n fout, miskien gebruikersfeedback verander jou prioriteite, miskien besef jy iets is belangriker as wat jy beplan het. Miskien beplan ek 2-3 dinge vooruit, so ek weet altyd wat kom, maar ek beplan nie die hele maand of die hele kwartaal in detail nie. Measure by Outcomes, Not by Process Sprints laat jou dinge soos spoed, storiepunte, verbrandingskaarte meet.Maar dit is net prosesmetrikes.Dit vertel jou nie of jy iets waardevol bou of nie. Wat regtig belangrik is, is resultate. Het jy iets gestuur? Het gebruikers dit gebruik? Het dit die probleem opgelos wat jy probeer oplos? Is dit geld maak as dit die doel is? Dit is die werklike metrikes wat jou vertel as jy suksesvol is of nie. Die proses maak nie saak as die uitslag goed is nie, en die proses help nie as die uitslag sleg is nie. Die belangrikste ding wat ek geleer het, is dat jy nie sprinte nodig het om goeie produkte te lewer nie. Jy benodig net duidelike fokus, vinnige terugvoerloop en die dissipline om dinge eintlik te voltooi voordat jy na die volgende ding beweeg. En dit beteken nie struktuur is sleg nie. Jy moet nog steeds beplan, jy moet nog steeds kommunikeer, jy moet nog steeds prioriteer. Maar jy kan dit alles doen sonder om jouself in hierdie rigide twee-week siklusse te dwing wat nie regtig sin maak vir hoe werklike produkontwikkeling werk nie. Net bou, skepping, leer, herhaal. Dit is die siklus wat regtig belangrik is.