Gumagawa ng tumpak na mga pagtatantya sa proyekto ng software

pagtatantya ng proyekto ng software

Pixabay

Panimula

Ang pagtantya ay mahirap lamang. Sa kasamaang palad, kinakailangan din talaga. Gumagamit ang mga kumpanya ng mga pagtatantya upang ipalabas ang mga iskedyul ng paglabas, gumawa ng mga pangako sa kanilang mga customer, magpasya kung ang isang ipinanukalang tampok ay nagkakahalaga ng pagpapatupad, subaybayan ang bilis ng mga koponan, at unahin nang epektibo ang trabaho. Kadalasang nais malaman ng mga tagapagpatupad kung kailan handa ang isang tampok o maihahatid para sa paggawa. Pagkatapos ng lahat, ang pag-unlad ng software ay hindi isang maliit na pamumuhunan. Nang walang mga pagtatantya, paano ang pagtatasa ng manager ng proyekto? Kung nahulaan ng mga tao ang hinaharap na tumpak, ang mga tao ay hindi mananalo sa mga karera ng kabayo ng 2% ng oras. Ang pagtantya ay ang mahusay na alanganin. Mahalaga at kinakailangan para sa mga kumpanya na tanungin ang kanilang mga tao na gawin ang imposible: hulaan ang hinaharap.

Una, suriin natin ang ilang mga tanyag na pamamaraan ng pagtatantya (kung sakaling napalampas mo ang ilan sa kaguluhan). Pagkatapos ay maaari nating tingnan kung ano ang ibig sabihin nito sa atin at sa aming mga proyekto.

Ang Modelo ng Manghuhula

Ang modelong ito ay nangangailangan ng halos walang pagsisikap upang makabuo ng isang pagtatantya. Nag-iisip ng kaunti ang mga estima tungkol sa kung ano ang kailangang gawin upang maipatupad at subukan ang isang tampok, pagkatapos ay nagtatapon sila ng isang numero. Ito ay katulad ng "… (mahabang pag-pause)… Ummmmm… 6 na linggo." Tapos lahat ay tumango at magpatuloy na kami. Maaari silang gumastos ng ilang sandali sa harap na dulo ng pakikipag-usap sa pamamagitan ng kung ano ang alam nila ng mga kinakailangan (na marahil ay hindi ang kumpletong larawan). Ang maingat na pagtatasa na ito ay ginagawang mas maaasahan ang kanilang pagtatantya. Sa pagtatapos ng proyekto, palaging may tinatanggap na katwiran kung bakit ang pagtatantya ay napakalayo mula sa katotohanan. Palaging may mga hindi inaasahang pangyayari na maaaring magsilbing isang scapegoat. Madalas na hindi ito nangyayari sa sinuman na ang modelo ay malubhang kapintasan.

Kaya paano natin gagawing mas mahusay ang prosesong ito? Alam ko! Maaari naming gamitin ang Diskomposisyon na Diskarte (ie. Hatiin at lupigin). Ipinapalagay ng pamamaraang ito na alam mo ang kumpletong saklaw ng tampok o proyekto sa harap na dulo. Ang bawat tampok ay pinaghiwalay sa mga kagat na laki ng mga piraso. Ang bawat tipak ay tinantya (istilo ng manghuhula), pagkatapos ay idinagdag namin ang mga ito upang makakuha ng isang pangkalahatang pagtatantya ng tampok / proyekto. Ito ay tiyak na isang mas kumplikadong diskarte, ngunit mukhang mas mahusay ito para sa dalawang kadahilanan:

• Ang mas maliit na mga piraso ng trabaho ay may posibilidad na mas madali upang tantyahin maaasahan.
• Habang may pagkakataon pa rin para sa error (+/- ilang halaga), mayroong palagay na ang mga error ay magkakansela bawat isa kapag idinagdag mo ang lahat at makakakuha ka ng isang mas maaasahang pangkalahatang pagtatantya.

