Ang Pinaka Kumpletong Gabay sa Pangangasiwa sa Pamamahala at Traceability

Ang mga kinakailangan ay dapat magkaroon ng kalidad kung ang proyekto ay magiging matagumpay. Sa pamamagitan ng pagtatakda ng mga pamantayan at kundisyon, masusuri ng mga koponan ang kanilang pag-unlad patungo sa pag-abot sa mga layuning iyon. Ang mga sukatan na ginamit ay mag-iiba depende sa gawaing ginagawa; gayunpaman, ang ilang pangkalahatang tagapagpahiwatig para sa mga kinakailangan sa pagsubaybay ay kinabibilangan ng:

Saklaw ng Pagsubok - Ilan sa mga function ng bawat system ang nasubok?
Katumpakan ng Pagtatasa – Mayroon bang mataas na antas ng kawastuhan sa mga pagtutukoy?
Pagkumpleto ng Pag-andar - Ang lahat ba ng mga lugar ng pag-andar ay tinukoy sa sapat na detalye?
Kalinawan ng Pamantayan sa Pagtanggap – Madali bang matukoy ang pamantayan sa pagtanggap ng user mula sa dokumentasyon?
Baguhin ang mga Kahilingan - Anong bilang ng mga kahilingan sa pagbabago ang naihain mula nang isulat ang mga pagtutukoy?

Sa pamamagitan ng regular na pagsukat sa mga salik na ito ng husay, matutukoy mo kung saan kailangang ituon ng iyong koponan ang kanilang mga pagsisikap at pagbutihin ang kalidad ng iyong mga proyekto.

Paano Sukatin ang Kalidad ng Mga Kinakailangan

Bakit Mahalagang Masuri ang Kalidad ng mga Kinakailangan?

Dapat muna nating tukuyin kung mayroon tayong problema sa mga kinakailangan at kung gaano ito kalaki ng isyu upang tumpak na kalkulahin ang dami ng pagsisikap na kailangan para sa pagbabago ng ating mga hindi sapat na mapagkukunan sa mga kasiya-siya.
Bilang mga superbisor, sinisikap naming matiyak na ang aming koponan ay gumagana nang produktibo habang gumagawa ng isang detalye ng mga kinakailangan o nagsasagawa ng pagsusuri ng mga kinakailangan. Natutugunan ba nila ang kanilang mga layunin?
Isinasaalang-alang ang magkakaibang mga sitwasyon, nagtayo kami ng benchmark para sa aming mga pagtutukoy ng kinakailangan sa mga tuntunin ng halaga ng isang sukatan ng kalidad ng pamantayan. Nagtakda kami ng apat na halaga upang ipakita ang bawat sitwasyon ayon sa pagkakabanggit:
- Ang paggawa ng isang orihinal na nobela sa isang mahirap na kapaligiran ay hindi madaling gawa.
- Gumagawa ng isang makabagong salaysay nang walang anumang presyon o limitasyon.
- Makamundong pag-unlad
- Pagkuha ng mga bagay na hindi pang-unlad
Upang matiyak ang pinakamataas na kalidad para sa aming mga proyekto, nagtatatag kami ng isang benchmark para sa Mga Pagsusuri ng Mga Kinakailangan sa System at mga entry sa Pagsusuri ng Mga Kinakailangan sa Software.

Pagdating sa mga sukatan ng engineering, ang sukatan ng kalidad ng mga kinakailangan ay isa sa mga pinakamakapangyarihang tool na magagamit. Pagkatapos ng lahat, sa kasaysayan, ang pagbuo ng isang bagay na naiiba kaysa sa kung ano ang inilaan sa una ay isang karaniwang problema para sa mga inhinyero. Habang ang paggamit ng isang layunin na pamantayan ay hindi magagarantiya ng perpektong mga resulta sa bawat oras, maaari nitong lubos na mabawasan ang mga potensyal na panganib at mga depekto sa huling produkto.

Sukat ng produkto

Ang pag-unawa sa bilang ng mga kinakailangan sa isang proyekto ay mahalaga. Magagawa ito sa pamamagitan ng mga kaso ng paggamit, mga kinakailangan sa pagganap, mga kwento ng user, mga paglalarawan ng tampok, mga talahanayan ng pagtugon sa kaganapan, o mga modelo ng pagsusuri. Gayunpaman, ang pagpili ng iyong koponan na kumatawan sa mga kinakailangang ito ay hindi nakakaapekto sa kanilang pangunahing pag-andar – ang pagpapatupad ng mga gawi ng system batay sa mga partikular na kundisyon at mga pangangailangan sa pagganap.

