GRĮŽTI ATGAL
Jei jūsų programinė įranga team susiduria su besikeičiančiais reikalavimais, praleistais terminais ar nesusikalbančiomis suinteresuotosiomis šalimis, nesate vieni. "Scrum" programinės įrangos inžinerijoje yra judri sistema, ypač veiksminga kuriant sudėtingus produktus dėl savo pasikartojančių procesų, skaidrumo ir gebėjimo prisitaikyti. Šiame vadove tiksliai paaiškinama, kaip veikia "Scrum", kas ką daro ir kaip jį veiksmingai įgyvendinti, o taip pat kaip [...]
Jei jūsų programinė įranga komanda kovojate su kintančiais reikalavimais, praleistais terminais ar nesusikalbančiomis suinteresuotosiomis šalimis, nesate vieni. scrum svetainėje programinės įrangos inžinerija yra Agile sistema ypač veiksminga kuriant sudėtingus produktus, nes joje taikomi kartotiniai procesai, skaidrumas ir pritaikomumas. Šiame vadove tiksliai paaiškinama, kaip veikia "Scrum", kas ką daro ir kaip ją veiksmingai įgyvendinti 2026 m.
"Scrum" - tai programinės įrangos inžinerijos srityje naudojama agile sistema, skirta valdyti sudėtingus produktų kūrimas atliekant iteracinį ir inkrementinį darbą, paprastai organizuojamą fiksuoto ilgio iteracijomis, vadinamomis sprintais (paprastai 1-4 savaitės). Supratimas, kodėl tai svarbu, prasideda nuo pagrindinių komponentų ir jų tarpusavio veikimo.
Scrum yra veržli programinės įrangos kūrimas sistema, pagal kurią darbas organizuojamas į terminuotus sprintus (paprastai nuo 1 iki 4 savaičių), per kuriuos team pristato darbinės programinės įrangos dalis, kurias galima išsiųsti. Sprintas yra fiksuotas laiko tarpas, per kurį Skirta team dirbama siekiant bendro sprinto tikslo, o dvi savaitės yra įprasta trukmė, kuri suderina grįžtamojo ryšio greitį ir planavimo sąnaudas.
Scrum grindžiamas empiriniu procesų valdymu, kuris teigia, kad žinios gaunamos iš patirties, o sprendimai priimami remiantis stebimais rezultatais. Empirinė procesų kontrolė apima skaidrumą, tikrinimą ir pritaikymą, kurie užtikrina, kad visi darbai būtų matomi, dažnai tikrinami ir prireikus pritaikomi siekiant pagerinti kokybę ir pažangą. Scrum remiasi aiškiai apibrėžtu kūrimo procesas užtikrinti skaidrumą, nuolatinį tobulėjimą ir aukštos kokybės rezultatus visoje projektas gyvavimo ciklą.
Šis empiriškumas padeda inžinieriams team efektyviau nei tradiciniai krioklio modeliai tvarkyti kintančius reikalavimus, sudėtingas architektūras ir paveldėtų sistemų integraciją. Tyrimai rodo, kad krioklio projektuose po išleidimo atsiranda iki 40% daugiau defektų, palyginti su judriais metodais, daugiausia dėl to, kad reikalavimai per anksti užfiksuojami.
Apsvarstykite tipinį scenarijų: team kuria žiniatinklio svetainė 2 savaičių trukmės sprintuose su nuolatiniu diegimu ir automatizuotais testais. Per kiekvieną sprintą sukuriama veikianti programinė įranga, kuria suinteresuotosios šalys gali iš tikrųjų naudotis ir teikti atsiliepimus, o ne mėnesius laukti didelės apimties išleidimo.
Svarbu, Scrum yra sistema, o ne griežta metodika. Tokia techninė praktika, kaip TDD, porinis programavimas, kūrimas pagal kamieną ir CI/CD pipelines, paliekama team autoriaus nuožiūrai. Šis lankstumas leido Scrum prisitaikyti prie šiuolaikinių stekų, įskaitant debesų programėles, mikroservisai, ir dirbtinio intelekto / ML funkcijas.
Agile yra plati filosofija, kylanti iš 2001 m. "Agile" manifesto, kurioje pirmenybė teikiama asmenims, o ne procesams, veikiančiai programinei įrangai, o ne dokumentams, bendradarbiavimui su klientais, o ne sutartims, ir reagavimui į pokyčius, o ne planų laikymuisi. Scrum yra viena iš konkrečių "Agile" struktūrų, kurioje šie "Agile" principai įgyvendinami per konkrečias struktūras.
Štai kuo praktiškai skiriasi "agile" metodika nuo "scrum" metodikos:
| Aspektas | Agile (filosofija) | "Scrum" (sistema) |
|---|---|---|
| Struktūra | Lankstus, pagrįstas principais | Nustatyti vaidmenys, įvykiai, artefaktai |
| Iteracijos | Neįpareigota | Sprintai pagal laiką (1-4 savaitės) |
| Vaidmenys | Nenurodyta | Produkto savininkas, Scrum Master, programuotojai |
| Susitikimai | Pagal poreikį | Penkios apibrėžtos "scrum" ceremonijos |
| Artefaktai | Skiriasi priklausomai nuo įgyvendinimo | Produkto darbų žurnalas, sprinto darbų žurnalas, prieaugis |
Apsvarstykite, kaip galėtų veikti neformali judri team: kūrėjai imasi užduočių, kai yra pasiruošę, susitikimai vyksta ad hoc, o leidiniai išleidžiami, kai team jaučiasi pasiruošusi. A Scrum kūrimas team, priešingai, darbas suskirstytas į sprintus su oficialiomis sprinto peržiūromis ir sprinto retrospektyvomis, kurios sukuria nuspėjamą ritmą.
Kitos judrios metodikos Kanban (nenutrūkstamas srautas su WIP apribojimais) ir XP (dėmesys techninei praktikai). Scrum geriausiai tinka produktų kūrimui, kai keičiasi funkcijų rinkiniai, daug suinteresuotųjų šalių, kurioms reikia reguliaraus grįžtamojo ryšio, ir team, kuriems naudingas struktūrinis iteracijos procesas. Scrum agile iš tiesų yra judrus programinės įrangos kūrimas, tačiau ne visi judrūs metodai naudoja "scrum" renginius ar reikalauja "scrum" meistro vaidmens.
Kenas Schwaberis ir Jeffas Sutherlandas sukūrė “Scrum" XX a. dešimtojo dešimtmečio pradžioje, įkvėpti 1986 m. "Harvard Business Review" straipsnio "The New New Produkto kūrimo žaidimas” pagal Takeuchi ir Nonaka. Tame straipsnyje buvo aprašytas regbio team stiliaus požiūris į inovacijas, taigi ir “Scrum”, kuris labai skiriasi nuo griežtų nuosekliųjų modelių.
Pirmieji "Scrum" diegimo etapai tokiose įmonėse kaip "Easel Corporation" ir "IDX Health" buvo orientuoti į nedideles, kartu veikiančias programinės įrangos team grupes, kurios kas 30 dienų pristatydavo naujienas. Telecom ir finansai sektoriuose buvo pradėta taikyti anksti, o atvejų tyrimai parodė, kad 50% sutrumpino ciklo laiką 30 dienų intervalais.
Svarbiausi "Scrum" evoliucijos etapai:
Šiuolaikinė inžinerinė praktika 2015-2026 m. pakeitė tai, kaip team kuria savo "Atlikto" apibrėžtį. DevOps integracija reiškia, kad dabar DoD dažnai apima CI/CD pipeline etapus, stebėsenos kabliukus ir našumo kriterijus. Komandos įtraukia funkcijų žymes, skirtas A/B bandymams, ir automatinio atšaukimo mechanizmus tiesiai į savo sprinto darbo eigą.
Šiandien "Scrum" galima pritaikyti daugeliui team ir sudėtingiems produktams, taikant tokius modelius kaip bendri darbų planai ir tarpusavio team koordinavimas. Scrum aljansas ir kitos organizacijos toliau sertifikuoja Scrum praktikus visame pasaulyje. Tačiau pagrindiniai "Scrum" principai tebėra orientuoti į team darbą, prisitaikymą ir skaidrumą.
"Scrum" team programinės įrangos inžinerijos srityje - tai nedidelis, daugiafunkcinis, savarankiškai valdomas padalinys, paprastai nuo 5 iki 10 žmonių, turintis visus įgūdžius, reikalingus veikiančiai programinei įrangai pristatyti kiekvieną sprintą. "Scrum" apima konkrečius vaidmenis, tokius kaip produkto savininkas, Scrum Master ir programuotojai, kurių kiekvienas turi apibrėžtas pareigas, kad būtų išvengta kliūčių ir paskirstyta atsakomybė. Scrum Master yra atsakingas už "Scrum" team efektyvumo didinimą, instruktuodamas team narius, šalindamas kliūtis ir palengvindamas "Scrum" procesus, kad pagerėtų team našumas ir pristatymas.
Drobiniai teams yra saviorganizuojantys ir tarpfunkciniai, t. y. team nariai glaudžiai bendradarbiauja ir prisiima kolektyvinę atsakomybę už atliktą darbą, o tai didina team sanglaudą ir veiksmingumą. Ši struktūra tinka įvairiems organizaciniams modeliams, organizuotiems pagal produktų linijas, team platformas ar vertės srautus.
Sistemoje sąmoningai vengiama dalinių team (specialių backend grupių, tik QA team), kurios pažeidžia visą team koncepciją. Tarpfunkciškumas sumažina perdavimų skaičių ir leidžia visiems sutelkti dėmesį į sprinto tikslą, o ne į atskirus rezultatus.
Produkto savininkas yra atsakingas už produkto vertės didinimą ir produkto "Backlog" valdymą, užtikrinant, kad jo prioritetai būtų nustatomi atsižvelgiant į verslo ir klientų poreikius. "Scrum" taiko verte pagrįstą prioritetų nustatymą, kad kuo anksčiau ir dažniau būtų užtikrinta didžiausia verslo vertė.
Programinėje įrangoje team produkto savininkas glaudžiai bendradarbiauja su naudotojais, UX dizaineriai, pardavėjai ir palaikymo specialistai, kad suformuotų naudotojo istorijas pagal INVEST kriterijus (nepriklausomas, sutartinis, vertingas, įkainojamas, nedidelis, išbandomas). Jie apibrėžia priėmimo kriterijus ir supranta, kaip funkcijos veikia aukšto lygio architektūrą.
Konkretaus produkto savininko pareigos:
Vienas produkto savininkas kiekvienam produktui padeda išvengti prieštaringų "scrum" kūrimo krypčių team. Net kai padeda verslo analitikai, galutinius sprendimus dėl atsilikimo priima produkto savininkas. Kai projektų valdymas kelioms team, dirbančioms su bendru produktu, produkto savininkas išlieka prieinamas team nariams sprinto metu, koordinuodamas visų komponentų veiklą.
Scrum Master veikia kaip team treneris, padedantis jiems laikytis "scrum" proceso, šalinantis kliūtis ir palengvinantis team narių bendradarbiavimą. Šis tarnaujančio lyderio vaidmuo sutelkia dėmesį į tai, kad team suteikia galimybę, o ne vadovauja jų darbui. Scrum Master taip pat palengvina "Scrum" darbą, įskaitant planavimą, kasdienius pasitarimus ir produkto prieaugio pristatymą, užtikrindamas, kad ši bendradarbiavimo veikla būtų gerai organizuota ir sinchronizuota pagal "Scrum" sistemą.
Dažniausiai pasitaikančios programinės įrangos inžinerijos kliūtys, kurias padeda išspręsti Scrum Master:
Scrum Master bendradarbiauja su vadovybe, siekdamas pagerinti organizacinę struktūrą ir kultūrą, kad team galėtų veiksmingai organizuoti savo veiklą. Jie apsaugo team nuo apimties šliaužimo sprinto metu ir užtikrina, kad tokie renginiai kaip kasdieniai "scrum" susirinkimai, sprinto peržiūra ir sprinto retrospektyva išliktų tikslingi, o ne tušti ritualai.
Priešingi modeliai, kurių reikia vengti: Scrum Master veikia kaip projektų vadovas skiria užduotis, atlieka tik susitikimų planuotojo funkciją arba tampa tarpininku, kuris apsaugo team nuo bendravimo su suinteresuotosiomis šalimis. Scrum Master turėtų mokyti team tiesiogiai bendrauti su šiais asmenimis, kartu pašalindamas sisteminius blokatorius.
Kūrimo grupė - tai savarankiškai organizuojama grupė, atsakinga už potencialiai išleidžiamos produkto dalies pristatymą kiekvieno sprinto pabaigoje, kurią paprastai sudaro nuo 5 iki 9 narių. Ją sudaro programinės įrangos kūrėjai, testeriai, DevOps inžinieriai, UX dizaineriai, duomenys inžinieriai - visi, kurie prisideda prie sprinto darbų sąrašo elementų kūrimo.
Kūrėjai kolektyviai planuoja, vertina ir vykdo. Jie sprendžia, kaip paversti produkto darbų sąrašo elementus veikiančia dalimi, atitinkančia sprinto tikslą. "Scrum" dėmesys savarankiškai valdomoms ir organizuojamoms team struktūroms skatina kūrybiškumą ir inovacijas, todėl team yra laimingesni ir produktyvesni.
Tarpfunkciniai įgūdžiai, padedantys sumažinti kliūtis:
praktika, pavyzdžiui, programavimas poromis, kodas peržiūros ir kūrimas pagal kamieną padeda kurti team kokybę kiekviename sprinte. Programuotojams tenka atsakomybė už atliktų darbų apibrėžimo laikymąsi ir sprinto darbų sąrašo atnaujinimą, kad būtų atspindėta reali pažanga. Kai kūrimo team kiekvieną sprintą pateikia naudingą produkto prieaugį, visa team įgyja pasitikėjimą jų nuspėjamumu.
"Scrum" turi tris pagrindinius artefaktus: produkto darbų žurnalą, sprinto darbų žurnalą ir prieaugį, kurie padeda apibrėžti produktą ir jam sukurti reikalingus darbus. Produkto darbų sąrašas ir sprinto darbų sąrašas iš esmės yra team darbų sąrašas, kuriame išsamiai aprašomos ir pagal prioritetus išdėstomos užduotys, kurias team turi atlikti kuriant produktą arba per kiekvieną sprintą. Šie Scrum artefaktai užtikrinti, kad "Scrum" team ir projekto suinteresuotosioms šalims būtų skaidrus darbas ir pažanga.
Kiekvienas artefaktas turi aiškų tikslą ir per sprintą nuolat tobulinamas. Kalbant apie programinę įrangą, artefaktai apima naudotojo istorijas, techninius reikalavimus, nefunkcinius reikalavimus, klaidų taisymus ir architektūrinius patobulinimus.
Gerai apibrėžta "Atlikto" apibrėžtis užtikrina, kad pakopos būtų tikrai išleidžiamos - kodas sujungiamas, išbandomas, dokumentuojamas ir įdiegiamas bent jau į stadijos aplinką. Šiuolaikinės priemonės, tokios kaip "Jira", Azure DevOps, ir Linear palaiko šiuos artefaktus lentomis, darbo eigomis ir ataskaitomis, nepaverčiant "Scrum" griežtu procesu.
Artefaktų skaidrumo užtikrinimas skatina tikslią patikrą "Scrum" renginių metu. Kai visi mato tą pačią informaciją, kasdieniai "scrum" ir sprinto peržiūros pokalbiai yra pagrįsti realybe, o ne prielaidomis.
Produktų sąrašas - tai dinamiškas funkcijų, reikalavimų, patobulinimų ir pataisymų sąrašas, kurį produkto savininkas tvarko ir nustato prioritetus, siekdamas maksimaliai padidinti vertę klientui. Tai yra viso produkto team darbų sąrašas, sudaromas pagal verslo vertę, investicijų grąžą, riziką ir priklausomybes.
Programinėje įrangoje tipiniai atsilikimo elementų formatai yra šie:
Reguliariose tobulinimo sesijose (apie 10% team pajėgumų) team nariai ir produkto savininkas kartu aptaria būsimus elementus, padalina dideles epines dalis ir papildo technines detales. Sveikame produkto darbų sąraše yra gerai patikslintų elementų bent 1-2 artimiausiems sprintams, todėl galima sklandžiai planuoti būsimus sprintus.
Sprinto darbų sąrašas - tai kūrimo grupės team atrinktų elementų, kuriuos reikia įgyvendinti per einamąjį sprintą, sąrašas, kuris sprinto metu gali keistis, tačiau turi būti išlaikytas pagrindinis sprinto tikslas. Jį sudaro atrinkti produktų sąrašo elementai ir jų įgyvendinimo planas.
Sprinto planavimo metu kūrėjai suskirsto pasirinktus elementus į užduotis:
Sprinto darbų sąrašą turi ir atnaujina kūrėjai. Jame atsispindi realiuoju laiku pasiekta pažanga, kliūtys ir bet kokie su produkto savininku suderinti pakeitimai. Apimties pokyčiai per dabartinis sprinto ciklas leidžiama tik tuo atveju, jei jie nekelia pavojaus sprinto tikslui arba neviršija team pajėgumų.
Sprinto tikslo pavyzdys: “Įgalinti naudotojų registraciją per OAuth2 naujiems mobiliesiems klientams.” Visi sprinto darbų sąrašo punktai turėtų būti suderinti su šiuo tikslu, kad visi vienodai suprastų prioritetus.
Inkrementas, taip pat žinomas kaip sprinto tikslas, yra sprinto galutinis produktas, kuris turi atitikti team apibrėžtį, kad būtų laikomas užbaigtu. Tai visų užbaigtų darbų sąrašo elementų suma, sudaranti potencialiai išleidžiamą versiją sprinto pabaigoje.
Programinės įrangos team apibrėžimas "Atlikta" gali būti toks:
| Kategorija | Kriterijai |
|---|---|
| Kodo kokybė | 80%+ vieneto testų aprėptis, praeinantys linter patikrinimus |
| Peržiūrėkite | Patvirtinta tarpusavio kodo peržiūra, saugumo patikra atlikta |
| Testavimas | Integracijos testai įveikiami, našumo kriterijai įvykdyti |
| Dokumentacija | Atnaujinti API dokumentai, README aktuali |
| Įdiegimas | Įdiegta į etapinį diegimą, sukonfigūruoti stebėjimo kabliukai |
Inkrementas demonstruojamas per sprinto peržiūrą, kurios metu suinteresuotosios šalys testuoja funkcionalumą ir nuolat teikia grįžtamąjį ryšį, kuris gali pakeisti produktų sąrašą. "Scrum" sumažina projekto nesėkmės riziką, nes reguliariai pateikiami maži veikiantys programinės įrangos vienetai. Inkrementas gali būti išleistas bet kurio sprinto metu arba po jo, kai produkto savininkas nustato pakankamą verslo vertę ir priimtiną techninę riziką.
Penki pagrindiniai "Scrum" renginiai - "Sprintas", "Sprinto planavimas", "Kasdienis "Scrum", "Sprinto peržiūra" ir "Sprinto retrospektyva" - struktūruoja team laiką ir užtikrina reguliarų tikrinimą bei pritaikymą. Laiko ribojimas "Scrum" įvykiuose padeda sutelkti dėmesį, mažina švaistymą ir užtikrina ritmą, griežtai ribodamas susirinkimų ir sprintų trukmę.
Įprastas 2 savaičių sprinto laikas:
Programinės įrangos inžinerijoje šie įvykiai glaudžiai susiję su išleidimais, kodo įšaldymu ir integracijos testavimo ciklais. Komandos turėtų eksperimentuoti su darbotvarkės formatais, tačiau vengti praleisti renginius arba paversti juos projektų vadovų statuso susirinkimais.
"Backlog" tikslinimas - tai pasikartojanti darbo sesija (dažnai kartą per savaitę), kurios metu produkto savininkas ir programuotojai aiškinasi, skirsto, vertina ir keičia prioritetus. Šia veikla parengiami būsimų sprintų elementai, kad sprinto planavimo renginio metu būtų galima sutelkti dėmesį į atranką ir įsipareigojimą, o ne į atradimą.
Tobulinimo veiklos pavyzdžiai:
Patikslinimas anksti atskleidžia riziką, todėl architektūros klausimus galima aptarti dar prieš įsipareigojant sprintui. Laikykitės sesijų laiko ribų - ne daugiau kaip 10% team pajėgumų, kad išvengtumėte nesibaigiančio analizės paralyžiaus.
Sprinto planavimas - tai susitikimas, kuriame visa kūrimo grupė planuoja darbus, kurie bus atliekami per einamąjį sprintą, nustatomas sprinto tikslas ir pasirenkami elementai iš produkto darbų sąrašo. Jame atsakoma, ką galima pristatyti ir kaip bus atliekamas darbas.
Pagrindiniai sprinto planavimo veiksmai:
Konkrečios programinės įrangos pavyzdžiai - planavimas integruoti trečiosios šalies mokėjimo API, duomenų bazės versijos atnaujinimas mažo lankomumo metu arba naujos funkcijos vėliavos paleidimas A/B bandymams. team pateikia team aiškias gaires, kaip atrodo sprinto sėkmė.
Kasdienis "Scrum", dar vadinamas "stand-up", yra trumpas susitikimas, vykstantis kiekvieną sprinto dieną, skirtas patikrinti pažangą siekiant sprinto tikslo ir nustatyti kliūtis. Jis trunka griežtai 15 minučių, vyksta kiekvieną darbo dieną tuo pačiu metu.
Kasdienis "Scrum" susirinkimas skatina atvirą team narių bendravimą, leidžiantį jiems aptarti pažangą, planuoti dienos darbus ir įvardyti kliūtis, su kuriomis jie susiduria. Tai nėra būsenos ataskaita Scrum Master - tai kūrėjų tarpusavio sinchronizacija.
Veiksmingos užuominos, neapsiribojančios klasikiniais trimis klausimais:
Praktiniai patarimai: vizualizuokite darbą lentoje, apsiribokite detalių problemų sprendimu ir jas aptarkite tik po kasdienių "scrum" diskusijų. Nuoseklūs kasdieniai "scrums" padeda anksti nustatyti integracijos problemas, kūrimo klaidas ir priklausomybės riziką. Sprintas team siekti tikslo, kasdien prižiūrint, kad visi būtų suderinti.
Kiekvieno sprinto pabaigoje rengiama sprinto peržiūra, kurios metu team suinteresuotosioms šalims parodo atliktą darbą ir pateikia atsiliepimus, kurie gali turėti įtakos kito sprinto planavimui. Pagrindinis artefaktas yra veikianti programinė įranga - venkite skaidrių lentelių, pakeičiančių realias demonstracijas.
Konkretūs grįžtamojo ryšio pavyzdžiai:
"Scrum" užtikrina greitą grįžtamąjį ryšį, leidžiantį koreguoti, atsižvelgiant į funkcijos veikimą vėlesniuose sprintuose. Remdamasis šia grįžtamąja informacija, produkto savininkas atnaujina produktų sąrašą. Įprastinis 2 savaičių sprinto laikas - iki 2 valandų. Skatinkite neformalias, interaktyvias diskusijas, o ne formalius pristatymus, kurie neleidžia užduoti klausimų.
Sprinto retrospektyva - tai sprinto pabaigoje vykstantis susitikimas, kuriame team apmąsto praėjusį sprintą ir aptaria, kas pavyko gerai ir ką būtų galima patobulinti būsimiems sprintams. Tai vidinė "Scrum" team veikla, kurioje daugiausia dėmesio skiriama žmonėms, santykiams, procesui, priemonėms ir "Done" apibrėžčiai.
Gerai veikiantys struktūrizuoti formatai:
"Scrum" didina team bendradarbiavimą ir produktyvumą, nes kasdien rengiami pasitarimai ir sprinto retrospektyvos skatina bendravimą. Rezultatai turėtų apimti konkrečius tobulinimo veiksmus, suplanuotus ateinančiuose sprintuose - įvesti porinį programavimą rizikingiems moduliams, automatizuoti tam tikrus regresijos testus arba pakoreguoti "Atlikta" apibrėžtį.
Svarbus psichologinis saugumas: team sąžiningai atspindi nesėkmes, techninius įsiskolinimus ir procesų spragas be kaltinimų. Reguliarus praeities retrospektyvos rezultatų peržiūrėjimas leidžia nuolat tobulėti, o ne kartoti problemas.
Penkios "Scrum" vertybės, kuriomis vadovaujamasi kasdienėje veikloje: įsipareigojimas, drąsa, susitelkimas, atvirumas ir pagarba. Tai nėra abstraktūs idealai - jos daro tiesioginę įtaką techniniams sprendimams, bendravimo modeliams ir reagavimui į incidentus.
"Scrum" sistema skatina skaidrumą, kuris stiprina pasitikėjimą tarp team, produkto savininko ir suinteresuotųjų šalių, gerina bendradarbiavimą ir bendravimą. Vertybės siejasi su scrum renginiais: atvirumas per kasdienius scrumus, pagarba ir drąsa per retrospektyvas, įsipareigojimas ir susitelkimas planuojant ir vykdant sprintą.
Kai team spaudžia terminai, nuo verčių priklauso, ar bus sumažinti kampai, ar problemos iškils į paviršių. "Scrum" skatina bendradarbiavimo kultūrą, skatindama team narius dirbti kartu, dalytis žiniomis ir padėti vieni kitiems siekti sprinto tikslų.
Komandos turėtų periodiškai peržiūrėti, kaip joms sekasi įgyvendinti šias vertybes, ir nustatyti kultūrinius pokyčius, reikalingus šioms vertybėms stiprinti. Scrum team efektyvumas priklauso nuo to, ar vertybės yra praktikuojamos, o ne tik deklaruojamos.
Įsipareigojimas reiškia, kad kiekvienas būrelio narys prisiima atsakomybę už sprinto tikslą, o ne tik už atskiras užduotis. Tai taip pat reiškia, kad reikia vengti pernelyg didelio įsipareigojimo dėl nerealios apimties, nes tai lemia team nesėkmę.
Dėmesį remia:
Dėmesio apsaugos pavyzdžiai - ad hoc užklausų mažinimas sprinto metu ir tvaraus tempo palaikymas (vengiant nuolatinių viršvalandžių). Susitelkimą matuokite paprastais rodikliais: WIP limitai ir neplanuoto darbo procentinė dalis per sprintą. Scrum team geriausiai veikia, kai yra apsaugotas nuo nuolatinių trukdžių.
Drąsa reiškia, kad reikia atskleisti techninę riziką, pripažinti klaidas (pvz., klaidingą diegimą) ir užginčyti nerealius terminus ar trumpesnius kelius, kurie kenkia kokybei. Programinės įrangos kūrėjai kurie jaučiasi saugūs ir anksti pastebi problemas.
Atvirumas reikalauja skaidraus bendravimo apie pažangą, trukdžius ir trūkumus. Tai padeda užtikrinti matomos lentos, bendri prietaisų skydeliai ir prieinami dokumentai. . "Scrum" vadovas pabrėžia, kad skaidrumas suteikia galimybę atlikti patikrinimus ir prisitaikyti.
Gerbkite visus vaidmenis - kūrėjus, testuotojus, Scrum Master, produkto savininką - pripažindami, kad kokybiškai programinei įrangai reikalingas bendradarbiavimas, o ne pavienių asmenų žygdarbiai. Pagarbi kodo peržiūra užtikrina konstruktyvų grįžtamąjį ryšį ir dalijimąsi žiniomis. Tarpusavio team integracijos darbui naudingas teigiamas ketinimas.
Šios vertybės sukuria aplinką, kurioje klesti nuolatinis tobulėjimas ir inovacijos, o tai yra labai svarbu, kad projekto sėkmė sudėtingoje programinės įrangos inžinerijoje.
"Scrum" naudoja laiko ribas atitinkančius sprintus, fiksuotus vaidmenis ir apibrėžtus įvykius. Kanban akcentuoja nenutrūkstamą srautą, WIP limitus, nenustatytus vaidmenis ir terminus. Kiekvienas metodas tinka skirtingoms aplinkybėms.
| Aspektas | Scrum | Kanban |
|---|---|---|
| Iteracijos | Fiksuoti sprintai (1-4 savaitės) | Nenutrūkstamas srautas |
| Vaidmenys | PO, SM, kūrėjai | Nenustatyta |
| Planavimas | Sprinto planavimo sesijos | Pagal pareikalavimą |
| Pakeitimai | Pageidautina tarp sprintų | Bet kuriuo metu |
| Geriausiai tinka | Funkcijų kūrimas | Operacijos, techninė priežiūra, palaikymas |
Hibridiniai metodai, tokie kaip "Scrumban" ar "Kanplan", sujungia struktūrizuotą sprinto planavimą ir peržiūrą su "Kanban" stiliaus srautais ir WIP apribojimais. A produktų komanda galbūt naudoja "Scrum" naujų funkcijų kūrimui, o papildoma pagalbinė priemonė team naudoja "Kanban" gamybos incidentams tvarkyti, su bendru matomumu visose valdybose.
Pasirinkite arba sumaišykite sistemas pagal team dydį, gaunamų darbų nepastovumą ir išleidimo nuspėjamumo poreikį. "Scrum" praktika tinka, kai suinteresuotosioms šalims reikia reguliariai demonstruoti rezultatus; "Kanban" tinka, kai darbai gaunami nenuspėjamai.
"Scrum" suteikia aiškią naudą - greitesnį grįžtamąjį ryšį, geresnį suderinamumą su klientais ir geresnį pristatymo nuspėjamumą, tačiau kyla sunkumų, kai ji neteisingai suprantama arba blogai įgyvendinama. Sėkmingam sprinto užbaigimui reikia ir sistemos supratimo, ir organizacinio palaikymo.
Dėl trumpų sprintų ir reguliaraus derinimo "Scrum" leidžia team greitai reaguoti į naujus reikalavimus ir pokyčius, todėl nuolat įtraukiamas grįžtamasis ryšys. Kokybė gerėja dėl to, kad testavimas, kodo peržiūra ir nuolatinė integracija įtraukiami į sprinto darbo eigą, o ne laikomi atskiru etapu.
Naudingos "agile" metrikos projektų valdymas sistemos stebėjimas:
Sprinto apžvalgos ir dažni išleidimai didina klientų pasitenkinimą, nes parodo pažangą ir leidžia klientams daryti įtaką veiksmų planui. Retrospektyvų metu rodiklius naudokite kaip mokymosi priemones, o ne kaip veiklos tikslus, kuriais galima žaisti.
Kai kurie teigia, kad naudojant "Scrum" padidėja 200-400% našumas, o apklausos rodo 95% laiku pristatytų darbų rodiklius, kai jie tinkamai įgyvendinami. Tačiau "Scrum" iššūkių gali kilti dėl masto didinimo problemų, neplanuoto darbo, neaiškių prioritetų ir standartų trūkumo, o tai gali trukdyti efektyviam įgyvendinimui. Apie 58% "Scrum" diegimo sunkumų kyla dėl prasto mokymo.
"Scrum" poveikis organizacinei struktūrai dažnai reiškia, kad vietoj laikinų projektų team formuojamos ilgalaikės tarpfunkcinės produkto team. Tyrimai rodo, kad ilgalaikės produkto team grupės padidina darbuotojų išlaikymą maždaug 30%.
Norint išplėsti iki kelių team, reikia:
Dėl fiksuoto "Scrum" sprintų laiko kartais gali būti pamiršti svarbūs projekto aspektai, nes per ribotą laiką gali būti įgyvendinti ne visi reikalavimai. Siekiant užkirsti kelią techninėms skoloms kauptis, reikia skirti apie 20% pajėgumų.
Plėskite palaipsniui: pradėkite nuo vieno ar dviejų team, nuodugniai išmokite "Scrum", tada išplėskite praktiką. Didelės pertvarkos paprastai būna sudėtingos. Inžinieriams team naudingas instruktavimas ir bandomasis diegimas, kuris parodo sėkmę prieš pradedant taikyti plačiau.
Ar esate pasirengę taikyti "Scrum"? Štai praktinė seka:
Iš pradžių naudokite minimalias priemones - pakanka paprastos lentos ir pagrindinio atsilikimo įrankio. Automatizuotas metrikų lenteles pridėkite tik tada, kai to reikia dėl konkrečių skaudžių vietų.
Investuokite į "scrum" team narių mokymus, ypač į Scrum Master ir produkto savininko vaidmenis. Prieš priimdami svarbius procesinius sprendimus, pradėkite nuo bandomojo projekto, vykdydami bent 3-4 sprintus. Retrospektyvos nuo pat pirmojo sprinto leidžia nuolat tobulėti, atsižvelgiant į jūsų team kontekstą ir produkto poreikius.
Projektų valdymas naudojant "Scrum" reikalauja kantrybės. Išmokite "Scrum" pagrindų, nuosekliai praktikuokitės ir prisitaikykite pagal tai, ką pastebėjote.
Dauguma programinės įrangos team pasirenka 1-4 savaičių sprinto trukmę, o 2026 m. dažniausiai pasirenkamos 2 savaitės, nes taip suderinamas grįžtamojo ryšio greitis ir planavimo išlaidos. Rinkdamiesi atsižvelkite į diegimo dažnumą, suinteresuotųjų šalių galimybes dalyvauti peržiūrose ir tipinį reikšmingų prieaugių dydį.
Nustatę sprinto trukmę išlaikykite stabilią. Po kelių sprintų persvarstykite tik tada, jei yra aiškių įrodymų, kad kitokia trukmė pagerintų rezultatus. Komandos, turinčios greitesnių diegimo galimybių, kartais naudoja 1 savaitės sprintus; komandos, turinčios sudėtingų integracijos poreikių, gali rinktis 3-4 savaičių sprintus.
Scrum gali būti pritaikytas funkcijų kūrimui ir techninei priežiūrai, tačiau dideliam nenuspėjamo operatyvinio darbo kiekiui geriau tinka "Kanban" arba mišrus modelis. Apsvarstykite galimybę kiekvieną sprintą rezervuoti fiksuotą team talpos buferį (15-20%) neplanuotiems darbams.
Rotuojamas budintis inžinierius, sprendžiantis skubius klausimus, gali apsaugoti likusius team sprinto įsipareigojimus. Kad ir kokį metodą naudotumėte, išsaugokite aiškų sprinto tikslą, o ne nuolat trikdykite įsipareigotą darbą.
Specialus Scrum Master idealiai tinka, ypač mokantis "Scrum" arba dirbant sudėtingoje aplinkoje. Mažesnėse organizacijose vienas Scrum Master gali aptarnauti 2-3 team arba team narys gali prisiimti atsakomybę ne visą darbo dieną, tačiau tam reikia disciplinos.
Jei vaidmuo per daug išskaidomas, team grįžta prie senų įpročių ir praranda "Scrum" naudą. Siekiant pagerinti team veiklą, Scrum Master trenerio, kliūčių šalinimo ir palengvinimo pareigos nusipelno realaus laiko ir dėmesio.
Techninės skolos ir architektūriniai patobulinimai turėtų būti aiškiai įtraukti į produktų sąrašą ir jiems turėtų būti teikiamas prioritetas kartu su funkcijomis. Daugelis team 15-30% sprinto pajėgumų skiria pertvarkymui, našumo derinimui ir infrastruktūros atnaujinimui.
Techninių skolų ignoravimas lėtina būsimus sprintus ir mažina kokybę. Produkto savininkas ir programuotojai turi glaudžiai bendradarbiauti, kad suderintų naujas funkcijas ir techninę būklę. Padarykite skolą matomą, įvertinkite jos poveikį ir palaipsniui spręskite ją per kitą sprintą ir vėliau.
Įprastos įrankių kategorijos yra šios:
Įrankiai turėtų padėti kurti matomus atsilikimo planus, aiškius sprinto planus ir skaidrius rodiklius, tačiau patys neturėtų tapti dėmesio centre. Pradėkite nuo paprastų priemonių, o sudėtingumą didinkite tik tada, kai jos padės išspręsti konkrečius skaudulius jūsų "Scrum" procese. Scrum modelis nenurodo konkrečių įrankių - team pasirenka tai, kas tinka jų kontekstui.
Lithuanian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Spanish 
Dutch 
Estonian 
Greek 
Portuguese 
Czech 
Latvian 
Icelandic