Kratka navodila za uporabo Gitlab

To navodilo je preneseno v Gitlab wiki: https://gitlab.maop.si/groups/maop/-/wikis

Navodila za sodelavce v Razvoju

Za bolj učinkovito delo ter boljšo komunikacijo znotraj ekipe in s stranko (posledično manj stresa in več zadovoljstva pri delu) si vsi prizadevamo čim bolj dosledno uporabo možnosti Gitlaba za profesionalno planiranje in izvedbo razvojnih nalog.

Spodaj navedena kratka navodila za uporabo Gitlaba bomo sproti optimirali in dopolnjevali glede na povratne informacije od ekipe.

Hvala vnaprej za vsak prispevek za izboljšanje – pošlji vodji Razvoja in/ali na kakovost@maop.si

Osnovno bližnjico Gitlaba si nastavim direktno na board, ki prikazuje moje naloge po statusih, na nivoju celotnega razvoja (primer linka – samo zamenjaj »???« s svojim uporabniškim imenom). Do seznama vseh mojih nalog lahko dostopam tudi preko ikone v glavi aplikacije, na desni strani.

Podrobno planiranje nalog (issue) v Gitlabu vodje projektov in projektanti izvajajo za naslednja dva tedna.

Naloge, ki morajo biti končane v naslednjih dveh tednih, naj bi imele:

1. • rok izvedbe in oceno dela (weight) v urah,
   • razdelitev na podtaske – to je koristen pripomoček za bolj učinkovito delo, ki pomaga tudi pri realni oceni potrebnega dela, hkrati pa je ogrodje za enostavno, sprotno poročanje že opravljenega dela na posamezni nalogi.

To velja tako za naloge, ki jih izvajam kot projektant ali kot programer. Več nedavnih študij programerskega dela je namreč pokazalo, da razčlenitev nalog na manjša, jasno definirana podopravila prinese več koristi za programerje, med drugim boljši fokus, zmanjšan stres, izboljšano produktivnost, boljše upravljanje časa.

Dokler posamezna naloga nima vpisanega roka, zanjo velja rok milestona oz. epika, v katerega je vključena. Izjema so naloge za neobvezne izboljšave, ki pa morajo imeti oznako »Prioriteta::nizka«.

Svojo nalogo dam v status »v izvedbi«, ko začnem delati na njej (s »povleci – spusti« v ustrezni stolpec na boardu). Nalog, ki so hkrati »v izvedbi«, naj ne bo preveč (npr. do pet; če na kakšni nalogi ne bom delal več dni, jo lahko vrnem nazaj v prvi stolpec na boardu – »Open«).

Vodje projektov lahko ročno razporejajo bolj prioritetne naloge na vrh seznamov v boardih, zato je obstoječi vrstni red nalog hkrati tudi navodilo glede prioritet oziroma vrstnega reda izvajanja.

Če kot izvajalec menim, da je treba naloge narediti po drugačnem vrstnem redu, ker bi bilo tako bolj optimalno, to uskladim z vodjo projekta in po dogovoru popravim prioriteto nalog na boardu (s »povleci – spusti«). Spremenjen vrstni red nalog naj bi bil samodejno ustrezno odražen na vseh boardih, ki jih uporabljamo, na seznamih nalog pa pod pogojem, če je sortiranje nastavljeno na »Manual« in »ascending«.

Če projektant za kakšno nalogo, ki mi je že dodeljena, ni vpisal podrobnejše razdelitve na podtaske in ocene dela, mi je s tem zaupal, da to naredim sam, ko se naloge lotim. Dodatna priporočila glede tega:

• • razgraditev posamezne naloge je običajno najbolj učinkovita v obliki enostavnih podtaskov v opisu naloge (alineje s kljukicami), saj jih pozneje samo s kljukanjem označujem kot dokončane in s tem hkrati vodjem poročam o napredku dela;
  • nova oblika samostojnih podtaskov (ki imajo večino lastnosti običajnih gitlab nalog) zahteva več administracije, poleg tega ne morejo biti prikazani na boardih, zato tam ne bo vidno, kdo je zaseden s temi podtaski; če je potrebna tovrstna dodatna razdelitev dela, jo je bolje narediti z več navadnimi nalogami (issue), ki se jih poveže z osnovno nalogo s funkcijo Linked items / Add.

