Scrum arendusmetoodika. Scrum: revolutsiooniline projektijuhtimise meetod

Mis on Scrumi metoodika? Kuidas seda arenduses ja kaugemalgi kasutada? Miks ei ole paindlikkus alati hea?

Minu õpingud jätkuvad, kolm korda nädalas tutvun uute teadmistega digitoodete arendamise ja seestpoolt mõistmise vallas. Turundaja jaoks on see uus maailm. Kui kuuled mingist Agile’ist, saad aru, et see on seotud arenguga ja saad lihtsalt üldjoontes juttu edasi ajada. Aga niipea, kui asi puudutab üksikasju, hõljusin.

Scrumi metoodika on kõige populaarsem kõigi arendustegevuse ja muude asjade seas. Mul tekkis huvi mõista, mis see on ja mis on selle tööriista praktiline rakendus. Esitan teile kaalumiseks ülevaate.

Mis on Scrum

Scrum on agiilne arendusmetoodika või paindlik juhtimisraamistik (s.o struktuur), mille rõhk on protsessi kvaliteedil.

Metoodika olemus seisneb selles, et toote loomine on jagatud teatud osadeks. Selliste osade sooritamiseks on ette nähtud tükk aega või sprint (tavaliselt 2 nädalat). Iga sellise sprindi lõpus on vaja sooritatud tükki demonstreerida. Ülaltoodud pilt on vaid protsesside üldine põhimõte. Vaatame lähemalt.

Kuidas Scrum töötab

Vaadake allpool, kuidas Scrum tegelikult töötab.

Siiani näeb see välja nagu hiina kiri, seega soovitan vaadata üksikuid osi ja lahti võtta kõik struktuurielemendid. Soovitan soojalt Boris Volfsani raamatut “Agile Methodologies”, mis oli selle materjali aluseks (osa pilte on sealt).

Scrum struktuur

Vaatame, millistest elementidest Scrum koosneb.

Rollid

• Toote omanik/juht. Määrab ülesande, määrab ülesannete prioriteedid, suhtleb kliendiga.
• Scrum master on inimene, kes vastutab meeskonnasiseste protsesside eest, koordineerib tööd ja jälgib sisemist õhkkonda. Planeerib sprindi, korraldab scrum koosoleku ja osaleb iga sprindi lõpus tulemuste demonstreerimisel.

Scrumi koosolek on igapäevane koosolek, kus vaadatakse sprindi edenemist. Mida olete teinud, kas on probleeme, mida kavatsete teha? Mitte rohkem kui 15 minutit koosoleku kohta. Kõik meeskonnaliikmed peavad rääkima. Scrum Master jälgib kõigi ajastust ja jõudlust.

• Meeskond – 7±2 inimest, kes viivad ellu tooteomaniku nõudeid.

Artefaktid

• Toodete mahajäämus. Nõuete loetelu koos prioriteetide ja tööjõukuludega.
• Sprindi mahajäämus. Osa sprindi mahajäämust ehk mitu ülesannet, mis reaalselt ühte sprindi ära mahuvad.
• Toote juurdekasv. Osa tootest valmis demonstreerimiseks. Digiprojektides võiks selleks olla funktsionaalsus. Näiteks saidil töötav registreerimisvorm, mida saab näidata.

Protsessid

• Sprindi planeerimine. Scrum Masteriga meeskond kavandab tulevaseks sprindiks tööplaani ehk koostab sprindi mahajäämuse (ülesannete loetelu).
• Sprindi ülevaade. Toote juurdekasvu demonstreerimine pärast iga sprinti. Meeskond näitab töötavat funktsionaalsust toote omanikule (ja soovi korral kliendile), kes omakorda teeb vajadusel nõuetes muudatusi.
• Tagasivaade. Ülevaade möödunud sprindist protsesside täiustamiseks. Meeskond, Scrum Master ja tooteomanik arutavad möödunud spurti, teevad järeldusi ja mõtlevad, mida saaks parandada.
• Scrum koosolek. (vt ülalt definitsiooni "Rollide" plokis)
• Sprint. Reeglina kahenädalane ajaetapp, mille jooksul meeskonnal õnnestub välja töötada demonstreerimiseks valmis funktsionaalsus.

Vabandust lugemise katkestamise pärast. Liituge minu telegrammi kanaliga. Värsked teadaanded artiklite, digitaalsete toodete arendamise ja kasvu häkkimise kohta – see on kõik olemas. Ootan sind! Jätkame...

Scrum näide

Kujutage ette, et peate oma suvilate puhastamiseks looma veebisaidi/teenuse. Teil on maamaja, kus piirkond on täiesti segaduses ja nädalavahetusi pole võimalik koristades veeta, sest soovite veidi lõõgastuda. Seega, voilaa, Uberimoydvori teenus!

Usume, et teenus on veebipõhine. Kasutaja registreerub, jätab päringu ning talle helistab tagasi operaator, kes täpsustab üksikasjad ja lepib kokku kliendile sobiva aja. Soovime veebisaidi arendamiseks kasutada Scrumit.

Valime veebilehe loomise osana välja näiteks olulise ülesande või kasutajaloo: “Kliendi/kasutaja registreerimine”. Ja jagage see väiksemateks osadeks. Loome toodete mahajäämuse.

Peamine kasutajalugu on jaotatud väikesteks ülesanneteks. Järgmiseks pannakse koos meeskonnaga paika prioriteedid ja jagatakse ülesanded sprintideks. Ärge unustage põhireeglit: pärast sprindi peab meil olema demonstreerimiseks valmis funktsionaalsus.

Praktikas on kasutajalugusid palju rohkem (näiteks “Kasutaja registreerimine”). Teenus/toode võib sisaldada palju selliseid lugusid, seega on prioriteetide seadmine üles ehitatud ülalt alla, vasakult paremale. Ülemises vasakpoolses osas on olulisemad kasutajalood (Activities) ja olulisemad ülesanded.

Ülesannete mahajäämuse kuvamiseks kasutatakse tavalisi kleepuvaid märkmeid ja tahvlit (mõnikord isegi seina). See võib välja näha järgmiselt.

Selge on see, et sellist “kolossi” reaalajas hallata on lihtsalt võimatu, seetõttu liigutatakse töö hõlbustamiseks kogu see sein spetsiaalsesse tarkvara/programmi (Jira, Trello, Redmine ja muud projektijuhtimise jälgijad). Seal saab määrata ülesannete ja täitjate eest vastutust, muuta ülesannete staatusi jne.

Sein töötab ka hästi, sest loomise etapis on kogu meeskond kirglik ja tunneb, et panustatakse ühisesse asja. Kuid pärast seda peate selle sobivale tööriistale üle kandma.

Lähme tagasi õue puhastamise juurde. Nii valisimegi sprindid ülesannetega ja asusime tööle. Meeskond täidab iga päev töömahu ning Scrum Master korraldab 15-minutilisi planeerimiskoosolekuid (Scrum meetings), kus uuendab sprindiülesannete seisu ja selgitab välja raskused töös, kui need tekivad.

Väga oluline on, et Scrum Master jälgiks kliimat ja meeskonnasiseseid suhteid, tema ülesandeks on iseorganiseeruva, motiveeritud meeskonna moodustamine ja hoidmine. Selleks on vaja lahendada probleemid ja arusaamatused kõigi osalejate vahel. Scrum Master on treener, kes täiustab meeskonda.

Pärast 2-nädalast sprindi viivad Scrum Master ja meeskond läbi funktsionaalse demonstratsiooni. Meie näites õnnestus meil luua registreerimisvorm ja näitame seda toote omanikule. Vaatab ja vajadusel korrigeerib. Kui töö vastu võetud, liigume edasi järgmisele sprindile.

Tagasivaade: sprindianalüüs

Paar päeva pärast sprindi läbimist peaksid tooteomanik, scrum-meister ja meeskond kokku saama ning tegema tagasivaate (sprindiülevaate). Tegemist on mitmetunnise kohtumisega (olenevalt sprindi pikkusest ja võistkonna suurusest), kus lahendatakse viimasel sprindil tekkinud raskused.

Osalejad jagavad oma arvamusi ja otsustavad, mida saab tulevastel sprindidel parandada. Seega toimub protsesside loomulik areng, kuna iga uue iteratsiooniga võetakse arvesse ja analüüsitakse eelnevat kogemust.

Kuidas prioriseerida

Hea, et kasutame Scrumi haldust, aga kuidas seada tähtsuse järjekorda tohutul hulgal kasutajalugusid? Lõppude lõpuks võib projekt sisaldada palju selliseid lugusid.

Selleks on tooteomanik. Just tema mõistab publiku vajadusi, jälgib turgu ja teeb järeldusi, mida tuleks mahajäämuses teha. Peamine ülesanne on lahendada kliendi vajadus ja alustada paremini kõige olulisemast.