Simulan ang proseso ng pagtatasa ng iyong mga kinakailangan sa pamamagitan ng pagbibilang ng mga indibidwal na kinakailangan sa paggana na inilalaan sa isang paglabas ng produkto o pag-ulit ng pag-develop. Kung ang iba't ibang indibidwal ay hindi makakakuha ng mga katulad na resulta kapag sila ay nagbibilang, mahalagang isaalang-alang ang iba pang uri ng mga hindi pagkakaunawaan at ambiguity na maaaring lumitaw sa hinaharap. Kailangan mong malaman ang bilang ng mga kinakailangan na bumubuo sa isang release upang tumpak na masubaybayan ang pag-unlad ng iyong koponan. Kung wala ang kaalamang ito, wala kang anumang paraan upang masukat kapag natapos mo na ang proyekto! Ang pagsubaybay sa kung gaano karaming trabaho ang natitira pa sa iyong backlog ay nagsisiguro na nauunawaan ng lahat kung ano ang kailangang mangyari bago makumpleto.

Upang matiyak na ang iyong mga kinakailangan sa paggana ay isang tumpak na sukat ng laki ng system, ito ay mahalaga para sa mga analyst na gawin ang mga ito sa isang pare-parehong antas ng detalye. Ang isang mahusay na paraan upang gawin ito ay sa pamamagitan ng paghahati-hati ng mga kinakailangan sa mataas na antas sa mas maliliit na bahagi ng bata na maaaring masuri nang paisa-isa. Sa madaling salita, ang mga tagasubok ay dapat magdisenyo ng mga simpleng pagsubok na magtatatag kung ang bawat kinakailangan ay naipatupad nang tama o hindi. Tinitiyak nito na ang lahat ng mga gawain ay nangangailangan ng parehong dami ng pagpapatupad at pagsusumikap sa pagsubok anuman ang kanilang pagiging kumplikado. Upang matiyak na maayos na maipapatupad at masusubok ng mga developer at tester ang bawat kinakailangan, mahalagang subaybayan kung gaano karaming kinakailangan ng bata ang mayroon. Kasama sa iba pang mga alternatibong paraan ng pag-size ang mga use case point at story point, na lahat ay sumusukat sa tinantyang pagsisikap na kailangan para sa partikular na tinukoy na bahagi ng functionality.

Bagama't mahalaga ang mga kinakailangan sa pagganap, hindi rin maaaring palampasin ang mga hindi gumagana. Ang mga partikular na kahilingang ito ay nangangailangan ng mas mataas na dami ng pagsisikap na magdisenyo at maipatupad nang epektibo. Ang ilang partikular na functionality ay nakadepende sa mga nakalistang nonfunctional na pangangailangan tulad ng mga alalahanin sa seguridad, na dapat ay kinakatawan sa tinantyang laki para sa mga functional na feature. Gayunpaman, hindi lalabas dito ang lahat ng hindi gumaganang pagnanasa—ang pagtitiyak na isasaalang-alang ang impluwensya nito sa iyong pagtatantya ay kritikal! Isaalang-alang ang mga sumusunod na sitwasyon:

Ang pagbibigay ng maraming pathway para gumamit ng isang partikular na feature ay nagpapaganda sa karanasan ng user; gayunpaman, ang naturang gawain ay nangangailangan ng mas maraming oras at lakas mula sa mga developer kaysa sa kung isang paraan lamang ng pag-access ang magagamit.
Kahit na hindi ka nagpapatupad ng mga bagong feature ng produkto, ang sapilitang disenyo at mga hadlang sa pagpapatupad tulad ng mga panlabas na interface upang ma-accommodate ang isang umiiral nang operating environment ay maaaring makabuluhang tumaas ang dami ng kailangang trabaho sa interface.
Upang matiyak ang pinakamataas na pagganap, maaaring kailanganin ang maselang algorithm at gawaing disenyo ng database upang magarantiya ang mabilis na mga tugon.
Upang matugunan ang mahigpit na mga kinakailangan sa pagkakaroon at pagiging maaasahan, kinakailangan na bumuo ng mga mekanismo ng failover at pagbawi ng data na maaaring magtagal. Bukod pa rito, ang arkitektura ng system na pipiliin mo ay maaaring maapektuhan din ng mga kahilingang ito.

