Hva er Agile and Scrum. Hva er Scrum? Scrum team

Definisjon

Agile (agile software development) er en familie av «agile» tilnærminger til programvareutvikling. Disse tilnærmingene blir også noen ganger referert til som rammer eller smidige metoder.

Agile stammer fra IT-miljøet, men spres deretter til andre områder – fra industriell ingeniørarbeid til kunstig intelligens.

Betydningen av Agile er formulert i Agile Software Development Manifesto: «Mennesker og interaksjoner er viktigere enn prosesser og verktøy. Et fungerende produkt er viktigere enn omfattende dokumentasjon. Samarbeid med kunden er viktigere enn å avtale vilkårene i kontrakten. Å være klar for endring er viktigere enn å følge den opprinnelige planen. «

Agile Manifesto er hoveddokumentet for alle smidige utviklingsmetoder. Agile ble opprettet i 2001 av en gruppe entusiastiske programmerere som ønsket å forstå hva som ligger i hjertet av utviklingen av et ettertraktet og nyttig IT-produkt. Du trenger ikke bare å stole på detaljerte planer når du implementerer et prosjekt. som er opprettet på forhånd. Det er viktig å fokusere på de stadig skiftende forholdene i det ytre og indre miljøet og ta hensyn til tilbakemeldingene fra kunder og brukere. Dette oppfordrer utviklere og ingeniører til å eksperimentere og søke nye løsninger uten å være begrenset av stive rammer og standarder.

Separate smidige tilnærminger inkluderer scrum og kanban.

Scrum er en «strukturert tilnærming». Et universelt team av spesialister jobber med hvert prosjekt, som ytterligere to personer blir med på: produkteieren og scrum-mesteren. Den første kobler teamet med kunden og overvåker utviklingen av prosjektet; dette er ikke en formell teamleder, men snarere en kurator. Det andre hjelper den første med å organisere forretningsprosessen: han holder generalforsamlinger, løser hverdagsproblemer, motiverer teamet og overvåker etterlevelsen av scrumtilnærmingen.

Scrum-tilnærmingen deler arbeidsflyten i like store sprinter – vanligvis perioder fra en uke til en måned, avhengig av prosjekt og team. Før sprinten blir oppgaver for denne sprinten formulert, til slutt blir resultatene diskutert, og teamet starter en ny sprint. Sprints er veldig praktiske å sammenligne med hverandre, noe som lar deg håndtere arbeidseffektiviteten.

Kanban er en «balansetilnærming». Dens oppgave er å balansere ulike spesialister i teamet og unngå en situasjon der designere jobber dag og natt, og utviklere klager over mangelen på nye oppgaver.

Hele teamet er ett – det er ingen produktseier og scrummesterroller i kanban. Forretningsprosessen er ikke delt inn i universelle sprints, men på scenen for å utføre spesifikke oppgaver: «Planlagt», «Utviklet», «Testet», «Fullført» osv.

Den viktigste ytelsesindikatoren i kanban er gjennomsnittlig tid det tar å fullføre en oppgave over hele linja. Oppgaven gikk raskt – teamet jobbet effektivt og greit. Oppgaven ble forsinket – du må tenke på hvilket stadium og hvorfor det var forsinkelser og hvis arbeid må optimaliseres.

For å visualisere smidige tilnærminger, brukes tavler: fysisk og elektronisk. De lar deg gjøre arbeidsflyten åpen og forståelig for alle spesialister, noe som er viktig når teamet ikke har en formell leder.

Hva er smidig?

Agile er en tilnærming til prosjektledelse eller programvareutvikling. I Agile utvikler krav og løsninger seg gjennom iterasjon og samarbeid fra tverrfunksjonelle, selvorganiserende team og forretningsbrukere. Agile gleder seg over endrede krav, selv på et senere tidspunkt. Kunder, forretningsdeltakere og utviklere jobber sammen gjennom hele prosjektet. Agile team tilpasser oppførselen for å møte prosjektets skiftende behov.

Agile er en filosofi eller orientering (Griffin). Agile er mye brukt som en guide for å komme nærmere prosjektarbeidet. Agile legger vekt på utvikling iterasjon samt testing i programvaren utvikling livssyklus (SDLC). Agile bryter ned et helt produkt eller prosjekt i små samlinger. I Agile metodikk skjer utvikling eller testing samtidig. Agile støtter samarbeid så vel som direkte kommunikasjon.

Hva er Scrum?

Scrum er grunnlaget for prosjektledelse eller programvareutvikling. Scrum er en av de smidige prosessene. Scrum fokuserer på å levere forretningsverdi til forretningsbrukere på minimal tid. Prosjektene er delt inn i sprint, som vanligvis varer fra en til tre uker. Scrum har tre hovedroller: scrum master, produkteier og teammedlemmer.