Samas on vaja arvestada meeskonna võimetega. Kui palju probleeme suudab ta sprindis lahendada? Mis ülesanded need on? Kuidas planeerida rakendamise üldist edenemist? Mahajäämuse sees hindamine aitab.

Kasutajalugude hindamine mahajäämuse sees

Oleme loonud mahajäämuse, aga kuidas hinnata kasutajalugusid keerukuse mõttes? Sel eesmärgil kasutatakse standardmeetodit. See on suhteline hinnang, mis võimaldab mõista meeskonna potentsiaali ja ligikaudselt hinnata ressursse.

Võtame ühe kasutajaloo mahajäämust näidisena ja omistame sellele väärtuse üks (loo punkt). Järgmisena hindame teisi kasutajalugusid valitud vaatepunktist.

Näiteks on meie teenuses kasutajalugu “Kasutaja registreerimine”. Me võtame selle näidisena ja anname sellele ühe punkti või ühe loo punkti väärtuse (nagu seda nimetatakse paindlikes metoodikates). Ülejäänud nimekirjas olevatele kasutajalugudele kirjutab iga meeskonnaliige oma hinnangu, võttes arvesse prooviks võetud ülesannet ja annab selle Scrum Masterile.

Ülaltoodud näites maksab “Rahulolevate klientidega fotogalerii” 0,5 loopunkti, st keerukuse poolest on see 2 korda väiksem kui meie võrdluslugu “Kasutaja registreerimine”. Meeskonnaliikmed annavad kõik hinnangud anonüümselt; saate need kleebistele kirjutada ja ümber pöörata.

Kui kõik on oma hinnangud andnud, avanevad tulemused. Scrum Master hõlbustab arutelu osalejate vahel, kes on andnud kõige äärmuslikumad hinnangud. Ülaloleval pildil on need 2 ja 8. Nad lepivad omavahel kokku ja algab teine ​​hääletusvoor.

Kõik osalejad peavad jõudma ühisele arvamusele ja hinded võrdsustatakse. Selle tulemusena saame kõigi kasutajalugude jaotuse suhteliste skooride põhjal.

Järgmiseks kogutakse prioriteete arvestades ülesanded sprintidesse ja töö algab. Läbitud sprintide tulemuste põhjal selgub, mitu loopunkti suudab meeskond ligikaudu läbida. Ja tagantjärele analüüsimise käigus (tagantjärele) võib leida kasvupunkte.

See annab meile sisemise arvesti või valuuta, mille meeskond saab sprindi kohta. Seda saab kasutada meeskonna efektiivsuse mõõtmiseks ja tulevaste iteratsioonide ennustamiseks.

Kas Scrumit on võimalik kasutada mitte ainult arenduses?

Jah ja ei. Enne, kui hakkasin aru saama, mida need 5 tähte (Scrum) tähendavad, kasutasin mõnda põhimõtet juba oma töös. Planeerimine, erinevate tööriistade kasutamine ja oma nn "ülesannete sprindi" ehitamine on juba toimunud.

Kuid ikkagi pole see Scrum. Scrum on metoodika ja süsteem, mis võimaldab olla paindlik ja meeskonnasiseseid protsesse pidevalt täiustada.

Ülesanded peaksid olema tüüpilised. Mida iganes võib öelda, arendus on inseneripraktika, st ülesande saab viia teatud tasemele. Ja seda on palju lihtsam teha kui näiteks loovuse, turunduse või juhtimise valdkonnas.

Mõned metoodikast tulenevad tavad on teistes valdkondades üsna rakendatavad. Meeskonnaga töötamine ja tehtud töö analüüsimine küll. Ülesannete prognoosimine ajajärgus, jah. Ka ülesannete haldamine mugavates programmides, jah.

Millal Scrum'i kasutada

Peamiselt väikeprojektides ja idufirmades. See on võimalik suurtes, nagu Mail.ru, kuid seal peaks olema teatud tegevusvabadus ja eraldi funktsionaalsed meeskonnad oma tooteomanikuga. Ärge unustage, et Scrum on seotud paindlikkuse ja muutustega. Meeskonnad ei tohiks olla suuremad kui 7±2 inimest, vastasel juhul on suhtluse tõhus korraldamine võimatu.

Nüansid

Kui otsustate Scrumi oma projektides rakendada, võtke arvesse järgmisi nüansse:

• Kliendikesksus puudub. Kõik kliendid ei ole teatud Scrumi standardite jaoks valmis.
• Riskile reageerimise süsteemi ei võeta arvesse. Meeskond võib ülesannete täitmiseks varuda veidi lisaaega, kuid kui plaanist on olulisi kõrvalekaldeid, siis süsteem seiskub.
• Meeskondlikud ja inimlikud omadused. Kuna rõhk on iseorganiseeruval meeskonnal, peab kõigil osalejatel olema kõrge vastutustundlikkus ja vastav motivatsioon. Sellise meeskonna loomine on väga raske ülesanne.
• Scrum Master. Meeskonna protsesside ja motivatsiooni eest vastutav isik peab tunnetama kõiki rühmasiseseid osalejaid ja sidemeid. See on haruldane spetsialist, keda on ka turult raske leida.

Lõpetame

Vaatamata Scrumi meetodite nüanssidele ja omadustele, tahaksin märkida, et see on endiselt kõige populaarsem kõigi paindlike metoodikate seas. Mõningaid selle osi saab rakendada ka teistes ärivaldkondades ning põhimõtted võivad olla aluseks Sinu enda arengustrateegiale.

Scrum on üks võimalikest viisidest paindliku (Agile) arendusmetoodika juurutamiseks. Erinevalt tarkvara elutsükli kosemudelist on Scrumi eripäraks iteratiivsus.

Arendusprotsess on jagatud eraldi etappideks, millest igaühe tulemuseks on valmistoode. Iga etapi lõpus (Scrumi terminoloogias sprint) tarnitakse valmistoode kliendile. Kliendi tagasiside võimaldab teil tuvastada võimalikud probleemid või vaadata mõnda esialgse plaani aspekti. Seega võimaldab Scrum kõige paremini järgida Agile arenduse põhimõtteid.

Enne kui hakkame kirjeldama Scrumi projekti elutsüklit, tasub rääkida Scrumi metoodikas omaks võetud peamistest rollidest:

• Toote omanik (Toote omanik) esindab lõppkasutaja huve.
• Scrum meister jälgib Scrumi arenduse põhimõtete järgimist, koordineerib protsessi, viib läbi igapäevased koosolekud (Scrum Meetings).
• Scrum meeskond (Scrum meeskond) osaleb tootearenduses. Scrumi meeskonda kuuluvad programmeerijad, testijad, analüütikud ja teised spetsialistid.

Niisiis, vaatame peamisi Scrumi spetsiifilisi arendusetappe.

1. samm: looge toote mahajäämus

Toote mahajäämus on väljatöötatava toote nõuete loetelu, mis on järjestatud tähtsuse järgi. Selle loendi üksusi nimetatakse kasutajalugudeks. Igal lool on kordumatu ID. Siin on näide kasutajalugudest toote mahajäämusest, mida kasutati XB Staff Manageriga töötamisel:

Iga loo kirjeldus peab sisaldama kohustuslikke välju, mis on vajalikud projekti edasiseks tööks:

• Tähtsus. Ülesande tähtsuse aste tooteomaniku arvates. Kirjeldatud suvalise arvuga.
• Esialgne hinnang. Tööde mahu eelhinnang. Mõõdetud jutupunktides.
• Kuidas demo teha. Kirjeldus selle kohta, kuidas täidetud ülesannet demonstreerida.

Lisaks nendele kohustuslikele väljadele saab vajadusel lisada täiendavaid välju:

• Kategooria (rada) võimaldab tooteomanikul valida kõik teatud kategooria üksused ja määrata neile madala või kõrge prioriteedi. Sellise kategooria näide oleks "Juhtpaneel".
• Komponendid koosneb tootekomponentide loendist, mida loo kallal töötamise ajal muudetakse. Need komponendid võivad olla rakendusmoodulid, nagu autentimine või otsing.
• Taotleja- teatud funktsionaalsuse rakendamisest huvitatud klient. See väli on vajalik, kui soovite klienti asjade hetkeseisuga kursis hoida.
• ID defektide jälgimise süsteemis (vea jälgimise ID) sisaldab linke tuvastatud defektidele, mis on seotud konkreetse ID-ga looga.

Kui projekti mahajäämus on koostatud, võite jätkata järgmise sammuga - sprindi planeerimine.

2. samm: sprindi planeerimine ja sprindi mahajäämuse loomine