Sa pamamagitan ng pagsubaybay sa pagtaas ng mga kinakailangan sa paglipas ng panahon, anuman ang sukatan ng sukat na ginamit, makakakuha ka ng mga kapaki-pakinabang na insight. Napansin ng aking kliyente na ang kanilang mga proyekto ay karaniwang tumaas ng humigit-kumulang dalawampu't limang porsyento bago ang paghahatid. Bukod pa rito, karamihan sa kanilang mga proyekto ay tumakbo nang hindi bababa sa dalawampu't limang porsyento na mas mahaba kaysa sa inaasahan! Walang pagkakataon dito — malinaw na may koneksyon ang dalawang trend na ito.

Kalidad ng mga Kinakailangan

Maglaan ng ilang oras upang sukatin ang kalidad ng iyong mga kinakailangan sa pamamagitan ng pagsasagawa ng mga inspeksyon sa mga ito. Idokumento ang anumang mga depektong makikita mo at hatiin ang mga ito sa iba't ibang kategorya, tulad ng mga nawawalang kinakailangan, mga hindi tama, mga hindi kailangan, kawalan ng katiyakan, atbp. Pagkatapos, suriin ang mga uri ng depekto na ito kasama ang ugat ng mga ito upang ang mga kahilingan sa hinaharap ay magawa nang tama mula simula hanggang matapos. Gamitin ang data na ito bilang isang pagkakataon para sa pagpapabuti upang mapalakas ang kahusayan ng iyong proseso ng kinakailangan! Halimbawa, kung matukoy mo na ang mga nawawalang kinakailangan ay karaniwang isang paulit-ulit na isyu, kailangan mong baguhin ang iyong mga paraan ng pag-elicitation. Posible na ang iyong mga analyst ng negosyo ay hindi humihingi ng sapat o tamang mga query, o marahil ay kailangan mong isama ang mas angkop na mga kinatawan ng user sa proseso ng pagbuo ng mga pangangailangan.

Kung ang koponan ay nahihirapan sa oras kapag sinusuri ang lahat ng kanilang dokumentasyon ng mga kinakailangan, ang isang mas mahusay na pagpipilian ay ang pag-inspeksyon ng ilang mga pahina at pagkatapos ay kalkulahin ang average na density ng depekto—ang bilang ng mga depekto sa bawat pahina ng detalye. Kung ipagpalagay na ang sample na ito ay tumpak na sumasalamin sa buong dokumento (na maaaring isang palagay), ang pagpaparami nito sa mga hindi na-inspeksyong pahina ay maaaring magbigay sa amin ng pagtatantya kung gaano karaming mga nakatagong bug ang maaaring manatili sa aming mga detalye. Maaaring hindi matukoy ng mga walang karanasan na inspektor ang lahat ng mga depekto, kaya gamitin ang tinantyang bilang ng mga walang batik-batik na mga depekto bilang isang minimal na pagtatantya. Sa pamamagitan ng paggamit ng inspeksyon sampling, maaari mong masuri ang kalidad ng dokumento at magpasya kung ito ay pinansyal na magagawa upang siyasatin ang iba pang detalye ng mga kinakailangan – na walang alinlangan na magiging oo!

Bukod pa rito, ang mga depekto sa mga kinakailangan sa pagtatala ay natuklasan pagkatapos maitatag ang baseline. Ang mga isyung ito ay hindi napapansin sa panahon ng kontrol sa kalidad habang binubuo ang mga kinakailangan. Kalkulahin ang rate ng tagumpay ng iyong koponan sa paghahanap ng mga error na ito sa maagang yugtong ito – ito ay magiging mas matipid kaysa sa pagtatangkang ayusin ang mga ito kapag nakumpleto na ang disenyo at coding!