Takoj po dokončanju programerske naloge jo prestavim v status »testiranje« (naloga analitika oz. testerja) ali v »pregled« (za peer review).

Če v Gitlabu nimam nalog vsaj za en teden naprej in ne morem sam pridobiti novih nalog, to čim prej javim nadrejenim (projektant, vodja projekta, vodja oddelka).

Za izboljšanje kakovosti in učinkovitosti spodbujamo občasno delo v parih (priporočljivo izven običajnega delovnega mesta v primerni prosti pisarni ali sejni sobi):

• • vodja projekta – projektant (za skupno planiranje in brainstorming pri načrtovanju izvedbe projekta),
  • dva projektanta (za peer review in brainstorming pri načrtovanju izvedbe aplikacije),
  • vodja Razvoja – projektant (za pregled plana razvoja in usklajevanje ekipe).

Tule je povezava do obstoječih, daljših navodil v Gitlabu. Če ima kdo težavo z uporabo Gitlaba (pravice za dostop itd), naj piše na gitlab.podpora@maop.si.

Hvala!

Navodila za sodelavce v Podpori

Za bolj učinkovito delo ter boljšo komunikacijo znotraj ekipe in s stranko (posledično manj stresa in več zadovoljstva pri delu) si vsi prizadevamo čim bolj dosledno uporabo možnosti Gitlaba za profesionalno planiranje in izvedbo nalog.

Spodaj navedena kratka navodila za uporabo Gitlaba bomo sproti optimirali in dopolnjevali glede na povratne informacije od ekipe.

Hvala vnaprej za vsak prispevek za izboljšanje – pošlji vodji ekipe in na kakovost@maop.si

Osnovno bližnjico Gitlaba si nastavim direktno na board, ki prikazuje moje naloge po statusih, na nivoju celotnega razvoja (primer linka – samo zamenjaj »???« na koncu linka s svojim uporabniškim imenom). Do seznama vseh mojih nalog lahko dostopam tudi preko ikone v glavi aplikacije, na desni strani.

Kot vodja projekta si nastavim vsaj še bližnjice do vseh nalog, ki sem jih izstavil: za skupni pregled na boardu na nivoju celotnega razvoja (primer linka), po potrebi pa za posamezne projekte še prilagojen board na nivoju projekta (pregled po statusih »Development«, pregled po izvajalcih »Developers«). Opomba: če se labele projekta dosledno uporabljajo na vseh nalogah, je možno preglede po projektu narediti tudi na nivoju celotnega razvoja, samo z dodatnim filtrom po ustrezni labeli.

Podrobno planiranje nalog (issue) v Gitlabu vodje projektov in projektanti izvajamo za naslednja dva tedna.

Vsaj tiste naloge, ki morajo biti končane v naslednjih dveh tednih, naj bi imele:

1. • rok izvedbe in oceno dela (weight) v urah,
   • razdelitev na podtaske – to je koristen pripomoček za bolj učinkovito delo, ki pomaga tudi pri realni oceni potrebnega dela, hkrati pa je ogrodje za enostavno, sprotno poročanje že opravljenega dela na posamezni nalogi (s kljukico za končan podtask).

Dokler posamezna naloga nima vpisanega roka, zanjo velja rok milestona oz. epika, v katerega je vključena. Izjema so naloge za neobvezne izboljšave, ki pa morajo imeti oznako »Prioriteta::nizka«.

Svojo nalogo dam v status »v izvedbi«, ko začnem delati na njej (s »povleci – spusti« v ustrezni stolpec na boardu).

