Planera Motivering Kontrollera

Scrum och Agile för Dummies

Att börja. Scrum och Agile - vad är skillnaden? Kort sagt är Agile en filosofi, en familj av flexibla metoder för mjukvaruutveckling. Scrum är ett sådant tillvägagångssätt. Han har en bror - Kanban. Det är också det tillvägagångssätt som används i Agile.

Elena Truskova säger:

Den här veckan gick jag en tvådagars Agile/Scrum-utbildning (uttalas "agile" och "scrum"). Det har skrivits mycket abstru och inte så litteratur om flexibla metoder för mjukvaruutveckling, jag läser mycket. Men först efter två dagars fördjupning i ämnet fick jag äntligen en grundläggande förståelse för ämnet från vilket jag skriver denna anteckning.

Agile och Scrum hjälper till att organisera teamarbetet på ett sådant sätt att regelbundet och ofta släpper en produkt som är intressant för användaren.

I vissa banker reducerades, tack vare agile, vägen för en idé till användarna från två år till sex månader - i andra företag komprimerades en sexmånaders utvecklingscykel till tre. I dessa hektiska tider är detta en verklig konkurrensfördel, speciellt för mindre spelare.

Scrum-principer kan appliceras på absolut allt: till exempel att arbeta med en kreativ produkt. Detta är naturligtvis inte "kanoniskt smidigt", Scrum-evangelister kommer att slipa tänder, men dina processer kommer att röra sig mer muntert. Dam eller gå?

En del av Agile och Scrum kan till och med tas in i individuellt arbete. Säkerställ regelbunden publicering av inlägg, mät belastningen på utföraren, utvärdera framtida uppgifter tidsmässigt och glöm inte att analysera kvaliteten på det utförda arbetet - titta, allt har redan tänkts på för oss. Det återstår att genomföra.

Vig

(engelska agile - "agile, smart, quick-minded")

Flexibilitetskoncept:

Ersätt din typ av aktivitet istället för ordet "utveckling" - och dessa principer kommer att bli nära och begripliga.

”En fungerande produkt är huvudindikatorn på framsteg”, ”enkelhet som konsten att minimera onödigt arbete” och ”människor och interaktion är viktigare än processer och verktyg” – låter det rimligt?

Klunga

(eng. scrum - krossa i kampen om bollen i rugby)

Det är värt att komma ihåg här att detta är min personliga och subjektiva syn på Scrum. Här reflekterar jag över tillämpbarheten av Scrum-element både i kreativa projekt långt från IT, och i individuellt arbete (säg på en blogg). Många exakta detaljer för detta kommer att behöva utelämnas; Jag försöker hålla texten enkel och inte övermata läsaren med terminologi.

Styvheten i Scrum ligger i strukturen. Det finns en viss uppsättning tillvägagångssätt som fungerar bättre tillsammans än var för sig. Dra ut något och använd det åt dig, jag hoppas ingen förbjuder det.

Scrum uppstår oftast där det finns en viss produkt som har ett värde för användare och kunder och man behöver förstå så snabbt som möjligt på vägen mot målet om vi springer åt rätt håll eller om vi behöver rätta till kursen. Scrum-formatet låter dig släppa nästa version oftare, få regelbunden feedback och snabbt förfina produkten, samt förbättra arbetsprocessen.

Om du arbetar i ett team kräver Scrum att alla deltagare i processen strävar efter utbytbarhet, förmågan att ”plocka upp” en hängande uppgift om en granne är sjuk, utbyte av kompetens och kollektivt ansvar för produkten. Det finns lite individualism i Scrum. Beslut fattas kollektivt (enligt strikta principer), ingen kan pressa och tvinga dem att välja en annan lösning om teamet är säkra på att de har kommit fram till rätt.

Att ha ett sådant förtroende för Scrum är inte skrämmande, eftersom varje marsch varar exakt en sprint (en tydlig tidsperiod, vanligtvis från en till fyra veckor). Efter att sprinten är över kommer det ett ögonblick av analys: hur tog vi oss igenom det? Vad kan göras ännu bättre nästa gång?

Därför, även om vi alla med säkerhet sprang åt fel håll, kommer vi i slutet av spurten att ha möjlighet att rätta till det och fixa det som leder oss åt fel håll. Teamet i Scrum är självorganiserande och självjusterande.

Team i Scrum

Standardstorleken på ett Scrum-team är 7 plus eller minus 2 personer. Det är fem till nio. Det finns scrum-skalning: du kan bygga ett system för arbete på en gigantisk uppgift av 25 team. Men grundenheten i Scrum är teamet.