Ang data ng inspeksyon ay maaaring magbigay sa iyo ng dalawang napakahalagang sukatan: kahusayan at pagiging epektibo. Sinusukat ng kahusayan ang average na bilang ng mga depekto na nakita sa bawat oras ng paggawa, habang ang Epektibo ay nagpapahiwatig kung anong proporsyon ng lahat ng umiiral na mga depekto ang natukoy sa pamamagitan ng inspeksyon – isang panukalang nagbibigay ng indikasyon kung gaano naging matagumpay ang iyong mga inspeksyon (o iba pang mga kasanayan sa pagtiyak ng kalidad). Ang kahusayan ay nagbibigay-daan sa iyo na tantyahin ang halaga ng pagtuklas ng isang depekto sa pamamagitan ng inspeksyon. Maaari mong timbangin ang gastos na ito laban sa halagang ginastos sa paghawak ng mga depekto sa mga kinakailangan na makikita sa susunod na pag-unlad o pagkatapos ng paghahatid, na nagbibigay-daan sa iyong matukoy kung ang pagpapahusay sa kalidad ng iyong mga kinakailangan ay sulit sa pananalapi.

Katayuan ng Mga Kinakailangan

Upang manatili sa tuktok ng proyekto, subaybayan ang bawat kinakailangan sa buong buhay nito. Maaari ka ring magtalaga ng halaga ng katangian upang iimbak ang impormasyong iyon para sa karagdagang seguridad at katumpakan. Ang ganitong uri ng pagsubaybay sa status ay makakatulong na bawasan ang karaniwang problema sa mga proyekto ng software – maling sinasabing ito ay "siyamnapung porsyentong tapos na". Ang bawat kinakailangan ay dapat magkaroon ng isa sa mga katayuang ito sa anumang partikular na takdang panahon:

Nagtaguyod (isang taong masiglang sumuporta dito)
Ang proseso ng pag-apruba ay matagumpay at ang alokasyon ay inilagay sa isang baseline.
Pagkatapos ng maingat na paggawa, pag-script, at pagsubok sa code, ipinatupad namin ito.
Kapag ang kinakailangan ay sumailalim at pumasa sa mga pagsubok nito, ito ay na-verify para sa matagumpay na pagsasama sa produkto.
Ang pangangailangang ito ay matutupad sa ibang araw.
Nagpasya kang Tanggalin ito at hindi ito ipatupad.
Na-dismiss (ang konsepto ay hindi kailanman binigyan ng berdeng ilaw)

Bukod sa mga nabanggit na opsyon sa status, maaaring isaalang-alang ang iba pang mga status. Ang ilan ay maaaring mag-opt para sa isang status na "Nasuri" upang patunayan ang kanilang mga kinakailangan bago idagdag ang mga ito sa mga baseline na configuration. Bilang kahalili, maaaring gamitin ng mga organisasyon ang "Naihatid sa Customer" bilang isang paraan ng pag-verify na inilabas nila ang kinakailangan nang maayos at tama.

Kung magtatanong ka tungkol sa pag-unlad ng isang developer, maaari niyang sagutin na mayroong 87 na kinakailangan para sa partikular na proyektong ito. 61 na ang nakumpirma at 9 ang nasa lugar ngunit nakabinbin pa rin ang verification habang 17 ang nananatiling pinal. Gayunpaman, mahalagang tandaan na ang mga kahilingang ito ay hindi lahat ay tumutugma pagdating sa laki o epekto sa kasiyahan ng customer; maaaring mangailangan din sila ng iba't ibang dami ng pagsisikap. Bilang isang tagapamahala ng proyekto, wala akong duda na mayroon kaming tumpak na pag-unawa sa laki ng subsystem at kung gaano ito kalapit sa pagkumpleto. Ito ay mas epektibo kaysa sa simpleng pagsasabi ng "Ako ay halos siyamnapung porsiyentong tapos na". Sa pangkalahatang larawan ng pag-unlad, masasabi kong may kumpiyansa akong “napakaganda nito!”

Pagbabago ng mga Kahilingan

Upang makamit ang matagumpay na pangangasiwa ng mga kinakailangan, dapat asikasuhin ng iyong organisasyon ang bawat pagdaragdag, pagtanggal at pagbabago ng kinakailangan. Ito ay magbibigay-daan sa iyong subaybayan ang katayuan pati na rin ang mga implikasyon ng lahat ng mga kahilingan sa pagbabago. Maaari mo ring gamitin ang data na ito upang sagutin ang ilang katanungan sa pagtatanong tulad ng:

Ilang kahilingan para sa pagbabago ang ginawa sa loob ng itinalagang takdang panahon?
Ilan sa mga kahilingan ang nasagot at ilan ang nananatiling hindi nalutas?
Ano ang rate ng pag-apruba para sa mga kahilingan, at ilang porsyento ang tinanggihan?
Gaano kalawak ang paggastos ng koponan ng lakas upang maisagawa ang bawat awtorisadong pagbabago?
Ano ang karaniwang haba ng oras na nananatiling bukas ang mga kahilingan?
Sa karaniwan, gaano karaming mga item (hal., mga kinakailangan o artifact) ang naaapektuhan ng bawat isinumiteng kahilingan sa pagbabago?

Tiyaking sinusubaybayan mo ang anumang mga pagbabagong ginawa sa panahon ng proseso ng pagbuo pagkatapos magtakda ng baseline para sa bawat release. Tandaan, ang isang kahilingan sa pagbabago ay maaaring magkaroon ng epekto sa maraming pangangailangan ng iba't ibang uri (naka-orient sa gumagamit, gumagana at hindi gumagana). Upang masuri kung gaano karaming mga pagbabago ang dumaan sa isang partikular na yugto ng panahon, hatiin ang bilang ng mga pagbabago sa kabuuang halaga ng mga kinakailangan bago ang panahong ito (tulad ng kapag tinukoy ang iyong baseline).

Hindi namin gustong ganap na alisin ang pagkasumpungin ng mga kinakailangan. Pagkatapos ng lahat, kadalasan ay may lehitimong katwiran para sa pagbabago sa mga ito. Ngunit sa parehong oras, kailangan nating tiyakin na ang ating proyekto ay makakayanan ang mga pagbabago at matutugunan pa rin ang mga obligasyon nito. Ang paglapit sa pagkumpleto ay magkakaroon ng mga karagdagang gastos kapag ang mga pagbabago ay ginagawa nang madalas; ginagawa nitong mahirap matukoy kung kailan mo ilalabas ang iyong produkto sa mundo! Habang umuunlad ang pag-unlad, karamihan sa mga proyekto ay dapat na maging mas matatag sa mga pagbabago; sa madaling salita, dapat na unti-unting bumaba ang rate ng pagtanggap ng pagbabago hanggang sa umabot ito sa zero kapag natapos na ang release. Ang umuulit na diskarte ay nagbibigay sa mga koponan ng maraming pagkakataon para sa pagsasama ng mga pagpapabuti sa mga susunod na pag-ulit habang nananatili pa rin sa track sa timeline ng bawat cycle.

Kung ang iyong koponan ay binaha ng mga kahilingan sa pagbabago, malamang na ang proseso ng elicitation ay hindi komprehensibo o patuloy na lumalabas ang mga ideya habang umuusad ang proyekto. Dahil dito, mahalagang subaybayan kung saan nagmumula ang mga pagbabagong ito sa marketing, user, salespeople, management team atbp. Ang pagsubaybay sa impormasyong ito ay tutulong sa iyo sa pagtukoy kung sino at ano ang nangangailangan ng pansin upang mabawasan ang hindi napapansin na mga kinakailangan at maiwasan ang miscommunication sa hinaharap.

Kapag ang mga kahilingan sa pagbabago ay nananatiling hindi naresolba sa mahabang panahon, ito ay isang malinaw na indikasyon na ang iyong proseso ng pamamahala sa pagbabago ay nangangailangan ng ilang pansin. Personal kong nasaksihan ang isang organisasyon na may mga kahilingan sa pagpapahusay na maraming taon na at nakabinbin pa rin. Para bigyang-priyoridad ng project manager ang kanilang lakas sa pinakamahahalagang item sa backlog, dapat magtalaga ang team na ito ng mga partikular na bukas na kahilingan sa mga nakaplanong release ng maintenance at i-convert ang iba pang pangmatagalang ipinagpaliban na mga pagbabago bilang mga tinanggihan. Sa ganitong paraan mas madali nilang matutugunan kung ano ang mahalaga at apurahan bago harapin ang anumang hindi gaanong mahahalagang bagay.

Oras at Pagsisikap

Upang matiyak ang pinakamainam na performance, lubos naming iminumungkahi na itala mo ang dami ng oras na ginugugol ng iyong koponan sa mga kinakailangan sa mga gawaing pang-inhinyero. Kabilang dito ang paggawa ng mga kinakailangan sa kalidad at pamamahala ng pagbabago, pagsubaybay sa pag-unlad, paggawa ng data ng traceability, at iba pang aktibidad na nauugnay sa prosesong ito.