Nalog, ki so hkrati »v izvedbi«, naj ne bo preveč (npr. do pet; če na kakšni nalogi ne bom delal več dni, jo lahko vrnem nazaj v prvi stolpec na boardu – »Open«). Smiselno je, da naloge na boardu vertikalno razporedim tako, da so na vrhu tiste, ki so najbolj prioritetne glede izvedbe.

Kot vodja projektov lahko ročno razporejam bolj prioritetne naloge na vrh seznamov v boardih tudi za druge izvajalce (s »povleci – spusti«), s čimer jim dajem navodilo glede vrstnega reda izvajanja. Spremenjen vrstni red nalog naj bi bil samodejno ustrezno odražen na vseh boardih, ki jih uporabljamo, na seznamih nalog pa pod pogojem, če je sortiranje nastavljeno na »Manual« in »ascending«.

Svoje naloge analize oz. načrtov izvedbe prestavim v status »pregled«, ko gre dokument v interno kontrolo, ki jo (običajno) dela projektant. Statusa »testiranje« in »verzija« pa pomenita, da dokument že čaka pri stranki na uskladitev oziroma na končno potrditev, po kateri se naloga analize oz. načrta izvedbe lahko zaključi.

Ena od mojih prednostnih nalog kot vodje projekta je, da skupaj s projektantom (skrbnikom aplikacije v Razvoju) tedensko obravnavam plan nalog projekta, ki morajo biti končane v naslednjih dveh tednih (to je hkrati priprava na standup sestanek ekipe projekta, ki je na ta način lahko bolj učinkovit in krajši). Moja naloga je tudi, da odprem in na koncu zaprem milestone za vsako zaključeno dobavo dograditve stranki (to je lahko ponudba ali skupna verzija izdelka z več manjšimi ponudbami) ter po potrebi epike (za manjše zaključene vsebinske sklope).

Zaradi preglednosti v Roadmap prikazu vsega aktualnega dela na firmi naj bi bilo v nazivu vsakega milestona ali epika tole, vključno z oklepaji:
[kratica stranke] [kratica produkta] [p.00xxxx oznaka ponudbe ali načrta izvedbe] + kratek opis

DODANO (1.12.2023): Roke izvedbe na vsakem milestone in epiku projektov, za katere sem zadolžen, sproti posodobim, čim se s stranko za izvedbo projekta dogovori nov rok.

Za izboljšanje kakovosti in učinkovitosti spodbujamo občasno delo v parih, npr.:

• • vodja projekta – projektant (za skupno planiranje in brainstorming pri načrtovanju izvedbe projekta),
  • dva projektanta (za peer review in brainstorming pri načrtovanju izvedbe aplikacije),
  • vodja Razvoja – projektant (za pregled plana razvoja in usklajevanje ekipe),
  • vodja PP – vodja projekta (za pregled plana projekta in usklajevanje projektov);

Priporočljivo je, da se sodelavca sestaneta izven običajnega delovnega mesta v primerni prosti pisarni ali sejni sobi.

Na sestanku Projektne pisarne in Razvoja izvajamo in spodbujamo dosledno uporabo Gitlaba, z vso potrebno pripravo:

• • vsak četrtek iz tajništva pošljejo po mailu spomnik vodjem projektov in projektantom za ažuriranje Gitlab nalog za prihodnja 1-2 tedna, kar je pomembno, da bodo v ponedeljek zjutraj te naloge uporabljene za usklajevanje med projekti;
  • vodja PP in vodja Razvoja se pripravita na tedenski sestanek svoje ekipe tako, da lahko med sestankom učinkovito uporabita pregled odprtih nalog v Gitlabu, tako da se lahko realno obravnava preobremenitve, po potrebi prerazporedi delo ali kako drugače ustrezno ukrepa;
  • tedenski sestanki ekip se uporabijo tudi za spodbujanje in utrjevanje dobre prakse pri uporabi Gitlaba.

Tule je povezava do obstoječih, daljših navodil v Gitlabu. Če ima kdo težavo z uporabo Gitlaba (pravice za dostop itd), naj piše na gitlab.podpora@maop.si.

Hvala!