Kjo përmbajtje është vetëm për abonentët
Elementet e Scrumit
Përmbledhje Libri
Hyrje
Çfarë ka në këtë libër për mua?
Bëhuni i shkathët, fleksibil, dhe mësoni se si Scrum-i do t’iu ndihmojë të punoni më mirë!
A mendoni se e keni metodën më të mirë për organizimin e një projekti? Është një gabim klasik, sidomos në zhvillimin e softverit. Çdo ekip ka parapëlqimet dhe kërkesat e veta: dizjanuesit e duan në një mënyrë, koduesit në një tjetër-dhe në këtë kaos, klienti mbetet jashtë në të ftohtë.
Puna është se nuk egziston ndonjë procedurë e caktuar, një rrugë perfekte nga A-ja tek Z-ja në zhvillimin e produkteve të mira softverike. Por egzistojnë disa truqe që do t’iu bëjnë punën sa më perfekte që është e mundur.
Ekipet e sotme duhet të jenë fleksibile dhe të shkathëta, gati për t’i kaluar ankesat dhe sfidat që ju shfaqen në rrugë. Prandaj, ju duhet të bëni një plan, pastaj ta hidhni atë anash, për ta ndërtuar një tjetër në ajër, derisa i mbani sytë në qëllimin tuaj përfundimtar.
Si e bëni këtë? Hidhni ato metoda ujëvare dhe përqafojeni Scrum-in-një sistem fleksibil, i shkathët që do t’iu ndryshojë mënyrën si mendoni dhe procesin tuaj zhvillimor.
Në këto pulsime do të mësoni:
- Pse ujëvarat në ditët e sotme vetëm do t’iu lagin;
- Si një takim 15-minutësh është bileta juaj për sukses; dhe
- Pse shumë vrapime janë shumë më efikase sesa një vrapim i gjatë, i ngadalshëm.
Ideja kyçe 1
Metodat tradicionale të zhvillimit të softverit janë joefikase dhe shpiejnë në tejkalime.
Tradita mund ta ketë sharmin e saj, por kur është në pyetje zhvillimi teknologjik, aty ka shumë pak fansa. Teknologjia ka nevojë të rifreskohet në mënyrë konstante për të mbetur e përshtatshme; në fakt, të qenit aktual është qenësore, jo vetëm për teknologjinë, por poashtu për proceset që përdoren për krijimin e saj.
Një sistem zhvillimi quhet metoda ujëvarë, i cili është një proces ‘’prej fillimit në fund’’ për prodhimin e softverit. Në një sistem të tillë, një ekip softveri zakonisht përpilon kërkesa, bën dizajne, shkruan, dizajnon, teston, dhe pastaj dërgon një produkt të përfunduar.
Aspekti ‘’prej fillimi në fund’’ i procesit është kyç. Aktiviteti A duhet të plotësohet para se të fillojë puna në aktivitetin B.Për shembull, nuk mund të filloni testimin e një dizajni para se ta përfundoni kodin.
Por mund t’iu lind pyetje: pse njerëzit dhe organizatat e pëlqejnë këtë metodë?
Duke ndarë çdo hap të tillë zhvillimor, planifikimi dhe caktimi i orarit lehtësohet. Menagjerët shpesh preferojnë një qasje ujëvare ngaqë besojnë se ju mundëson saktësi më e madhe në orare dhe shpërndarje të bugjeteve.
Por metoda ujëvarë nuk është shumë e besueshme. Softveri shpesh është një produkt shumë i komplikuar për t’u dizajnuar plotësisht para se të fillojë prodhimi. Prandaj, nëse kërkoni një produkt të dizajnuar në mënyrë perfekte, do të mbeteni me pak hapësirë për të ndryshuar gjatë prodhimit.
Prandaj, derisa është e mundur që një dizajn perfekt të kalojë pa probleme në një proces perfekt prodhimi, kjo zakonisht ndodh vetëm kur prodhoni një projekt statik, sikurse vetura. Në këtë shembull, ju do të dizajnoni çdo element në veturë, pastaj mund t’i ndiqni udhëzimet e dizajnit në letër gjatë prodhimit.
Por prodhimi i softverit, në anën tjetër, është thjesht shumë i ndërlikuar.
Pra, ndërsa dizajnerët mund të dalin me atë që ata mendojnë se është një produkt i përsosur, komplikimet sigurisht që do të lindin kur të aplikohen dizajnet. Numrat tregojnë përrallën: vetëm 16 për qind e projekteve të metodës së ujëvarës përmbushin afatet e përfundimit, ndërsa 31 për qind anulohen dhe 53 për qind kalojnë buxhetin!
Si të shmangni një kurth të tillë në projektet tuaja? Lexoni për të mësuar më shumë.
Ideja kyçe 2
Nje proces i shkathët ka të njëjtit përbërës si një proces ujëvarë, por ju jep më shumë fleksibilitet.
Në tregun me ritëm të shpejtë dhe shpesh të paparashikueshëm, ju duhet të jeni fleksibil për ta përshtatur procesin e zhvillimit tuaj shpejtë. Kjo nënkupton pengimin e një elementi projekti, duke e mbajtur një tjetër.
Por si mund ta mbani trenin e zhvillimit në lëvizje?
E zgjidhni një proces të shkathët-një strategji zhvillimore që e përqafon ndryshimin si një mundësi për rritje.
Ekipet e shkathta funksionojnë shumë në të njëjtën mënyrë, sikurse që funksionojnë ato që përdorin një proces ujëvarë: ato mbledhin kërkesa, bëjnë dizajne, shkruajnë kode, teste dhe dërgojnë produkt. Gjëja që ato nuk e bëjnë është të presin që çdo hap të përfundohet para se të fillojnë në tjetrin.
Në vend të kësaj, ekipet e shkathta punojnë hap pas hapi, duke dërguar pjesë produkti një klienti. Ekipi e përsërit këtë proces, kohë pas kohe, derisa të përfundohet produkti. Ky cikël quhet përsëritje.
Le të mendojmë për një ekip zhvillimor softverik të editimit të fotografive. Duke përdorur një proces të shkathët, ekipi mundet fillimisht të përfundojë një veqori që ndryshon ngjyrën e fotos në bardhë e zi. Ekipi do ta dërgojë këtë veqori të vogël tek klienti i cili do të jepë koment.Ekipi pastaj do të mund të punonte në përmirësimin e veqorisë bazuar në komentet e përsëritjes tjetër.
Por mos mendoni që proceset e shkathëta janë thjesht ujëvara ‘’të vogla’’; ato janë plotësisht të integruara në procese. Kjo nënkupton se ekipet e shkathëta e trajtojnë çdo projekt si një njësi të plotë dhe jo si pjesë të ndara, siq bëjnë ekipet kur punojnë në proces ‘’prej fillimi ne fund’’.
Kështu, një ekip i shkathtë sigurohet që dizajnerët dhe koderët mendojnë për kontributet e tyre si plotësuese për njëra-tjetrën-në vend që të mendojnë vetëm për ‘’pjesën e tyre’’ dhe duke injoruar pjesën tjetër.
Egziston një tjetër dallim në mes të proceseve ujëvara dhe të shkathëta. Në një proces ujëvarë, klienti i ofron kërkesat e softverit të tij kur fillon projekti, dhe nuk konsultohet përsëri derisa të dërgohet produkti. Por me një proces të shkathtë, ekipi vazhdimisht ndërhyn me klientin gjatë procesit, duke bërë të mundur ndryshimin e kërkesave në ndërkohë.
Ideja kyçe 3
Katër vlerat kryesore të shkathtësisë e shtrojnë rrugën për një proces efikas, efektiv dhe të suksesshëm.
Imagjinoni sikur jeni duke ecur përgjatë rrugës tuaj të zakonshme, kur e shihni që një aksident po e bllokon rrethin para jush. Çfarë bëni? A do të prisni që aksidenti të kalojë apo ta lëni një rrugë të panjohur për ta eksploruar një mënyrë të re?
Nëse ktheheni dhe eksploroni ju tashmë e keni një prej katër vlerave kyqe të shkathtësisë. Çdo vlerë përfaqëson një prioritet, apo një zgjidhje në mes të qasjeve të ndryshme.
Vlera e parë e shkathtësisë është prioritizimi i individëve dhe ndërveprimeve mbi proceset dhe mjetet. Kjo nënkupton se njerëzit e përfshirë në një projekt janë më të rëndësishëm se procesi i udhëheqjes së projektit.
Kryesisht, mjetet dhe proceset duhet t’iu shërbejnë njerëzve dhe jo e kundërta.
Vlera e dytë është ti prioritizoni softverin funksional mbi dokumentimin e thellësishëm. Sigurisht, dokumentacioni është me rëndësi, por nuk duhet ta mbizotërojë vetë produktin. Prandaj nëse keni presion në kohë, fokusojeni gjithë energjinë në krijimin e një produkti të mirë, dhe mos u djersitni duke marrë qindra dokumente fotosh.
Vlera e tretë është ta prioritizoni bashkëpunimin konsumator mbi negocimin e kontatës. Është qenësore që marrëveshja kontraktuese në mes të ekipit zhvillimor dhe klientit të mbetet e hapur. Vetëm duke bërë kështu mund të siguroheni që të prodhoni dhe dërgoni atë që konsumatori po kërkon vërtetë.
Ekipet e shkathët mbajnë takime të rregullta dhe mbajnë komunikim të hapur në çdo përsëritje. Ndërsa kontratat janë të rëndësishme, ato nuk sigurojnë që standardet e cilësisë së klientit të respektohen – por komunikimi i hapur dhe i rrjedhshëm do të respektohet.
Dhe në fund, vlera e katërt e prioritizon përgjigjen ndaj ndryshimit mbi ndjekjen e një plani. Plani tregon se e dini ku doni të shkoni dhe si të mbërrini atje; por nëse ka një ndryshim të papritur (sikurse një aksident trafiku), do të ju duhet të jeni edhe fleksibil edhe të shkathët për t’u përshtatur dhe për t’i arritur qëllimet në kohë.
Kur jeni të vërtetë ndaj katër vlerave të shkathtësisë, ju do të jeni në gjendje të vendosni prioritete projekti edhe të përshtatshme edhe efikase.
Ideja kyçe 4
Scrum-i është një sistem që mishëron shkathtësi përmes një procesi të fokusuar zhvillimi.
Tani që i dini vlerat e shkathtësisë, do të ju duhet një sistem në të cilin mund ti zbatoni ato-dhe këtu do t’iu ndihmojë Scrum-i.
Por çfarë është saktësisht ‘’Scrum’’?
SCRUM-i është një proces i zhvillimit të softuerit që aplikon katër vlerat e shkathtësisë për të ndërtuar produkte të reja përmes një seri sprints – me secilën seri që përmban çdo hap të procesit të zhvillimit, nga kërkimet e hulumtimit deri tek dorëzimi i produktit tek klienti.
Brenda çdo sprinti mund të trajtoni vetëm një pjesë të vogël të projektit tuaj të madh, që mund të nënkuptojë se një periudhë sprinti mund të marrë pak kohë aq sa një javë dhe mund të marrë kohë më të gjatë, sa gati një muaj.
Pra, si e filloni një sprint?
Sprintdo sprint vjen i gjallë në një takim të planifikimit të sprintit, i cili është i përbërë nga dy pjesë: e para përcakton se cilat janë dorëzimet e sprintit, dhe figurat e dyta se si t’i arrijnë ato.
Së pari zbuloni se çfarë i duhet ekipit tuaj të dërgojë në fund të sprintit. Kjo pjesë udhëhiqet nga pronari i produktit, anëtari i ekipit që vendos çfarë të ndërtojë dhe kur, bazuar në dëshirat e klientit tuaj.
Në shembullin tonë të softuerit për redaktimin e fotografive, pronari i produktit mund të thotë që ekipi do të bëjë një sprint në tiparin bardh e zi të produktit këtë javë, pastaj të përqendrohet në një veçori tjetër javën tjetër.
Pronari i produktit është poashtu përgjegjës për prezantimin e një përvojë ideale përdoruesi, e quajtur tregim (për këtë do të mësoni më shumë në pulsimin e radhës).
Sapo të jeni marrë vesh për pjesën e parë, pjesa e dytë e takimit të planifikimit të sprintit i kushtohet vendosjes se si do t’i arrijë ekipi qëllimet e tij.
Për ta bërë këtë, ekipi vendos detyra të caktuara, sikurse përpilimi i intervistave apo testimit të përdoruesit. Eshtë me rëndësi që asnjë detyrë nuk merr më gjatë se një gjysmë dite, prandaj detyrat e mëdha duhet të ndahen në detyra më të vogla.
Ideja kyçe 5
Sprintet kanë të bëjnë me përvojën dhe tregimet e përdoruesve tuaj.
Një aspekt kyç i çdo takimi të planifikimit të sprintit është të keni një përvojë të mrekullueshme përdoruesi. Por si e përfshijnë Scrumet këtë element në proces? Përmes tregimeve të përdoruesit.
Tregimet janë një mënyrë e thjeshtë përmes të cilës mund t’iu tregoni njerëzve si ta përdorin një produkt. Ato quhen tregime përdoruesish të cilat sigurohen që ekipi e mban vëmendjen e tij te konsumatori i fundit, dhe jo tek pronari i produktit, dizajneri apo koduesi.
Çdo tregim i përdoruesve ka tre përbërës: kush është përdoruesi target, cila është kërkesa e përdoruesit, dhe pse kërkesa e përdoruesit është e nevojshme.
Ja një shembull i tregimit: Si një (lloj përdoruesi) dua të (bëj diçka), ashtuqë të krijohet një vlerë e caktuar. Duke mbushur letrën e zbrazët, një ekip mund të vijë me: Si një përdorues i një telefoni të mençur me kamerë, dëshiroj që fotot që i bëj të editohen automatikisht nga softveri i telefonit për ta ruajtur kohën time.
Për të planifikuar një sprint të suksesshëm, ekipi duhet ta masë se sa e komplikuar-apo sa ‘’i madh’’ është’ një tregim. Sa më i madh tregimi, aq më e madhe është koha që nevojitet për ta zhvilluar. Për shembull, matja e gjithë procesit të blerjes së përdoruesit është një tregim i madh, që kërkon një muaj sprint, ndërsa zhvillimi i titujve të rinjë është një i vogël, të cilit i nevojitet një javë.
Pra si e matni madhësinë e një tregimi të një përdoruesi?
Një mënyrë është të fokusoheni në madhësinë relative të tregimit-që domethënë, sa e ‘’madhe’’ është në raport me tregimet tjera në projektin tuaj. Një tregim është në fund të fundit, një koncept abstrakt; nuk ka mënyrë për ta matur saktësisht sa ‘’e madhe’’ është.
Pra hidhuani një shikim projekteve dhe krahasoni tregimet e përdoruesve. Gjeni atë që mendoni se do të ishte tregimi ‘’më i vogël’’, dhe pastaj matni tregimet tjera kundrejt më të voglit.
Mundeni madje edhe të gjeni një sistem të veqantë numërimi si mjet reference për ekipin tuaj, për t’i identifikuar shpejtë tregimet e mëdha nga ato të voglat. Për shembull, nëse një sprint për ridizajnimin e titujve është më i vogli në listen e projekteve tuaja, do të mund ta matnit procesin e blerjes së sprintit si ‘’ridizajnime me katër koka’’.
Ideja kyçe 6
Përfshini tri lloje të takimeve Scrum për ta siguruar reagimin dhe shkthtësinë e sprintit.
Pra ekipi juaj ka lansuar një projekt të ri, dhe të gjithë thonë se janë të qartë- në fushëveprim dhe në pritshmëri dhe është punë e madhe. Një muaj kalon, dhe ju mblidheni t’i ndani shënimet-dhe pastaj fillojnë problemet.
Tre anëtarë ekipi i kanë përfunduar detyrat e tyre, dy kanë ngecur duke përsiatur një problem dhe s’mund ta përfundojnë, dhe njëri e ka marrë mbi vete ta ndryshojë detyrën e tij në një mënyrë që e bën lëmsh jetën e çdokujt.
A tingëllon kjo e njohur:
Metoda Scrum përdor tri lloje të takimeve për ta shmangur këtë lloj situate.
Së pari, një Scrum ditor i identifikon ndryshimet ashtu siq ndodhin në ‘’kohë reale’’.Është një takim shumë i shkurtër, ditor, i dizajnuar për ta mbajtur ekipin tuaj në hap duke identifikuar pengesat në atë mënyrë që të mund t’i adresojnë atë menjëherë.
Një Scrum ditor duhet të mbahet në të njejtën kohë çdo ditë-për maksimum 15 minuta-dhe vetëm anëtarët e ekimit duhet të jenë të pranishëm.
Në takim, çdo anëtar ekipi ndan atë që ka arritur një ditë më përpara, atë që do ta trajtojnë sot dhe pengesat e rrugëve që mund të jenë duke e zvogëluar progresin.
Një tjetër lloj takimi është rishqyrtimi i sprintit, i mbajtur në fund të çdo sprinti që klientët të ofrojnë koment. Këtu ekipi juaj mund ta tregojë punën e tij tek klienti; prandaj sigurohuni që pronari i produktit dhe anëtarët e tjerë të ekipit të marrin shënime për reagimet e klientit.
Përgjigja e klientit e len pronarin e produktit ta rregullojë produktin rezervë- një list të artikujve për t’u bërë që rangohen sipas prioritetit.
Tipi i fundit është takimi retrospektiv. Këtu ti dhe ekipi juaj mund të shikoni pas në sprintin e përfunduar dhe të diskutoni gjithqka që të gjithë kanë mësuar.Ky takim duhet të mbahet pas çdo shqyrtimi të sprintit, në ditën e njëjtë që është përfunduar sprinti.
Gjatë këtij takimi, ekipi juaj duhet të reflektojë poashtu se si ta aplikojë njohurinë e re në sprintin e ardhshëm. Për shembull, ekipi mund ta ketë të domosdoshme ndryshimin e procesit të testimit për ta bërë atë me efiqient.
Përmbledhja Finale
Mesazhi kyç në këtë libër:
Metodat tradicionale për menagjimin e zhvillimit softverik janë joefektive dhe jofleksibile. Në vend të përkufizimit të projektit, shkuarja në punë dhe të mos ndaloni deri të keni përfunduar, është esenciale t’i sjellni konsumatorët në proces herët dhe të kërkoni këshillë shpesh. Për ta krijuar kënaqësinë konsumatore që dëshironi, ju duhet një proces me shkathtësi dhe fleksibilitet për t’u adaptuar me ndonjë ndryshim. Ky proces është scrumi!
Këshillë vepruese:
Vendoseni projektin të parin.
Zhvillimi i softverit ka të bëjë me ndërtimin e një sistemi që e zgjedh një problem; dhe zgjidhja e një problemi ka të bëjë plotësisht me punën ekipore. Kjo sepse asnjë projekt softverik nuk kryhet ndonjëherë nga një individ i vetëm, pa marrë parasysh rolin e tij qendror. Në vend të kësaj, proceset zhvillimore mbështeten në punë ekipore për të gjetur zgjidhje dhe për t’i kaluar pengesat. Me fjalë të tjera, vendoseni projektin të parin, jo egon tuaj.
Sugjerohet lexim i mëtejshëm: ”Scrum” nga Jeff Sutherland
Mësoni gjithçka rreth ”Scrum-it”, sistemit të menaxhimit të projektit që ka revolucionarizuar industrinë e teknologjisë. Ky është një sistem unik adaptiv, fleksibël që lejon ekipet të planifikojnë në mënyrë reale dhe të rregullojnë qëllimet e tyre përmes reagimeve të vazhdueshme. Duke përdorur Scrum-in, ekipi juaj mund të përmirësojë produktivitetin e tyre (dhe rezultatin përfundimtar) pa krijuar stres të panevojshëm ose duke punuar me orë të gjata.
Keni komente?
Sigurisht që do të donim të dëgjonim se çfarë mendoni për përmbajtjen tonë! Thjesht dërgoni një email në [email protected] me titullin e këtij libri si temë dhe ndani mendimet tuaja!
