Matugunan ang iyong mga deadline: mga paraan na ginagamit ng mga developer para tantiyahin ang pagsisikap

Kumusta, lahat! Mayroong napakalaking halaga ng teorya na kailangan mong malaman upang makapagsimula sa pagbuo ng software. Ang ilang mga espesyalista (halimbawa, mga developer ng backend na gumagamit ng Java at iba pang mga wika) ay higit na nakakaalam nito, habang ang iba (halimbawa, mga developer ng frontend na gumagamit ng JavaScript at React Native) ay maaaring mas kaunti ang nalalaman. Iyon ay sinabi, ang parehong mga grupo ay dapat magkaroon ng isang malaking katawan ng hindi lamang teknikal, kundi pati na rin ang "organisasyon" na kaalaman. Ang kaalamang "organisasyon" na ito ay isang bahagi ng overlap para sa mga developer ng frontend at backend. Ngayon gusto kong pag-usapan ang isang aspeto ng hindi teknikal, kaalamang pang-organisasyon na ito. Ngayon ay pag-uusapan natin ang tungkol sa pagtatantya ng pagsisikap . Dahil may karanasan lang ako sa paggamit ng Agile methodology(na itinuturing na pinakasikat), mas partikular ang balangkas ng Scrum, isasaalang-alang ko ang pagtatantya ng pagsisikap sa konteksto ng Scrum . Sa simula pa lang, dapat kong sabihin na mahirap ang pagtatantya ng pagsisikap. Para sa akin, isa ito sa pinakamahirap/hindi kasiya-siyang aspeto ng aking trabaho bilang developer. Mayroong maraming iba't ibang mga kadahilanan upang isaalang-alang na maaaring makaapekto sa iyong pagtatantya ng pagsisikap na kinakailangan para sa isang gawain. Bukod pa rito, ang mga plano sa pagpapaunlad sa hinaharap ay ibabatay sa iyong mga pagtatantya.

Paano kung magbigay ka ng hindi magandang pagtatantya?

Kung ang isang developer ay nagtatantya ng mas maraming oras para sa isang gawain kaysa sa kalaunan ay ginugugol sa gawain, ang kanilang kadalubhasaan ay maaaring ilagay sa pagdududa dahil ang pagtatantya ay masyadong hindi tumpak. Sa madaling salita, ito ay isang ligaw na hula. Kasabay nito, kung hindi nagawa ng developer ang trabaho sa hinulaang oras, ilalagay niya sa panganib ang mga plano ng customer na ilabas ang produkto o bagong feature. Ito ay negosyo, at ang negosyo ay pera. Ilang mga customer ang masisiyahan sa gayong slip. Sa katunayan, iyon ang dahilan kung bakit hindi ko gusto ang pagtatantya — dahil kung minsan ay napakahirap na tumpak na matukoy ang oras na kinakailangan upang makumpleto ang isang gawain.

Paano gumawa ng pagtatantya ng oras

Bilang panuntunan, ang mga pagtatantya ay ginagawa sa mga oras o mga punto ng kuwento. Ang aking personal na kagustuhan ay gawin ang proseso ng pagtatantya gamit ang mga punto ng kuwento . Mahirap na mapagkamalan tungkol sa mga konkretong pisikal na bagay, ngunit ang mga punto ng kuwento ay medyo mas abstract. Ang mga software development team ay karaniwang nagbibigay ng mga pagtatantya bilang tagal ng oras: oras, araw, linggo, buwan. Ang mga pagtatantya ng oras na ito ay pangunahing batay sa personal na karanasan, hula, at/o intuwisyon. Sa kasong ito, tinitingnan lamang ng mga developer ang gawain at ipahayag ang kanilang palagay tungkol sa kung gaano katagal aabutin sila. Bilang resulta, ang mga pagtatantya na ito ay napakabihirang tumpak, dahil napakaraming mga kadahilanan na maaaring makaapekto sa tagal ng trabaho. Kaya naman maraming team na gumagamit ng Agile methodology ang gumagamit din ng story point. Sumisid tayo!

Ano ang mga punto ng kuwento?