Planeerimisetapis määratakse sprindi kestus. Lühike sprint võimaldab teil sagedamini välja anda toote tööversioone ja seetõttu saada sagedamini kliendilt tagasisidet ja tuvastada võimalikud vead õigeaegselt. Teisest küljest võimaldavad pikad spurdid pühendada rohkem aega probleemi lahendamisele. Optimaalne sprindi pikkus valitakse nende kahe otsuse ristandena ja see on tavaliselt umbes 2 nädalat. Selles etapis on oluline suhtlus tooteomaniku ja Scrumi meeskonna vahel. Tooteomanik määrab konkreetse ülesande prioriteedi ja Scrumi meeskonna ülesanne on määrata vajalik pingutus.

Sprindi planeerimise käigus valib meeskond toodete mahajäämust kõrgeima prioriteediga kasutajalood ja otsustab, kuidas määratud ülesanded lahendatakse. Selle sprindi käigus rakendamiseks valitud lood on järgmised: Sprindi mahajäämus. Sprindi mahajäämusse kaasatud lugude arv sõltub nende kestusest igale loole eelhindamise etapis määratud loopunktides. See number on valitud nii, et iga lugu oleks sprindi lõpuks edukalt ellu viidud.

Samm 3. Töötage sprindil. Scrum koosolekud

Kui sprindi jaoks olulised kasutajalood on tuvastatud, algab protsess.

Arendusprotsessi visualiseerimiseks on mugav kasutada registrikaarte. Need võivad olla suurte kaartide kujul, millel on konkreetse loo nimi ja väikesed kleepsud, mis kirjeldavad loo rakendamiseks vajalikke üksikülesandeid. Pärast konkreetse ülesande kallal töötamist liigub selle kleebis väljalt „Plaanitud“ alale „Käimas“. Pärast ülesandega töö lõpetamist liigub kleebis väljale "Testimine" ja seejärel, kui testimine õnnestub, väljale "Tehti". Reastades lugusid nende tähtsuse järgi, saate aimu projekti hetkeseisust:

Kasutada saab ka seda tüüpi ülesannete jaoks loodud tarkvara. Sellise tarkvara näide on näiteks Atlassian JIRA.

Scrumi oluline eristav tunnus on igapäevased koosolekud (Scrum koosolekud), mille eesmärk on anda meeskonnale täielikku ja usaldusväärset teavet selle kohta, millises etapis arendusprotsess on. Kohtumise käigus annab iga Scrumi meeskonna liige aru, millise ülesande nad on täitnud, millist ülesannet täitma hakatakse ja milliseid raskusi töötamise ajal ette tuli.

Iga kohtumise tulemus on ka läbipõlemise diagramm. X-teljel on näidatud sprindi tööpäevad ja Y-teljel selle sprindi loopunktide koguarv. Pärast ülesande täitmist, mille lahendamiseks oli vaja teatud arvu loopunkte, saate skeemile märkida punkti, kus projekt hetkel asub. Sellise JIRA-s ehitatud diagrammi näide on toodud allpool:

See võimaldab hinnata meeskonna töötempot ja otsustada, kas järgmisel sprindil lugude arvu suurendada või vähendada.Igapäevased koosolekud aitavad suurendada arendusprotsessi paindlikkust ja annavad ülevaate vajalikest kohandustest, mida on vaja selle käigus teha. järgnevate sprindide projekteerimisfaas.

4. samm. Toote testimine ja tutvustamine

Kuna iga sprint annab ideaalis tootmisvalmis toote, on testimine Scrumi oluline osa. Kulude minimeerimiseks selles etapis on erinevaid viise: alates sprindi lugude arvu vähendamisest ja sellest tulenevalt vigade arvu vähendamisest kuni testijate kaasamiseni Scrumi meeskonda.

Iga sprindi finaal on valmistoote demonstratsioon. Scrumi meeskond kirjutab ülevaate, mis kirjeldab sprindi eesmärke, määratud ülesandeid ja nende lahendamist. Tooteomanik, kliendid ja kasutajad otsustavad arvustuste ja demonstratsioonide põhjal, mida tuleks edasises arendusprotsessis muuta.

5. samm. Tagasivaade. Järgmise sprindi planeerimine

Demonstratsioonijärgselt toote kohta saadud tagasiside põhjal tehakse tagasivaade. Selle peamine eesmärk on kindlaks teha, kuidas arendusprotsessi järgmisel sprindil parandada, et vältida probleeme ja töötada tõhusamalt. Kui töökvaliteedi parandamise viisid on leitud, saab meeskond alustada järgmise sprindi planeerimist.

Järeldus

Scrumi tunnusteks on paindlikkus ning keskendumine pidevale arengule ja muutustele. See saavutatakse suures osas pideva suhtluse ja suhtlemise kaudu. Sprindi planeerimise etapis suhtleb tooteomanik Scrumi meeskonnaga, et teha kindlaks, millisteks ülesanneteks kasutajalood jaotada ja kuidas neid rakendada. Igapäevastel koosolekutel arutavad Scrumi meeskonnaliikmed iga üksiku ülesande elluviimist ja selgitavad välja võimalikud viisid tekkinud probleemide lahendamiseks. Sprindi lõpus esitletakse valmistoodet kliendile, kes saab hinnata hetke funktsionaalsust ja märkida, mida ta sooviks muuta. See Scrumi eripärane omadus võib olla kasulik, kui aja jooksul muutub kliendi nägemus sellest, milline toode peaks välja nägema. Lõpuks võetakse kogu nendest etappidest saadud teave arvesse kõikidel järgnevatel sprintidel, mis aitab arendusprotsessi parimal võimalikul viisil optimeerida.

Järgmised kaks vahekaarti muudavad sisu allpool.

Mis on Scrum. Tehnika olemus

Projektijuhtimisega või lihtsalt juhtimisega tegelejad teavad hästi, kui keeruline on hästi koordineeritud meeskonnatööd korraldada. Sest sidususe puudumine, plaane rikutakse pidevalt, graafikud on maas, projekti eelarve on paisutatud, raha ja aeg libisevad näppude vahelt, erinevate osakondade ülesanded dubleeritakse, inimesed vaidlevad ega aita üksteist, kuigi tundub, et nende pingutused on suunatud sama eesmärgi saavutamisele. Lisaks on kliendid sageli rahulolematud loodud toote lõppversiooniga.

Jeff Sutherlandi ja Ken Schwaberi poolt välja töötatud Scrumi metoodika on mõeldud kõigi nende probleemide lahendamiseks. Scrum— See on vastupidine klassikalisele samm-sammult lähenemisele, mida rakendatakse projekti elluviimisel. Scrumi metoodika on omaks võtnud paljud ettevõtted nii tehnoloogiatööstusest, kust see pärineb, kui ka traditsioonilistest ja isegi mittetulunduslikest ettevõtetest. Scrumi metoodika aluseks olevat lähenemist saab rakendada erinevate tegevuste puhul, mis nõuavad meeskonnatööd.

Scrumi olulisteks omadusteks on paindlikkus ja kliendikesksus, kuna see eeldab tema (kliendi) vahetut osalemist tööprotsessis.

Scrum ei vaja rakendamistükskõik milline kallid tööriistad. Scrumi metoodikat saab lühidalt kirjeldada järgmiselt:

1. Kõigepealt peate valima« Toote omanik» — inimene, kellel on nägemus sellest, mida kavatsete luua või saavutada.

2. Siis peate koguma"Meeskond" , mis hõlmab otseselt tööd tegevaid inimesi. Neil peavad olema oskused ja teadmised, mis aitavad tooteomaniku visiooni ellu viia.

3. Peate valima "Scrum Masteri" - keegi, kes jälgib projekti edenemist, hõlbustab lühikesi koosolekuid ja aitab meeskonnal kõrvaldada takistused eesmärgi saavutamisel.

4. Tööd alustades peate koostama kõige täielikuma loendi kõigist tootele või eesmärgile esitatavatest nõuetest. Selle loendi üksused tuleks eelistada. Nimekirja nimetatakse"Toote mahajäämus" . See võib projekti eluea jooksul areneda ja muutuda.

5. Meeskonnaliikmed peavad hindama iga eset, kasutades oma punktisüsteemi raskuste ja kuludega, mis on vajalikud selle täitmiseks.

6. Siis osalejad Scrum Master ja toote omanik peab läbi viima esimese scrum koosolek , kus nad plaanivad sprinti— teatud aeg osa ülesannete täitmiseks. Sprindi kestus ei tohiks ületada ühte kuud. Iga sprindi eest teenib meeskond teatud arvu punkte. Meeskond peaks pidevalt püüdma ületada uuel sprindil eelmisel sprindil kogutud punktide arvu ehk oma eesmärki— pidevalt ületada oma tulemusi— « suurendada tootlikkuse dünaamikat» .

