Home | Blog | Guide

Vipimo vya Uhandisi Bila Jira

Huhitaji Jira kupima mambo yanayomaanisha. Jifunze jinsi ya kufuatilia afya ya uhandisi kutoka Git, CI, na zana ambazo timu yako tayari inatumia.

By Ellis Keane · 2026-03-23

Timu ndogo ambazo zinapata uonekano bora wa uhandisi kwa kawaida ni zile ambazo ziliamua kuacha kufuatilia vipimo ambavyo Jira inataka zifuatilie.

Najua hii inasikika kama kupingana tu kwa sababu ya kupingana – na kwa uaminifu, labda kidogo ndiyo hivyo. Lakini nilitumia karibu miaka mitatu nikisimamia kwa uaminifu ubao wa spriinti, kusafisha backlog, na kusasisha makadirio ya tiketi ambazo tayari zilikuwa zimemalizika nusu kabla mtu yeyote hajafungua Jira asubuhi hiyo. Kila wiki mbili, tulikaa pamoja (kwenye Zoom – ilikuwa 2023) na kuangalia chati ya kasi ambayo haikutuambia chochote ambacho hatukujua tayari kutoka kwa mazungumzo yetu. Vipimo vya uhandisi bila Jira haikuwa kitu nilichokuwa nikitafuta. Ndiyo kilichotokea nilipoacha kujifanya kuwa chati za kasi zilikuwa zikinieleza chochote muhimu.

Kama timu yako ni ndogo ya kutosha kukaa mezani moja, labda huhitaji Jira kujua unavyofanya. Unahitaji ishara bora kutoka kwa zana ambazo tayari unatumia.

Hii si makala inayosema "Jira ni mbaya". Jira ni zana nzuri kwa mashirika yanayohitaji ufuatiliaji wa aina ya Jira (na kwa kiwango fulani, wanauhitaji kweli kweli). Lakini kama wewe ni meneja wa uhandisi katika kampuni ndogo ya watu 10 hadi 40 na unalipa Jira tu ili kuzalisha chati za kasi, ni kama kununua tanuri ya viwanda ili joto upya chakula chako cha mchana.

"Kulipa Jira tu kuzalisha chati za kasi ni kama kununua tanuri ya viwanda ili joto upya chakula chako cha mchana." – Chris Calo

Vipimo vya Jira hupima nini hasa

Niwe wazi: vipimo vingi vya Jira hupima matumizi ya Jira, si matokeo ya uhandisi. Pointi za hadithi hupima uwezo wa timu wa kukadiria pointi za hadithi. Kasi hupima jinsi timu inavyojaza spriinti hadi karibu na uwezo sawa. Chati za burndown hupima kama mtu alikumbuka kukokota tiketi kwenye ubao alasiri ya Alhamisi.

Hakuna mojawapo ya hizi inayokuwa bure kabisa. Lakini hizi ni vipimo vya mchakato vilivyovikwa kama vipimo vya tija ya wasanidi programu – na pengo hilo ndilo ambapo wasimamizi wa uhandisi hupoteza mwelekeo.

Nilikuwa EM ambaye alitumia karibu saa moja kabla ya mkutano na wadau akiunda data ya Jira katika uwasilishaji unaoonyesha "tuko kwenye njia sahihi". Mdau anaashiria, anauliza swali moja kuhusu hitilafu ya kuingia ya Jumanne iliyopita, na mkutano unaisha. Saa ile ilikuwa kwa uwasilishaji. Jibu halisi lilikuwa "mwulize mhandisi".

Kama vipimo vyako vinahitaji matengenezo zaidi kuliko kazi inayopimwa, vipimo ndivyo tatizo.

Muda wa mzunguko kutoka Git, si kutoka kwa ubao wa kazi

Kwa timu ndogo za bidhaa, muda wa mzunguko kwa kawaida ni kipimo chenye ishara ya juu zaidi unachoweza kufuatilia. Hupima muda kutoka commit ya kwanza hadi usambazaji wa uzalishaji, na unaweza kutokana nao kabisa kutoka historia ya Git na mtiririko wa kazi wa CI – bila ubao wa kazi unaohitajika.

Sehemu:

Muhuri wa wakati wa commit ya kwanza kwenye tawi au PR
Muhuri wa wakati wa kuunganisha PR
Muhuri wa wakati wa usambazaji (kutoka CI/CD yako – GitHub Actions, CircleCI, au unachokimbia)

Tofauti kati ya 1 na 3 ni muda wako wa mzunguko. Igawanye katika sehemu – muda wa uandishi (1 hadi PR kufunguliwa), muda wa mapitio (PR kufunguliwa hadi kuunganishwa), na foleni ya usambazaji (kuunganishwa hadi uzalishaji) – nawe una chombo cha uchunguzi kinachokwambia wapi kazi inasimama hasa.