Ang story point ay isang yunit ng pagsukat para sa pagpapahayag ng pagtatantya ng kabuuang pagsisikap na kinakailangan upang ganap na maipatupad ang isang partikular na bahagi ng functionality. Ibig sabihin, relative ang pinag-uusapanpagiging kumplikado. Nagtatalaga ang mga koponan ng pagtatantya sa mga story point batay sa pagiging kumplikado ng trabaho, dami ng trabaho, at panganib o kawalan ng katiyakan. Ang mga halagang ito ay karaniwang nakatalaga upang mas mahusay na hatiin ang gawain sa mas maliliit na piraso, sa gayon ay inaalis ang kalabuan. Sa paglipas ng panahon, nakakatulong ito sa mga team na maunawaan kung ano ang magagawa nila sa isang partikular na yugto ng panahon at tinutulungan silang mas tumpak na magplano ng mga susunod na bahagi ng trabaho. Ito ay maaaring mukhang ganap na counterintuitive sa iyo, ngunit ang abstraction na ito ay talagang madaling gamitin: itinutulak nito ang koponan na gumawa ng mahihirap na desisyon tungkol sa pagiging kumplikado ng trabaho. Tingnan natin ang ilan sa mga dahilan para gumamit ng mga story point kapag nagpaplano:

• Maiiwasan mo ang mga hindi tumpak na pagtatantya sa oras.
• Hindi tulad ng mga pagtatantya na ginawa sa mga yunit ng oras, binibigyang-daan ka ng mga story point na isaalang-alang ang mga overhead na gastos: mga komunikasyon sa pagitan ng mga miyembro ng team at ng customer, iba't ibang talakayan ng team at mga aktibidad sa pagpaplano, pati na rin ang mga hindi inaasahang sitwasyon.
• Tantyahin ng bawat koponan ang kanilang trabaho gamit ang iba't ibang mga sukat, na nangangahulugan na ang kanilang kapasidad (sinusukat sa mga puntos) ay magkakaiba.
• Sa pamamagitan ng pagtukoy ng sukat para sa pagtatalaga ng bawat punto ng kuwento, maaari mong mabilis na maglaan ng mga punto nang walang gaanong kontrobersya.

Paano HINDI gumamit ng mga punto ng kuwento

Sa kasamaang palad, ang mga punto ng kuwento ay madalas na maling ginagamit. Maaaring mapanlinlang ang mga punto ng kuwento kapag ginamit ang mga ito upang masuri ang mga tao, tukuyin ang mga detalyadong deadline at mapagkukunan, at kapag napagkamalan ang mga ito bilang sukatan ng pagganap. Sa halip, dapat gamitin ng mga koponan ang mga ito upang maunawaan ang saklaw/kumplikado ng bawat gawain at magtakda ng mga priyoridad. Marahil na ang mga bahagi na itinuturing na mas mahirap ay dapat munang harapin, upang magawa ang mga ito bago matapos ang sprint , posibleng ilipat ang mga mas madaling gawain sa ibang pagkakataon. Hayaan akong ipaalala sa iyo kung ano ang isang sprint sa konteksto ng pamamaraan ng Scrum : Ang haba ng yugto ng panahon na ito ay tinutukoy kapag nagsimula ang pag-unlad at napagkasunduan 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 mga pagtatantya ng pagsisikap ay ginagawa sa simula ng bawat sprint upang maplano ang gawain na maaaring makumpleto sa pagtatapos ng sprint, kapag ang natapos na trabaho ay naihatid sa customer. Tinutulungan ka ng demo na makita ang iyong pag-unlad sa pagbuo ng produkto, makatanggap ng feedback mula sa customer, at ayusin ang trajectory ng proyekto ayon sa pananaw ng customer. Ngunit lumihis kami ng kaunti. Bumalik tayo sa mga pagtatantya. Masyadong subjective kung ang isang developer lang ang magbigay ng mga pagtatantya para sa lahat ng gawain. Kaya ang prosesong ito ay karaniwang pagsisikap ng pangkat. Mayroong ilang mga diskarte na magagamit ng mga koponan upang makabuo ng mga pagtatantya. Ngayon ay titingnan natin ang pinakasikat na pamamaraan: scrum poker . Ang pamamaraan na ito ay nangangailangan ng isang manager na gaganap bilang isang moderator para sa scrum poker . Ito ay maaaring isang taong scrum master o posibleng isang PM .