Madalas akong tinatanong ng mga tao kung gaano karaming oras at lakas ang dapat ilaan sa mga pangangailangan ng isang proyekto. Ang sagot na ito ay lubos na nakadepende sa laki, koponan, organisasyong bumubuo nito, at layunin nito. Ang pagsubaybay sa iyong mga pagsisikap na namuhunan sa mga kritikal na gawain para sa mga proyektong tulad nito ay makakatulong sa iyong mas mahusay na magplano ng mga hinaharap na may tumpak na mga pagtatantya.

Kung ang iyong koponan ay dati nang nakakumpleto ng isang proyekto at naglaan ng 10% ng oras nito sa mga kinakailangan, sa pagmumuni-muni ay maaaring napansin mo na ang kalidad ng mga kinakailangang iyon ay maaaring mas mapabuti. Kung nahaharap sa isa pang katulad na proyekto, makabubuti para sa Project Manager na tiyaking mas maraming pagsisikap ang ibibigay sa paglikha ng masusing mga detalye - higit sa sampung porsyento ng kabuuang magagamit na mga mapagkukunan ay dapat sapat na!

Habang nangongolekta at nagsusuri ka ng data, ihambing ang pagsusumikap sa pagbuo ng proyekto sa sukat ng laki ng produkto. Ang iyong mga dokumentong kinakailangan ay magbibigay ng ideya sa kabuuang sukat nito. Upang maging mas tumpak, maaari mong iugnay ang pagsusumikap upang mabilang ang nasusubok na mga indibidwal na detalye, gamitin ang mga punto ng kaso, o mga punto ng paggana – anuman ang proporsyonal sa mga sukat ng iyong produkto. Ang pagtukoy sa Figure 1 sa kontekstong ito ay nagbubunga ng panukat para sa pagsusuri ng mga kakayahan ng iyong development team na higit pang nakakatulong sa pagtataya ng mga nilalaman ng paglabas pati na rin sa saklaw ng mga ito nang tumpak! Sa pamamagitan ng pangangalap ng data na nauugnay sa laki para sa iyong produkto at pagpuna sa nauugnay na pagsusumikap sa pagpapatupad, maaari kang magbalangkas ng mga tumpak na pagtatantya bilang paghahanda para sa mga katulad na proyekto sa hinaharap.

Maaaring manatili ang takot sa isipan ng marami; takot na ang pagbuo ng isang software measurement program ay magnanakaw ng mahalagang oras mula sa mahahalagang gawain. Sa kabaligtaran, ang pagpapatupad ng isang mahusay at naka-target na sistema ng sukatan ay hindi nangangailangan ng labis na pagsisikap o enerhiya. Ang kailangan mo lang gawin ay bumuo ng isang pangunahing imprastraktura para sa pagkolekta at pagsusuri ng data, pati na rin hikayatin ang mga miyembro ng iyong koponan na mag-log ng ilang nauugnay na detalye tungkol sa kanilang mga aktibidad sa trabaho. Kapag lumikha ka ng isang kultura batay sa mga sukatan sa loob ng iyong kumpanya, kamangha-mangha kung ano ang matututuhan ng isa sa pamamagitan ng pamamaraang ito!

Konklusyon

Ang elicitation at analysis ng mga kinakailangan ay mahalagang bahagi ng software development. Kung wala ang mga ito, maaaring mabigo ang isang proyekto dahil sa nawawala o hindi tamang mga detalye, na humahantong sa magastos na muling paggawa at posibleng hindi kasiya-siyang resulta. Samakatuwid, mahalagang tiyakin na mayroon kang mahusay na proseso para sa pangangalap ng mga kinakailangan at pag-verify ng katumpakan sa buong timeline ng proyekto. Sa wastong pamamahala, makakamit ng mga koponan ang tagumpay sa pamamagitan ng paglikha ng mga detalyadong kinakailangan na tumpak na naglalarawan sa lahat ng nais na paggana, na tinitiyak na walang napapalampas. Sa pamamagitan ng regular na pagsusuri sa mga kasalukuyang proseso at sukatan sa bawat pakikipagsapalaran, mas mauunawaan ng mga team kung ano ang pinakamahusay para sa kanila kapag naghahanap ng feedback ng user sa mga yugto ng pag-develop. Makakatulong ito na panatilihin ang mga proyekto sa track at mag-ambag patungo sa mas mataas na kalidad na mga resulta.

Huwag kalimutang ibahagi ang post na ito!