7. Selleks, et kõik osalejad asjade seisuga kursis oleksid, tuleb luua scrum board kolme veeruga:« Vaja teha või mahajäämus"; "Käimas"; "Tehtud" . Osalejad panevad tahvlile ülesannetega kleebised, mida töö käigus veerust ükshaaval teisaldatakse."Tagasilogimine" veergu "Käimas" ja seejärel veergu "tehtud".

8. Läbiviidud iga päev scrum koosolek . Jeff Sutherlandi sõnul« see on kogu Scrumi protsessi pulss» . Selle olemus on lihtne— Iga päev liikvel olles on kõigil viisteist minutit aega vastata kolmele küsimusele:« » , « » , « » .

9. Sprindi lõpus vaatab meeskond selle üle— korraldab koosoleku, kus osalejad räägivad sprindi jooksul tehtust.

10. Pärast sprindi tulemuste ettenäitamist korraldavad osalejad tagasivaatekoosoleku, kus arutatakse, mis võistkonnal läks hästi, mida saaks paremini teha ja mida saaks praegu parandada.

Traditsioonilise projektijuhtimise lähenemisviisi puudused

Nagu märgib raamatu autor Jeff Sutherland, on traditsioonilisel lähenemisel projekti elluviimisele kosemudeli kujul, mis hõlmab samm-sammult edasiminekut eesmärgi poole, palju puudusi. Kogu protsess on väga aeglane, sageli tekivad ettearvamatud raskused ja pealegi juhtub sageli, et töövõtja loob toote, mis klienti üldse ei rahulda.

Kose mudel hõlmab Gantti diagrammide kasutamist— graafikud, mis näitavad tööde etappe ja nende sooritamise aega. Projekti käik on detailselt kaardistatud ja iga töö samm kajastatud. Eeldatakse, et projekti iga etapp liigub järjestikku järgmisesse,— See on kaskaadi põhimõte.

Miks? Nagu Jeff Sutherland märgib, leiutas Henry Gantt sellised graafikud juba 1910. aastal. Need said laialt levinud Esimeses maailmasõjas. Kuid,« Igaüks, kes on selle sõja ajalugu uurinud, teab, et ei tööjõu väljaõpe ega organisatsioonisüsteem ei olnud kunagi selle tugevad küljed. Ma ei saa aru, miks I maailmasõja kontseptsioonmuutub de factoanalüütilise disaini tööriist ja seda kasutatakse isegi 21. sajandil. Loobusime kaevikusõja põhimõtetest, kuid kuidagi selle "kraav" organisatsioonilised ideed on populaarsed tänapäevani» .

Kaasaegsetes tingimustes on see skeem sobimatu ja sarnaneb NLKP Keskkomitee poliitbüroo mudeliga, mis"uskunud" teatab, et see saadi Nõukogude Liidu kokkuvarisemise eelõhtul ja millel oli asjade tegeliku seisuga vähe pistmist.

Scrum filosoofia

Scrumi metoodika peegeldab autori kirge Jaapani võitluskunstide vastu. Tema sõnul Jaapanis« Scrumit ei käsitleta moeröögatusena. Jaapanlased peavad Scrumit lähenemiseks probleemide lahendamisele, tegutsemisviisiks, olemisviisiks — üldiselt kui elustiili. Kui ma õpetan inimestele seda tehnikat, räägin sageli oma aastatepikkusest kogemusest Jaapani võitluskunsti aikido vallas. » .

Aikidol ja Scrumil on ühine see, et neid saab omandada ainult töö käigus, millal« teie keha, meel ja vaim saavad pideva harjutamise ja tipptaseme poole püüdlemise kaudu üheks. Aikidoga tegeledes mõistame shuhari (Shu Ha Ri) mõistet. — see on nii võitluskunstide kontseptsioon kui ka oskuste taseme näitaja » .

Meeskonnatöö olemus Scrumis

Scrum - See on ennekõike meeskonnatöö. Autor toob välja kolm parimate meeskondade tunnust:

lõputu tipptaseme otsimine;

• autonoomia - eneseorganiseerumisvõime;
• multifunktsionaalsus. Erinevate spetsialistide olemasolu ning suhtlemis- ja vastastikuse abistamise kultuur.

Kui suur peaks olema meeskond? Jeff Sutherland soovitab väikeseid gruppe— umbes seitse inimest. Ta toob näiteks andmed, et kui grupp koosneb rohkem kui üheksast inimesest, siis selle töö kiirus langeb.

Lisaks tuletab autor meelde “Brooksi seadust”:

« Kui projekt ei ole õigel ajal, lükkab tööjõu lisamine seda veelgi edasi. » .

Meeskonna pealik- see on Scrum Master . Tema kohustus— hoidke koosolekud lühikesed ja avatud, aidake rühmal läbida takistusi, mis takistavad tööd, suunake meeskonda pideva täiustamise teel« ja otsige regulaarselt vastust küsimusele« Kuidas saaksime teha veelgi paremini seda, mida me juba hästi teeme?» .

Ei mingit multitegumtööd

Autor hoiatab multitegumtöö eest— Tegelikult pole ühtegi, meie aju ei saa teha kahte toimingut korraga, see lihtsalt lülitub ülesannete vahel ja nende täitmiseks kuluv koguaeg pikeneb võrreldes sellega, kui teeksime neid vaheldumisi. Scrumi metoodika eeldab, et peate täitma kõik ülesanded ükshaaval ja mitte« juhtida korraga viit projekti» .

« Kasutades traditsioonilist meetodit, mille kohaselt üritatakse kõike korraga teha, lõpetab rühm oma kolm projekti enne juuli lõppu. Kui meeskond läheneb sellele agiilse strateegiaga, nagu Scrum, ja töötab iga projektiga ükshaaval, minimeerides konteksti vahetamisega kaasnevat aega ja vaeva, võiks seda teha mai alguseks. » .

Teose olemus on voolamine

Scrum aitab teil jõuda"vool" - kõrgeima keskendumisvõimega seisund, kui teete seda, mida vajate, ilma selleks pingutusi kulutamata, end sundimata või peale surumata. Autor usub, et eduka töö peamine asi— seda seisundit saavutada ja juhtida.« Oma töös peate saavutama peamise— pingutuseta voolu juhtimine. Võitluskunstide või meditatsioonipraktikatega saavutame liikumises ühtsustunde, mis ei nõua pingutust,— see on energia, mis voolab meid takistamatult läbi. Kui vaatate suurepäraseid tantsijaid või lauljaid, tunnete, kuidas nad sellele energiale alluvad. Peame oma töös püüdlema sellise seisu saavutamise poole.» .

Kuidas seda saavutada? Voolu oleku taga on sisemine distsipliin,

« Ühtegi liikumist ei tohiks raisata » .

Scrum ja õnn

Inimesed tahavad olla õnnelikud. Kuid Jeff Sutherland on selles õnnes kindel— See pole mitteaktiivne taimestik, vaid särav, rikas ja aktiivne elu. Scrum aitab kaasa õnnelikule elule, sest see aitab teil töötada ja tulemuslikult tegutseda.

Iga sprindi lõpus peavad osalejad tagasivaatava koosoleku, kus räägivad oma tööst ja tõstavad kaalutud ülesanded veergu."Tehtud" ja seejärel arutage, mis on hea ja mida saab parandada. Nad leiavad peamise takistuse ja nuputavad, kuidas seda järgmisel sprindil parandada. See on lahendus pideva täiustamise probleemile.

Scrumi elemendid

Sprindid

Nagu eespool märgitud, tuleb sprindi alguses ning avatuse ja nähtavuse tagamiseks luua spetsiaalne tahvel ja jagada see kolme veergu:"Tagasijäämine"; "Käimas"; "Tehtud" . Enne iga sprinti kleebivad meeskonnaliikmed veerus"Tagasijäämine" kleepuvad märkmed ülesannetega, mida nad arvavad, et suudavad sprindis täita. Sprindi ajal kleebib iga meeskonnaliige ülesande täitnud kleebise sektsioonilt uuesti"Tagasilogimine" veerus "Käimas". . Pärast ülesande täitmist— veerus "Valmis". . Nii saavad kõik näha, millega teised osalejad parasjagu tööd teevad.

Siiski on oluline märkus— « veergu ei kanta midagi üle"Tehtud" kuni seda projekti osa on klient testinud» .

« Teine sprindi oluline aspekt: ​​kui meeskond on nõuete loendi heaks kiitnud, siis selle loendi ülesanded „ on blokeeritud“ . Kellelgi pole õigust neid muuta ega täiendusi teha » . Seda soovitab autor sest et igasugune sekkumine aeglustab meeskonna tööd.

Igapäevased koosolekud

Asi on selles, et neid tuleks hoida seistes, iga päev samal ajal, nende kestus ei tohiks ületada 15 minutit ja osalejad peaksid esitama samad kolm küsimust:« Mida sa eile tegid, et aidata meeskonnal sprindi läbida?» , « Mida teete täna, et aidata meeskonnal sprindi läbida?» , « Millised takistused on meeskonna teel?» .