Ano ang Scrum poker?

Ang scrum poker , o planning poker, ay isang diskarte sa pagtatantya na batay sa pag-abot sa isang kasunduan. Pangunahing ginagamit ito upang tantyahin ang pagiging kumplikado ng gawain sa hinaharap o ang kamag-anak na laki ng mga gawain sa pagbuo ng software. sasabihin ko agad yung scrum pokeray isang pangkaraniwang kasanayan sa pagbuo ng software, at kailangan mong malaman kung tungkol saan ito. Karaniwan itong nagsasangkot ng isang app o website upang mapadali ang paggawa ng collaborative ng isang team ng isang pagtatantya para sa isang partikular na gawain. Paano ito nangyayari? Ang koponan ay kumukuha ng isang bagay mula sa backlog (isang bagong gawain, ilang pag-andar) at maikling tinatalakay ang mga posibleng pitfalls at iba pang mga nuances na nauugnay dito. Pagkatapos ay pipili ang bawat kalahok ng isang card na may numero na nagpapakita ng kanilang pagtatantya sa pagiging kumplikado. Oh, isa pa, kapag ginagawa ang mga pagtatantya na ito, gumagamit kami ng mga numero sa Fibonacci sequence kaysa sa mga ordinaryong numero. Ang mga numero ng Fibonacci ay sikat sa scrum poker, dahil may lalong malaking agwat sa pagitan nila (na kahawig ng mga antas ng isang pyramid). Ang ilang mga gawain ay magiging lubhang masalimuot, at hindi tayo makakaalis sa kaunting bilang ng mga punto ng kuwento. Mayroong ilang mga hindi pangkaraniwang card na may mga sumusunod na kahulugan:

Hindi kilalang bilang ng mga endpoint

Walang katapusang mahabang gawain

Kailangan ng pahinga

Ang mga hindi gaanong karaniwang paraan ng pagtatantya ay gumagamit ng:

• Mga laki ng t-shirt — S, M, L, XL
• Mga lahi ng aso — chihuahua, pug, dachshund, bulldog, at iba pa (sa personal, sa tingin ko ito ang kakaibang yunit ng sukat para sa pagtatantya ng pagsisikap =D)

Pagkatapos, ikinukumpara ng team ang mga pagtatantya na ibinigay ng iba't ibang developer para sa parehong gawain. Kung sumang-ayon sila, mahusay! Kung hindi, kung gayon ang mga dahilan (mga argumento) para sa iba't ibang mga pagtatantya ay kailangang talakayin. Pagkatapos nito, nagtutulungan ang koponan upang bumuo ng isang pagtatantya na tinatanggap ng lahat, higit pa o mas kaunti. Kaya bakit ginagamit ang poker upang magplano ng mga seryosong proyekto ng software? Kailangan mong aminin na ito ay kakaiba. Ang katotohanan ay ang ganitong uri ng gamification ay naghihikayat sa mga miyembro ng koponan na mag-isip nang nakapag-iisa, na nag-aanyaya sa kanila na ihayag ang kanilang mga pagtatantya kasabay ng kanilang mga kasamahan sa koponan. Ito, sa turn, ay umiiwas sa paglikha ng isang sitwasyon kung saan ang ilang mga miyembro ng koponan ay umaasa sa mga opinyon ng iba. Kung hindi ito ginawa sa ganitong paraan, titingnan at tututukan ng mga di-gaanong karanasang developer ang mga pagtatantya na ibinibigay ng mas maraming karanasang miyembro ng koponan, at gagawin nitong hindi gaanong kapaki-pakinabang ang sarili nilang mga pagtatantya. Ngunit ang sabay-sabay na pagpapakita ng mga pagtatantya ay ginagawa itong mahalagang imposible. Mga alok ng Atlassianisang scrum poker app para gamitin sa proseso ng pagpaplano.

Halimbawa ng pagtatantya ng pagsisikap

Ipagpalagay na itinatag ng iyong koponan ang sumusunod na sukat para sa pagtatalaga ng mga punto ng kuwento sa mga pagtatantya: Ang scrum poker ay nilalaro para sa bawat gawain, at nagbibigay ka ng pagtatantya tulad ng sumusunod:

