Anong mga paraan ang ginagamit ng mga developer upang suriin ang mga gawain?

Kamusta kayong lahat! Ang teorya na kinakailangan upang simulan ang pag-unlad ay napakalawak. Ang ilang mga espesyalista (mga backend developer sa Java at iba pang mga wika) ay may higit pa nito, habang ang iba (halimbawa, mga frontend na developer sa JavaScript - React Native) ay may kaunti pang kaunti. Gayunpaman, ang dalawa sa kanila ay dapat magkaroon ng isang malaking stock ng hindi lamang teknikal, kundi pati na rin ang "organisasyon" na kaalaman. Ang kaalamang "organisasyon" na ito ay isa sa mga intersection point para sa mga developer ng frontend at backend. Ngayon gusto kong pag-usapan ang isang aspeto ng naturang di-teknikal, kaalaman sa organisasyon - tungkol sa pagtatasa ng gawain (pagtantiya). At dahil nagtrabaho lamang ako sa Agile methodology (na sa katunayan ay itinuturing na pinakasikat), sa subpart nito, Scrum , isasaalang-alang ko ang pagtatasa ng gawain sa konteksto ng Scrum . Sasabihin ko kaagad na ang pagtatasa, na tinatawag ding pagtatantya, ay mahirap. Para sa akin bilang isang developer ito ay isa sa pinakamahirap/hindi kanais-nais na aspeto ng trabaho. Mayroong maraming iba't ibang mga kadahilanan upang isaalang-alang na maaaring makaimpluwensya sa pagtatasa ng isang gawain. Kasabay nito, ang mga plano para sa karagdagang pag-unlad ay ibabatay sa iyong mga pagtataya.

Paano kung hindi mo makuha ang rating?

Kung ang isang developer ay gumugugol ng mas maraming oras sa isang gawain kaysa sa gagastusin sa huli, maaaring mukhang hindi siya ang pinakamahusay na espesyalista, dahil ang pagtatantya ay masyadong hindi tumpak. Kaya't magsalita, isang daliri sa langit. Kasabay nito, kung hindi mamuhunan ang developer sa hinulaang oras, ilalagay niya sa panganib ang mga plano ng customer na ilabas ang produkto/bagong feature. Ito ay isang negosyo, at ang negosyo ay nangangahulugan ng pera, at kakaunti ang mga customer ang magugustuhan ang gayong pagbutas. Ito talaga ang dahilan kung bakit hindi ko gusto ang pagtatantya, dahil minsan napakahirap matukoy ang eksaktong oras para sa pagkumpleto ng isang gawain.

Paano tinatasa ang oras?

Bilang isang tuntunin, ang pagtatantya ay isinasagawa sa mga oras o mga punto ng kuwento. Sa personal, mas malapit ako sa proseso ng pagsusuri sa mga punto ng kuwento . Kung ang isang relo ay isang bagay na pisikal, kung gayon isang bagay na maaaring magkamali, ang mga punto ng kuwento ay medyo tungkol sa ibang bagay, mas abstract. Karaniwan, ang mga software development team ay nagbibigay ng mga pagtatantya sa format ng oras: oras, araw, linggo, buwan. Ang nasabing mga pagtatantya ng oras ay pangunahing batay sa personal na karanasan, hula, o intuwisyon. Sa kasong ito, tinitingnan lang ng mga developer ang gawain at tinitingnan ang isang pagtatantya kung gaano katagal ito aabutin. Bilang isang resulta, ang mga ito ay napakabihirang tumpak, dahil napakaraming mga kadahilanan na maaaring makaapekto sa deadline para sa pagkumpleto ng trabaho. Samakatuwid, maraming mga koponan na nagtatrabaho ayon sa Agile methodology ang gumagamit ng mga story point. Alamin natin ito.

Ano ang Story points

