Ang Pinaka Kumpletong Gabay sa Pangangasiwa sa Pamamahala at Traceability

Gaano katagal ang Mga Kinakailangan?

Naisip mo na ba kung gaano katagal bago gawin ang mga kinakailangan para sa iyong paparating na proyekto? Madalas itanong ito ng mga analyst at manager ng negosyo.

Para sa karamihan ng mga isyu na may kaugnayan sa software at pagbuo ng produkto, walang one-size-fits-all na sagot; ang tugon ay talagang nakadepende sa iyong natatanging mga kalagayan.

Maraming mga variable ang nag-aambag sa problemang ito, nangunguna sa mga average ng industriya na nagmumungkahi kung anong porsyento ng pagsisikap ng isang proyekto ang dapat italaga sa pagbuo ng mga kinakailangan tulad ng pagtitipon at elicitation.

Paano mo matutukoy ang tamang dami ng oras at pagsisikap na kailangan para sa mga aktibidad tulad ng pagtitipon ng mga kinakailangan? Hindi kataka-taka, ang data mula sa magkakaibang mga benchmark ay hindi palaging nakikipag-jibe sa isa't isa. Pinagtatalunan din kung ang mga "karaniwan" na proyektong ito ay katulad ng sa iyo. Upang matulungan kang lutasin ang isyung ito, inangkop ko ang ilang ideya mula sa aking aklat na “Higit pa tungkol sa Mga Kinakailangan sa Software” sa artikulong ito – tingnan ito!

Mga Benchmark sa Industriya

Upang magbigay ng isang halimbawa ng potensyal na pagiging kapaki-pakinabang ng mga benchmark, mangyaring sumangguni sa Talahanayan 1. Ang ipinakitang data ay nagpapahiwatig ng mga average ng industriya para sa iba't ibang mga kinakailangan sa elicitation at prototyping na pagsisikap tungkol sa mga proyekto na may sukat na 10,000 function point (humigit-kumulang isang milyong linya ng code), na nagmula sa "Mga Pagsusuri sa Software, Mga Benchmark, at Pinakamahuhusay na Kasanayan" ni Capers Jones. Gaano kahalaga ang mga figure na ito sa iyong sariling proyekto?

Ang paggamit ng mga benchmark ng industriya tulad ng mga ito ay walang mga disbentaha nito. Nabigo ang data na sabihin sa amin kung ang mga proyekto ay tunay na matagumpay o kung mayroong anumang ugnayan sa pagitan ng tagumpay at mga pagsisikap na inilagay sa pagkuha ng mga kinakailangan. Ang impormasyong ito ay nagbibigay lamang sa amin ng average ng kung ano ang ginawa, kaya nahihirapang tumpak na ilarawan ang tagumpay ng bawat indibidwal na proyekto.

Ang paglalaan ng 10% o mas kaunti sa mga pagsusumikap ng koponan sa mga gawain tulad ng pangangalap ng mga kinakailangan ay maaaring mapatunayang kapaki-pakinabang, sa kondisyon na hindi sila natigil sa paralisis ng pagsusuri. Taliwas sa popular na paniniwala na ang pamumuhunan ng mas mataas na halaga ng pagsisikap sa pagpapahusay ng iyong proseso ng pag-unlad ng kinakailangan ay talagang magpapabilis ng produksyon. Ang paggamit sa konseptong ito ay nagbibigay ng napakalaking return on investment para sa anumang proyekto!

Habang nagtatrabaho ako sa mas maliliit na proyekto kapag nagtatrabaho sa Kodak, madalas na naglalaan ang aming koponan ng 15% hanggang 18% ng kabuuang pagsisikap sa mga aktibidad na kinakailangan. Nalaman namin na binawasan ng pamumuhunan na ito ang dami ng mga pagbabagong kailangan pagkatapos ng paghahatid. Nakakalito na ikonekta ang mga sanhi at epekto nang may katiyakan, ngunit malamang na ang aming mababang rate ng pagpapanatili ay higit sa lahat ay dahil sa paglinang ng makabuluhang pakikilahok ng user.