• Hindi ka pa nagpatupad ng katulad na pagpapagana dati: +3
• Ang functionality ay average-sized: +2
• Ang pagpapatupad ay magiging lubhang kumplikado: +3
• Ang mga pagsusulit sa pagsulat para sa functionality ay magiging lubhang kumplikado: +3

Kapag nagdadagdag ng bawat bahagi, makakakuha ka ng kabuuang 11 story point, ngunit walang ganoong card, kaya iminumungkahi mo ang 13. Inilalagay ng isang katrabaho ang sumusunod na pagtatantya para sa gawain:

• Siya ay nagtrabaho sa isang katulad na gawain bago: +1
• Ang functionality ay average-sized: +2
• Ang pagpapatupad ay magiging sa average na kumplikado: +2
• Ang mga pagsusulit sa pagsulat para sa functionality ay magiging katamtaman ang pagiging kumplikado: +2

Ang kanyang intermediate na resulta ay 7 story point, ngunit ang numerong iyon ay hindi umiiral sa Fibonacci series, kaya isinusumite niya ang card na may pinakamaraming tinatayang numero — 8. Ang iba pang miyembro ng team ay gumagawa din ng kanilang mga pagtatantya batay sa kanilang mga pansariling pananaw. Pagkatapos ay ipinapakita ng lahat ang kanilang mga card at nalaman mong halos lahat ng iyong katrabaho ay nagbigay ng pagtatantya na 13, maliban sa isang developer na nagmungkahi ng 8. Sa kasong ito, pinapayagan siyang magsalita upang magbigay ng mga dahilan para sa kanyang mas mababang pagtatantya. Ipagpalagay na nag-aalok siya ng katwiran na ito: dati siyang nagtrabaho sa parehong gawain, at hindi ito kasing hirap gaya ng tila. Sa huli, kinukumbinsi niya ang natitirang bahagi ng koponan na baguhin ang kanilang isip mula 13 hanggang 8 puntos ng kuwento, na sinasabi na tutulungan niya ang sinumang magtatapos sa gawaing ito. O baka siya mismo ang gagawa. Sa anumang pangyayari, hindi Hindi mahalaga kung tatanggapin ng iba ang kanyang mga argumento o hindi, dahil ang isang paraan o iba pang isang pagtatantya ay itatalaga sa gawain, at ang koponan ay magpapatuloy upang isaalang-alang ang susunod. Sa una, 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 pagtatantyang ito ay ginawa gamit ang mga pagtatantya. Pagkaraan ng ilang oras, maaaring makalipas ang tatlong buwan, magsisimulang tantiyahin ng team ang oras na kinakailangan para sa mga gawain nang mas tumpak, at ang average na dami ng trabaho na kayang gawin ng team sa isang sprint ay magiging maliwanag. Ngunit ito ay isang proseso upang makagawa ng pangkalahatang plano para sa saklaw ng trabaho. Ito ay pangunahing nakatuon sa oras, ngunit sa kasong ito ay maaaring mayroong maraming iba't ibang nauugnay na mga kadahilanan. Halimbawa, ipagpalagay na nagbakasyon ang isang developer sa loob ng dalawang linggo. Kakailanganin mong bawasan ang isang tiyak na halaga ng nakaplanong trabaho (nakaplanong pag-andar). O ipagpalagay na ang isang bagong developer ay sumali sa koponan, ngunit hindi pa ganap na nakakatugon, kaya kailangan mong bigyan siya ng oras na maging pamilyar sa proyekto sa pamamagitan ng isangproseso ng onboarding . Ito ay maaaring dalawang linggo, bigyan o tumagal ng isang linggo, depende sa pagiging kumplikado ng proyekto. Yan lamang para sa araw na ito! Sana ay bahagyang napabuti ko ang iyong kaalaman sa pagtatantya ng pagsisikap, isang kinakailangang hindi teknikal na aspeto ng pagbuo ng software. Kung gusto mong palalimin ang paksang ito, at sa mga detalye ng scrum, lubos kong inirerekomenda na basahin mo ang aklat na "SCRUM" ni Jeff Sutherland. Hindi ako makakagawa ng anumang mga pangako tungkol sa mga kahihinatnan, dahil pagkatapos basahin ito magkakaroon ka ng nakakainis na pagnanais na maging isang scrum master =D