Agile (agile software development) er en familie av «agile» tiln\u00e6rminger til programvareutvikling. Disse tiln\u00e6rmingene blir ogs\u00e5 noen ganger referert til som rammer eller smidige metoder.<\/p>\n
Agile stammer fra IT-milj\u00f8et,<\/strong> men spres deretter til andre omr\u00e5der – fra industriell ingeni\u00f8rarbeid til kunstig intelligens.<\/p>\n Betydningen av Agile er formulert i Agile<\/a> Software Development Manifesto<\/a>: «Mennesker og interaksjoner er viktigere enn prosesser og verkt\u00f8y. Et fungerende produkt er viktigere enn omfattende dokumentasjon. Samarbeid med kunden er viktigere enn \u00e5 avtale vilk\u00e5rene i kontrakten. \u00c5 v\u00e6re klar for endring er viktigere enn \u00e5 f\u00f8lge den opprinnelige planen. «<\/p>\n Agile Manifesto er hoveddokumentet for alle smidige utviklingsmetoder. Agile ble opprettet i 2001 av en gruppe entusiastiske programmerere som \u00f8nsket \u00e5 forst\u00e5 hva som ligger i hjertet av utviklingen av et ettertraktet og nyttig IT-produkt. Du trenger ikke bare \u00e5 stole p\u00e5 detaljerte planer n\u00e5r du implementerer et prosjekt. som er opprettet p\u00e5 forh\u00e5nd. Det er viktig \u00e5 fokusere p\u00e5 de stadig skiftende forholdene i det ytre og indre milj\u00f8et og ta hensyn til tilbakemeldingene fra kunder og brukere. Dette oppfordrer utviklere og ingeni\u00f8rer til \u00e5 eksperimentere og s\u00f8ke nye l\u00f8sninger uten \u00e5 v\u00e6re begrenset av stive rammer og standarder.<\/p>\n Separate smidige tiln\u00e6rminger inkluderer scrum og kanban.<\/p>\n Scrum er en «strukturert tiln\u00e6rming».<\/strong> Et universelt team av spesialister jobber med hvert prosjekt, som ytterligere to personer blir med p\u00e5: produkteieren og scrum-mesteren. Den f\u00f8rste kobler teamet med kunden og overv\u00e5ker utviklingen av prosjektet; dette er ikke en formell teamleder, men snarere en kurator. Det andre hjelper den f\u00f8rste med \u00e5 organisere forretningsprosessen: han holder generalforsamlinger, l\u00f8ser hverdagsproblemer, motiverer teamet og overv\u00e5ker etterlevelsen av scrumtiln\u00e6rmingen.<\/p>\n Scrum-tiln\u00e6rmingen deler arbeidsflyten i like store sprinter – vanligvis perioder fra en uke til en m\u00e5ned, avhengig av prosjekt og team. F\u00f8r sprinten blir oppgaver for denne sprinten formulert, til slutt blir resultatene diskutert, og teamet starter en ny sprint. Sprints er veldig praktiske \u00e5 sammenligne med hverandre, noe som lar deg h\u00e5ndtere arbeidseffektiviteten.<\/p>\n Kanban er en «balansetiln\u00e6rming».<\/strong> Dens oppgave er \u00e5 balansere ulike spesialister i teamet og unng\u00e5 en situasjon der designere jobber dag og natt, og utviklere klager over mangelen p\u00e5 nye oppgaver.<\/p>\n Hele teamet er ett – det er ingen produktseier og scrummesterroller i kanban. Forretningsprosessen er ikke delt inn i universelle sprints, men p\u00e5 scenen for \u00e5 utf\u00f8re spesifikke oppgaver: «Planlagt», «Utviklet», «Testet», «Fullf\u00f8rt» osv.<\/p>\n Den viktigste ytelsesindikatoren i kanban er gjennomsnittlig tid det tar \u00e5 fullf\u00f8re en oppgave over hele linja. Oppgaven gikk raskt – teamet jobbet effektivt og greit. Oppgaven ble forsinket – du m\u00e5 tenke p\u00e5 hvilket stadium og hvorfor det var forsinkelser og hvis arbeid m\u00e5 optimaliseres.<\/p>\n For \u00e5 visualisere smidige tiln\u00e6rminger, brukes tavler: fysisk og elektronisk. De lar deg gj\u00f8re arbeidsflyten \u00e5pen og forst\u00e5elig for alle spesialister, noe som er viktig n\u00e5r teamet ikke har en formell leder.<\/p>\n Agile er en tiln\u00e6rming til prosjektledelse eller programvareutvikling. I Agile utvikler krav og l\u00f8sninger seg gjennom iterasjon og samarbeid fra tverrfunksjonelle, selvorganiserende team og forretningsbrukere. Agile gleder seg over endrede krav, selv p\u00e5 et senere tidspunkt. Kunder, forretningsdeltakere og utviklere jobber sammen gjennom hele prosjektet. Agile team tilpasser oppf\u00f8rselen for \u00e5 m\u00f8te prosjektets skiftende behov.<\/p>\n Agile er en filosofi eller orientering (Griffin). Agile er mye brukt som en guide for \u00e5 komme n\u00e6rmere prosjektarbeidet. Agile legger vekt p\u00e5 utvikling iterasjon samt testing i programvaren utvikling livssyklus (SDLC). Agile bryter ned et helt produkt eller prosjekt i sm\u00e5 samlinger. I Agile metodikk skjer utvikling eller testing samtidig. Agile st\u00f8tter samarbeid s\u00e5 vel som direkte kommunikasjon.<\/p>\n Scrum er grunnlaget for prosjektledelse eller programvareutvikling. Scrum er en av de smidige prosessene. Scrum fokuserer p\u00e5 \u00e5 levere forretningsverdi til forretningsbrukere p\u00e5 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.<\/p>\n Scrum legger vekt p\u00e5 egenorganisering og delt eierskap blant teammedlemmene. Han ser p\u00e5 prosjektledelse som en prosess for \u00e5 skape felles verdi; og vektlegger samarbeid og iterativ utvikling for effektivt \u00e5 h\u00e5ndtere endring og skape bedre produkter for \u00e5 m\u00f8te kundenes behov. Scrum ser p\u00e5 tiden som en begrensning. Den legger vekt p\u00e5 boksetid og bruker daglig sprintplanlegging og gjennomgangsm\u00f8ter.<\/p>\n Agile og scrum er begge relatert til prosjektledelse og programvareutvikling. Siden Scrum er en av m\u00e5tene \u00e5 implementere Agile p\u00e5, har de begge flere likheter. Begge vektlegger optimal bruk av ressurser. Begge vektlegger effektiv og effektiv styring av ulike oppgaver.<\/p>\n Agile og scrum, begge tar sikte p\u00e5 \u00e5 f\u00e5 mest mulig ut av forretningsbrukere. De pr\u00f8ver \u00e5 sikre at et produkt eller prosjekt blir levert til forretningsbrukere s\u00e5 snart som mulig. Begge vektlegger kontinuerlig forbedring, samarbeid, \u00e5pen kommunikasjon, etc.<\/p>\n Agile er en utviklingsmetodikk basert p\u00e5 en inkrementell og iterativ tiln\u00e6rming; mens Scrum er en av de mange implementeringsskjemaene eller Agile prosessene.<\/p>\n Scrum tilbyr trinnvise moduler til klienten hver uke eller fjorten dager.<\/p>\n Et av prinsippene til Agile er basert p\u00e5 en persons personlige ansvar, og ikke p\u00e5 feils\u00f8king av interne prosesser.<\/p>\n (Fra en artikkel<\/a> p\u00e5 VC.ru)<\/p>\n N\u00e5r vi arbeider med profesjonelle team bruker vi Scrum, ofte velger vi en 2-3 ukers syklus med retrospektive m\u00f8ter som gj\u00f8r at vi kan holde alt under kontroll.<\/p>\n (Fra et intervju med<\/a> Vedomosti med Frank Sosier, trener for Frittst\u00e5ende Agility)<\/p>\n Hovedideen til Kanban er visualisering av arbeidsflyten. Den best\u00e5r i \u00e5 lage et fysisk dashbord der du visuelt kan merke fremgangen din.<\/p>\n (Fra oversettelsen av Forbes-kolonnen p\u00e5 Rusbase)<\/p>\n 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\u00e5rt arbeid med produkter med, med prosesser i organisasjonen.<\/p>\n (Alexey Pimenov, Managing Partner for ScrumTrek i en artikkel om Rusbase)<\/p>\n<\/blockquote>\n F\u00f8r tilkomsten av Scrum ble fossefalltiln\u00e6rmingen vedtatt i programvareutviklingsverdenen. Arbeidet med produktet ble utf\u00f8rt i henhold til f\u00f8lgende plan.<\/p>\n Utviklerne koordinerte arbeidsplanen med kunden og fulgte vilk\u00e5rene strengt. Da produktet var klart ble det testet, men det var ingen m\u00e5te \u00e5 endre noe p\u00e5. Derfor, hvis feil ble oppdaget, m\u00e5tte de starte p\u00e5 nytt, og arbeidstiden \u00f8kte.<\/p>\n Dette var helt til en gruppe innovat\u00f8rer bestemte seg for \u00e5 endre situasjonen fullstendig. De s\u00e5 p\u00e5 hvordan vellykkede team fungerer: uten \u00e5 g\u00e5 glipp av tidsfrister og f\u00e5 n\u00f8yaktig det resultatet de planla. Det viste seg at suksessen var i fleksibiliteten i prosessen.<\/p>\n Leksjonene bidro til \u00e5 skape Agile Software Development Manifesto. Den inkluderte bare fire poeng, men de endret prosessen fullstendig.<\/p>\n Agile programvareutviklingsmanifest<\/p>\n 1 Mennesker er viktigere enn verkt\u00f8y. 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.<\/p>\n 12 smidige prinsipper<\/p>\n 1 Det viktigste er god programvare og en forn\u00f8yd kunde. Smidig og foss, vekter<\/p>\n En av de smidige metodene for programvareutvikling basert p\u00e5 smidige prinsipper er Scrum.<\/p>\n Scrumskapere Jeff Sutherland og Ken Schwaber har sett arbeidet til det amerikanske milit\u00e6ret, spesialstyrker og til og med rugbyspillere i mange \u00e5r. Og de la merke til at suksessen deres er basert p\u00e5 interaksjon og teamarbeid. Sutherland og Schwaber inns\u00e5 at dette var akkurat det programvareutviklerne trengte. Slik dukket Scrum-metoden opp.<\/p>\n Scrum fokuserer alltid p\u00e5 kunden som trenger \u00e5 f\u00e5 \u00f8nsket produkt i tide og til lavest mulig pris. Dette kan oppn\u00e5s ved \u00e5 f\u00f8lge noen viktige prinsipper.<\/p>\n Arbeide i korte sykluser (sprints)<\/p>\n Planlegg en sprint, ikke hele prosjektet p\u00e5 en gang. Hver sprint er en tidsperiode der teamet jobber p\u00e5 en helt ferdig del av produktet.<\/p>\n Fleksibilitet. «Sjekk og tilpass»<\/p>\n Prosessfleksibilitet og produkttesting etter hver sprint. Hvis noe g\u00e5r galt, er teamet alltid klar til \u00e5 endre utviklingsstrategien eller revidere etterslepet.<\/p>\n Deltakelse fra kunde og brukere i opprettelsen av produktet.<\/p>\n Kunden st\u00e5r ikke til side, men er fullt involvert i arbeidet. For dette er det rollen som eieren av produktet, som utf\u00f8res av kunden selv eller hans representant. Det er gjennom ham teamet samhandler med brukerne. Siden utviklingen utf\u00f8res i korte faser, blir brukerne involvert i testing nesten umiddelbart.<\/p>\n Etter f\u00f8rste testing f\u00e5r de tilgang til produktet, og produkteieren samler inn tilbakemeldinger. Slik kan laget forbedre resultatet.<\/p>\n Laginteraksjon<\/p>\n Et Scrum-team er en gruppe mennesker som jobber for ett resultat og som en helhet. Alle tilstreber ett felles m\u00e5l.<\/p>\n Et scrum-team er oftest en gruppe p\u00e5 fem til ni personer. Dette er det optimale tallet, men noen ganger er det lag p\u00e5 tre. Hvis det er flere mennesker, blir det vanskeligere for dem \u00e5 samhandle med hverandre, noe som forstyrrer arbeidet og reduserer produktiviteten.<\/p>\n Produkteier.<\/strong> Personen som representerer produktet og er mellomleddet mellom kunden, brukerne og utviklingsteamet. Noen ganger kan det v\u00e6re kunden selv.<\/p>\n<\/li>\n Scrum master.<\/strong> Oftest – en spesialansatt ansatt som leder teamet til resultatet. Han leder ikke teamet, men overv\u00e5ker implementeringen av de grunnleggende prinsippene til Scrum. Hans oppgave er ikke \u00e5 presse, ikke \u00e5 gj\u00f8re alt arbeidet selv og ikke \u00e5 fordele ansvar, men \u00e5 hjelpe, lede og l\u00f8se problemer som hindrer utviklingsprosessen.<\/p>\n<\/li>\n Utviklere.<\/strong> Et scrum-team har alltid folk med forskjellige ferdighetssett. S\u00e5 et team p\u00e5 fem til ni personer leder hele prosjektet fra start til slutt. Ett team – ett ferdig produkt.<\/p>\n<\/li>\n<\/ul>\n Hvordan et scrum-team ser ut<\/p>\n Scrum fungerer n\u00e5r det er en rollefordeling. Det er tre av dem.<\/p>\n Team.<\/strong> Dette er en egenorganisert gruppe p\u00e5 3-9 personer. Bidraget til en enkelt ansatt blir ikke evaluert. Det er bare viktig hvilket resultat teamet har oppn\u00e5dd gjennom felles innsats.<\/p>\n Produkteier.<\/strong> Dette er vanligvis en gr\u00fcnder som kjenner sin virksomhet og forst\u00e5r kundenes behov. Han har erfaring nok til \u00e5 vite hva det ferdige produktet skal v\u00e6re. Produkteieren er koblingen mellom teamet, forbrukeren og produksjonen. Han jobber med tilbakemeldinger, tar viktige beslutninger og overv\u00e5ker prosjektbudsjettet. Produkteieren forteller ikke teamet hvilken vei de skal ta, men ser bare p\u00e5 resultatet.<\/p>\n Scrum Master eller teamleder<\/strong>. Scrum Master er ansvarlig for suksessen til teamet. Han tar ikke avgj\u00f8relser og leder ikke. Hans oppgave er \u00e5 f\u00e5 laget til \u00e5 fungere uten ledelsesmessig innflytelse. Scrum Master er limet som holder teamet sammen.<\/p>\n Scrum er en fleksibel planleggingsteknikk som passer for ethvert prosjekt. Med hjelpen kan du \u00f8ke produktiviteten til selskapet og oppn\u00e5 bedre resultater. For eksempel brukte teamet en m\u00e5ned p\u00e5 en oppgave, og en halv m\u00e5ned p\u00e5 forbedringer. N\u00e5 vil den samme oppgaven ta to uker, og mest sannsynlig blir det ingen forbedringer.<\/p>\n Scrum er enklere enn andre rammer. Han gir verkt\u00f8yene og foresl\u00e5r i hvilken rekkef\u00f8lge han skal bruke dem for \u00e5 oppn\u00e5 resultatet.<\/p>\n Scrum foresl\u00e5r \u00e5 gj\u00f8re dette:<\/p>\n Agile endrer m\u00e5ten vi tiln\u00e6rmer oss liv og entrepren\u00f8rskap. Han l\u00e6rer deg \u00e5 raskt svare p\u00e5 omstendighetene og tilpasse deg dem.<\/p>\n Agile jobber overalt: innen ledelse, handel, tjenester. Noen bruker det til \u00e5 styre sine egne liv og holde tritt med alt.<\/p>\n<\/blockquote>\n Men ingen kan garantere at han vil hjelpe et bestemt selskap. Hvis selskapet er lite, er det lettere \u00e5 ombestemme folket. Det er vanskeligere for store selskaper: N\u00e5r det er flere avdelinger, og hver har sin egen leder, kan implementeringen av Agile bli forsinket. Teamet vil motst\u00e5 endring. For \u00e5 gj\u00f8re det lettere, inviterer slike selskaper Agile-trenere.<\/p>\n Agile passer ikke for de som har laget et typisk produkt i mange \u00e5r p\u00e5 rad. Det er mer l\u00f8nnsomt for slike selskaper \u00e5 lage tusen identiske stoler om gangen: det vil fortsatt v\u00e6re bestillinger. Men s\u00e5 snart en kunde dukker opp med spesielle \u00f8nsker, trenger du n\u00f8yaktig samme stol, men la bena v\u00e6re bredere, og polstringen er lysere – Agile er n\u00f8dvendig.<\/p>\n Avhengig av oppgavene bruker vi forskjellige metoder innen filosofien – smidig, scrum, kanban.<\/p>\n Scrum lar deg utvikle de n\u00f8dvendige egenskapene hos de ansatte – proaktivitet, uavhengighet, organisering, kommunikasjonsevner og fremsyn. Hovedpoenget med metoden er \u00e5 utf\u00f8re oppgaver i selvorganiserende team, der alle har sin egen rolle og alle er ansvarlige for sin del av arbeidet. Ved hjelp av scrum gjennomf\u00f8rer vi unders\u00f8kelser av personell, tegner grafer over forventet hastighet p\u00e5 oppgavens fullf\u00f8ring.<\/p>\n Vi bruker Agile i intern kommunikasjon. Vi holdt nylig en ny sprint for \u00e5 eliminere ansattes forsinkelse. Alle sjefer og spesialister som var involvert i prosjektet tilbrakte hele dagen i m\u00f8tet og diskuterte prestasjonene, utfordringene og kommende oppgaver i den nye sprinten.<\/p>\n N\u00e5 introduserer vi aktivt kanban-metoden i selskapet. M\u00e5let med kanban-implementering er \u00e5 \u00f8ke produksjonsfleksibiliteten, bedre tilpasse seg endrede markedskrav. I praksis hjalp metoden oss med \u00e5 oppn\u00e5 samsvar mellom lagerbeholdningen og produktene som faktisk ble brukt i produksjonen.<\/p>\n Et viktig poeng: smidig metodikk er en generell retning, og kanban og scrum er allerede dens varianter.<\/p>\n Vi bruker scrum + fossepakken, og foredlet ogs\u00e5 selve det smidige brettet i l\u00f8pet av \u00e5ret. Hoved\u00e5rsaken til bruk: gjennomsiktighet og enkelhet. Faktisk viser dette seg \u00e5 v\u00e6re den samme Henry Ford-r\u00f8rledningen: overgangen til en oppgave fra status til status med skifte av ut\u00f8ver, derfor er hovedprinsippet til det smidige styret allerede enkelhet.<\/p>\n Vi bruker smidig som en direkte del av arbeidsflyten v\u00e5r, s\u00e5 alle prosjekter, fra merkevarebygging og nettstedutvikling til v\u00e5r AI og opprinnelige reklameoppstart NativeOS, blir utf\u00f8rt p\u00e5 Chernika n\u00f8yaktig i henhold til denne arbeidsflyten.<\/p>\n 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\u00f8dvendig byr\u00e5krati.<\/p>\n Scrum brakte rytme og forst\u00e5else til teamet v\u00e5rt – enten vi er i tide eller ikke i tide. Vi ser hastigheten p\u00e5 teamets arbeid, det er ingen f\u00f8lelse av konstant j\u00e6vla. Tidligere var det situasjoner som f\u00f8r harde utgivelser forsvant et sted, og alle begynte bare \u00e5 finne ut av det – n\u00e5 har vi mistet det, det er en konstant f\u00f8lelse av at vi er i tide. Hvis det oppst\u00e5r risiko, diskuterer vi dem med PD tidlig, justerer planen eller reduserer omfanget av oppgaver p\u00e5 en eller annen m\u00e5te.<\/p>\n Arbeidet ble mer gjennomsiktig, arbeidsdagen begynte \u00e5 passe inn i 8-timers normen, og det f\u00f8ltes som om vi begynte \u00e5 gj\u00f8re mer. Vi forst\u00e5r at n\u00e5r du har en f\u00f8lelse av at du ikke gj\u00f8r nok, f\u00f8ler du at du trenger \u00e5 jobbe hardere – dette har en veldig d\u00e5rlig effekt p\u00e5 produktiviteten, du m\u00e5 bli kvitt den.<\/p>\n For \u00e5 gi klarhet og \u00e5penhet i utviklingsavdelingen, setter vi opp et spesielt styre merket «\u00e5 gj\u00f8re», «p\u00e5g\u00e5r», «gjennomgang», «test», «ferdig», der alle teammedlemmer klistrer klistremerker med oppgaver (i kolonnen «\u00e5 gj\u00f8re»), og etter hvert som de er fullf\u00f8rt, flyttes de til p\u00e5f\u00f8lgende punkter, og en lykkelig slutt er den endelige «ferdig.» Dette hjelper til med \u00e5 f\u00e5 det store bildet og gj\u00f8r det mulig \u00e5 se hva hver deltaker er jobber med.<\/p>\n Et veldig viktig punkt i metoden (og organisering av arbeidsflyten): etter godkjenning av alle oppgaver («\u00e5 gj\u00f8re»), er listen blokkert for innsetting. Dermed distraherer ikke nye innkommende oppgaver prosessen og bremser ikke arbeidet.<\/p>\n Alle deltakere evaluerer ogs\u00e5 hver oppgave i form av tid og materialkostnader som kreves for \u00e5 fullf\u00f8re. Og kirseb\u00e6ret p\u00e5 toppen er daglige m\u00f8ter p\u00e5 et bestemt tidspunkt (Daily Scrum), hvor hvert lagmedlem kort snakker om hva han skal gj\u00f8re i dag, hva han gjorde i g\u00e5r (og om han m\u00f8tte noen hindringer). Dette er viktig p\u00e5 vei mot langsiktige m\u00e5l – slik kan du forst\u00e5 i tide at det er p\u00e5 tide \u00e5 endre strategien.<\/p>\n Vi implementerte Scrum p\u00e5 to fors\u00f8k fordi alle, fra teamet til brukerne, \u00f8nsker et mer forutsigbart resultat. Dette er et pluss av metodikken – klare rytmer str\u00f8mlinjeformer teamet, \u00f8ker det samlede kunnskapsniv\u00e5et om prosjektet. Som et resultat blir resultatet mer forutsigbart, inkludert for v\u00e5re «interessenter» – brukere.<\/p>\n Teamarbeid \u00f8ker ogs\u00e5 ansvaret: Alle mottar en bonus bare hvis teamet har fullf\u00f8rt oppgavene som ble satt p\u00e5 et bestemt tidspunkt.<\/p>\n Inga Koryagina Kilder som brukes og nyttige lenker om emnet: https:\/\/rb.ru\/story\/agile-scrum-kanban\/<\/a> https:\/\/ru.esdifferent.com\/difference-between-agile-and-scrum<\/a> https: \/\/ skillbox. ru \/ media \/ management \/ kak_ponyat_scrum \/<\/a> https:\/\/allo.tochka.com\/agile-scrum<\/a><\/p>\nHva er smidig?<\/h2>\n
Hva er Scrum?<\/h2>\n
Likheter mellom Agile og Scrum:<\/h2>\n
The Nature of Agile and Scrum:<\/h2>\n
Eksempler p\u00e5 bruk<\/h2>\n
\n
Hvordan og hvorfor scrummetodologien dukket opp<\/h2>\n
\n
\n2 Produktkvalitet er viktigere enn dokumentasjon.
\n3 Interaksjon med kunden er viktigere enn kontrakten.
\n4 Beredskap for endring er viktigere enn en plan.<\/p>\n
\n2 Beredskap for endring n\u00e5r som helst.
\n3 Fullt fungerende programvare – s\u00e5 ofte som mulig.
\n4 Teamm\u00f8te er best for informasjonsutveksling.
\n5 Kunden og utviklingsteamet m\u00e5 samarbeide.
\n6 Stol p\u00e5 at folk gj\u00f8r jobben sin.
\n7 Det er fungerende programvare – det er fremgang.
\n8 Agile prosesser – kontinuerlig utvikling.
\n9 Oppmerksomhet p\u00e5 kvalitet fremmer fleksibilitet.
\n10 Enkelheten i prosessen eliminerer un\u00f8dvendig arbeid.
\n11 Et selvorganiserende team fungerer bedre.
\n12 Kontinuerlig jakt p\u00e5 st\u00f8rre effektivitet.<\/p>\nScrum kjerneprinsipper<\/h2>\n
Betydningen av scrum-teamet<\/h2>\n
Kommandostruktur<\/h3>\n
\n
Fordeling av roller<\/h4>\n
Scrum Tools<\/h2>\n
Instruksjoner: hvordan du bruker Scrum til \u00e5 fungere som Ajail<\/h2>\n
\n
Hvem er smidig for?<\/h2>\n
\n
Et ord til ekspertene<\/h2>\n
\n<\/strong>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\u00f8dvendige rollene. Scrum er basert p\u00e5 iterasjoner som kombinerer planlegging, prosessoptimalisering og frigj\u00f8ring. I kanban kan du gj\u00f8re dette regelmessig eller n\u00e5r du trenger det. Scrum-teamet krever en vurdering av sitt arbeid, mens kanban-teamet ikke gj\u00f8r det.<\/p>\n