Varje lag har:

  • deltagare (när det gäller IT - utvecklare, vilka är dessa sju personer du har - bestäm själv)
  • produktägare (produktägare, produktägare). Hans roll: att förstå marknaden och användaren, att formulera uppgifter på företagens och användarnas språk, att ha i åtanke medvetenheten om i vilken riktning värde och nytta ska utvecklas, att uppfinna och välja uppgifter för produktutveckling. Något som en produktledare (inte ett team).
  • scrum master (scrum master, scrum evangelist). Hans roll: följa processen, observera lagets inre liv, motivera människor, ta bort hinder. Lite som en tränare.
    Runt teamet finns användare och intressenter (intressenter, kunder). Produktägaren går till dessa personer för att få råd.

Enhetssprint

Scrumarbete består av sprints. Alla sprints är upplagda på samma sätt. Det antas att för varje nästa sprint blir laget mer samarbetsvilligt och effektivt. I Scrum lär du dig av dina misstag, men snabbt – varje sprint analyserar du exakt vad du gjorde och hur du vill fixa det.

Produktägaren har en lista med affärsidéer för att hålla användarna nöjda. Det kallas en "produkt backlog" (en lista med produktidéer). I den sorteras idéer efter betydelse och betydelse.

Varje sprint har en sprintbacklog (sprintbacklog, lista över uppgifter för en sprint) - en sorterad lista med idéer som teamet bestämde sig för att göra i nästa sprint. Meningen med Scrum är att teamet själva utvärderar komplexiteten i varje uppgift och bestämmer vilka uppgifter som ska ingå i nästa sprint.

Uppgiften i sprinten har en tyngd känd för laget (det är känt hur lång tid det kommer att ta), en utförare är knuten till den, den är förståelig och viktig. Om du inte vet hur lång tid en uppgift kommer att ta måste du dela upp den i mindre delar.

I början av sitt liv planerar laget alltid dåligt. Detta är en objektiv verklighet. Men hon för statistik över vad hon klarar av i en sprint, och planerar mer exakt över tiden. Hon får hjälp av sprintens slutmöte – en retrospektiv. Där kan man diskutera de svaga punkterna i den utgående spurten och komma på sätt att göra det annorlunda.

Vanligtvis passar 5 plus eller minus 2 idéer in i en sprint. Om idéerna är för stora delar teamet upp dem så att det i varje sprint finns något litet att visa.

I Scrum kallas idéer för user stories (user stories, stories om användare) och formuleras på följande sätt: ”Jag gillar (roll?) vill (vad?) för att (varför?)”. Således ser teamet inte bara funktionaliteten utan också innebörden av dess skapelse, och för en specifik roll: användare, kund, köpare.

Resultatet av en sprint är alltid något att visa. Visar lagets arbete på demon i slutet av sprinten.

Enligt min åsikt liknar Scrum-processen att arbeta på en teamblogg. En sådan process skulle hjälpa till att upprätthålla regelbundenhet, samla författarnas expertis och inte rekrytera så mycket att du inte kan göra det.

Sprintstruktur

Sprinten börjar med planering: laget sätter sig ner och diskuterar: vi tar den här idén, vi tar inte den. Inom IT kan denna process dra ut på ett par timmar, eftersom diskussionen går ner till detaljerna. När det gäller att arbeta med en blogg kan detta bli en diskussion om ämnen och en artikelplan som du sedan måste sätta dig ner och skriva - förstå vad vi skriver, när och varför.

Varje dag är det uppställningsmöte (ståuppmöte, ståmöte) i 15 minuter. Det är viktigt att göra det stående: om någon pratar kommer resten vältaligt att växla från fot till fot och klia sig i örat. Du kan använda något föremål så att bara en deltagare talar åt gången, och skicka runt det i en cirkel.

Varje ståupp-deltagare turas om att svara på tre frågor:

  • vad jag gjorde igår
  • vad ska jag göra idag
  • det som saktar ner mig

Alla detaljerade samtal som binds upp i processen går utöver gränserna för stand-up. Stand-up är en punkt där du kan fånga problem eller få reda på att jag och en kollega av någon anledning gör samma sak samtidigt, vilket gör att någon av oss kan göra något annat.

I allmänhet bör underhållet av alla dessa tydliga beteenderegler hanteras av Scrum Master. Dessa är vanligtvis teknikens ideologer, som tror på det och är redo att bygga en process för maximal effektivitet av den tid som spenderas tillsammans. Utan en Scrum Master kommer processer att degenerera till det minsta möjliga, eftersom en person är lat och ekonomisk.

I slutet av sprinten finns en demo (demo, demonstration) som visar vad vi lyckades skapa under sprinten, en sprintrecension (sprintrecension, sprintrecension) med en revidering av produktbackloggen och prata om VAD vi gör, samt en retrospektiv (retro ) - vad vi inte gjorde på bästa sätt hela sprinten och vill förbättra ytterligare - om HUR vi gör det.

"Om jag hade åtta timmar på mig att hugga ner ett träd skulle jag ägna sex timmar åt att slipa en yxa." (Tillskrivs skogshuggare och president Abraham Lincoln)