Tehke seda lõpuni

Scrumis on oluline õppida meeskonna rütmi tunnetama. Halvimal juhul— kui sprindi lõpus midagi jääb pooleldi valmis. Siis on parem seda äri üldse mitte alustada.

« Ressursid, vaev, aeg, raha on kulutatud, kuid täiesti töötavat toodet pole kätte saadud » .

Planeerimine Scrumis

Kuidas Scrumis planeerimisprotsess käib? Kõigepealt peate koostama nimekirja kõigist asjadest, mis teie eesmärki mõjutavad. Pärast seda seadke need prioriteediks. Kui te ei pea kinni ajalistest ja rahalistest piirangutest, saate loendist viimased üksused hõlpsamini kõrvaldada.

Mida edasi teha? Iga loendis oleva üksuse puhul tuleb hinnata, kui palju vaeva, aega ja muid ressursse selle täitmiseks kulub. Kuidas hinnangut anda? Autor pakub välja suhteliste hinnangute skaala. Näiteks saate ülesandeid võrrelda"koertel". See probleem - taks või retriiver? Või äkki saksa dogi?

Kuid igal juhul on mugavam seada arvväärtusi. Näiteks,« Taks— üksus; dogi— kolmteist; labradorist sai viieline ja buldogist — kolm» .

Autor soovitab kasutada ka huvitavat pokkeri planeerimise tehnikat. Selle olemus— Igale planeerimisprotsessis osalejale antakse kaardipakk Fibonacci numbritega— 1, 2, 3, 5, 8, 13 ja nii edasi. Iga loendi üksus, tööühik, mida tuleb hinnata, asetatakse lauale.

Nõuded on lood

Selleks, et edukalt ja selgelt sõnastada tootenõuete loetelu ning luua kõigi jaoks mahajäämus, kasutab Scrum erakordset lähenemist. Lihtsa ülesannete loendi asemel koostatakse kasutajalugusid— lühilood, mis sisaldavad kasutaja soove lõpptoote osas.

« Kujutage ette, et teete end välja „ Amazon.com kasutaja taotlus “ . Prooviversioon näeb välja selline: „ Tarbijana tahan maailma suurimat raamatupoodi, kust saaksin igal ajal osta ükskõik millise raamatu “ .See kirjeldus sobib Amazoni tegelaskujuga hästi, kuid lugu on liiga ebamäärane, et sellest kasu oleks. midagiteha. Peame oma ajalugu killustama. Tee see tõesti väga spetsiifiliseks ja funktsionaalseks. Siin on mõned kasutajate näidislood, mida saate raamatut silmas pidades kirjutada. online pood :Tarbijana meeldib mulle otsida raamatuid žanri järgi, et leida kiiresti need, mida lugeda armastan. Tarbijana tahan osta raamatuid valides need korraga ostukorvi panna. Tootejuhina , soovin jälgida meie klientide oste , olla kursis, milliseid raamatuid neile pakkuda saab Siin on professionaalselt tehtud kasutajasoovid, mille olemusega grupp peaks arvestama » .

Kasutajalugu peab olema terviklik, erinevatest asjaoludest sõltumatu ja praktikas rakendatav. Need kriteeriumid näitavad loo valmisolekut. Samuti on oluline, et lugu saaks hinnata selle teostatavuse osas.

Kuidas sprinti planeerida

Scrumis toimub planeerimisprotsess iga uue sprindi alguses ja seda nimetatakse— « sprindi planeerimine» . « Kõik saavad kokku, vaatavad kasutajalugude loendit, mis on juba täitmise järjekorras; teada saada, mitu ülesannet saab iga rühmaliige enda peale võtta; kaaluge hoolikalt, kas nad suudavad selle sprindi jooksul valitud ülesanded täielikult valmis saada; kas nad suudavad demonstreerida kliendile tehtud tööüksusi ja näidata talle toote valmis funktsioone; Kas nad suudavad endale sprindi lõpus öelda, et on kõigega hakkama saanud? » .

Pärast seda ütleb meeskond ühehäälselt:"Edasi! "- ja asub tööle

Aga mis on töö? Rutiin, kohustus? Scrumi vaatenurgast töö— see on ajalugu. Mida see tähendab? See tähendab, et peaksite tutvustama kedagi, kes vajab teie tegevust; siis, mis see on, ja lõpuks, miks inimesed seda vajavad.

Meeskonnad peavad oma dünaamikat hästi tundma— kui palju tööd ta ühe sprindi jooksul teha suudab. See aitab tal targemalt töötada ja kõrvaldada kõik takistused.

« Dünaamika x aeg = tulemus. Teades, kui kiiresti te liigute, saate teada, millal jõuate finišisse » .

Avatus kõiges

Scrum eeldab kõigi toimingute ja protsesside läbipaistvust.

Seda väljendatakse kolmeveerulisel tahvlil, millele on juurdepääs kõigil meeskonnaliikmetel.

« Salastatus— I. Midagi ei saa saladuses hoida. Kõik peaksid teadma kõike, sealhulgas finantsandmeid. Hämardamine on vajalik ainult neile, kes otsivad endale kasu. » .

Toote omanik

Scrum täidab kolme rolli: Scrumi meeskond - konkreetsete projektide elluviijad; Scrum Master - see on see, kes jälgib projekti edenemist ja aitab meeskonnal probleeme lahendada ning toote omanikku— see, kes lahendab tootekontseptsiooni küsimused ja koostab mahajäämuse.

« Scrum Masterja meeskond vastutab oma töötempo ja selle eest, kui kiiresti nad projekti lõpetavad. Tooteomanik vastutab selle eest, et tõhus meeskonnatöö muutuks kasumlikeks tulemusteks. » . Tooteomanikul peavad olema turu kohta põhjalikud teadmised ja tal peab olema volitus otsuste tegemiseks.

See võib olla ühe inimese jaoks liiga suur vastutus, nii et suurtes projektides võib kaasata tooteomanike meeskond.

Riskide minimeerimine Scrumis

Kuna Scrum näeb ette samm-sammult projekti edastamise, aitab see riske minimeerida. See aitab kiiresti toodet kliendile näidata ja temalt tagasisidet saada.

« Scrumi metoodika on ärile kasulik, sest annab kiiresti vastuse küsimusele: kas saame raha teenida, kui teeme seda või teist?

Sa ei pea kulutama palju raha, enne kui aru saad midagi ei tööta.

See juhend aitab tarkvaraarendajatel ja testijatel mõista Agile SCRUM-i metoodikat ja sellega alustada.

Õppige põhilisi, kuid olulisi termineid, mida kasutatakse Agile Scrumi protsessis, ja kogu protsessi tegelikku näidet.

SCRUM on agiilne protsess, mis on kombinatsioon iteratiivsetest ja inkrementaalsetest mudelitest.

Traditsioonilise kosemudeli üks peamisi puudusi on see, et kuni esimese etapi valmimiseni ei liigu rakendus teise etappi. Kui juhtub, et tsükli hilisemas etapis on muudatusi, siis on neid muudatusi väga raske läbi viia, kuna sellega kaasneb eelmiste etappide ülevaatamine ja muudatuste uuesti tegemine.

Mõned SCRUM-i põhifunktsioonid on järgmised:

• Organiseeritud ja sihikindel meeskond
• Puuduvad dokumendinõuded, piisab täpsete tekstide olemasolust.
• Funktsionaalne meeskond töötab ühtse üksusena.
• Tihe side kasutajaga, mis aitab funktsioone mõista.
• Täpne ajatelg on maksimaalselt 1 kuu.
• Selle asemel, et teha kõike korraga, teeb Scrum etteantud aja jooksul kõike natuke.
• Enne mis tahes toimingu tegemist kaalutakse ressursside omadusi ja saadavust.

Selle metoodika hästi mõistmiseks on oluline mõista SCRUM-i võtmetermineid.

Olulised SCRUM-i tingimused:

1. Scrum meeskond

Scrumi meeskond on 7 +/- 2 liikmeline meeskond. Meeskonnaliikmed on segu pädevatest arendajatest, testijatest, andmebaasi inimestest, tugioperaatoritest jne, aga ka tooteomanikust ja scrum masterist. Kõik need inimesed teevad kindlaksmääratud funktsioonide väljatöötamiseks ja täitmiseks teatud rekursiivse perioodi jooksul tihedat koostööd.

2. Sprint

Sprint on standardne ajavahemik, mille jooksul töö peab olema lõpetatud ja valmis ülevaatamiseks või toote vabastamiseks. Tavaliselt kestab see periood kaks nädalat kuni kuu. Kui ütleme, et teeme 1 sprindi kuus, tähendab see, et töötame ühe kuu ülesannete kallal ja valmistame need ülevaatamiseks ette selle kuu lõpuks.