Ang pagsisikap na malaman kung gaano karaming oras ang kakailanganin para sa iyong susunod na proyekto ay isang nakakalito na tanong, at maaaring mahirap sukatin nang tumpak. Ngunit sa kabutihang-palad, ang Figure 1 ay nagbibigay sa amin ng ilang pananaw sa mga variable na maaaring paikliin o pahabain ang nasabing proseso; na tumutulong sa iyong tantiyahin nang mas epektibo kapag gumagawa ng mga kinakailangang kinakailangan.

Sariling Karanasan

Upang magsimula, maaaring kapaki-pakinabang na suriin ang data mula sa mga nakaraang proyekto upang matukoy kung anong uri ng pagsisikap ang partikular na nakatuon sa pangangalap ng mga kinakailangan. Ito ay magbibigay-daan sa iyo upang masuri kung gaano naging matagumpay ang iyong proseso ng pag-unlad sa nakaraan at gamitin ang impormasyong ito kapag tinatantya ang gastos nito para sa mga pagsusumikap sa hinaharap. Bilang karagdagang salik, ayusin ang iyong mga paunang pagtatantya sa pamamagitan ng pagtukoy sa Figure 1 na nagbabalangkas ng mga pagkakaiba sa pagitan ng mga paparating na proyekto at mga benchmark pati na rin ang pagsasaalang-alang sa anumang iba pang nauugnay na pagsasaalang-alang tungkol sa iyong proyektong nasa kamay. Sa pamamagitan ng pagtatasa sa bawat isa sa mga elementong nakalista sa Figure 1 sa isang sukat mula 0 (walang impluwensya) hanggang 5 (mahusay na epekto), ang pagsusuring ito ay makakatulong sa iyo na matukoy ang mga salik ng panganib na maaaring magpalawig sa proseso ng pagbuo ng iyong mga kinakailangan.

Sa tabi ng iba pang mga elemento, mahalagang isaalang-alang ang ikot ng buhay ng proyekto. Huwag ipagpalagay na ang lahat ng mga kinakailangan ay dapat maipon sa simula tulad ng sa isang sequential o waterfall approach (inilalarawan ng may tuldok na linya sa Figure 2). Sa halip na magkaroon ng natatanging "bahagi ng mga kinakailangan," mag-isip tungkol sa isang hanay ng mga kinakailangan na dumadaan sa bawat yugto ng pag-unlad. Habang umuunlad ang ating System Requirements Specification (SRS) at nagsisimulang lumitaw ang mga kahilingan sa pagbabago, dapat tayong manatiling masigasig sa aktibong pamamahala sa mga baseline ng kinakailangan. Ito ay isang patuloy na proseso na nangangailangan ng pare-parehong atensyon.

Mga Paulit-ulit at Incremental na Pagdulog

Ang mga diskarte sa mabilis na pag-unlad, tulad ng Scrum, ay dumaan sa isang progresibong ruta. Nagbibigay-daan ito sa mga user na makuha ang kanilang mga kamay sa mga potensyal na kapaki-pakinabang na feature ng produkto nang mabilis at madaling baguhin ang kanilang mga kinakailangan kung kinakailangan. Sa gayon ang mga developer ay maaaring makasabay sa patuloy na pagbabago ng mga pangangailangan ng negosyo nang walang kahirap-hirap. Sa maliksi na mga proyekto, bihirang kailanganin ang malalaking inisyatiba sa paghingi dahil sa maliit ngunit regular na pagsisikap sa pagkolekta ng kinakailangan (solid na linya sa Figure 2).

Sa halip na nakatuon sa simula ng proyekto, ang mga kinakailangan na pagsisikap sa isang maliksi na proyekto ay kumakalat sa iba't ibang yugto. Ang mga paunang paggalugad ay humahantong sa isang backlog na nagdedetalye ng functionality batay sa antas ng priyoridad nito. Kapag oras na para sa pag-unlad at pagsubok, pinipino ng mga koponan ang mga kinakailangan upang magkaroon sila ng sapat na detalye upang magpatuloy nang may kumpiyansa sa bawat pag-ulit.