Scrum legger vekt på egenorganisering og delt eierskap blant teammedlemmene. Han ser på prosjektledelse som en prosess for å skape felles verdi; og vektlegger samarbeid og iterativ utvikling for effektivt å håndtere endring og skape bedre produkter for å møte kundenes behov. Scrum ser på tiden som en begrensning. Den legger vekt på boksetid og bruker daglig sprintplanlegging og gjennomgangsmøter.

Likheter mellom Agile og Scrum:

Agile og scrum er begge relatert til prosjektledelse og programvareutvikling. Siden Scrum er en av måtene å implementere Agile på, har de begge flere likheter. Begge vektlegger optimal bruk av ressurser. Begge vektlegger effektiv og effektiv styring av ulike oppgaver.

Agile og scrum, begge tar sikte på å få mest mulig ut av forretningsbrukere. De prøver å sikre at et produkt eller prosjekt blir levert til forretningsbrukere så snart som mulig. Begge vektlegger kontinuerlig forbedring, samarbeid, åpen kommunikasjon, etc.

The Nature of Agile and Scrum:

Agile er en utviklingsmetodikk basert på en inkrementell og iterativ tilnærming; mens Scrum er en av de mange implementeringsskjemaene eller Agile prosessene.

Scrum tilbyr trinnvise moduler til klienten hver uke eller fjorten dager.

Eksempler på bruk

Et av prinsippene til Agile er basert på en persons personlige ansvar, og ikke på feilsøking av interne prosesser.

(Fra en artikkel på VC.ru)

Når vi arbeider med profesjonelle team bruker vi Scrum, ofte velger vi en 2-3 ukers syklus med retrospektive møter som gjør at vi kan holde alt under kontroll.

(Fra et intervju med Vedomosti med Frank Sosier, trener for Frittstående Agility)

Hovedideen til Kanban er visualisering av arbeidsflyten. Den består i å lage et fysisk dashbord der du visuelt kan merke fremgangen din.

(Fra oversettelsen av Forbes-kolonnen på Rusbase)

Hvis vi snakker om hva smidig er, vil jeg begrense meg til en slik setning – det er et sett med verdier innenfor rammen vi bygger vårt arbeid med produkter med, med prosesser i organisasjonen.

(Alexey Pimenov, Managing Partner for ScrumTrek i en artikkel om Rusbase)

Hvordan og hvorfor scrummetodologien dukket opp

Før tilkomsten av Scrum ble fossefalltilnærmingen vedtatt i programvareutviklingsverdenen. Arbeidet med produktet ble utført i henhold til følgende plan.

1. Definere produktkrav.
2. Planlegg hele prosjektet fra start til slutt.
3. Skriv koden.
4. Test produktet.

Utviklerne koordinerte arbeidsplanen med kunden og fulgte vilkårene strengt. Da produktet var klart ble det testet, men det var ingen måte å endre noe på. Derfor, hvis feil ble oppdaget, måtte de starte på nytt, og arbeidstiden økte.

Dette var helt til en gruppe innovatører bestemte seg for å endre situasjonen fullstendig. De så på hvordan vellykkede team fungerer: uten å gå glipp av tidsfrister og få nøyaktig det resultatet de planla. Det viste seg at suksessen var i fleksibiliteten i prosessen.

Leksjonene bidro til å skape Agile Software Development Manifesto. Den inkluderte bare fire poeng, men de endret prosessen fullstendig.

Agile programvareutviklingsmanifest

1 Mennesker er viktigere enn verktøy.
2 Produktkvalitet er viktigere enn dokumentasjon.
3 Interaksjon med kunden er viktigere enn kontrakten.
4 Beredskap for endring er viktigere enn en plan.

Disse fire punktene var grunnlaget for fremveksten av Agile, en smidig programvareutviklingsprosess. Senere ble det opprettet 12 prinsipper, som fremdeles brukes i enhver smidig metodikk.

12 smidige prinsipper

1 Det viktigste er god programvare og en fornøyd kunde.
2 Beredskap for endring når som helst.
3 Fullt fungerende programvare – så ofte som mulig.
4 Teammøte er best for informasjonsutveksling.
5 Kunden og utviklingsteamet må samarbeide.
6 Stol på at folk gjør jobben sin.
7 Det er fungerende programvare – det er fremgang.
8 Agile prosesser – kontinuerlig utvikling.
9 Oppmerksomhet på kvalitet fremmer fleksibilitet.
10 Enkelheten i prosessen eliminerer unødvendig arbeid.
11 Et selvorganiserende team fungerer bedre.
12 Kontinuerlig jakt på større effektivitet.