3. Toote omanik

Tooteomanik on arendatava rakenduse peamine müügiinimene või juhtivkasutaja.

Tooteomanik on isik, kes esindab kliendi poolt. Tal on lõplik volitus ja ta peab alati meeskonnale kättesaadav olema. Ta peab olema kättesaadav, kui keegi vajab midagi selgitamist. Tooteomanikul on oluline mõista ja mitte seada uusi nõudeid keset sprindi või siis, kui see on juba alanud.

4. Scrum master

Scrum Master on Scrumi meeskonna koordinaator. Ta tagab, et scrum-meeskond on produktiivne ja edumeelne. Igasuguse häire korral otsib ja lahendab Scrum Master selle meeskonna eest.

5. Kasutaja lugu

Kasutajalood on nõuded või funktsioonid, mis tuleb täita. Scrumis meil neid suuri nõudeid dokumente ei ole, vastupidi, nõuded on kirjas ühes lõigus, tavaliselt sellises vormingus:

Kuidas<тип пользователя>

ma tahan<доступная цель>

saavutuse eest<результат/причина>

Näiteks:

Administraatorina soovin, et saaksin parooli lukustada, et piirata volitamata juurdepääsu juhuks, kui kasutaja sisestab 3 korda järjest vale parooli.

Kasutajalugudel on mõned omadused, millest tuleb kinni pidada. Kasutajate lood peaksid olema lühikesed, realistlikud, võimaluse korral hinnangulised, täielikud, läbiräägitavad ja testitavad.

Igal kasutajalool on aktsepteerimise kriteerium, mis peab olema selgelt määratletud ja meeskonnale arusaadav. Nõustamiskriteeriumid kirjeldavad üksikasjalikult kasutajalugusid ja pakuvad toetatud dokumente. See võimaldab kasutajate lugusid üksikasjalikult kirjeldada. Vastuvõtukriteeriumid võib üles kirjutada iga meeskonnaliige. Kinnitusmeeskond lähtub oma testjuhtumite/tingimuste loomisel nendest kriteeriumidest.

6. "Eeposed"

Eeposed on ebamäärased kasutajalood. Või võime öelda, et need on kasutajalood, mida pole määratletud ja mis salvestatakse tulevaste sprintide jaoks. Proovige seda lihtsalt eluga siduda, kujutage ette, et lähete puhkusele. Kuna lahkute järgmisel nädalal, on teil kõik planeeritud: hotellibroneeringud, vaatamisväärsused, reisikott pakitud jne. Aga kuidas on teie puhkusega järgmisel aastal? Sul on vaid ähmane ettekujutus, et võid XYZ kohta minna, aga sul pole mingit detailplaneeringut.

“Epic” on nagu sinu puhkus järgmisel aastal: tead, et võid minna, aga kuhu, millal ja kellega – sellel teemal veel mõtteid ei ole.

Samuti on funktsioone, mida tuleks tulevikus kasutusele võtta, kuid nende üksikasjad pole veel teada. Tavaliselt algab võimalus "eeposega" ja jagatakse seejärel lugudeks, mida saab realiseerida.

7. Tootesoovide logi

Tootesoovide logi on omamoodi segment või allikas, kuhu salvestatakse kõik kasutajalood. Seda hooldab toote omanik. Tootesoovide logi võib mõelda kui soovide nimekirja tooteomanikult, kes prioriseerib selle vastavalt ärivajadustele. Planeerimise ajal (vt järgmist jaotist) võetakse üks kasutajalugudest mahajäämust, meeskond hakkab ajurünnakut tegema, kontseptualiseerima, viimistlema ja ühiselt otsustama (tooteomaniku sisendiga), milline kasutajalugu vastu võtta.

8. Sprindi soovinimekiri

Tootesoovide logist võetakse korraga üks kasutajalugu. Scrumi meeskond teeb ajurünnakuid, teeb kindlaks teostatavuse ja otsustab, millise loo kallal konkreetse sprindi jooksul edasi töötada. Üldnimekirja kõigist kasutajalugudest, millega Scrumi meeskond antud sprindi jooksul töötab, nimetatakse sprindi mahajäämuseks.

9. Kasutaja loo punktid:

Need punktid on kasutajaloo keerukuse numbriline esitus. Nende hinnete põhjal määratakse ühe loo punktisumma ja töömaht. Punktid ei ole absoluutsed, need on suhtelised. Selleks, et meie jõupingutused ja hinnangud oleksid õiged, peame kontrollima, kas kasutajalood on suured. Mida väiksem ja selgem on kasutajalugu, seda täpsem on hinnang.

Igale kasutajaloole määratakse Fibonacci hinne (1, 2, 3, 5, 8, 13, 21). Mida suurem number, seda keerulisem on lugu.

Täpsemalt siis

• Kui panustate 1/2/3 punkti, tähendab see, et lugu on lühike ja madala raskusastmega.
• Kui annad 5/8 punkti siis on see keskmise raskusastmega ja
• 13 ja 21 punkti – lugu on väga keeruline.

Raskus seisneb siin arenduses ja testimistöö mahus

Et otsustada, kui palju punkte anda, alustab Scrumi meeskond ajurünnakut ja otsustab ühiselt. Võib juhtuda, et arendusmeeskond annab konkreetsele loole 3 punkti, sest nende jaoks võib see olla 3 rida asenduskoodi, kuid testimismeeskond annab 8 punkti, kuna nad tunnevad, et see koodivahetus mõjutab mooduleid rohkem, nii et töömaht on testimise ajal rohkem. Kuid ükskõik kui palju punkte annate, peate oma otsust põhjendama. Seega toimub ajurünnak ja meeskond otsustab, kui palju punkte panna.

Kui otsustate, kui palju punkte panustada, võtke arvesse järgmisi tegureid:

• Ajaloo seos teiste rakenduste/moodulitega,
• Ressursioskuste komplekt
• Ajaloo keerukus
• Narratiivne õppimine,
• Kasutajalugude aktsepteerimise kriteeriumid

Kui te pole konkreetsest loost teadlik, ärge muutke selle suurust.
Kui näete, et loo hind on väga kõrge, jagage see väiksemateks lugudeks.

10. Ülesande läbipõlemise diagramm

Ülesande läbipõlemise diagramm esitab graafiku, mis näitab scrumi ülesannete tegeliku pingutuse hinnangulist v/s.

See on konkreetse sprindi jälgimismehhanism. Iga päev jälgitakse ülesandeid, et kontrollida, kas lood liiguvad lõpule või mitte.

Näide: selle mõistmiseks vaadake pilti:

Ma valisin:

• Kahenädalane sprint (10 päeva)
• 2 ressurssi sprindi tegelikuks tööks.

"Ajalugu" -> veerus on näha sprindiks võetud kasutajalood. "Ülesanne" -> veerus kuvatakse kasutajalugudega seotud ülesannete loend.

“Töö ulatus” -> veerg näitab töö mahtu. See meede on nüüd ülesande täitmiseks tehtud töö kogumaht. See ei kujuta ühegi konkreetse inimese töömahtu.

“1. päev – 10. päev”->– veerg(id) näitab loo lõpuni jäänud aega. Pange tähele, et see EI OLE aeg, mis on juba möödas, VAID aeg, mis on veel alles.

“Eeldatav töömaht” -> töö kogumahu näitaja. "Start" puhul on see lihtsalt kogu ülesande kogusumma: SUM (C5:C15)

1 päevaga tehtavate tööde kogumaht on 70 / 10 = 7. Seega tuleks esimese päeva lõpuks töömahtu vähendada 70-7 = 63-ni. Samamoodi arvutatakse see kõigi päevade kohta kuni 10. kuupäevani, mil hinnanguline töömaht peab olema null (rida 16)

“Järeljäänud töömaht” -> Nagu nimigi ütleb, on see töömaht, mis jääb enne loo valmimist. Samuti võib juhtuda, et tegelik töömaht jääb oodatust suuremaks või väiksemaks.

Selle ülesannete läbipõlemisdiagrammi loomiseks saate Excelis kasutada funktsioone ja diagramme.

Ülesande põletamise diagrammi etapid:

1. Sisestage kõik lood (veerud A5–A15)
2. Sisestage kõik ülesanded (veerud B5–B15)
3. Sisestage päevad (1. päev – 10. päev)
4. Sisestage esialgne töömaht (summeerige ülesanded C5-C15)
5. Kasutage valemit, et arvutada iga päeva "hinnanguline töömaht" (1. päevast 10. päevani). Sisestage valem lahtrisse D15 (c16-$ C$ 16/10) ja lohistage see kõikidele päevadele.
6. Iga päeva kohta sisestage tegelik töömaht. Sisestage D17-sse valem (SUM (D5:D15)), et summeerida järelejäänud töömaht ja lohistada see kõikidele teistele päevadele.
7. Valige see ja looge selline diagramm:

11. Meeskonna kiirus

Scrum-meeskonna sprindis salvestatud punktide koguarvu nimetatakse meeskonna kiiruseks. Scrumi meeskonda hinnatakse selle kiiruse järgi. Peab ütlema, et tuleb silmas pidada, et maksimaalse punktide arvu saavutamine EI OLE siin eesmärgiks, vaid kvaliteetsed tulemused tõstavad scrumtiimi mugavustaset.

Näiteks: Konkreetse sprindi puhul: kasutajalugude koguarv on 8. Igaühel neist on kindel arv punkte

Seega on kiirus punktide summa = 30

12. Mõiste „valmis” määratlus:

Ajalugu on Scrumis TEHTUD vaid siis, kui on olemas areng, täielik kvaliteedikindlus ja võimalus tootmisse pääseda.

Tegevused SCRUMis:

#1: Planeerimiskoosolek

Planeerimiskoosolek on SCRUM-i alguspunkt. See on koosolek, kuhu koguneb kogu Scrumi meeskond. Tooteomanik valib prioriteedi alusel toote mahajäämust kasutajalood ja meeskond alustab ajurünnakut. Arutelu käigus määrab Scrumi meeskond loo keerukuse ja mõõdab seda Fibonacci seeria järgi. Meeskond määratleb nii ülesanded kui ka töömahu (tundides), mida saaks teha kasutajaloo juurutamise lõpuleviimiseks.

Koosolekule eelneb “Koosoleku eelplaneerimine”. See on nagu kodutöö, mida Scrumi meeskond teeb enne ametlikku planeerimiskoosolekut. Meeskond püüab üles kirjutada sõltuvused või muud tegurid, mida nad sooviksid koosolekul arutada.

#2: Sprindi eesmärkide täitmine

Nagu nimigi ütleb, on Scrumi meeskonna ülesanne täita oma ülesanne ja viia kasutajalugu olekusse "tehtud".

#3: igapäevane Scrumi koosolek (kõne)

Sprinditsükli ajal kohtub scrum-meeskond iga päev kuni 15 minutit (see võib olla kõne, mis on soovitatav päeva alguses). Koosolekul esitatakse kolm küsimust:

1. Mida on meeskonnaliige pärast viimast kohtumist teinud?
2. Mida meeskonnaliige täna teha plaanib?
3. Kas meeskonnal on mingeid takistusi?

Scrum Master töötab nende probleemide lahendamise nimel. Kui osalejal tekib mingeid raskusi, aitab Scrumi meister neid lahendada.

#4: tulemuste ülevaade

Iga sprinditsükli lõpus tuleb SCRUM-i meeskond uuesti kokku ja demonstreerib tooteomanikule kasutajalugude rakendamist. Tooteomanik saab lugusid kokku võtta vastavalt nende aktsepteerimiskriteeriumidele. Jällegi on Scrum Masteri kohustus seda koosolekut juhatada.

#5: tagasivaatav kohtumine

Pärast tulemuste ülevaatamist toimub tagasivaatav koosolek. SCRUM-i meeskond kogub, arutab ja dokumenteerib järgmisi punkte:

1. Mis läks eelmisel sprindil hästi (parim praktika)
2. Mida ei tehtud väga hästi
3. Õppetunnid
4. Tegevuselemendid.

Scrumi meeskond peab jätkama parimate tavade järgimist, ignoreerima "halbu tavasid" ja rakendama saadud õppetunde järgmistel sprindidel. Tagasivaatav koosolek aitab SCRUM-i protsessi pidevalt täiustada.

Kuidas protsess toimub? Näide!

Olles lugenud SCRUMi tehnilisi žargooni, proovin kogu protsessi näitega demonstreerida.

Samm 1: Kujutagem ette 9-liikmelist SCRUM-i meeskonda, mis koosneb 1 omanikust, 1 Scrumi meistrist, 2 testijast, 4 arendajast ja 1 andmebaasi administraatorist.

Samm nr 2: Näiteks sprinditsükkel kestab 4 nädalat. Niisiis, meil on 1-kuuline sprint: 5. juunist 4. juulini.

Samm nr 3: Tooteomanikul on toote backlogis eelisjärjekorras kasutajalugude loend.

• Tooteomanik võtab toote soovide nimekirjast 1 loo, kirjeldab seda ja edastab meeskonnale ajurünnakuks.
• Kogu meeskond arutab ja läheb otse tooteomaniku juurde, et kasutajalugu üksikasjalikult selgitada.
• Teisi kasutajalugusid aktsepteeritakse samamoodi. Võimalusel saab meeskond jätkata ja ka lugusid mõõta.

Pärast arutelu naasevad meeskonnaliikmed oma töökohtadele ja

• Nad määratlevad iga loo jaoks oma individuaalsed ülesanded.
• Arvutage täpne aeg, mis neil töötamiseks kulub. Kuidas osaleja seda aega arvutab? Kontrollime:

Töötunde kokku = 9

Miinus 1 tund pausi, miinus 1 tund koosolekute jaoks, miinus 1 tund meilide, arutelude, veaotsingu jne jaoks.
Seega tegelik tööaeg = 6

Tööpäevade koguarv sprindi jooksul = 21 päeva.
Saadaolevad tunnid kokku = 21 * 6 = 126

Liige on puhkusel 2 päeva = 12 tundi (see on iga liikme puhul erinev, mõni võib puhkust võtta, mõni mitte.)
Tegelike tundide arv = 126-12 = 114 tundi.

See tähendab, et osaleja on selle sprindi jooksul tavaliselt saadaval 114 tundi. Seetõttu jagab ta oma individuaalse sprindiülesande nii, et see saavutatakse 114 tunniga.

• Lõplik arvamus kasutajaloo kohta tootemahust valmib ja jutt liigutatakse sprindi mahajäämusse.
• Iga loo puhul teatab iga meeskonnaliige oma konkreetsed ülesanded. Kui soovite neid probleeme arutada, saate neid mõõta või nende suurust muuta (mõelge Fibonacci seeriale!).
• Scrum Master või meeskond sisestab programmi oma individuaalsed ülesanded ja iga loo ajastuse.
• Kui kõik lood on lõpetatud, märgib Scrum Master algkiirust ja sprint algab ametlikult.

Samm nr 6: Kui sprint algab, hakkab iga meeskonnaliige tegelema määratud ülesannetega.

Samm nr 7: Meeskond kohtub iga päev 15 minutit ja arutab 3 küsimust:

• Mida nad eile tegid?
• Mida nad täna teha plaanivad?
• Kas on mingeid häireid?

Samm nr 8: Scrum Master jälgib iga päev edenemist põlemisdiagrammi abil

Samm nr 9: Mis tahes häirete korral lahendab Scrum Master selle.

Samm nr 10: 4. juulil koguneb meeskond uuesti, et tulemused üle vaadata. Iga meeskonnaliige demonstreerib juurutatud kasutajalugu toote omanikule.

Samm nr 11: 5. juulil koguneb meeskond uuesti tagasivaatavale koosolekule, kus arutatakse

• Mis läks hästi?
• Mis ei läinud hästi
• Tegevuselemendid.

Samm nr 12: 6. juulil koguneb meeskond uuesti järgmisele sprindi eelplaneerimise koosolekule ja tsükkel jätkub.

(Klõpsa pildi suurendamiseks)

Programmid, mida saab kasutada SCRUM-i tegevuste jaoks:

Scrumi tegevuste jälgimiseks on palju tööriistu. Siin on mõned neist:

• XPplanner
• VersionOne
• Sprintomeeter
• ScrumNinja

Järeldus:

Alguses võib inimestel tekkida raskusi selle tehnika valdamisega, kuid harjutades näete, et SCRUM teeb imesid. SCRUM koondab ressursid nii, et näete oma rakenduse arengut.

Paljud ajutised organisatsioonid julgustavad meeskonda pühendama paar tundi iseõppimisele ja arengule. Ka ülevaatuse käigus näitavad rühmaliikmed õpitut ja esitlevad vahel ka enda välja töötatud programme või rakendusi. Isiklikult hindan seda meetodit, sest see annab inimestele võimaluse oma teadmisi laiendada ja oma oskusi näidata.

Jätkan projektijuhtimise eriala lõputööga. Täna heidame kiire pilgu Scrumile, vaatleme levinud vigu, mis põhjustavad probleeme. See postitus ei pretendeeri täielikkusele, see on ülevaade ja on suunatud neile, kes Scrumiga veel kursis ei ole või on tuttavad vaid osaliselt (näiteks töötavad muudetud Scrumis).

Praegu on Scrum üks populaarsemaid tarkvaraarenduse metoodikaid. Definitsiooni järgi on Scrum arendusraamistik, mis võimaldab inimestel lahendada esilekerkivaid probleeme, olles samal ajal produktiivne ja tootnud kõrgeima väärtusega tooteid.

