Antaŭparolo

Mi uzas la vorton «Hack» en la nobla senco de la termino. La plej ofte akceptita traduko estas «bricolado», do tre malproksime de la kapuĉulo malantaŭ ekrano, sur kiu defilas amaso da verdaj linioj sur nigra fono. Mi do klarigos al vi la nekonvencian uzon, kiun mi faras de la laborfluoj de Jira. Se vi pensis trovi ruzon por fariĝi super-administranto de la instanco … daŭrigu vian vojon.

Kunteksto

Jira estas neprezinda ilo en la mondo de projekt-administrado. Ĝi sukcesis establiĝi kiel la referenco en multaj fakoj. Kaj tio estas merita! Fleksebla, laŭbezone agordebla, fidinda, tre bone ekipita (raportoj, grafikaĵoj, kromprogramoj, konektiloj, …). Ĝi povas rapide fariĝi la nemalhavebla kunulo de tuta organizo por la sekvado de ĝiaj aktivaĵoj. Vera panoptika kontrolturo.
Tamen, frustra punkto, kiun mi ofte renkontis en teamoj, estas la devigo de la laborfluoj. Kiam oni skaligas la produkton, oni forte tentiĝas voli harmonieigi kaj minimume kontroli ĝian uzadon. Oni povas trovi avantagojn, sed ofte koste de la kreado de decidaj kaj administraj instancoj, kiuj neeviteble peziĝas. 🤢

La infero estas la fluoj.

Ne maloftas trovi en Jira laborfluojn, kiuj postulis semajnojn, eĉ monatojn da laboro de multaj homoj por interkonsenti pri io kontentiga. Oni tiam alfrontas aĵojn kiel tio 😱:

Fonto: https://abhilashshukla.com/business/best-practices/jira-workflow-for-software-development-and-quality-analyst-qa-teams/

Mi ne ĵetas la ŝtonon kontraŭ ili, ĉar tio kongruas kun ilia pensoskemo kaj Jira forte favoras tian solvon. Mi mem cedis al tiu facilo kiam oni petis min starigi teamojn. Sed fine, mi rapide alfrontis plurajn limigojn, kiuj igis min grumbli kontraŭ la ilo.

• Komplekseco de starigo
• Rigideco de la procezo
• Manko da aliĝo de la teamoj
• Troa normigo
• Tempovora administrado
• …

Oni sciu, ke potenciale ĉiu projekto en Jira povas tre bone havi sian propran laborfluon, siajn proprajn biletospecojn, siajn proprajn prioritatojn, sian propran administradon de rajtoj kaj profiloj, ktp. La kontraŭparto estas pli kompleksa administrado por ĉiu projekto kaj, por tiuj, kiuj gastigas sian propran instancon, tipe grandaj klientoj, la rendimento forte malboniĝas. Neizite, antaŭ tiuj limigoj, precipe la lasta, oni entreprenas grandan penon je harmonieigo, sed precipe je limigo. Kio perdigas la plimulton de la antaŭe cititaj avantagoj.

Mia vizio

Mi ne diras, ke mia vizio estas la plej bona, sed post uzo kaj misuzo de la eblecoj de tiu ilo, mi ĉiam revenas al io pli simpla kaj adaptebla. Post la x-a plendo pri la starigitaj fluoj, mi prenis momenton da meditado por provi kompreni, kial tiu tiom promesplena ilo estas tiom malŝatata, kaj ĉu oni povus renversi la situacion. Kaj tiam mi rememoris la unuan el la valoroj de la agila manifesto:

Individuoj kaj iliaj interagoj pli ol procezoj kaj iloj

Kaj jen precize la problemo: oni igis Jira la alfo kaj omego de projekt-administrado. Ĉio, aŭ preskaŭ, devas esti registrita, notita, priskribita, klarigita en ĝi. Ĉio tio por akiri belajn grafikaĵojn, kiuj ornamos la sprint-reviziojn. Por perfektigi tiun sekvadon, la laborfluoj estas nemalhaveblaj, kun la tempo-atributado, la devigitaj (do sensignifaj) komentoj, la multnombraj propraj kampoj, ktp.
Trudi laborfluon al teamo estas, iusence, signo, ke oni ne fidas ĝin pri la sekvado de la procezoj. Oni infanigas ĝin pri la administrado de la vivciklo de la biletoj. Oni do iras kontraŭ la bona praktiko de responsigitaj, memadministrantaj teamoj.