Ang isang story point ay isang yunit ng pagsukat na nagpapahayag ng isang pagtatasa ng kabuuang pagsisikap na kinakailangan upang ganap na maipatupad ang isang tiyak na lugar ng trabaho (functionality). Iyon ay, ito ay isang kamag-anak na pagiging kumplikado . Ang mga koponan ay nagtatalaga ng mga punto ng kuwento batay sa pagiging kumplikado ng trabaho, ang saklaw ng trabaho, at ang panganib o kawalan ng katiyakan. Karaniwan, ang mga halagang ito ay itinalaga upang mas mahusay na hatiin ang trabaho sa mas maliliit na bahagi, sa gayon ay inaalis ang kawalan ng katiyakan. Sa paglipas ng panahon, nakakatulong ito sa mga team na maunawaan kung ano ang maaari nilang makamit sa isang partikular na yugto ng panahon at tinutulungan silang magplano ng mga susunod na bahagi ng trabaho nang mas tumpak. Ito ay maaaring mukhang ganap na counterintuitive sa iyo, ngunit ang abstraction na ito ay talagang kapaki-pakinabang: ito ay nagtutulak sa koponan na gumawa ng mas mahihigpit na mga desisyon tungkol sa pagiging kumplikado ng trabaho. Tingnan natin ang ilang dahilan para gamitin ang mga punto ng kuwento sa pagpaplano:

• maiiwasan ang hindi tumpak na pagtatantya sa mga agwat ng oras;
• Hindi tulad ng pagtatantya sa paglipas ng panahon, ang mga gastos sa overhead ay maaaring mas mahusay na isinasaalang-alang: mga komunikasyon sa pagitan ng mga miyembro ng koponan at ng customer, iba't ibang mga talakayan at pagpaplano ng koponan, pati na rin ang mga hindi inaasahang sitwasyon;
• Ang bawat pangkat ay magre-grade ng trabaho sa ibang sukat, na nangangahulugan na ang kanilang bilis (sinusukat sa mga puntos) ay magkakaiba;
• Sa pamamagitan ng pagtukoy ng sukat para sa pagtatalaga ng bawat punto ng kuwento, maaari mong mabilis na ipamahagi ang mga puntos nang walang gaanong kontrobersya.

Paano HINDI gumamit ng mga punto ng kuwento

Sa kasamaang palad, ang mga punto ng kuwento ay kadalasang ginagamit para sa iba pang mga layunin. Ang mga punto ng kuwento ay maaaring may depekto kapag ginamit ang mga ito upang suriin ang mga tao, tukuyin ang mga detalyadong deadline at mapagkukunan, at kapag nagkamali ang mga ito bilang sukatan ng pagganap. Sa halip, kailangang gamitin ng mga koponan ang mga ito upang maunawaan ang dami/kumplikado ng trabaho sa bawat gawain at upang bigyang-priyoridad. Posible na ang mga bahagi na na-rate na mas mahirap ay dapat gawin muna upang makumpleto ang mga ito bago matapos ang sprint , ngunit ang mas madali ay maaaring itulak pabalik sa ibang pagkakataon. Hayaan akong ipaalala sa iyo kung ano ang isang sprint sa konteksto ng pamamaraan ng Scrum : Gaano katagal ang yugto ng panahon na ito ay tinutukoy sa simula ng pagbuo sa pamamagitan ng kasunduan sa pagitan ng team at ng customer. Ito ay maaaring isang panahon ng dalawang linggo o isang buwan, o anumang iba pang panahon. Bilang isang patakaran, ang pagtatantya ng gawain ay isinasagawa sa simula ng sprint upang planuhin ang posibleng dami ng trabaho na natapos sa pagtatapos ng sprint, kapag ang natapos na trabaho ay naihatid sa customer. Tinutulungan ka nitong makita ang iyong pag-unlad sa pagbuo ng produkto, makatanggap ng feedback mula sa customer at ayusin ang pagbuo ng proyekto ayon sa pananaw ng customer. Ngunit gayon pa man, lumihis tayo ng kaunti: bumalik tayo sa pagtatantya. Ang pag-evaluate ng mga gawain ng isang developer lang ay magiging masyadong subjective. Samakatuwid, bilang isang patakaran, ito ay gawain ng pangkat. Mayroong ilang mga diskarte para sa pagtatasa ng pangkat. Ngayon ay titingnan natin ang pinaka ginagamit sa kanila - Scrum poker . Ang pamamaraan na ito ay nangangailangan ng isang manager na magiging isang tulad ng pinuno ng Scrum poker na ito . Maaaring ito ay isang taong nagdadalubhasa sa Scrum Master , o PM .