Nilipoifanya hii kwa timu yetu kwa mara ya kwanza, nambari zilikuwa za kushangaza kweli. Nilidhani muda wa mapitio ulikuwa kikwazo chetu (kila mtu daima anadhani muda wa mapitio ni kikwazo, sivyo?). Inabadilika kuwa awamu ya uandishi hadi PR ilikuwa sawa, mapitio yalikuwa sawa, na tulikuwa tunapoteza wastani wa siku mbili kati ya kuunganisha na kusambaza kwa sababu mazingira yetu ya staging yalikuwa ya msongo na hakuna aliyepewa kipaumbele kuirekebisha. Chati ya kasi haingaliwahi kuonyesha hilo.

Jinsi ya kupima

Kama uko kwenye GitHub, unaweza kuchomoa hii na CLI:

```bash

Pata PR zilizounganishwa kwa siku 30 zilizopita

gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```

Kwa muhuri wa wakati wa usambazaji, mifumo mingi ya CI inauweka wazi kupitia API au webhook. Ramani SHA za kuunganisha PR kwa matukio ya usambazaji, nawe una muda wa mzunguko uliosegmentwa kwa awamu.

Kidokezo: Kama CI yako haifichui muhuri wa wakati wa usambazaji kwa uwazi, njia rahisi kabisa ni bot ya Slack inayochapisha kwenye kituo cha #deploys na SHA ya commit. Unapata muhuri wa wakati, kumbukumbu inayosomeka na binadamu, na – kama athari ya ziada – kituo kinachokwambia mara ngapi unasambaza.

Uwezo wa mapitio ya msimbo

Uwezo wa mapitio – idadi ya PR zilizokaguliwa kwa mhandisi kwa wiki, na muda wa kati kutoka kufungua PR hadi mapitio ya kwanza – unakuambia zaidi kuhusu afya ya timu kuliko kipimo chochote cha spriinti. Imepuuzwa.

Kwa nini? Kwa sababu tabia ya mapitio ni kiashiria cha mapema. Wakati nyakati za mapitio zinapoanza kupanda, kwa kawaida inamaanisha wasanifu wana mzigo mzito, wanabadilisha muktadha mara nyingi sana, au – na hii ndiyo inayokera – wanakimbia msimbo wa kila mmoja. Yoyote kati ya hizi inastahili kujulikana kabla ya kuonekana kama muda uliopita wiki mbili baadaye.

GitHub inakupa data hii kupitia API yake. Sehemu muhimu ni createdAt kwenye PR na submittedAt kwenye tukio la kwanza la mapitio.

Nambari ninayoangalia ni saa za kati hadi mapitio ya kwanza. Kwa uzoefu wetu katika timu chache ndogo, mzunguko wa afya wa mapitio kwa kawaida hukaa chini ya saa 8. Inapopita siku kwa mfululizo, kitu cha kimuundo kimebadilika – na chochote kile, haionekani kwenye Jira.

Uwiano wa mikutano kwa maamuzi

Hii si kipimo cha jadi cha uhandisi, na niwe wazi: ni heuristic ya takriban, si KPI. Lakini kwa timu ndogo, nimekuta inafunua mambo ya kushangaza.

Hesabu mikutano ambayo timu yako ilikuwa nayo wiki hii. Hesabu maamuzi mahususi yaliyotokana nayo (si "tunapaswa kuchunguza X" – maamuzi halisi na wenye umiliki na hatua za mwisho). Gawanya ya pili kwa ya kwanza.

Kama chini ya nusu ya mikutano yako ilitoa uamuzi, inastahili kuuliza kama mikutano hiyo inajibu muda wake. Mikutano mingine ipo kupunguza hatari au kushiriki muktadha, na hiyo ni halali – si kila kitu kinahitaji kuisha na azimio. Lakini unapoanza kufuatilia hii hata kwa njia isiyo rasmi (niliweka kumbukumbu kweli kweli kwenye daftari langu), unakuza hisia ya ni mikutano ipi inayozalisha na ipi ni mila tu ambayo hakuna aliyeihoji.

Nilifuatilia hii kwa karibu mwezi mmoja, na ilibadilisha jinsi nilivyopanga mikutano zaidi ya makala yoyote ya tija. Unapoweza kuona kwamba standup yako ya Jumatatu imetoa maamuzi sifuri kwa wiki tatu mfululizo, kuifuta kunaacha kuhisi kali.

Kujenga vipimo vya uhandisi bila Jira: dashibodi nyepesi

Huhitaji zana ya BI kwa hili. Ukurasa wa Notion, lahajedwali la Google, au chapisho la kila wiki la Slack na nambari nne inatosha:

Muda wa kati wa mzunguko (kutoka Git/CI) – tunasambaza haraka zaidi au polepole zaidi?
Muda wa kati hadi mapitio ya kwanza (kutoka GitHub) – je, timu inakagua kwa wakati?
Mara ngapi tunasambaza (kutoka CI au kituo cha #deploys) – tunasambaza mara ngapi?
Uwiano wa mikutano kwa maamuzi (hesabu ya mkono) – mikutano yetu inastahili?

Nambari nne, zote zinazoweza kutokana na zana unazomiliki tayari, hakuna inayohitaji kudumisha ubao wa Jira. Sasisha kila wiki. Kama nambari inaenda katika mwelekeo mbaya kwa wiki mbili mfululizo, chunguza. Kama inabaki imara, iache.

Lengo si kujenga mfumo wa ufuatiliaji (tafadhali usifanye – wasanifu wako watakuchukia, na watakuwa sahihi). Uonekanu wa timu ya uhandisi unapaswa kutoka kwa kazi yenyewe, si kwa kuwauliza watu kutoa taarifa kuhusu kazi.

Vipimo bora vya uhandisi ni vya bei nafuu kukusanya, vigumu kudanganya, na vinakuambia kitu unachoweza kutenda. Pointi za hadithi zinashindwa katika viwango vyote vitatu.

Unapohitaji kweli kweli ubao wa kazi

Nilisema hii si makala inayosema "Jira ni mbaya" – na nilimaanisha hivyo. Kuna hali halali ambapo kufuatilia vipimo bila zana ya usimamizi wa mradi inakuwa ya kutowajibika kweli kweli:

Sekta zenye mahitaji mazito ya utiifu ambapo nyaraka za ukaguzi wa hali ya kazi zinahitajika kisheria
Mashirika makubwa ya uhandisi ambapo utegemezi wa timu mbalimbali hufanya uratibu usio rasmi kuwa hauwezekani
Mashirika yenye kazi maalum za usimamizi wa mradi ambayo yanahitaji chanzo kimoja cha ukweli kote katika timu

Kama hiyo ndiyo hali yako, Jira (au Linear, au Shortcut) ndiyo chaguo sahihi. Ninachohoji ni kwamba kwa timu ndogo, kudumisha zana nzito kwa ajili ya vipimo peke yake ni biashara mbaya. Unakuwa ukiboresha kwa ajili ya mfano wa kazi wa zana badala ya kazi halisi ya timu yako.

Na kwa uaminifu? Hata timu zinazotumia Jira zingenufaika kwa kuongeza data ya ubao wao na vipimo vilivyotokana na Git vilivyoelezwa hapo juu. Jira inakuambia kile watu wanachosema wanafanya. Git inakuambia wanachofanya hasa. Vyote viwili ni vya manufaa, lakini ni kimoja tu ambacho hakizuiiwi na mchezo wa masasisho ya hali.

Kama swali la vipimo linaendelea kutokea katika kampuni yako, jaribu dashibodi ya nambari nne kwa mwezi. Vipimo vya uhandisi bila Jira vinaweza kusikika kama kwenda bila wavu wa usalama – lakini ukiona ni ishara ngapi zinazoishi katika historia yako ya Git na mtiririko wa kazi wa CI, utashangaa ubao wa kazi ulikuwa unaongeza nini.

Gundua muda wa mzunguko, PR zilizosimama, na vikwazo vya mapitio moja kwa moja – bila hati maalum au ubao wa Jira.

Q: Je, unaweza kupata vipimo vya uhandisi vyenye maana bila zana ya usimamizi wa mradi? A: Ndiyo. Muda wa mzunguko (kutoka commit ya kwanza hadi usambazaji), uwezo wa mapitio, na mara ngapi unasambaza – vyote vipo katika historia ya Git na mtiririko wa kazi wa CI. Kwa timu za chini ya wasanifu 40, kwa kawaida hivi ni vikali zaidi na vigumu kudanganya kuliko chochote kinachozalishwa na ubao wa kazi – na havihitaji mtu kukokota kadi kwenye ubao ili kubaki sahihi.

Q: Je, Sugarbug inaonyesha vipimo vya uhandisi moja kwa moja? A: Sugarbug inaunganika na GitHub, Linear, Slack, na kalenda kujenga grafu ya maarifa ya shughuli za timu yako. Inabainisha mifumo kama PR zilizosimama, vikwazo vya mapitio, na maamuzi ambayo hayakutatuliwa – ambayo inashughulikia ishara nyingi zilizoelezwa hapa bila kuhitaji uandike na kudumisha hati maalum dhidi ya API ya GitHub.

Q: Jinsi ya kupata idhini ya kuacha kutumia Jira kwa vipimo? A: Iwasilishe kama jaribio, si uasi. Endesha vipimo vilivyotokana na Git pamoja na dashibodi zako zilizopo za Jira kwa wiki nne, kisha ulinganishe ni nambari zipi zilizosababisha mabadiliko halisi. Kama vipimo vya Git vitakuwa zaidi ya vitendekaji (na kwa uzoefu wetu, kwa kawaida ni hivyo), hoja inajengeka yenyewe.

Q: Ni nini tofauti kati ya vipimo vya mchakato na vipimo vya utendaji? A: Vipimo vya mchakato (pointi za hadithi, kasi, burndown) hupima jinsi timu inavyofuata mtiririko wa kazi kwa usawa. Vipimo vya utendaji (muda wa mzunguko, mara ngapi unasambaza, uwezo wa mapitio) hupima kile timu kinachosambazwa hasa na kwa kasi gani. Timu ndogo karibu daima hupata ishara zaidi kutoka kwa vipimo vya pili, kwa sababu vipimo vya utendaji vinatokana na kazi yenyewe badala ya masasisho ya hali ya mkono.