Smidig og foss, vekter

En av de smidige metodene for programvareutvikling basert på smidige prinsipper er Scrum.

Scrumskapere Jeff Sutherland og Ken Schwaber har sett arbeidet til det amerikanske militæret, spesialstyrker og til og med rugbyspillere i mange år. Og de la merke til at suksessen deres er basert på interaksjon og teamarbeid. Sutherland og Schwaber innså at dette var akkurat det programvareutviklerne trengte. Slik dukket Scrum-metoden opp.

Scrum kjerneprinsipper

Scrum fokuserer alltid på kunden som trenger å få ønsket produkt i tide og til lavest mulig pris. Dette kan oppnås ved å følge noen viktige prinsipper.

Arbeide i korte sykluser (sprints)

Planlegg en sprint, ikke hele prosjektet på en gang. Hver sprint er en tidsperiode der teamet jobber på en helt ferdig del av produktet.

Fleksibilitet. «Sjekk og tilpass»

Prosessfleksibilitet og produkttesting etter hver sprint. Hvis noe går galt, er teamet alltid klar til å endre utviklingsstrategien eller revidere etterslepet.

Deltakelse fra kunde og brukere i opprettelsen av produktet.

Kunden står ikke til side, men er fullt involvert i arbeidet. For dette er det rollen som eieren av produktet, som utføres av kunden selv eller hans representant. Det er gjennom ham teamet samhandler med brukerne. Siden utviklingen utføres i korte faser, blir brukerne involvert i testing nesten umiddelbart.

Etter første testing får de tilgang til produktet, og produkteieren samler inn tilbakemeldinger. Slik kan laget forbedre resultatet.

Laginteraksjon

Et Scrum-team er en gruppe mennesker som jobber for ett resultat og som en helhet. Alle tilstreber ett felles mål.

Betydningen av scrum-teamet

Et scrum-team er oftest en gruppe på fem til ni personer. Dette er det optimale tallet, men noen ganger er det lag på tre. Hvis det er flere mennesker, blir det vanskeligere for dem å samhandle med hverandre, noe som forstyrrer arbeidet og reduserer produktiviteten.

Kommandostruktur

• Produkteier. Personen som representerer produktet og er mellomleddet mellom kunden, brukerne og utviklingsteamet. Noen ganger kan det være kunden selv.

• Scrum master. Oftest – en spesialansatt ansatt som leder teamet til resultatet. Han leder ikke teamet, men overvåker implementeringen av de grunnleggende prinsippene til Scrum. Hans oppgave er ikke å presse, ikke å gjøre alt arbeidet selv og ikke å fordele ansvar, men å hjelpe, lede og løse problemer som hindrer utviklingsprosessen.

• Utviklere. Et scrum-team har alltid folk med forskjellige ferdighetssett. Så et team på fem til ni personer leder hele prosjektet fra start til slutt. Ett team – ett ferdig produkt.

Hvordan et scrum-team ser ut

Fordeling av roller

Scrum fungerer når det er en rollefordeling. Det er tre av dem.

Team. Dette er en egenorganisert gruppe på 3-9 personer. Bidraget til en enkelt ansatt blir ikke evaluert. Det er bare viktig hvilket resultat teamet har oppnådd gjennom felles innsats.

Produkteier. Dette er vanligvis en gründer som kjenner sin virksomhet og forstår kundenes behov. Han har erfaring nok til å vite hva det ferdige produktet skal være. Produkteieren er koblingen mellom teamet, forbrukeren og produksjonen. Han jobber med tilbakemeldinger, tar viktige beslutninger og overvåker prosjektbudsjettet. Produkteieren forteller ikke teamet hvilken vei de skal ta, men ser bare på resultatet.

Scrum Master eller teamleder. Scrum Master er ansvarlig for suksessen til teamet. Han tar ikke avgjørelser og leder ikke. Hans oppgave er å få laget til å fungere uten ledelsesmessig innflytelse. Scrum Master er limet som holder teamet sammen.

Scrum Tools

Scrum er en fleksibel planleggingsteknikk som passer for ethvert prosjekt. Med hjelpen kan du øke produktiviteten til selskapet og oppnå bedre resultater. For eksempel brukte teamet en måned på en oppgave, og en halv måned på forbedringer. Nå vil den samme oppgaven ta to uker, og mest sannsynlig blir det ingen forbedringer.

Instruksjoner: hvordan du bruker Scrum til å fungere som Ajail

