Scrum
Scrum ir veiklais ietvars, kas palīdz komandām risināt sarežģītu darbu īsos, iteratīvos ciklos, izmantojot fiksētas lomas, notikumus un artefaktus.
Scrum ir veiklais ietvars sarežģītu produktu izstrādei un vadīšanai, kas sākotnēji izveidojies programmatūras izstrādē un tagad tiek izmantots daudzās nozarēs. Tā pamatā ir empīriskās procesu kontroles ideja: tā vietā, lai uzdevumu no sākuma līdz beigām pilnībā izplānotu jau iepriekš, komanda strādā īsos, fiksētos laika logos, ko sauc par sprintiem, parasti no vienas līdz četrām nedēļām. Katrs sprints beidzas ar lietojamu darba pieaugumu, kas rada telpu atgriezeniskajai saitei un ļauj komandai pielāgot savus nākamos soļus. Šī caurredzamības, pārbaudes un pielāgošanās kombinācija Scrum padara piemērotu darbam, kur prasības ir neskaidras vai var mainīties.
Scrum nosaka trīs fiksētas lomas. Product owner atbild par produkta vērtību un uztur product backlog, prioritizētu sarakstu ar visu, kas jāpaveic. Scrum master rūpējas, lai komanda strādātu ietvara robežās, novērš šķēršļus un veicina sadarbību, nesadalot uzdevumus tieši. Izstrādes komanda pati plāno un veic darbu. Četri atkārtoti notikumi katram sprintam dod struktūru: sprinta plānošana sākumā, daily scrum ātrai saskaņošanai, sprinta pārskats (sprint review), lai parādītu paveikto, un sprinta retrospektīva, lai uzlabotu komandas sadarbības veidu.
Scrum vislabāk darbojas uzdevumiem, kuros apjoms vai risinājums sākumā nav pilnībā skaidrs, piemēram, produktu izstrādei vai sarežģītiem projektiem ar daudziem iesaistītajiem. Tas no Kanban atšķiras ar fiksētiem laika logiem un noteiktām lomām, kamēr Kanban vairāk balstās uz nepārtrauktu plūsmu bez fiksētām iterācijām. Salīdzinājumā ar klasisko ūdenskrituma plānošanu tā priekšrocība ir regulāra pārbaude: nepareizi vērtējumi atklājas agri, nevis tikai projekta beigās. Praksē Scrum bieži cieš neveiksmi nevis ietvara dēļ, bet gan pusvirziena izpildes dēļ, piemēram, kad retrospektīvas tiek izlaistas vai backlog netiek uzturēts.
Praktisks piemers
Vidēja lieluma mašīnbūves uzņēmums izstrādā jaunu programmatūru sava ražošanas aprīkojuma uzraudzībai. Piecu cilvēku komanda strādā divu nedēļu sprintos: katra sprinta sākumā tā no aptuveni 40 atvērtajiem backlog ierakstiem izvēlas desmit svarīgākos, sinhronizējoties katru dienu 15 minūšu garā daily scrum sanāksmē. Pēc desmit sprintiem, piecu mēnešu laikā, ir gatava pirmā lietojamā versija, nevis deviņu mēnešu izstrāde bez starprezultāta, ko komanda sākotnēji bija plānojusi. Retrospektīvas atklāj, ka neskaidras prasības pirmo trīs sprintu laikā komandai izmaksāja aptuveni 20 procentus tās jaudas, tāpēc product owner no tā brīža sāk rakstīt precīzākus backlog aprakstus.
Ka Leanshift palīdz
Sprinta retrospektīva savā būtībā ir tikai atkārtots Kaizen cikls: komanda apstājas, godīgi paskatās uz tikko pabeigto darbu un apzināti uzlabo savu darba veidu, pirms virzās tālāk. Tas saskan ar Leanshift skatījumu, ka uzlabošana nav vienreizējs projekts, bet gan regulārs ieradums, kas iestrādāts ikdienas darbā. Komandas, kas šādi dzīvo, ne tikai uzlabo produktu, tās veido vairāk cilvēku, kas paši prot uzlabot lietas.
Bieži uzdotie jautajumi
Vai Scrum noder tikai programmatūras izstrādei?
Nē. Scrum sākās programmatūras jomā, taču tagad tiek izmantots mārketingā, produktu izstrādē, izglītībā un citās jomās, visur, kur darbs ir sarežģīts un prasības var mainīties gaitā.
Kā Scrum atšķiras no Kanban?
Scrum darbojas fiksētos laika logos, ko sauc par sprintiem, ar noteiktām lomām un notikumiem, savukārt Kanban vizualizē nepārtrauktu darba plūsmu bez fiksētām iterācijām un fokusējas uz nepabeigtā darba apjoma ierobežošanu.
Vai mazai komandai patiešām vajadzīgs atsevišķs scrum master?
Ne obligāti kā pilnas slodzes loma. Mazās komandās to bieži uzņemas kāds papildus savam parastajam darbam; svarīgi, lai facilitēšana un pats ietvars faktiski tiktu ievērots.