Estas necese reveni al la esenco de tiu ilo, kiu permesas al ni ne perdiĝi en la progreso de la produkto, sen ornamaĵoj, simple (KISS), flue. Sed por tio oni devas fari radikan rompon en ĝia uzado, kaj la laborfluoj estas en la antaŭa linio. Do ni faru la aferojn ĝuste! Ni tute eksplodigu tiujn malbenitajn fluojn! 🤯

1-a ideo

Ĝi estas tre simpla starige kaj uze. Ĝi uzas kaj tro uzas la transiron «Toutes» («Ĉiuj») 😈

Ĝi estas speciala transiro en Jira. Ĝi ne havas precizan originon, sed malfermas la eblon atingi la celitan paŝon el kiu ajn punkto de la laborfluo. Tre utila por atendaj aŭ nuligaj statoj, ĉar ĝi povas okazi je kiu ajn momento.
Nu, ĉio ripozas sur tiu eco! Ni metu amason da statoj ĉiam atingeblaj el kiu ajn punkto de tiu ne-laborfluo!

La rezulto estas, krom bagateloj, Trello (produkto de la sama eldonisto). 😜

Mi vidas plurajn avantaĝojn:

• Facilo de starigo (simpligita administrado)
• Evoluo sen efiko sur la ekzistanton (malantaŭa kongrueco)
• Agordo en Jira de unu sola flu-sistemo por ĉiuj teamoj (skaligo)
• Plena laŭprojekta personecigo de la fluoj per la tasktabulo (akcepteblo)

Sed ĝi ankaŭ ne estas sen difektoj:

• Multaj senutilaj statoj, videblaj kaj atingeblaj
• Pli facila «perdo» de biletoj, se ne mapitaj en la kolumnoj.
• Transira menuo en la detalo de bileto treeege longa.

Persone, mi opinias, ke la pesilo forte klinas al la flanko de la avantaĝoj.
Tre entuziasmiĝinta pri tiu ideo kaj lastatempe katapultita kiel respondeculo pri la praktikoj de Jira en mia tasko, mi rondiris ĉe la estroj por vendi mian ideon. Diru ke tio ne vekis troan entuziasmon 😅
Ĉe la administrantoj de Jira, ili estis singardemaj pri la ideo, ĉar ĝi tute eliris el la kadro. Ĉe la estroj, oni afable rememorigis min, ke tamen oni devas eltiri iujn metrikojn el Jira kaj ke iuj paŝoj devas esti neeviteblaj por havi iom da fidindaj datumoj.

2-a provo

Mi do reiris al mia desegnotabulo por kontentigi kiel eble plej bone ĉiujn tiujn partoprenantojn.
Post sufiĉe multa returnado kaj turmentado de la fasonilo de Jira, mi fine sukcesis akiri ion konvinkan kaj respondan al la postuloj de ĉiuj.

NB: se linio ne havas sagon, ĝi estas dudirekta

En tiu fluo estas 4+1 neeviteblaj paŝoj: Backlog, Todo, Doing, Done + Canceled. Tiu lasta stato estas iom aparta, ĉar ĝi estas garaĝvojo sen granda intereso por nia temo. La 4 ĉefaj paŝoj estas ĉiuj atingeblaj per la transiro «Toutes», do oni povas tute bone pasi de Backlog al Done, eĉ se tio ne estas la celo.
Oni klare vidas la dividon de tiu fluo en 3 apartajn partojn, kaj la paso de unu al alia el tiuj partoj povas okazi nur per niaj 4 nemalhaveblaj paŝoj. En ĉiu sekcio oni ankaŭ rimarkas, ke ĉiuj paŝoj estas interligitaj dudirekte. Kio signifas, ke el kiu ajn stato de sekcio oni povas pasi al kiu ajn alia stato de la sama tipo. Oni simulas, kiel eble plej multe, la transiron «Toutes», limigante tiun eblon al sekcio de la fluo.
Por do pasi de unu stata tipo al alia, oni ja estas devigita pasi tra unu el niaj 4 esencaj paŝoj … celo atingita.