Scrum er enklere enn andre rammer. Han gir verktøyene og foreslår i hvilken rekkefølge han skal bruke dem for å oppnå resultatet.

Scrum foreslår å gjøre dette:

1. For å pumpe opp den teoretiske basen: les bøker om emnet og se videoforelesninger. Opptakene fra Agiledays-konferansene er tilgjengelige på YouTube på kanalen. I samfunnet deler Scrum-tilhengere sine erfaringer – du kan lære av dem.
2. Velg en produkteier. Dette er personen som presenterer det ferdige produktet i detalj. Han vil også vurdere risiko, fordeler og ta strategiske beslutninger.
3. Sett sammen et team på 3-9 personer. Teamet må ha folk som har nok kunnskap og ferdigheter til å jobbe med prosjektet.
4. Utnevne en Scrum Master eller ansett en profesjonell fra et konsulentbyrå.
5. Be produkteieren om å skrive et etterslep og la teamet evaluere det. Det er flott om teamet vil rangere det ikke i timer, men i relative enheter.
6. Planlegg en sprint. Den må ha en fast varighet og en presis liste over oppgaver som ikke kan utvides.
7. Gjør arbeidet gjennomsiktig. Hvert teammedlem bør se hvilke oppgaver som allerede er løst og hvilke som fortsatt må jobbes med. For å gjøre dette trenger du verktøy: et scrumbrett eller et utbrenthetsdiagram.
8. Å gjennomføre daglige teammøter er en daglig Scrum. På møter sjekker teammedlemmer hverandres resultater, ser på hvilket stadium prosjektet er på og bestemmer hvordan de skal gå videre til målet. Møtet varer 15 minutter. Hvis det tar lengre tid, gjør teamet og Scrum Master noe galt.
9. Avslutt sprinten med en anmeldelse. Sprint gjennomgang – et møte som er interessert i enhver interessert person: forbruker, kunde, produkteier, scrum master. På møtet viser teamet det ferdige produktet eller deler av det. Det spiller ingen rolle hva det vil være, det viktigste er at det oppfyller sin funksjon.
10. Gjennomføre et retrospektivt møte umiddelbart etter sprintgjennomgangen. Når teamet har vist et fungerende produkt, setter alle seg ned ved bordet og analyserer sprinten. Hva gikk bra? Hva kan forbedres? Hvilke hindringer overvant teamet? På slutten av møtet bør Scrum Master og teamet tenke på hvordan du kan gjøre neste sprint enda bedre.
11. Planlegg en ny sprint med en gang!

Hvem er smidig for?

Agile endrer måten vi tilnærmer oss liv og entreprenørskap. Han lærer deg å raskt svare på omstendighetene og tilpasse deg dem.

Agile jobber overalt: innen ledelse, handel, tjenester. Noen bruker det til å styre sine egne liv og holde tritt med alt.

Men ingen kan garantere at han vil hjelpe et bestemt selskap. Hvis selskapet er lite, er det lettere å ombestemme folket. Det er vanskeligere for store selskaper: Når det er flere avdelinger, og hver har sin egen leder, kan implementeringen av Agile bli forsinket. Teamet vil motstå endring. For å gjøre det lettere, inviterer slike selskaper Agile-trenere.

Agile passer ikke for de som har laget et typisk produkt i mange år på rad. Det er mer lønnsomt for slike selskaper å lage tusen identiske stoler om gangen: det vil fortsatt være bestillinger. Men så snart en kunde dukker opp med spesielle ønsker, trenger du nøyaktig samme stol, men la bena være bredere, og polstringen er lysere – Agile er nødvendig.

Et ord til ekspertene

Avhengig av oppgavene bruker vi forskjellige metoder innen filosofien – smidig, scrum, kanban.

Scrum lar deg utvikle de nødvendige egenskapene hos de ansatte – proaktivitet, uavhengighet, organisering, kommunikasjonsevner og fremsyn. Hovedpoenget med metoden er å utføre oppgaver i selvorganiserende team, der alle har sin egen rolle og alle er ansvarlige for sin del av arbeidet. Ved hjelp av scrum gjennomfører vi undersøkelser av personell, tegner grafer over forventet hastighet på oppgavens fullføring.

Vi bruker Agile i intern kommunikasjon. Vi holdt nylig en ny sprint for å eliminere ansattes forsinkelse. Alle sjefer og spesialister som var involvert i prosjektet tilbrakte hele dagen i møtet og diskuterte prestasjonene, utfordringene og kommende oppgaver i den nye sprinten.