Ang pangunahing kapintasan sa pamamaraang ito ay ang mga indibidwal na nag-ambag (ang mga tao na talagang gumagawa ng trabaho) sa buong mundo na hindi pinapansin. Ang mga ito ay makabuluhang mas mahusay pa kaysa sa mga nasa itaas at sa paligid nila, ngunit hindi iyon isang mataas na bar. Mukhang hindi ito ang kaso sapagkat nakita nating lahat ang mga kaso kung saan sorpresa ng mga developer ang kanilang sarili sa pamamagitan ng pagkamit ng isang bagay nang maaga sa iskedyul. Ngunit ito ay isang solong data point, hindi isang kalakaran. Talagang nanalo ang mga tao paminsan-minsan sa casino; gumastos ng pera sa isang casino araw-araw sa loob ng isang taon at magkakaroon ka ng mas kaunting pera kaysa sa iyong nasimulan. Kung susubaybayan mo ang mga pagtatantya kumpara sa mga aktwal sa loob ng isang taon o dalawa, matutuklasan mo na ang mga pagtatantya ay nawalan ng katotohanan. Habang maraming mga negosyante ang ganap na sigurado na tinatamad na padding ng mga developer ang kanilang mga pagtatantya at gumagamit ng sobrang oras upang "gold-plate" o suriin ang kanilang mga stockiba ang ipinapakita ng data. Ang diskarte na "pagkansela" ay hindi gagana.

Kaya, ngayon ano? Ilagay natin ang modelo ng tagahula at lumipat sa isang diskarte na batay sa laki. Ito ay lumabas na, habang ang mga tao ay medyo kakila-kilabot sa pagtantya ng oras ng pagkumpleto, talagang mahusay kami sa pagsasabi kung gaano kalaki ang isang bagay. Lalo kaming mahusay sa paghahambing ng sukat ("mas malaki ito, ngunit mas maliit kaysa doon"). Kung sa tingin namin sa mga tuntunin ng laki o pagiging kumplikado kaysa sa oras, mas maaasahan itong iproseso ng ating utak. Pagkatapos ay maaari naming kunin ang mga halaga ng laki at kalkulahin ang aktwal na bilang ng mga oras para sa proyekto batay sa isang nakakatawang formula sa mahika! At iyon ang kapag ang tanyag na modelo ng mga puntos ng pag-andar ay pumasok sa eksena (kaliwa sa entablado).

Pagtatasa ng Mga Punto ng Pag-andar (FPA)

Para sa pagtatasa ng point point, kailangan naming kilalanin ang limang uri ng mga bagay sa aming aplikasyon: panlabas na input, panlabas na output, panlabas na mga query, panlabas na mga file ng interface, at panloob na mga lohikal na file (huwag mag-alala nang labis tungkol sa mga kahulugan; maaari mong saliksikin ang mga iyon sa ibang pagkakataon). Ang bawat halimbawa ng mga (isang pagpapaandar) ay may isang pagiging kumplikado na nauugnay dito (mababa, average, o mataas). Ginagamit namin ang talahanayan sa ibaba upang malaman kung gaano karaming mga puntos ang naatasan sa bawat pag-andar.

Ngayon kung idagdag namin ang mga puntos para sa lahat ng aming mga pag-andar maaari kaming makakuha ng isang bilang tulad ng 457 mga puntos ng pag-andar para sa aming proyekto. Pagkatapos kailangan lang namin ng isang pormula upang malaman ang bilang ng mga oras… Batay sa aming huling proyekto, ang aming "rate ng paghahatid" ay 15 mga puntos ng pag-andar bawat tao bawat buwan. Iyon ay humigit-kumulang na 30 buwan ng tao na nagkakahalaga ng trabaho, na dapat tumagal ng kaunti sa dalawa at kalahating buwan para sa aking koponan na 12. Ta-da!

Tiyak na ito ay mas kumplikado kaysa sa aming nakaraang modelo. Sa katunayan, mayroong apat na pangunahing mga lugar ng pagiging kumplikado upang makilala.

1. Ang limang uri ng sangkap ay hindi kinakailangang madaling maunawaan, at madaling makalimutang maglagay ng isang bagay sa listahan o italaga ito sa maling timba.
2. Ang talahanayan na ginamit upang aktwal na makabuo ng mga puntos ng pag-andar ay naglalaman ng mga magic number na mangangailangan ng maraming pagsisikap upang mapatunayan. Naka-calibrate ba nang maayos ang mga numerong ito upang makabuo ng maaasahang mga pagtatantya para sa aking mga koponan?
3. Ang rate ng paghahatid (isang kritikal na piraso ng palaisipan) ay kinakalkula batay sa pagiging produktibo ng iyong koponan. Gaano kadalas natin kailangan upang makalkula ang isang bagong numero? Talagang may napakaliit na patnubay dito.
4. Ano ang bumubuo ng mababa, average, o mataas na pagiging kumplikado? Paano namin ito tinutukoy upang maunawaan ito ng lahat? Hindi ba kritikal ang pagkuha ng tamang karapatan sa kawastuhan ng aming mga kalkulasyon?