Ano ang Scrum Poker

Scrum poker - o planning poker - ay isang diskarte sa pagsusuri na batay sa pag-abot sa isang kasunduan. Pangunahing ginagamit upang masuri ang pagiging kumplikado ng gawain sa hinaharap o ang kamag-anak na dami ng mga gawain na malulutas sa panahon ng pagbuo ng software. Mapapansin ko kaagad na ang Scrum poker ay isang karaniwang kasanayan sa pag-unlad, at tiyak na kailangan mong malaman kung anong uri ng halimaw ito. Para sa prosesong ito, karaniwang gumagamit kami ng ilang uri ng application o website na nagbibigay-daan sa aming mag-organisa ng pagtatasa ng pangkat ng isang partikular na gawain. Paano ito nangyayari? Ang koponan ay tumatagal ng isang backlog item (bagong gawain, pag-andar), maikling tinatalakay ang mga posibleng pitfalls at iba pang mga nuances na nauugnay dito. Ang bawat kalahok ay pipili ng isang card na may numero na kumakatawan sa kanilang rating ng kahirapan. Oh, at kapag tinatantya, hindi ang karaniwang serye ang ginagamit, ngunit ang mga numero ng Fibonacci . Ang mga numero ng Fibonacci ay napakapopular sa scrum poker dahil ang agwat sa pagitan ng mga ito ay tumataas sa paglipas ng panahon (nakapagpapaalaala sa mga antas ng pyramid). May mga gawain na magkakaroon ng napakalaking kumplikado, at isang maliit na bilang ng mga punto ng kuwento ay hindi maaaring makamit. Paliwanag para sa mga hindi pangkaraniwang card:

hindi kilalang bilang ng mga endpoint

isang walang katapusang mahabang gawain

kailangan ng pahinga

Higit pang mga bihirang paraan ng pagtatantya:

• sa mga laki ng T-shirt - S, M, L, XL
• o sa mga aso - chihuahua, pug, dachshund, bulldog, at iba pa (sa palagay ko, ito ang pinaka kakaibang yunit para sa pagsusuri ng mga gawain =D)

Pagkatapos, ikinukumpara ng team ang mga pagtatantya na ibinigay sa parehong problema ng iba't ibang developer, at kung sumasang-ayon sila, mahusay! Kung hindi, kinakailangang talakayin ang mga dahilan ng mga pagkakaiba sa pagtatasa (mga argumento). Pagkatapos nito, magkakasama tayong makakarating sa isang pagtatantya, kung saan sasang-ayon ang lahat, plus o minus. Buweno, bakit ginagamit ang poker upang magplano ng isang seryosong proyekto ng software? Pagkatapos ng lahat, ito ay kakaiba. Sa katunayan, hinihikayat ng naturang gamification ang mga miyembro ng koponan na mag-isip nang nakapag-iisa, na hinihiling sa kanila na ipakita ang kanilang mga resulta kasabay ng kanilang mga kasamahan sa koponan. Ito, sa turn, ay nag-iwas sa pag-asa sa mga pananaw ng iba pang mga miyembro ng koponan. Kung hindi, titingnan at aasa ang mga di-gaanong karanasang developer sa mga pagtatasa ng mas maraming karanasang miyembro ng team, na magpapawalang-bisa sa pagiging kapaki-pakinabang ng sarili nilang pagtatasa. Ngunit sa sabay-sabay na pagbubukas ng mga resulta, ito ay mahalagang imposible. Isang halimbawa ng Scrum Poker scheduling app ay mula sa Atlassian .

Halimbawa ng pagtatasa ng gawain

Isipin natin na ang iyong koponan ay nakatukoy ng isang tiyak na sukat para sa pagsusuri sa mga punto ng kuwento: Nagsisimula ang Scrum Poker sa isang gawain, at sinusuri mo ito tulad nito:

• hindi ka pa kailanman nagtrabaho sa pagpapatupad ng katulad na paggana bago - +3
• functionality ng isang medium-sized na gawain - +2
• ang pagpapatupad ng gawain ay may mataas na pagiging kumplikado - +3
• mataas na kumplikado ng mga pagsusulit sa pagsulat para sa pagpapaandar na ito - +3

Bilang resulta, makakakuha ka ng 11 story point, ngunit dahil walang ganoong card, nag-aalok ka ng 13. Sinusuri ng isa pang kasamahan mo ang gawain:

• nagtrabaho sa isang katulad na problema bago - +1
• functionality ng isang medium-sized na gawain - +2
• ang pagpapatupad ng gawain ay may average na pagiging kumplikado - +2
• average na pagiging kumplikado ng mga pagsusulit sa pagsulat para sa pagpapaandar na ito - +2

Bilang resulta, nakakuha siya ng 7 story point, ngunit walang ganoong bagay sa mga numero ng Fibonacci, at naglalagay siya ng card na may pinakamalapit na posibleng numero - 8. Ang iba pang miyembro ng team, ayon dito, ay nagbibigay ng mga pagtatantya batay sa kanilang mga pansariling pananaw. Susunod, ipakita mo ang iyong mga resulta at natuklasan na halos lahat ng iyong mga kasamahan ay nagbigay ng pagtatantya na 13, maliban sa isang developer na nagbigay nito ng 8. Sa kasong ito, binibigyan siya ng sahig at nagbibigay siya ng mga dahilan. At sila, halimbawa, ay ganito: nagtrabaho siya dati na may parehong problema, at hindi ito kasing hirap tulad ng tila, at sa huli ay nakumbinsi niya ang natitirang mga miyembro ng koponan na baguhin ang kanilang solusyon mula 13 hanggang 8 kuwento puntos, na nagsasabing tutulungan niya ang sinumang kumuha ng gawaing ito ay malalaman ito. O, sa huli, siya mismo ang gagawa. At sa pangkalahatan, hindi mahalaga kung ang iba ay nakikinig sa kanyang mga argumento o hindi, dahil sa isang paraan o iba pa, ang isang rating ay itatalaga sa gawaing ito, at ang koponan ay magpapatuloy upang maging pamilyar sa susunod. Sa mga unang pagkakataon, ang mga pagtatantya ay magiging hindi tumpak, gayundin ang mga pagtatantya ng dami ng trabaho na plano mong gawin sa susunod na yugto ng panahon (sprint). Pagkatapos ng lahat, ang mga pagtatantya na ito ay ginawa nang tumpak batay sa mga pagtatantya. Pagkalipas ng ilang oras, mga tatlong buwan, magsisimula ang koponan sa mas tumpak na pagtatantya ng mga gawain, at ang average na dami ng trabaho na maaaring tapusin ng koponan sa bawat sprint ay makikita. Ngunit ito ay pangkalahatang pagpaplano ng saklaw ng trabaho, ito ay higit pa tungkol sa oras, at sa kasong ito ay maaaring mayroong maraming iba't ibang mga kadahilanan na may epekto. Halimbawa, nagbakasyon ang isa sa mga developer sa loob ng dalawang linggo. Iyon ay, kailangan mong i-cross out ang isang tiyak na halaga ng nakaplanong trabaho (nakaplanong pag-andar). O isang bagong developer ang dumating sa koponan, ngunit hindi mo kailangang ganap na umasa sa kanya, dahil... kailangan mong isaalang-alang ang oras na kinakailangan upang umangkop sa proyekto, na tinatawag na onboarding . Ito ay maaaring dalawang linggo, plus o minus sa isang linggo, depende sa pagiging kumplikado ng proyekto. Iyon lang para sa araw na ito, sana ay napabuti ko nang bahagya ang iyong kaalaman sa isang hindi teknikal na bahagi ng kaalaman bilang pagtatantya ng problema. Kung gusto mong palalimin ang paksang ito, pati na rin ang mga detalye ng Scrum, mariing ipinapayo ko sa iyo na basahin ang aklat na "SCRUM" ni Jeff Sutherland. Hindi ko matiyak ang mga kahihinatnan, dahil marahil pagkatapos nito ay magkakaroon ka ng nakakainis na pagnanais na maging isang Scrum Master =D