Ilang taon na ang nakararaan, bahagi ako ng isang software development team na gumamit ng incremental na diskarte upang matiyak ang tagumpay. Bawat cycle, ang aming proyekto ay ilalabas sa tatlong linggong yugto na ang unang bahagi ay nakatuon sa pagpaplano ng mga kinakailangan at pagbuo para sa partikular na pagtaas na iyon. Kami ay natugunan ng magagandang resulta mula sa paraang ito dahil nagdadala ito ng kapaki-pakinabang na paggana bawat ilang linggo sa corporate user base. Masigasig na nagtrabaho ang team upang mabilis na makapaghatid ng bagong functionality nang paunti-unti, na nagbibigay sa mga user ng madalas na pag-update. Napakahalaga ng mga insight ng user na ito para sa paggabay sa proyekto at pagtulong na matiyak na ang pinakamataas na halaga ay nakakamit sa pamamagitan ng pagkumpleto nito.

Hindi lahat ng inisyatiba ay angkop para sa paghahatid sa maliliit na piraso. Kapag muling bubuo ng isang umiiral na application, ang bagong system ay dapat magkaroon ng isang malaking antas ng pag-andar bago ang mga gumagamit ay maaaring lumipat dito. Hindi alintana kung gaano karami ang nakumpleto ng iyong koponan sa bawat ikot ng proyekto, kailangan nilang maunawaan ang mga kinakailangan para sa partikular na pagkakasunud-sunod na iyon upang maiwasan ang anumang mga nahugot na redo at muling pagsulat ng mga disenyo, code, o mga pagsubok.

Mga Kinakailangan sa Pagpaplano Elicitation

Madalas itong mas kumplikado kaysa sa lumalabas kapag sinimulan mong i-compile ang mga kinakailangan para sa isang bagong proyekto. Kapag nag-brainstorming ng mga aktibidad na kailangang gawin ng iyong mga analyst, tandaan kung kailangan nilang gampanan ang mga tungkulin tulad ng mga ito:

Paglinang ng mga relasyon sa mga kampeon ng produkto sa pamamagitan ng negosasyon.
Pagkalap ng mga insight sa pamamagitan ng mga interactive na workshop at malalalim na panayam.
Pagsusuri ng mga kasalukuyang tala at produkto upang matuklasan ang mga potensyal na pagpapabuti.
Pagbuo, pagpapakalat, at pag-decipher ng mga survey.
Pagdidisenyo, at pagtatasa ng mga prototype, pag-aaral ng mga modelo, at iba pang mga pananaw na kinakailangan para sa tagumpay.
Pagkamit ng tagumpay sa pamamagitan ng pagtatasa ng panganib, pagtiyak na sinusunod ang mga protocol sa kaligtasan at seguridad, pagsusuri ng mga potensyal na pagkabigo, at pagsasagawa ng mga pagsusuri sa peligro.
Pagla-log ng mga detalye ng iyong mga pangangailangan sa isang imbakan ng data.
Maingat na sinusuri ang mga hinihingi na nakadetalye sa mga detalye ng mga kinakailangan.
Paggawa ng mga test case mula sa mga nakalistang kinakailangan, at masusing sinusuri ang kanilang performance.
Pagkatapos ng masusing pagsusuri o pagsubok, ayusin ang mga detalye ng kinakailangan upang matiyak ang katumpakan.

Upang mas mahusay na matantya ang pagsisikap na kailangan para sa mga proyekto sa hinaharap, mahalagang matutunan ang tungkol sa iba't ibang mga gawain na maaaring kailanganin ng iyong koponan bilang bahagi ng mga kinakailangan sa elicitation, analysis, specification, at validation. Ang kaalamang ito ay higit pang tutulong sa iyo na maunawaan kung gaano katagal ang bawat gawain ay kinasasangkutan at makakatulong sa pagpapabuti ng pagganap ng iyong proyekto. Hindi ito nangangahulugan na ang lahat ng mga aktibidad ay kailangang gawin sa bawat pakikipagsapalaran ngunit sa halip na maunawaan kung ano ang kailangang gawin ay humahantong sa daan patungo sa isang matagumpay na resulta.

Huwag kalimutang ibahagi ang post na ito!