Mayroong maraming mga gumagalaw na bahagi sa napakasimpleng halimbawa na ito, at hindi pa namin napag-usapan ang mas kumplikadong mga modelo ng pagiging kumplikado at iba pang data na maaaring mai-play (hal. Rate ng gastos, rate ng suporta, density ng depekto, atbp.). Ang mas maraming gumagalaw na bahagi ay nangangahulugang maraming mga pagkakataon para sa mga error na maganap. Masyado ba tayong kumplikado sa paggawa ngayon? Hindi kami nagbabayad ng mga developer upang magtalaga ng maraming oras sa pagtatantya. Hindi ako makapagbenta ng isang pagtatantya sa aking mga customer. Kailangan ko ng gumaganang software. Mayroon bang iba pa doon?

Agile Aging

Tingnan natin sandali sa mabilis na scrum (sapat lamang upang makagawa ng paghahambing). Tulad ng nakasaad nang mas maaga, ang mga tao ay kahila-hilakbot sa pagtantya ng oras, at medyo mahusay sa paghahambing ng sukat. Narito ang ilang mga tuntunin upang maunawaan:

• Isang sprint - isang oras na may kahon na oras ng oras (karaniwang dalawang linggo).

• Kuwento ng gumagamit - isang discrete na trabaho, mas mabuti na sapat na maliit upang magawa ng isang tao sa isang sprint. Ito ang bagay na tinatantiya namin.

Ang pinakatanyag na diskarte ay ang paggamit ng isang pagkakasunod-sunod ng fibonacci (0, 1, 2, 3, 5, 8, 13) para sa mga pagtatantya. Ito ay hindi linear - sa pag-angat mo sa laki ng pagtaas ng mga puwang. Ang susi ay ang mga puwang ay dapat na sapat na malawak na walang dahilan upang magtalo sa hindi gaanong pagkakaiba. Kapag nakakuha ka ng higit sa 3, ang pagkakaiba sa pagitan ng 4 at 5 o 7 at 8 ay napakabayaan na walang saysay na gumastos ng oras sa pag-hash kung alin ito. Gagana rin ang isang pagkakasunod-sunod na base-2 (0, 1, 2, 4, 8, 16, atbp.).

“Pero teka, number lang ito. Ano ang ibig sabihin nito Ilang oras ang punto? " Ang mga puntos ay hindi inilaan upang maiugnay nang direkta sa mga oras, sapagkat kung gumawa sila ng mga koponan ay matutuksong bumalik sa pagtantya sa oras at pagkatapos ay i-convert ito sa mga punto kahit papaano. Tulad ng tinalakay nang mas maaga, ang kawastuhan ng aming mga pagtatantya ay nagmula sa paghahambing na sukat at hindi tinatantya ang bilang ng mga oras na kukuha ng isang bagay. Kung bibigyan mo ang koponan ng kakayahang mag-isip sa mga tuntunin ng mga oras, kinokompromiso mo ang iyong kakayahang magtantiya nang wasto.

Sabihin nating nagsimula ka sa isang ehersisyo ng pagkakalibrate. Hilahin ang iyong koponan sa isang silid at lakarin sila sa isang listahan ng 10-12 mga kwento ng gumagamit. Pumili ng isa na maliit ngunit hindi ang pinakamaliit at gawin muna ang isa. Suriin ito at ipahayag na ang kuwentong ito ay isang "3". Hindi mo tinatanong. Sinasabi mo. Pagkatapos ay magpatuloy sa susunod na kuwento. "Kung iyon ay isang 3, ano ito?" Ngayon ang koponan ay ang laki ng mga kwento na may kaugnayan sa iba pang mga kwento. Sa paglaon, magkakaroon sila ng magandang ideya kung ano ang bumubuo ng isang "1", isang "2", atbp. Hindi nila tinatantya. Hindi mahalaga ang oras. Nagpapalaki sila ng mga kwento, na may kaugnayan sa iba pang mga kwento na mayroon nang isang bilang. Pagkatapos ay maaari kang maglagay ng mga halimbawa ng mga kwento para sa bawat numero sa pagkakasunud-sunod sa isang dokumento na tinatawag na isang pinuno. Maaari nilang gamitin iyon bilang isang sanggunian kung hindi nila sigurado kung ano ang isang "5".

Ngayon narito ang susi. Ang magic sauce na gumagawa ng gawaing ito ay "bilis" (ang bilang ng mga puntos na maaaring makumpleto ng isang koponan sa isang sprint na may average na 3-4 sprint). Sabihin nating ang iyong sprint ay dalawang linggo at ang iyong pangkat ng 8 katao ay may average na bilis na 35 puntos. Nakakakuha ka ng 35 puntos sa 640 na oras ng trabaho (8 x 80 na oras). Kung malalaman natin na ang isang tampok ay kukuha ng halos 100 puntos na halaga ng trabaho na magsisimulang matapos matapos kong malaman na tungkol sa 6 na linggo ng trabaho at ~ 1900 na oras. Napakahusay ng koponan sa patuloy na pag-laki ng mga kwento, at pinakikinabangan mo iyon upang gawin ang pagpaplano ng iyong proyekto. Gumagawa ang pagkalkula na ito dahil ang tagal ay pare-pareho mula sa sprint hanggang sa sprint.