See viitab sellele, et Scrumis on võimatu leida vastuseid kõikidele küsimustele ja tegevusjuhiseid kõikides olukordades (näiteks Scrumi ametlik kirjeldus viitab vaid vajadusele hinnata töö valmimiseks kuluvat aega, kuid ei täpsusta töö tüüpi st see võib olla planeerimispokker või mõni muu hindamismeetod). Seega ei ole teema enda nimi õige :)

Scrumi metoodikast rääkides mõeldakse enamasti paindlikku tarkvaraarenduse metoodikat, mis on üles ehitatud Scrumi reeglite ja tavade alusel, nii et võib selguda, et teie Scrum on lahedam kui minu Scrum ja samas ka nii kaugel. see nagu VAZ 7 on BMW 7. seeriast :)

Rollid Scrumis

Klassikalises Scrumis on kolm põhirolli:
-Toote omanik
-Scrum meister
-Arendusmeeskond

Toote omanik(PO) on lüli arendusmeeskonna ja kliendi vahel. PO ülesanne on maksimeerida arendatava toote väärtust ja meeskonna tööd.

Üks peamisi ostutellimuse tööriistu on toote mahajäämus. Toote backlog sisaldab täitmiseks vajalikke tööülesandeid (nt lugu, viga, ülesanne jne), mis on järjestatud prioriteetsuse (kiireloomulisuse) järjekorras.

Scrum meister(SM) on "teenija-juht". Scrum Masteri ülesanne on aidata meeskonnal oma efektiivsust maksimeerida, kõrvaldades takistused, abistades, treenides ja motiveerides meeskonda ning abistades PO

Arendusmeeskond(Development team, DT) koosneb spetsialistidest, kes tegelevad vahetult valmistatava tootega. Vastavalt Scrum Guide'ile (dokument, mis on selle autorite ametlik Scrumi kirjeldus) peaksid DT-del olema järgmised omadused ja omadused:
-Ole iseorganiseeruv. Keegi (sealhulgas SM ja PO) ei saa meeskonnale öelda, kuidas toote backlogi muuta toimivaks tooteks
-Ole multifunktsionaalne, omama kõiki vajalikke oskusi töötava toote vabastamiseks
- Tehtud töö eest vastutab kogu meeskond, mitte üksikud meeskonnaliikmed

Soovitatav meeskonna suurus on 7 (pluss-miinus 2) inimest. Scrumi ideoloogide hinnangul nõuavad suuremad meeskonnad liiga palju suhtlusressursse, samas kui väiksemad meeskonnad suurendavad riske (võimaliku vajalike oskuste puudumise tõttu) ja vähendavad töömahtu, mida meeskond ajaühikus teha suudab.

Scrum protsess

Scrumi aluseks on Sprint, mille käigus tehakse tööd toote kallal. Sprindi lõpus tuleks hankida toote uus tööversioon. Sprint on alati ajaliselt piiratud (1-4 nädalat) ja sama kestusega kogu toote eluea jooksul.

Enne iga sprindi algust viiakse läbi sprindi planeerimine, mis hindab toote Backlogi sisu ja genereerib Sprint Backlogi, mis sisaldab ülesandeid (lugu, vead, ülesanded), mis tuleb praegusel sprindil täita. Igal sprindil peaks olema eesmärk, mis on motiveeriv tegur ja mis saavutatakse sprindi mahajäänud ülesannete täitmisega.

Iga päev viiakse läbi Daily Scrum, mille käigus iga meeskonnaliige vastab küsimustele "mida ma eile tegin?", "Mida ma täna teha plaanin?", "Milliste takistustega ma oma töös kokku puutusin?" Daily Scrumi ülesandeks on määrata sprindi tööde seis ja edenemine, tekkivate takistuste varajane avastamine ning lahenduste väljatöötamine sprindi eesmärkide saavutamiseks vajaliku strateegia muutmiseks.

Sprindi lõpus viiakse läbi Sprint Review ja Sprind Retrospective, mille ülesandeks on hinnata meeskonna tulemuslikkust (sooritust) möödunud sprindil, ennustada eeldatavat tulemuslikkust (sooritust) järgmisel sprindil, tuvastada olemasolevad. probleeme, hinnata tõenäosust, et tootega tehakse kõik vajalikud tööd ja palju muud.

Protsessi skemaatiline kujutis on näidatud järgmisel joonisel:

Olulised, sageli unustatud funktsioonid

Tihti kuulete, et Scrum ei tööta või töötab oodatust halvemini. Tuleb märkida, et enamasti juhtub see ühel järgmistest põhjustest:

1. Scrum on paigaldatud valesti või puudulikult.
Scrumi autorite sõnul on empiiriline kogemus peamine usaldusväärse teabe allikas. Vajadus Scrumi täielikuks ja täpseks rakendamiseks on märgitud Scrumi juhendis ning selle põhjuseks on protsessi ebatüüpiline korraldus ning formaalse juhi ja juhi puudumine.

2. Alahinnatakse meeskonna motiveerimise nimel töötamise tähtsust.
Scrumi üks põhiprintsiipe on iseorganiseeruvad, funktsionaalsed meeskonnad. Sotsioloogide uuringute kohaselt ei ületa iseorganiseerumisvõimeliste isemotiveeritud töötajate arv 15% töötavast elanikkonnast.
Seega on vaid väike osa töötajatest võimelised Scrumis tõhusalt töötama ilma oluliste muutusteta Scrumi meistri ja tooteomaniku rollides, mis on vastuolus Scrumi ideoloogiaga ja võib viia Scrumi ebaõige või mittetäieliku kasutamiseni.

3. Scrumit kasutatakse toote puhul, mille nõuded on vastuolus Scrumi ideoloogiaga.
Scrum kuulub Agile'i perekonda, seega tervitab Scrum nõuete muudatusi igal ajal (Toote mahajäämust saab igal ajal muuta). See muudab Scrumi kasutamise fikseeritud kulu/fikseeritud ajaga projektides keeruliseks. Scrumi ideoloogia ütleb, et kõiki muudatusi on võimatu ette näha, mistõttu ei ole mõtet kogu projekti ette planeerida, piirdudes just-in-time planeerimisega, s.t planeerida ainult neid töid, mis tuleb teha praeguses plaanis. Sprint. On ka teisi piiranguid.

Eelised ja miinused

Scrumil on üsna atraktiivsed eelised. Scrum on kliendikeskne ja kohanemisvõimeline. Scrum annab kliendile võimaluse nõuetes igal ajal muudatusi teha (kuid ei garanteeri nende muudatuste elluviimist). Võimalus nõudeid muuta on paljudele tarkvaraklientidele atraktiivne.

Scrum on üsna lihtne õppida ja võimaldab säästa aega, välistades mittekriitilised tegevused. Scrum võimaldab teil saada potentsiaalselt töötava toote iga sprindi lõpus.
Scrum rõhutab iseorganiseeruvat, funktsionaalset meeskonda, kes suudab täita nõutud ülesandeid minimaalse koordineerimisega. See on eriti atraktiivne väikeettevõtetele ja alustavatele ettevõtetele, kuna see välistab vajaduse palgata või koolitada spetsialiseerunud juhtimispersonali.

Muidugi on Scrumil ka olulisi miinuseid. Scrum seab oma lihtsuse ja minimalismi tõttu väikese hulga üsna rangeid reegleid. See läheb aga põhimõtteliselt vastuollu kliendikesksuse ideega, kuna klient ei hooli arendusmeeskonna sisereeglitest, eriti kui need klienti piiravad. Näiteks saab vajadusel kliendi otsusel Sprinti mahajäämust muuta, hoolimata ilmsest vastuolust Scrumi reeglitega.

Probleem on suurem, kui tundub. Sest Scrum kuulub Agile perekonda, Scrum ei koosta näiteks suhtlus- ja riskireageerimisplaani. Seega on Scrumi reeglite rikkumiste formaalne (juriidiline või administratiivne) vastu võitlemine raskendatud või võimatu.

Teine Scrumi nõrk omadus on rõhk iseorganiseeruval, ristfunktsionaalsel meeskonnal. Vaatamata meeskonna koordineerimise kulude ilmsele vähenemisele suurendab see personali valiku, motiveerimise ja koolituse kulusid. Teatud tööturutingimustes võib täisväärtusliku ja tõhusa Scrumi meeskonna moodustamine olla võimatu.

Kasutatud allikate loetelu

Scrum Guide. Scrumi lõplik juhend: mängureeglid. (Ken Schwaber, Jeff Sutherland)
Juhtimise psühholoogia, õpik. (A. A. Trus)
Kuidas traditsiooniline projektijuht muutub Scrumiks: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Tänan teid juba ette nende vigade ja ebatäpsuste eest!