Nå introduserer vi aktivt kanban-metoden i selskapet. Målet med kanban-implementering er å øke produksjonsfleksibiliteten, bedre tilpasse seg endrede markedskrav. I praksis hjalp metoden oss med å oppnå samsvar mellom lagerbeholdningen og produktene som faktisk ble brukt i produksjonen.

Et viktig poeng: smidig metodikk er en generell retning, og kanban og scrum er allerede dens varianter.

Vi bruker scrum + fossepakken, og foredlet også selve det smidige brettet i løpet av året. Hovedårsaken til bruk: gjennomsiktighet og enkelhet. Faktisk viser dette seg å være den samme Henry Ford-rørledningen: overgangen til en oppgave fra status til status med skifte av utøver, derfor er hovedprinsippet til det smidige styret allerede enkelhet.

Vi bruker smidig som en direkte del av arbeidsflyten vår, så alle prosjekter, fra merkevarebygging og nettstedutvikling til vår AI og opprinnelige reklameoppstart NativeOS, blir utført på Chernika nøyaktig i henhold til denne arbeidsflyten.

Et fungerende produkt er viktigere enn detaljert dokumentasjon. Dette betyr ikke at vi ikke opprettholder noen dokumentasjon, nei. Det er snarere et blikk mot effektivitet med et slag mot unødvendig byråkrati.

Scrum brakte rytme og forståelse til teamet vårt – enten vi er i tide eller ikke i tide. Vi ser hastigheten på teamets arbeid, det er ingen følelse av konstant jævla. Tidligere var det situasjoner som før harde utgivelser forsvant et sted, og alle begynte bare å finne ut av det – nå har vi mistet det, det er en konstant følelse av at vi er i tide. Hvis det oppstår risiko, diskuterer vi dem med PD tidlig, justerer planen eller reduserer omfanget av oppgaver på en eller annen måte.

Arbeidet ble mer gjennomsiktig, arbeidsdagen begynte å passe inn i 8-timers normen, og det føltes som om vi begynte å gjøre mer. Vi forstår at når du har en følelse av at du ikke gjør nok, føler du at du trenger å jobbe hardere – dette har en veldig dårlig effekt på produktiviteten, du må bli kvitt den.

For å gi klarhet og åpenhet i utviklingsavdelingen, setter vi opp et spesielt styre merket «å gjøre», «pågår», «gjennomgang», «test», «ferdig», der alle teammedlemmer klistrer klistremerker med oppgaver (i kolonnen «å gjøre»), og etter hvert som de er fullført, flyttes de til påfølgende punkter, og en lykkelig slutt er den endelige «ferdig.» Dette hjelper til med å få det store bildet og gjør det mulig å se hva hver deltaker er jobber med.

Et veldig viktig punkt i metoden (og organisering av arbeidsflyten): etter godkjenning av alle oppgaver («å gjøre»), er listen blokkert for innsetting. Dermed distraherer ikke nye innkommende oppgaver prosessen og bremser ikke arbeidet.

Alle deltakere evaluerer også hver oppgave i form av tid og materialkostnader som kreves for å fullføre. Og kirsebæret på toppen er daglige møter på et bestemt tidspunkt (Daily Scrum), hvor hvert lagmedlem kort snakker om hva han skal gjøre i dag, hva han gjorde i går (og om han møtte noen hindringer). Dette er viktig på vei mot langsiktige mål – slik kan du forstå i tide at det er på tide å endre strategien.

Vi implementerte Scrum på to forsøk fordi alle, fra teamet til brukerne, ønsker et mer forutsigbart resultat. Dette er et pluss av metodikken – klare rytmer strømlinjeformer teamet, øker det samlede kunnskapsnivået om prosjektet. Som et resultat blir resultatet mer forutsigbart, inkludert for våre «interessenter» – brukere.

Teamarbeid øker også ansvaret: Alle mottar en bonus bare hvis teamet har fullført oppgavene som ble satt på et bestemt tidspunkt.

Inga Koryagina
Agile er en filosofi, scrum er en struktur, foss er en metode, kanban er et styringssystem. Scrum og kanban er smidige alternativer, men de har noen klare forskjeller. Scrum krever faste roller, mens kanban mangler de nødvendige rollene. Scrum er basert på iterasjoner som kombinerer planlegging, prosessoptimalisering og frigjøring. I kanban kan du gjøre dette regelmessig eller når du trenger det. Scrum-teamet krever en vurdering av sitt arbeid, mens kanban-teamet ikke gjør det.

Kilder som brukes og nyttige lenker om emnet: https://rb.ru/story/agile-scrum-kanban/ https://ru.esdifferent.com/difference-between-agile-and-scrum https: // skillbox. ru / media / management / kak_ponyat_scrum / https://allo.tochka.com/agile-scrum