Kahit na ang mga praktikal na kasanayan at kaalaman sa mga partikular na programming language, tool at teknolohiya ay ang susi para makakuha ng full-time na trabaho bilang software developer, may isa pang mahalagang indicator na sa maraming paraan ay maaaring tingnan bilang isang presupposition para sa tagumpay sa propesyon na ito: pagiging produktibo. Ang pagsukat sa pagiging produktibo ay isang bagay na kailangan ng lahat ng propesyonal na developer ng software na maunawaan at isaalang-alang dahil likas na mahalaga ang mga sukatan ng pagganap para sa alinmang software development team sa kapaligiran ng negosyo ngayon.
Bakit mahalaga ang iyong pagiging produktibo bilang isang developer?
Sa panahon ng Agile development, DevOps at lumiliit na mga ikot ng paglabas ng software, kapag kailangan ng mga developer na magpadala ng mga bagong bersyon ng mga produkto sa lalong madaling panahon, gumagamit ang mga kumpanya ng maraming iba't ibang sukatan ng produktibidad upang suriin ang performance ng mga indibidwal na programmer at isang team sa kabuuan. Kung titingnan ito mula sa pananaw ng isang developer, ang pagsukat ng pagganap ay maaaring maghatid ng maraming mahahalagang layunin, na tumutulong sa iyong subaybayan ang pag-unlad ng iyong mga kasanayan sa programming, na magbibigay-daan sa iyong makamit ang pare-parehong propesyonal na paglago. Ang mga mataas na produktibong coder ay ang mga nakakatanggap ng mga alok na nakakahulog sa suweldo at makapagtrabaho sa mga pinakakapana-panabik na proyekto. Ngunit kahit na hindi ka eksaktong isang high achiever at gusto mo lang ng anumang trabaho sa software development at maging makatwirang matagumpay dito, kailangan mo pa ring magkaroon ng hindi bababa sa isang pangunahing pag-unawa sa mga tagapagpahiwatig ng pagganap at kung paano ginagamit ang mga ito upang sukatin ang pagiging produktibo ng iyong input sa trabaho. Na kung ano ang pag-uusapan natin ngayon.
Mga sukatan ng pagsukat ng produktibidad sa pagbuo ng software
Ano ang mga sukatan ng pagiging produktibo sa pagbuo ng software?
Ang mga sukatan ng pag-develop ng software ay ang mga lugar ng gawaing programming kung saan maaaring ilapat ang mga quantitative measurement upang masubaybayan ang performance, kalidad ng trabaho at produktibidad ng isang developer. Ang bawat sukatan ng pagiging produktibo ay batay sa pagkuha ng data mula sa proseso ng pag-unlad at paggamit nito upang sukatin ang pagiging produktibo. Dahil halos walang kinalaman sa pagbuo ng software ay madali at diretso, maaari mong sabihin na ang pagsukat ng pagiging produktibo sa programming ay medyo hindi pare-pareho at pira-piraso sa buong industriya. O, sa madaling salita, ang iba't ibang mga koponan at kumpanya ay maaaring gumamit ng ganap na magkakaibang mga tagapagpahiwatig ng pagganap at lapitan ang isyung ito mula sa isang bilang ng mga anggulo. Kaya hindi mo kailangang mag-abala sa pag-aaral ng bawat sukatan na maaaring gamitin ng mga software development team.
Anong mga uri ng mga sukatan ng pagiging produktibo sa pagbuo ng software ang naroroon?
Naturally, mayroong maraming iba't ibang sukatan ng produktibidad na lumalapit sa pagsukat ng pagganap sa iba't ibang antas at anggulo. Narito ang mga pinakakaraniwang uri ng naturang sukatan ng pagiging produktibo:
Mga sukatan na nakatuon sa pormal na laki.
Nakatuon ang mga sukatang ito sa pagsukat sa laki ng resulta ng trabaho ng isang programmer, gaya ng mga linya ng code (LOC), haba ng mga tagubilin sa code, pagiging kumplikado ng code, atbp. Ang mga sukatang ito ay lalong itinuturing na luma na sa industriya ng software development ngayon.
Mga sukatan ng produktibidad na nakatuon sa oras at paggana.
Mayroong isang seleksyon ng mga tradisyunal na sukatan ng produktibidad na ginagamit sa pagbuo ng software ng waterfall, gaya ng mga aktibong araw, ang saklaw ng functionality na ipinadala sa isang takdang panahon, mga rate ng pag-churn ng code, bilang ng mga gawaing itinalaga, atbp.
Mga sukatan ng proseso ng maliksi na pag-unlad.
Ang mga sukatan ng proseso ng mabilis na pag-unlad, gaya ng ulat ng sprint burndown, bilis, oras ng pag-usad, oras ng pag-ikot at iba pa, ay marahil ang pinakakaraniwang ginagamit na sukatan sa mga pangkat ng software development ngayon. Pag-uusapan natin ang tungkol sa Agile metrics nang mas detalyado mamaya sa artikulo.
Mga sukatan ng operational analytics.
Nakatuon ang hanay ng mga sukatan na ito sa pagsukat ng performance ng software sa kasalukuyang kapaligiran ng produksyon nito. Ang mean time between failures (MTBF), mean time to recover (MTTR), at ang rate ng pag-crash ng application ay ang pinaka ginagamit na sukatan dito.
Mga sukatan ng pagsubok.
Ang pagsubok sa software ay may sariling hanay ng mga sukatan upang masukat ang kalidad ng pagsubok sa system, tulad ng porsyento ng mga automated na pagsubok, saklaw ng code, atbp.
Mga sukatan ng kasiyahan ng customer.
Panghuli, ang pinakahuling sukatan para sa anumang piraso ng software ay end customer experience, at mayroong isang buong hanay ng mga sukatan para din doon, gaya ng customer effort score (CES), customer satisfaction score (CSAT), net promoter score (NPS) at iba pa.
Mga sukatan ng maliksi na software development
Tulad ng nakikita mo, medyo madaling mawala sa lahat ng mga intricacies ng software productivity metrics. Gayunpaman, ang tanging alam ng isang regular na software developer ay ang Agile metrics, na karaniwang ginagamit ng mga software development team ngayon bilang mga pamantayan ng pagsukat ng productivity ng team sa iba't ibang bahagi ng ikot ng buhay ng software development. Ilista natin ang pangunahing at pinakakaraniwang ginagamit na Agile metrics.
1. Sprint Burndown.
Ang mga ulat ng Sprint Burndown ay isa sa mga pangunahing sukatan para sa mga maliksi na scrum development team. Tulad ng sa maliksi ang proseso ng pag-unlad ay inayos sa pamamagitan ng time-bound sprints, ang Sprint Burndown ay ginagamit bilang isang paraan ng pagsubaybay sa pagkumpleto ng mga gawain sa panahon ng isang sprint. Ang mga oras o story point ay ginagamit bilang isang yunit ng pagsukat. Ang layunin ay upang makamit ang pare-parehong pag-unlad at maghatid ng trabaho alinsunod sa mga paunang pagpapakita. Tinutulungan ng Sprint Burndown ang mga team na sukatin ang bilis ng trabaho at ayusin ito kapag kinakailangan.
2. Bilis ng Team.
Ang bilis ay isa pang pangunahing tagapagpahiwatig, na nakabatay din sa mga oras o mga punto ng kuwento bilang isang yunit ng pagsukat. Sinusukat nito ang average na dami ng trabaho na nakumpleto ng isang koponan sa isang sprint at ginagamit para sa pagtatantya at pagpaplano sa buong proyekto. Ang bilis ng pagsubaybay ay mahalaga upang matiyak na ang koponan ay naghahatid ng pare-parehong pagganap.
3. Mga Punto ng Kwento.
Sa antas ng indibidwal na miyembro ng development team, ang mga story point ay isang mahalagang sukatan, dahil ang laki ng mga kwentong inihahatid ng isang programmer sa bawat release ay isang indicator ng pagiging produktibo ng coder na ito.
4. Cycle Control Chart.
Sinusukat ang kabuuang oras mula sa sandaling nagsimula ang gawain sa isang gawain o isa pang backlog item hanggang sa matapos ito. Nagbibigay-daan na subaybayan at kontrolin ang mga tagal ng pag-ikot na naghahatid ng mas mahuhulaan na mga resulta.
5. Throughput at Value Delivered.
Sinusuri ng mga tagapamahala ng proyekto ang mga gawain na itinalaga sa mga developer at nagtatalaga ng halaga sa kanila. Ang sukatan na ito ay pagkatapos ay ginagamit upang sukatin ang throughput ng koponan o, sa madaling salita, ang halaga ng idinagdag na gawaing nagawa.
6. Code Churn.
Ang code churn ay isa pang sukatan na dapat banggitin dahil ginagamit ito para sa pagsukat ng produktibidad ng isang team sa kabuuan at para subaybayan ang performance ng mga indibidwal na programmer. Sinusukat ng code churn kung gaano kadalas nag-aalis o gumagawa ng mga pagbabago ang isang developer sa mga naunang idinagdag na linya ng code, at ilang porsyento ng dating nakasulat na code ang nauwi sa pagbabago o pagtatapon.
Mga opinyon ng eksperto
Panghuli, upang magdagdag ng ilang pananaw, ilang mga panipi sa bagay na ito ng mga karanasang propesyonal sa industriya ng software development. “Umaasa ako na hindi ka naghahanap na "ikumpara" ang iyong mga sukatan sa ilang uri ng pamantayan o maging sa pagganap ng isa pang koponan sa ibang kumpanya. Saanman ako nagtrabaho ay may mga kakaibang pagkakaiba-iba sa kanilang mga kahulugan ng mga punto ng kuwento, bilis, oras-oras na pagtatantya, mga gawain, atbp. na talagang magiging imposible na ihambing ang pagganap ng isang koponan mula sa isang kumpanya nang direkta sa isa pang koponan sa isa pa kumpanya, " sabi ni Cliff Gilley, dating Technical Product Manager at Agile Coach. “Medyo nalilito ako sa mga sukatan pagdating sa paggabay sa performance ng team. Sa sandaling bigyang-pansin mo lamang ang isa o dalawang variable, magiging napakadaling mahulog sa (sinasadya o kung hindi man) sa paglalaro ng sukatan at lokohin ang iyong sarili na ikaw ay nagpapabuti - kapag ang ginagawa mo lang ay pagpapabuti ng sukatan. Halimbawa, ang mga sukatan na nakabatay sa bilis ay maaaring "mapabuti" ng paglipat ng koponan sa mas maliliit na kwento (mas kaunting trabaho bawat kuwento - kaya mas maraming kuwento ang natapos - kaya tumaas ang bilis). Maaaring isang magandang bagay iyon kung ang mga kuwento ay kapaki-pakinabang na mga kuwento ng user na naghahatid ng mas maliliit na pagtaas ng halaga ng negosyo. Iyon ay maaaring isang masamang bagay kung ang mga kuwento ay nagiging mas maliit at mas "teknikal" na mga gawain na hindi naghahatid ng tunay na halaga sa kanilang sarili," sabi ni Adrian Howard, isa pang propesyonal sa industriya.. “Kapag nagtatrabaho sa isang pull-based system, pinahahalagahan ko ang throughput at cycle time. Ang una ay nagbibigay sa akin ng pangkalahatang impormasyon tungkol sa kapasidad ng aming team, at sa paglipas ng panahon ay maaaring maging isang napakalakas na predictive measure. Ang pangalawa ay nakakatulong bilang pangkalahatang sukatan ng kahusayan ng aming mga pipeline. Kung ang cycle time ay mataas, oras na upang simulan ang pagtingin sa pipeline, dahil mayroong isang hadlang na malamang na maaari naming gawin patungo sa easing/exploit. Ngunit ang mga sukatan ay mga kasangkapan lamang. Huwag mawala sa kanila, at tiyak na huwag simulan ang pagpaplano patungo sa isang partikular na sukatan. Isipin kung ano ang ginagawa mo bilang isang koponan at kung paano ka natural na nagtatrabaho, pagkatapos ay buuin ang sistema sa paligid ng mga tao. Dapat makatulong sa iyo ang mga sukatan na makita kung paano sinusuportahan ng iyong system ang gawain ng lahat. O hindi,” Dave Cerra, isang video game development producer, concluded .
GO TO FULL VERSION