• Pri avantaĝoj, oni reprenas idente tiujn de la unua ideo kaj, pro la devo pasi tra iuj paŝoj, oni plibonigas la fidindecon de la mezurado kaj de la statistikoj.
• Pri malavantaĝoj, oni senteble malpliigas la longon de la transira menuo en la detalo de la biletoj; ankaŭ la nombro de atingeblaj statoj estas iom pli limigita.

Do fine, oni ne vere perdas kaj neniu vere havis ion por riproĉi. Do la meto en produktadon estis akceptita sen tro da peno.

Uzado

Vide, por la ĉiutaga uzado, tio aspektas jene:

Ne plu estas limigo pri la movado de la biletoj kaj, interesa detalo, en la kolumno «Terminé» oni havas la statojn «Done» kaj «Canceled» bone identeblaj. Estas interesa kromefiko de tio, ke oni igis tiujn du statojn ĉiam atingeblaj: ne eblas plu meti biletojn en la staton «Canceled» erare.
En la pli klasikaj fluoj, la stato «Canceled» ofte havas la transiron «Toutes», dum la «Done» estis atingebla nur per la devigita vojo. Do kiam oni volis fini bileton en stato, kiu normale ne povis atingi ĝin KAJ la stato «Canceled» estis mapita en tiu sama kolumno, la kolumno estis tamen atingebla, sed ne por la supozita stato … kaj mi ofte retrovis erare forlasitajn biletojn.
Kun mia solvo, tio ne plu eblas.

Aliaj rimarkindaj ŝanĝoj

Prioritatoj

Defaŭlta konduto de Jira, kiu ŝajnas al mi misgvida, estas la defaŭlta poziciigo de la biletoj je «Medium / Moyen» dum ilia kreado. Kiel distingi inter la ĵus kreitaj biletoj, eble kun prioritato ankoraŭ ne fiksita, kaj tiuj vere je tiu nivelo? Mi do modifigis la prioritatan sistemon jene, integrante valoron «Not prioritized / Non priorisé» kiel la defaŭltan valoron.

En si, nenio revolucia, sed bonvena eta ĝustigo.

Subteno

Mi konsideras la subtenajn biletojn ĉe la rando de la projekto kaj ili povas esti objekto de aparta kaj pli taŭga laborfluo. Kial mi diras «rando de la projekto»? Ĉar la homoj, kiuj povus krei bileton de tiu tipo, ne nepre apartenas al la teamo, ili ne nepre kutimas uzi tiun ilon, kaj oni do devas faciligi ilian taskon kiel eble plej multe gvidante ilin maksimume. Do, en tiu kazo, neniel eblas lasi ilin ŝanĝi la staton de la bileto tro libere.

Sperto-raporto

Post kelkaj semajnoj da metado sur pilota projekto, mi ne havis multajn ĝustigojn farendajn. Du statoj je la realiga nivelo, aŭtomatismoj sur la transiroj, sed nenio pli. Iomete reklaminte tiun fluon, aliaj projektoj petis pasi al ĝi … poste ĝi fariĝis la referenca fluo por la programo, kio forte instigis la aliajn projektojn pasi al ĝi.
Ankoraŭ kelkaj semajnoj pasis kaj la tuto de la projektoj estas kontenta. Lastatempe mi ankaŭ parolis pri ĝi ekster la programo kaj iuj homoj aspektis interesitaj, kio estas kuraĝiga por la estonteco. Interesa afero: la projektoj, vidante ke oni povis vere adapti la ilon por fari ĝin pli agrabla, venis peti min pri aliaj modifoj. Ekzemple, la tro multnombraj kampoj kun dubinda utileco.

Konkludo

Denove, mi ne scias, ĉu tio, kion mi starigis, taŭgos por via situacio. En mia kazo, mi estas kontenta kaj la teamoj ŝajnas ankaŭ esti, do kial sin senigi 😁.
Ne hezitu doni al mi vian opinion, se vi inspiriĝis de la ĉi tie prezentitaj fluoj; mi tre ĝojus priparoli tion vive 😄.