Upang makagawa ng pangmatagalang pagpaplano sa mataas na antas, maaari mong tanungin ang iyong mga lead na masira ang mga tampok na mataas na antas sa pansamantalang mga kwentong one-liner at ilagay ang mga halagang ito. Magkakaroon ng isang antas ng kawalang katumpakan, ngunit pinapakinabangan mo ang modelo na naiintindihan na nila. Ang isang mas tumpak na landas ay magiging medyo sukat sa antas ng tampok. "Ang tampok na ito ay mas malaki kaysa sa tampok na 40 point, mas maliit kaysa sa tampok na 120 point doon, at bahagyang mas malaki kaysa sa tampok na 65 point na ngayon lang namin ginawa." Ang mga kwento ay pinagsasama sa "epiko". Kung ang bawat tampok ay isang mahabang tula, sa huli malalaman mo kung gaano karaming mga puntos ang kinakailangan upang makumpleto ang tampok na iyon. Panatilihin ang isang kasaysayan niyan at maaari mo itong magamit para sa iyong pagpaplano sa paglabas.

Konklusyon

Mayroong maraming mga pamamaraan na ginagamit ngayon. Ang bawat isa ay may kalamangan at kahinaan. Sa paanuman kailangan nating malaman kung paano i-maximize ang kawastuhan ng aming mga pagtatantya upang makagawa kami ng magagandang desisyon. Hindi nangangahulugan iyon na dapat maging tumpak ang aming mga pagtatantya. Kailangan lang nilang maging sapat na tumpak na kapaki-pakinabang ang mga ito. Kung hindi mo maintindihan ang pagtantya, maaari mong ipalagay na ang mga pagtatantya ay hindi tumpak dahil ang koponan ay hindi gumawa ng magandang trabaho. Hindi nila tinantya nang tama, o hindi sila naipatupad nang tama sa proyekto. Ang pagpapatalo ay magpapatuloy hanggang sa mapabuti ang mga pagtatantya. Ngunit ang mga pagtatantya ay hindi dapat gamitin bilang isang pangako. Ito ay isang pinakamahusay na hulaan batay sa limitadong impormasyon na mayroon kami ngayon. Kapag nag-pop up ang bagong impormasyon, kailangan naming payagan ang mga pagtatantya na muling bisitahin. Anumang iba pa ay umaasa sa imposible, na isang problema sa pamumuno (hindi sa koponan).

Ang diskarte ni Scrum ay mas simple kaysa sa nakikita namin sa pag-aaral ng mga point point. At sasabihin kong mas mapagkakatiwalaan ito kaysa sa mga magic table na may mga magic number. Nakukuha nito ang pinaka-putok para sa usok (kaunting pagsisikap na may isang makatwirang mataas na antas ng kawastuhan). Mula sa isang pananaw sa pagsisikap, hindi ito lumilikha ng isang proseso ng mabibigat na timbang upang maunawaan at magamit ng mga koponan. Ang piraso ng pagtantya ng maliksi ay maaaring mangyari nang napakabilis sa oras na maunawaan ng lahat ang mga detalye ng pagtatantya sa trabaho. Tiyak na mas mahusay ito kaysa sa paghugot ng mga numero mula sa manipis na hangin. Ang paggamit ng bilis ay gumagawa ng isang bagay na napakahalaga: nagdadala ito ng makasaysayang data sa pagkalkula. Tuwing sprint, muling kalkulahin ang bilis mo. Ito ay kritikal, dahil sa paglipas ng panahon ay nagbabago ang mga pagbabago. Ang mga koponan na gumagamit ng FPA ay maaaring makuha ang kanilang rate ng paghahatid mula sa kanilang nakaraang proyekto,na sa ilang mga kaso ay ilang buwan na ang nakakaraan. Marahil maraming nagbago mula noon. Ang aking mungkahi ay para sa iyo upang galugarin ang Agile at talagang magsikap sa pag-unawa sa mga puntos ng kwento at bilis. Huwag bumalik sa pagtantya sa oras dahil lamang sa iyon ang naiintindihan mo. Naniniwala akong magpapasalamat ka sa iyong sarili mamaya.

Mabilis na Poll