Du ved, efter at have arbejdet på flere produkter og bygget ting i et stykke tid, har jeg altid tænkt på hele denne sprint ting, som alle gør. Som ethvert firma, hvert hold bare følger denne to-ugers sprint cyklus, fordi det er, hvad alle andre gør, og det er bare får mig til at tænke meget som hvad de virkelig får fra at gøre ting som dette. fordi ærligt de fleste af tiden disse sprints ikke virkelig har nogen indflydelse på din faktiske produktivitet eller dit produkt kvalitet, det er bare en måde at organisere arbejde, at nogen besluttede er den "rigtige måde" og alle bare følger det. Du har sprintplanlægning, du har daglige standups, du har retrospektiver, du har alle disse ceremonier, der tager din tid, når du faktisk kunne bygge noget. Så jeg fandt ud af nogle måder at designe korte udførelsescyklusser uden al denne sprint overhead, og det har fungeret rigtig godt for mig: Work in Natural Cycles Based on Actual Tasks Det største problem med sprints er, at de tvinger dig ind i denne kunstige to-ugers cyklus, uanset hvad du rent faktisk bygger.Som hvis en funktion tager 3 dage at bygge, hvorfor planlægger du det i en to-ugers sprint? Hvad jeg gør i stedet er, at jeg nedbryder arbejdet i naturlige cyklusser baseret på den faktiske opgave. Nogle opgaver tager 2-3 dage, nogle tager en uge, nogle tager længere. Og jeg arbejder bare på dem, indtil de er færdige, sender dem, og flytter til den næste ting. Der er ingen kunstig deadline, der ikke har nogen forbindelse til det faktiske arbejde. Dette er den vigtigste del, fordi det giver dig mulighed for at fokusere på leveringskvalitet i stedet for at sætte ting i vilkårlige tidslinjer. Ship Continuously Instead of Batch Releases Du færdiggør 10 funktioner på to uger og frigiver dem alle på én gang. Men det giver ikke mening for de fleste produkter, især SaaS-produkter, hvor du kan implementere når som helst. Jeg sender funktioner, så snart de er klar. Hvis noget er gjort på tirsdag, skubber jeg det på tirsdag. Hvis noget andet er klar på fredag, går det ud på fredag. På denne måde får brugerne værdi hurtigere, og du kan få feedback hurtigere. Og feedback er den vigtigste del, fordi det er hvordan du ved, om du har bygget den rigtige ting eller ej. Focus on One Thing at a Time I sprints planlægger hold som 5-10 forskellige ting at arbejde på på samme tid. Og så hopper alle mellem opgaver, kontekst skifter hele tiden, og intet virkelig gøres ordentligt. Det, der virker bedre, er bare at fokusere på en hovedting ad gangen. Vælg den vigtigste funktion eller problem, arbejd på det, færdiggør det, send det, og derefter flytte til den næste ting. Dette betyder ikke, at du ikke kan have små opgaver på siden, men dit hovedfokus skal være én ting. Use Deadlines Only When They Actually Matter Sprints skaber disse kunstige deadlines hver anden uge. Men de fleste funktioner har ikke virkelig brug for en bestemt deadline. Som hvis du bygger en ny dashboard-funktion, er det ligegyldigt, om den leveres på mandag eller onsdag? I stedet for at tvinge deadlines på alt, bruger jeg dem kun, når der faktisk er en grund. Som hvis du lancerer noget til en konference, eller du lovede en kunde en bestemt dato, eller der er en konkurrencedygtig grund til at sende ved en bestemt tid. Keep Communication Lightweight Den største overhead af sprints er alle møderne. Planlægning af møder, daglige standups, anmeldelser, retrospektiver. Det hele tilføjer op til timer hver uge, hvor du faktisk ikke bygger noget. Hvad jeg gør er at holde kommunikationen virkelig let. Hvis jeg arbejder solo, holder jeg bare noter for mig selv om, hvad jeg arbejder på, og hvad der skal ske. Hvis jeg arbejder med et team, tjekker vi bare ind, når det er nødvendigt, ikke på en fast tidsplan. Nogen har et spørgsmål? De spørger. Nogen færdig med noget? De deler det. Nogen er blokeret? De taler op. Det kræver ikke et dagligt møde kl. 10 hver eneste dag, hvor alle siger, hvad de arbejder på, når du allerede ved, hvad alle arbejder på. Plan Only What You Need to Plan Sprintplanlægning får dig til at planlægge to ugers arbejde på forhånd. Men tinget er, at du ikke rigtig ved, hvad der kommer op i de to uger. Måske vises en fejl, måske brugerfeedback ændrer dine prioriteter, måske indser du, at noget er vigtigere end det, du planlagde. Måske planlægger jeg 2-3 ting fremad, så jeg altid ved, hvad der kommer op, men jeg planlægger ikke hele måneden eller hele kvartalet i detaljer. Measure by Outcomes, Not by Process Sprints får dig til at måle ting som hastighed, historiepunkter, burndown-diagrammer.Men disse er kun procesmetrikker.De fortæller dig ikke, om du bygger noget værdifuldt eller ej. Hvad der virkelig betyder noget er resultaterne. Har du sendt noget? bruger brugerne det? løser det det problem, du forsøgte at løse? tjener det penge, hvis det er målet? Dette er de virkelige målinger, der fortæller dig, om du er vellykket eller ej. Processen betyder ikke noget, hvis resultatet er godt, og processen hjælper ikke, hvis resultatet er dårligt. Det vigtigste, jeg har lært, er, at du ikke har brug for sprints for at levere gode produkter. du har bare brug for klart fokus, hurtige tilbagemeldingsløb og disciplinen til faktisk at afslutte tingene, før du flytter til den næste ting. Og det betyder ikke, at strukturen er dårlig. Du har stadig brug for at planlægge, du har stadig brug for at kommunikere, du har stadig brug for at prioritere. Men du kan gøre alt dette uden at tvinge dig selv ind i disse stive to-ugers cyklusser, der ikke virkelig giver mening for, hvordan den faktiske produktudvikling fungerer.
