Kapag sinimulan mo nang maghanda ng isang seryosong proyekto, isa sa mga unang mahahalagang desisyon ay ang pagpili ng pamamaraan ng pamamahala na iyong susundin. Hindi ito maliit na detalye: ang pagpaplano, ang paraan ng iyong pakikipagtulungan sa kliyente, ang dokumentasyon, ang mga deadline, at maging ang mga uri ng pagkakamali na iyong makakaharap sa proseso ay lahat nakasalalay sa pagpiling ito.
Sa loob ng saklaw na ito, ang metodolohiya ng Waterfall ay nananatiling isa sa mga pinakakilala. Bagama't malawakang tinatalakay ang Agile, Scrum, at Kanban, ang Waterfall ay patuloy na buhay na buhay sa mga sektor kung saan ang katatagan, kakayahang mahulaan, at komprehensibong dokumentasyon ay mas mahalaga kaysa sa ganap na kakayahang umangkop. Sa komprehensibong gabay na ito, ipapaliwanag ko, hakbang-hakbang, kung ano ang Waterfall, saan ito nagmula, paano ito nakabalangkas, kailan ito makatuwiran na gamitin, paano ito naiiba sa Agile, at paano ito umaangkop sa modernong pamamahala ng proyekto.
Ano ang metodolohiya ng Waterfall?
Ang metodolohiyang Waterfall ay isang linear at sequential na modelo ng pag-unlad kung saan ang isang proyekto ay umuusad nang paunti-unti, nang walang sistematikong mga balakid. Ang pangalang "talon" ay nagmula mismo sa larawang ito: ang bawat yugto ay nagbubuhos ng mga resulta nito sa susunod, tulad ng tubig na bumabagsak mula sa isang hakbang patungo sa isa pa, at kapag nakababa ka na sa isang hakbang, napakahirap nang bumalik sa itaas.
Sa pagsasagawa, nangangahulugan ito na ang siklo ng buhay ng proyekto ay nakukumpleto nang isang beses lamang, mula simula hanggang katapusan : una, tinitipon ang lahat ng mga kinakailangan; pagkatapos, dinisenyo ang solusyon; kasunod, ipinapatupad ito, beripikahin, at sa huli, inilalagay sa serbisyo at pinapanatili. Ang bawat yugto ay dapat na ganap na makumpleto at maaprubahan bago simulan ang susunod, na may pormal na mga resulta at mahusay na natukoy na pamantayan sa pagtatapos.
Ang pamamaraang ito ay batay sa isang napakalinaw na premisa: ang mga kinakailangan sa proyekto ay maaaring malaman at idokumento nang maaga nang may sapat na katumpakan upang magtatag ng isang medyo hindi mababagong baseline. Ang baseline na ito ang gumagabay sa lahat ng disenyo, pag-unlad, at beripikasyon, at ang anumang kasunod na mga pagbabago ay itinuturing na pambihira at magastos na mga pagbabago na napapailalim sa pormal na kontrol.
Pinagmulan at ebolusyon ng modelo ng Waterfall
Ang ideya ng pag-oorganisa ng trabaho sa magkakasunod na mga yugto ay hindi nagmula sa software. Nagmula ito sa mga tradisyunal na sektor ng inhinyeriya tulad ng konstruksyon, inhinyerong sibil, at mabibigat na industriya, kung saan ang paulit-ulit na paggawa ng isang tapos na produkto ay maaaring maging hindi praktikal o lubhang mapanganib. Kung nagtatayo ka ng tulay o dam, kailangan mong maging ganap na malinaw sa kung ano ang iyong gagawin bago ilatag ang unang ladrilyo.
Sa larangan ng pagbuo ng software, isa sa mga unang halimbawa ay nagsimula noong Hunyo 1956, nang iprisinta ni Herbert D. Benington ang isang phased model para sa malalaking sistema. Gayunpaman, ang paglalarawan na itinuturing na klasiko ng waterfall model ay iniuugnay kay Winston W. Royce sa isang artikulo noong 1970 tungkol sa pamamahala ng malalaking proyekto sa pagbuo ng software. Pagkalipas ng ilang taon, noong 1976, pinasikat nina Bell at Thayer ang terminong "waterfall" at binanggit si Royce bilang isang reperensya.
Ang kakaiba ay nagbabala mismo si Royce na ang isang mahigpit na sequential na modelo, nang walang anumang feedback, ay mapanganib. Iminungkahi niya ang pagsasama ng mga iterasyon sa pagitan ng magkatabing mga yugto at mga prototype upang mabawasan ang panganib na iyon. Sa paglipas ng panahon, ang umusbong sa industriya ay isang pinasimple, halos matibay na bersyon, kung saan ang bawat yugto ay ganap na nakumpleto bago lumipat sa susunod, at sa gayon ay pinagtibay ang estereotipo na iniuugnay nating lahat sa waterfall model ngayon.
Dahil sa malinaw na lohika at kadalian ng pagpaplano , ang Waterfall ay mabilis na ginamit hindi lamang sa software, kundi pati na rin sa mga sektor tulad ng konstruksyon, inhenyeriya, o anumang regulated na kapaligiran kung saan ang saklaw ay mahusay na natukoy at walang gaanong tolerance para sa improvisasyon.
Paano gumagana ang metodolohiya ng Waterfall
Sa isang proyektong pinamamahalaan gamit ang waterfall approach, ang mga yugto ay sumusunod sa isa't isa sa isang napakahigpit na linear na pagkakasunud-sunod. Ang isang yugto ay hindi nagsisimula hangga't hindi natatapos ang nauna , at sa teorya, walang pagbabalik maliban kung may lumitaw na isang napakaseryosong problema o may naganap na pagbabago sa kontrata.
Sa pinakaklasikong bersyon nito, ang Waterfall lifecycle ay binubuo ng lima, anim, o kahit pitong yugto. Ang pagkakaiba ay karaniwang nasa kung ang deployment at maintenance ay pinaghihiwalay o pinagsama-sama, ngunit ang pinagbabatayang lohika ay pareho: ang pag-unlad nang walang magkakapatong na mga yugto at may mga pormal na deliverable sa bawat hakbang.
Mga Yugto ng Metodolohiya ng Waterfall
Para lubos na maunawaan ang Waterfall, mahalagang maingat na suriin ang bawat yugto nito. Hindi sila magkakahiwalay na bahagi, kundi nagsisilbing mga kawing sa isang kadena kung saan ang output ng isang yugto ay pumapasok sa input ng susunod.
1. Mga Kinakailangan
Ang yugto ng mga kinakailangan ang siyang puso ng anumang proyektong waterfall. Dito, ang layunin ay makuha ang lahat ng pangangailangan at limitasyon ng kliyente at negosyo, kapwa functional (kung ano ang dapat gawin ng sistema) at di-functional (pagganap, seguridad, regulasyon, atbp.).
Ang yugtong ito ay kinabibilangan ng mga panayam, workshop, at pagsusuri kasama ang mga gumagamit at mga eksperto sa larangan upang matiyak na walang makakaligtaan. Ang resulta ay isang detalyadong dokumento ng detalye ng mga kinakailangan na sinusuri at nilagdaan ng lahat ng partido . Ang dokumentong ito ang magiging batayan ng kontrata at teknikal na pamamahala sa natitirang bahagi ng proyekto.
Sa klasikong pamamaraang Waterfall, ang kliyente ang pangunahing kasangkot sa unang yugtong ito . Pagkatapos, ang kanilang pakikilahok ay lubhang nababawasan hanggang sa yugto ng pagpapatunay o pagtanggap. Kaya naman napakahalaga na ang pangangalap ng mga kinakailangan ay maging masinsinan at malinaw hangga't maaari: ang anumang mga pagkukulang o kalabuan ay lalakas sa mga susunod na yugto at magiging lubhang magastos upang itama.
2 Pagtatasa
Kapag naitatag na ang mga kinakailangan, ang pangkat ay papasok sa isang yugto ng pagsusuri kung saan pinag-aaralan ang teknikal at praktikal na posibilidad ng lahat ng hinihiling. Isang konseptwal na modelo ng sistema ang binubuo, tinutukoy ang mga dependency, nililinaw ang mga kumplikadong tuntunin sa negosyo, at inilalatag ang pundasyon para sa kasunod na disenyo.
Ang yugtong ito ay nagbibigay-daan sa pagsasalin ng lengguwahe ng negosyo sa mas teknikal na lengguwahe, nang hindi pa umaabot sa antas ng detalye ng arkitektura. Sa maraming proyekto, ang pagsusuri at mga kinakailangan ay nagsasapawan sa paglipas ng panahon, ngunit sa mga modelo ng waterfall, kadalasan silang kinakatawan bilang isang natatanging yugto na may kani-kanilang mga resulta.
3. Disenyo o konsepto
Binabago ng yugto ng disenyo ang "ano" tungo sa "paano." Simula sa mga itinakdang kinakailangan, tinutukoy ng pangkat ng arkitektura at disenyo ang kumpletong istruktura ng solusyon . Sa software, madalas itong nahahati sa disenyo na may mataas na antas (arkitektura, mga modyul, mga interface, mga teknolohiya) at detalyadong disenyo (mga algorithm, mga database, mga iskema ng interface, atbp.).
Sa ibang mga sektor, ang yugtong ito ay katumbas ng mga plano sa konstruksyon, mga kalkulasyon ng istruktura, mga eskematiko sa kuryente, o mga talaan ng mga materyales. Ang layunin ay ang kasunod na pagpapatupad ay maging, sa esensya, isang tapat na pagsasalin ng disenyo , nang hindi kinakailangang muling bigyang-kahulugan ang mga kinakailangan.
Sa mga kumplikadong proyekto, ang plano at mga dependency ng proyekto ay makikita sa mga tool tulad ng Gantt chart at iba pang mga tool sa pamamahala ng oras , na akma sa sequential mindset ng waterfall: magkakaugnay na mga gawain, napakalinaw na mga milestone at isang mahusay na tinukoy na iskedyul ng paghahatid.
4. Pagpapatupad o pagpapaunlad
Kapag nakumpleto na ang disenyo, magsisimula na ang yugto ng implementasyon. Dito nakatuon ang pangkat ng pagbuo, konstruksyon, o integrasyon sa pagbuo ng produkto nang eksakto ayon sa disenyo . Halimbawa, sa software, ito ang oras para magsulat ng code, mag-configure ng mga sistema, mag-set up ng imprastraktura, at iba pa.
Paradoxically, sa maraming proyektong waterfall, ang yugtong ito ay mas maikli kaysa sa mga kinakailangan at yugto ng disenyo dahil malaking bahagi ng pagsisikap ay naipuhunan na sa pagpaplano at dokumentasyon . Ang ideya ay upang mabawasan ang improvisasyon: ang mga pangunahing desisyon ay nagawa na, at ngayon ay oras na para isagawa.
Bagama't maaaring may mga panloob na pagsusuri at pagsubok sa yunit, ang tradisyonal na metodolohiya ng Waterfall ay naglalaan ng pormal na beripikasyon para sa susunod na yugto, kapag ang buong sistema ay naisama na.
5. Pag-verify, pagsubok at pagpapatunay
Kapag naitayo na ang sistema, oras na para beripikahin kung talagang ginagawa nito ang dapat nitong gawin. Dito, mahalagang pag-iba-ibahin ang beripikasyon at pagpapatunay , dalawang konsepto na tinatalakay nang mahigpit sa sunod-sunod na proseso.
Ang beripikasyon ay kinabibilangan ng pagtiyak na ang produkto ay naitayo nang tama: ang sistema ay inihahambing sa mga detalye ng disenyo, at ang mga pagsusuri sa unit, integrasyon, at sistema ay isinasagawa upang makahanap ng mga teknikal na error. Kapag ginamit ang mga API, ginagamit ang mga tool tulad ng gabay sa pagsubok ng API ni Postman . Ang tanong na sinasagot ay: "Naitayo ba natin ang sistema ayon sa disenyo?"
Sa kabilang banda, ang pagpapatunay ay nakatuon sa pagpapatunay na tama ang produkto : na natutugunan nito ang mga kinakailangan at pangangailangan ng gumagamit gaya ng unang tinukoy. Sinasagot nito ang tanong na: "Tunay bang nalulutas ng sistemang ito ang problema sa negosyo?"
Sa yugtong ito, isinasagawa ang pagsubok sa pagtanggap kasama ang kliyente. Kung may matuklasan na mga pagkakamali, itinatama ang mga ito; kung may lumitaw na mga paglihis mula sa inaasahan ng kliyente, maaaring kailanganing gawin muli ang ilan sa mga gawain. Dahil ang mga problemang ito ay nahuhuli sa pagtuklas, ang gastos sa pagwawasto ay karaniwang mataas sa oras at pera , isa sa mga pangunahing disbentaha ng modelo ng waterfall sa pabago-bagong kapaligiran.
6. Pag-deploy o pagsisimula
Kapag nakumpleto na ang pormal na pagsubok at pagtanggap ng customer, ang produkto ay lilipat sa pag-deploy o produksyon . Sa software, maaaring kasama rito ang pag-install ng sistema sa mga pinal na kapaligiran, paglilipat ng data, pagsasanay sa mga gumagamit, at pagsasama ng bagong sistema sa mga umiiral na, kung saan kapaki-pakinabang ang kaalaman sa pamamahala ng API.
Sa ibang mga sektor, ito ay minamarkahan ang sandali kung kailan pinasinayaan ang isang pasilidad, inilipat ang isang plantang pang-industriya, o kinomisyon ang isang imprastraktura. Sa isang sunod-sunod na paraan, ang mahalagang pangyayaring ito ay nagsasaad ng pagtatapos ng proyekto sa pagpapaunlad at ang simula ng yugto ng pagpapanatili.
7. Pagpapanatili
Pagkatapos magsimula, nagsisimula ang isang yugto ng pagpapanatili, na sa maraming pagkakataon ay ang pinakamahaba sa siklo ng buhay . Kabilang sa yugtong ito ang pagwawasto ng mga error na pumapasok, pag-aangkop ng sistema sa mga partikular na pagbabago sa kapaligiran (mga regulasyon, panlabas na sistema, hardware), at paggawa ng mga maliliit na pagpapabuti.
Sa purong pilosopiya ng Waterfall, ang mga pangunahing pagbabago na may malaking epekto sa arkitektura o mga kinakailangan ay karaniwang nilalapitan bilang mga bagong proyekto ng waterfall, na may sariling siklo ng mga kinakailangan, disenyo, implementasyon, at pagpapatunay. Ang dokumentasyong nabuo sa mga nakaraang yugto ay nagiging isang mahalagang sandata para sa pangkat ng suporta, na maaaring hindi ang parehong pangkat na nagdisenyo ng orihinal na sistema.
Ang pangunahing papel ng dokumentasyon sa Waterfall
Kung may isang bagay na tumutukoy sa waterfall methodology, bukod sa pagkakasunod-sunod ng mga yugto, ito ay ang kahalagahan ng dokumentasyon bilang gulugod ng proyekto. Ang bawat yugto ay bumubuo ng mga pormal na deliverable na napapailalim sa pagsusuri at pag-apruba: mga detalye ng mga kinakailangan, disenyo, plano ng pagsubok, mga ulat sa beripikasyon, mga manwal sa pagpapatakbo, atbp.
Ang dokumentasyong ito ay hindi isang burukratikong kapritso; sa maraming sektor, ito ay isang regulasyon o kontratadong kinakailangan . Pinapayagan ka nitong ipakita kung ano ang napagkasunduan, kung paano ito dinisenyo, kung paano ito ipinatupad, at kung paano napatunayan ang lahat. Bukod pa rito, pinapadali nito ang kumpletong pagsubaybay mula sa isang kinakailangan hanggang sa kodigo na nagpapatupad nito at ang pagsubok na nagpapatunay dito.
Plano ng proyekto at baseline
Ang plano ng proyekto sa isang kapaligirang Waterfall ay isang tunay na roadmap . Tinutukoy nito ang saklaw, detalyadong iskedyul, mga mapagkukunan, mga milestone, mga panganib, at pamantayan sa pagtanggap para sa bawat yugto. Karaniwan itong kinakatawan ng mga detalyadong Gantt chart at isang iskedyul ng mga pormal na pagsusuri sa dulo ng bawat yugto.
Kapag naaprubahan na, ang plano ay itinitigil bilang baseline. Anumang mahahalagang paglihis (sa saklaw, gastos, o iskedyul) ay pinamamahalaan sa pamamagitan ng mga kahilingan sa pagbabago at mga proseso ng pagkontrol , na karaniwang sinusuri ng isang komite ng proyekto. Ang katigasan na ito ay nagbibigay ng mataas na antas ng kakayahang mahulaan, na lubos na pinahahalagahan sa mga kontrata o programa na may takdang presyo na may mga parusa para sa mga pagkaantala.
Pagtukoy sa mga Kinakailangan bilang isang Pangunahing Dokumento
Sa lahat ng dokumentasyon, ang ispesipikasyon ng mga kinakailangan ay karaniwang ang dokumentong may pinakamaraming bigat na naaayon sa kontrata . Binabalangkas nito kung ano ang dapat gawin ng sistema, sa ilalim ng anong mga limitasyon, sa anong antas ng kalidad, at kung paano ito dapat makipag-ugnayan sa iba pang mga elemento.
Sa isang cascaded approach, ang yugtong ito ay karaniwang kumukonsumo ng nasa pagitan ng 20% at 30% ng kabuuang pagsisikap sa proyekto. Maaaring mukhang malaki ito, ngunit kapag mataas ang gastos sa paggawa ng isang pagkakamali, mas mura ang maglaan ng oras sa paglilinaw ng ninanais na resulta kaysa sa muling buuin ang kalahati ng sistema sa huli.
Mga talaan ng pagsubaybay at pagsubok
Ang isa pang tipikal na katangian ng Waterfall ay ang paggamit ng mga traceability matrices, na nag-uugnay sa bawat kinakailangan sa mga elemento ng disenyo na nagpapatupad nito at sa mga test case na nagpapatunay nito . Ang pagpapanatili ng mga matrices na ito ay nangangailangan ng disiplina, ngunit napakahalaga ng mga ito sa mga pag-awdit at sertipikasyon.
Ang mga plano sa pagsubok, mga iskrip, mga resulta, at mga ulat sa pagsusuri ay bumubuo ng isang kalipunan ng ebidensya na nagpapakita na ang sistema ay sistematikong nasubukan . Sa mga sektor tulad ng mga parmasyutiko, aerospace, at riles, ang mga rekord na ito ay mandatory at dapat itago sa loob ng maraming taon.
Dokumentasyon oo, burukrasya hindi
Isang karaniwang kritisismo sa modelo ng waterfall ay ang paglikha nito ng napakaraming papeles na walang nagbabasa. At kung minsan ay totoo iyan, huwag nating lokohin ang ating mga sarili. Kaya naman mahalagang makilala ang pagkakaiba sa pagitan ng dokumentasyong nagdaragdag ng halaga (ang uri na nakakatulong sa pag-unawa sa mga desisyon, pagpapakita ng pagsunod, o pagpapanatili ng sistema) at burukrasya na nagsisilbi lamang sa pagpuno ng mga form.
Ang isang project manager ng waterfall ay dapat magkaroon ng kakayahang mag-alis ng mga hindi kinakailangang impormasyon at tumuon sa mga dokumentong sumasagot sa mga pangunahing tanong: sino ang humiling, ano , bakit ito dinisenyo nang ganoon, at paano napatunayan ang paggana nito. Kung ang isang dokumento ay hindi nakatutulong sa pagsagot sa alinman sa mga tanong na ito o hindi kinakailangan upang makapasa sa isang audit, malamang na ito ay kalabisan na.
Mga Bentahe ng Metodolohiyang Waterfall
Hindi lunas ang talon para sa lahat, ngunit sa tamang konteksto ay mayroon itong ilang kalakasan na mahirap tapatan. Ito ang mga pinakakapansin-pansin.
Una, nag-aalok ito ng malinaw, lohikal, at lubos na organisadong istruktura . Ang proyekto ay natatapos nang sunud-sunod, na may mga yugtong hindi magkakapatong at mahusay na natukoy na mga milestone. Lubos nitong pinapadali ang alokasyon ng mapagkukunan at pagsubaybay sa progreso, dahil palaging malinaw kung anong yugto ka na.
Pangalawa, nagbibigay-daan ito para sa napakatumpak na pagpaplano at pagtatantya kapag ang mga kinakailangan ay matatag. Dahil ang lahat ay natukoy na bago magsimula, mas madaling kalkulahin ang mga gastos, mga takdang panahon, at mga pangangailangan sa tauhan. Ito ay mainam para sa mga kontratang may takdang presyo, mga pampublikong tender, at mga proyekto kung saan kailangang malaman ng kliyente mula sa simula kung magkano ang kanilang babayaran at kung kailan nila matatanggap ang resulta.
Pangatlo, ang waterfall model ay bumubuo ng komprehensibong dokumentasyon at kumpletong traceability . Ang bawat yugto ay nag-iiwan ng bakas ng mga sinuri at inaprubahang deliverables, isang bagay na lubos na pinahahalagahan sa mga regulated at kritikal na kapaligiran kung saan ang kawalan ng mga papeles ay maaaring magdulot ng mga legal o panganib sa seguridad.
Bukod pa rito, dahil malinaw na naitakda ang mga yugto, mas madaling sukatin ang pag-unlad ng proyekto at iulat ito sa pamamahala. Ang mga pamamaraan tulad ng kinita na halaga ay maaaring gamitin at ihambing sa baseline nang obhetibo.
Panghuli, mas nasisiyahan ang ilang kliyente na, pagkatapos ng unang yugto ng mga kinakailangan, hindi na nila kailangang patuloy na makilahok . Sa Waterfall, ang kanilang pakikilahok ay karaniwang nakatuon sa simula (upang tukuyin kung ano ang gusto nila) at sa huli (upang patunayan kung ano ang naihatid na). Para sa mga organisasyong may limitadong oras o walang kultura ng patuloy na pakikipagtulungan, maaari itong maging isang kalamangan.
Mga limitasyon at panganib ng diskarte sa talon
Ang downside ng lahat ng nabanggit ay ang modelo ng Waterfall ay lubhang naapektuhan kapag ang konteksto ay nangangailangan ng kakayahang umangkop at pag-aangkop sa pagbabago . Kilalang-kilala ang mga pangunahing disbentaha nito.
Ang pinakahalatang disbentaha ay ang kakulangan nito ng kakayahang umangkop . Ang mga kinakailangan sa pag-freeze sa simula at ang pagsulong nang hindi lumilingon ay nagpapahirap sa pagpapakilala ng mga makatwirang pagbabago sa kalagitnaan ng proyekto. Ang anumang makabuluhang pagsasaayos ay maaaring humantong sa mga pagbabago sa disenyo, muling pagpapatupad, at paulit-ulit na pagsubok, na magreresulta sa epekto sa oras at badyet.
Isa pang problema ay ang naantalang paghahatid ng halaga . Sa isang waterfall model, hindi nakikita ng customer ang isang gumaganang produkto hanggang sa mga huling yugto. Kung, sa puntong iyon, matuklasan nila na ang naihatid ay hindi akma sa kanilang aktwal na mga pangangailangan (dahil nagbago ang konteksto, lumitaw ang mga bagong kakumpitensya, o lumitaw ang mas magagandang ideya), kakaunti ang magagawa nang hindi lubos na bumabalik sa dati.
Mayroon ding malakas na pagdepende sa kalidad ng mga paunang kinakailangan . Kung ang kliyente ay hindi malinaw kung ano ang gusto nila, o kung ang koponan ay nabigong makuha ito nang epektibo, ang waterfall model ay nagiging isang magastos na patibong: maraming ipinupuhunan sa pagpaplano ng isang bagay na kailangang bawiin.
Pinalala pa ito ng kakulangan ng patuloy na feedback . Dahil limitado ang pakikilahok ng kliyente sa panahon ng pagbuo, nawawala ang mga pagkakataong agad na isaayos ang solusyon at matukoy ang mga isyu sa usability o business fit.
Panghuli, kapag ginamit nang wala sa konteksto, ang waterfall model ay maaaring lumikha ng maling pakiramdam ng kontrol . Ang pagkakaroon ng magandang Gantt chart at mga tambak ng mga aprubadong dokumento ay hindi garantiya na ang sistema ay maisasama nang maayos o gagana ayon sa inaasahan. Maraming problema ang lumalabas lamang sa huli, kapag mas mahal itong ayusin.
Talon sa pagbuo ng software
Sa mundo ng software, ang Waterfall ang nangingibabaw na modelo sa loob ng maraming taon , lalo na sa malalaking sistema para sa gobyerno, depensa, pagbabangko, at telekomunikasyon. Ang pagkakasunod-sunod na "mga kinakailangan-disenyo-code-pagsubok-pagpapanatili" ay akma sa kaisipan ng inhinyeriya noong panahong iyon.
Sa paglipas ng panahon, naging malinaw na ang mga kinakailangan para sa karamihan ng mga digital na produkto ay patuloy na nagbabago . Mabilis na gumagalaw ang merkado, patuloy na umuunlad ang teknolohiya, at natutuklasan lamang ng mga gumagamit kung ano ang tunay nilang gusto kapag sinimulan nilang gumamit ng isang partikular na bagay. Sa ganitong kapaligiran, ang pagtuklas ng isang konseptwal na pagkakamali sa huling yugto ng pagsubok ay nangangahulugan ng pagsasayang ng maraming trabaho.
Kaya naman karamihan sa mga product-oriented software team ay gumagamit ng maliksi at paulit-ulit na mga pamamaraan (Scrum, Kanban, Lean, atbp.), na nagpapahintulot sa madalas na pagdaragdag, pagpapatunay ng mga hypotheses sa negosyo, at mabilis na pagsasaayos ng kurso.
Gayunpaman, ang waterfall model ay mayroon pa ring lugar sa software kahit na ang saklaw ay napakalimitado at ang katatagan ay isang prayoridad: mga mission-critical system (medikal, militar, aeronautical), mga integrasyon na may mga saradong kontrata, mga pag-unlad para sa mga kapaligirang may mataas na regulasyon, o mga paglipat ng mga napakalumang sistema kung saan ang mga patakaran sa negosyo ay perpektong naidokumento.
Kailan makatuwiran na gamitin ang metodolohiyang waterfall?
Ang pagpili sa pagitan ng Waterfall at Agile ay hindi tungkol sa mga uso, ito ay tungkol sa konteksto. May mga sitwasyon kung saan ang Waterfall ay isang napaka-makatwirang pagpipilian at ang iba naman ay isang tunay na metodolohikal na pagpapakamatay.
Mga proyektong may matatag at kilalang mga kinakailangan
Ang mainam na senaryo para sa Waterfall ay kung saan ang mga kinakailangan ay malinaw, kumpleto, at malamang na hindi magbabago . Halimbawa, ang paglipat ng isang legacy system sa isang bagong platform habang pinapanatili ang parehong functionality, pagkopya ng isang napatunayang industrial plant sa ibang lokasyon, o pagpapatupad ng isang ERP na may saklaw na tinukoy ng kontrata.
Sa mga kasong ito, ang organisasyon ay karaniwang may napakahusay na pag-unawa sa larangan at mga panganib. Ang modelo ng waterfall ay nagbibigay-daan sa kanila na gamitin ang karanasang iyon, magplano nang detalyado, at i-optimize ang paggamit ng mapagkukunan nang may kaunting sorpresa.
Mga kapaligirang may regulasyon at lubos na kritikal na antas
Aerospace, riles, enerhiyang nukleyar, mga aparatong medikal… Ito ang mga sektor kung saan kinakailangan ang ganap na pagsubaybay at komprehensibong dokumentasyon . Ang mga ahensya ng regulasyon ay nangangailangan ng access sa mga sunud-sunod na plano, mga pagsusuri sa disenyo, mga talaan ng pagsubok, at isang kumpletong katwiran para sa bawat teknikal na desisyon.
Sa mga larangang ito, ang magaan na dokumentasyon at patuloy na pag-eeksperimento ng ilang agile approach ay hindi akma sa mga kinakailangan sa sertipikasyon. Ang waterfall methodology ay nagbibigay ng kinakailangang balangkas ng dokumentasyon upang makapasa sa mga pormal na audit at mga milestone sa pagpapatunay ng regulasyon.
Mga kontratang may takdang presyo at outsourcing
Kapag pumirma ang isang supplier ng isang kontrata na may takdang presyo, kailangan nilang bawasan ang mga kawalan ng katiyakan. Angkop dito ang waterfall model dahil ang saklaw ay napagkasunduan, naidodokumento, at napapatigil bago gawin ang anumang pangako. Anumang kasunod na mga pagbabago ay may sariling pormal na proseso at karaniwang nauugnay sa muling pag-uusap tungkol sa mga gastos at mga deadline.
Sa mga proyektong outsourcing kung saan ang mga pangkat ay nakakalat at limitado ang impormal na komunikasyon, binabawasan ng waterfall model ang kalabuan sa pamamagitan ng pagpapalit ng mga palaging pag-uusap ng mga detalyadong detalye.
Kultura ng organisasyon na may kaunting pagpaparaya sa kawalan ng katiyakan
May mga organisasyong may mataas na hirarkiya na may takdang taunang badyet at obsesyon sa pagiging mahuhulaan. Sa mga ganitong sitwasyon, ang pagsisikap na ipatupad ang Agile ayon sa aklat ay kadalasang nagreresulta sa isang "kakaibang hybrid" kung saan walang modelo ang nakikinabang sa mga bentahe nito.
Ang modelo ng waterfall ay pinakaangkop sa mga istruktura kung saan pinahahalagahan ang isang matibay na plano mula sa simula, na may mga linear na ulat ng progreso at pormal na pagsusuri. Dito, ang project manager ay gumaganap bilang tagapag-alaga ng baseline , sa halip na isang tagapagpadaloy ng mga pag-ulit.
Pagsasama ng maraming vendor at malalaking programa
Sa mga malalaking proyekto na may maraming kontratista (hal., sasakyan, paggawa ng barko, o pangunahing imprastraktura), ang waterfall model ay nagsisilbing isang karaniwang wika para sa pag-coordinate ng mga interface . Binubuo ng bawat vendor ang kanilang subsystem laban sa mga nakapirming detalye ng interface, at ang pagsubok sa integrasyon ay pinaplano nang maaga.
Kung ang bawat pangkat ay gagawa nang may pabago-bagong mga prayoridad at mga independiyenteng sprint nang walang pangkalahatang balangkas, magiging magulo ang integrasyon. Ang sequential approach ay ginagawang mas madali ang pagtukoy ng malinaw na mga punto ng integrasyon at mas mahusay na pagkontrol sa supply chain.
Kailan HINDI magandang ideya na gamitin ang Waterfall?
Kasinghalaga ng pag-alam kung saan kumikinang ang talon ay ang pagtukoy sa mga sitwasyon kung saan pinakamahusay na itapon ito nang walang pag-aalinlangan . Ilang karaniwang senaryo:
Kapag hindi lubos na alam ng kliyente ang kanilang kailangan at inaasahang matututo sa pamamagitan ng pagsubok at pagkakamali, ang pagpilit sa isang sequential model ay hahantong lamang sa pagkabigo at labis na gastos. Maraming oras ang gugugulin sa pagdodokumento ng isang bagay na malapit nang magbago.
Kung ang merkado ay nagbabago nang linggo o buwan (mga startup, makabagong digital na produkto, mga proyekto sa karanasan ng gumagamit), ang paghihintay hanggang sa katapusan upang mapatunayan ang solusyon ay isang pabaya. Sa mga kasong ito, mas angkop ang mga paulit-ulit at paunti-unting pamamaraan na nagbibigay-daan sa pagsubok, pagsukat, at pagsasaayos.
Bukod pa rito, kung ang mga deadline ay napakaagresibo na hindi na pinapayagan ang isang mahigpit na yugto ng mga kinakailangan, ang pagsunod sa Waterfall ay hindi maiiwasang hahantong sa isang bersyon ng modelo ng waterfall na walang tunay na mga kontrol , kung saan minamadali ang dokumentasyon para lamang "lagyan ng tsek ang kahon." Iyan ang pinakamasama sa parehong mundo.
Agile vs Waterfall: Mga Pangunahing Pagkakaiba
Ang paghahambing sa pagitan ng Waterfall at Agile ay lumalabas sa halos bawat talakayan tungkol sa pamamahala ng proyekto. Hindi sila likas na mabuti o masama; sumasalamin lamang ang mga ito sa magkaibang pilosopiya.
Nagmumungkahi ang Waterfall ng isang linear at sequential na pamamaraan: una, ang lahat ay binibigyang kahulugan, pagkatapos ay dinisenyo, ipinapatupad, sinubukan, at inihahatid. Sa kabilang banda, hinahati ng Agile ang gawain sa maikli at paulit-ulit na mga siklo (sprint) kung saan ang isang maliit na hanay ng mga functionality ay pinaplano, dinisenyo, binuo, at sinubukan sa bawat iteration.
Sa waterfall, ang saklaw ay nakatakda sa simula at ang mga pagbabago ay magastos na eksepsiyon. Sa Agile, ang pagbabago ay ipinapalagay na pamantayan at ang produkto ay umuunlad nang sprint por sprint , inaayos ang backlog batay sa feedback ng user at negosyo.
Tungkol sa pakikilahok ng customer, itinutuon ng Waterfall ang pakikilahok nito sa simula at katapusan ng proyekto. Ipinamamahagi ito ng Agile sa buong lifecycle, na may madalas na mga pagsusuri at isang potensyal na maipapadalang produkto sa dulo ng bawat sprint.
Tungkol sa time to market, ang mga proyektong waterfall ay karaniwang naghahatid ng halaga sa pagtatapos ng proseso. Pinapayagan ng Agile ang paglabas ng mga naunang bersyon (MVP) na pinoproseso sa paglipas ng panahon.
Sa pagsasagawa, maraming organisasyon ang pumipili ng mga hybrid na pamamaraan , tulad ng kilalang "Water-Scrum-Fall": pagpaplano at pangkalahatang disenyo sa waterfall mode, pang-araw-araw na pag-develop gamit ang Scrum, at muling pag-deploy/paghahatid sa ilalim ng mas predictive na payong.
Ang papel ng project manager sa Waterfall
Ang project manager sa isang waterfall environment ay may ibang tungkulin kumpara sa isang Scrum Master o isang Agile Coach. Dito, inaasahang sila ay maging isang masusing tagaplano at tagakontrol ng progreso , sa halip na isang tagapagpadaloy ng mga pangkat na nag-oorganisa sa sarili.
Kabilang sa mga pangunahing responsibilidad ang pagpapanatili ng baseline ng proyekto, pag-coordinate ng mga pagsusuri sa yugto, pamamahala ng mga panganib, pagkontrol sa mga pagbabago, pagtiyak ng pagsunod sa mga deadline at badyet, at pagpapabatid ng katayuan ng proyekto sa pamamahala sa pamamagitan ng mga pormal na ulat. Sa malalaking proyekto, ang tungkuling ito ay karaniwang kinabibilangan ng malapit na pakikipagtulungan sa isang teknikal na pinuno upang matiyak ang kalidad ng mga desisyon sa disenyo at arkitektura.
Para sa mga nais magpakadalubhasa sa ganitong uri ng pamamahala, ang mga sertipikasyon tulad ng PMP mula sa PMI o mga partikular na pamantayan ng mga regulated na sektor (halimbawa, DO-178C sa aerospace) ay nagpapatibay nang tumpak sa mga kasanayang ito na nakatuon sa predictive at mahigpit na dokumentadong mga life cycle.
Mga hybrid na metodolohiya at pakikisama sa mga agile na pamamaraan
Ang katotohanan ay halos walang seryosong proyekto ngayon ang 100% waterfall o 100% agile. Karaniwang makakahanap ng mga kumbinasyon kung saan ang waterfall ay nagsisilbing isang kontratwal na payong , habang ang mga paulit-ulit na siklo ay inilalapat sa loob upang mabawasan ang panganib sa mga partikular na lugar.
Halimbawa, ang pangkalahatang arkitektura at mga interface ay maaaring tukuyin gamit ang isang waterfall methodology, ngunit ang ilang mga subsystem ay maaaring mabuo gamit ang maiikling iteration at prototyping . Hangga't ang mga interface at integration milestones ay iginagalang, ang mix na ito ay maaaring gumana nang mahusay.
May katulad na nangyayari sa mga proseso ng digital transformation: maaaring ilipat ng isang organisasyon ang transactional core nito (stable at regulated) gamit ang Waterfall, habang bumubuo ng mga front-end application para sa end customer gamit ang mga agile team. Malayo sa pagiging magkasalungat, ito ay isang matalinong paraan upang magtalaga ng tamang tool sa bawat problema.
Mayroon ding mga transisyon mula Waterfall patungong Agile kung saan ang pamamahala ng mga mapagkukunan at kasanayan ng pangkat ay nangangailangan ng isang makabuluhang pagbabago sa kultura . Ang pagsisimula sa mga pamamaraang agile sa maliliit na proyekto ay nagbibigay-daan sa mga pangkat na masanay sa dynamic na pagpaplano at patuloy na feedback nang hindi isinasapanganib ang mga kritikal na programa.
Sa madaling salita, ang metodolohiyang Waterfall ay nananatiling isang lubos na mahalagang kasangkapan sa pamamahala ng proyekto, kung ang mga kalakasan nito— pagkahula, istruktura, at kakayahang masubaybayan— ay lubos na nauunawaan . Kapag inilapat sa mga larangan na may matatag na mga kinakailangan, mahigpit na regulasyon, o mga kontratang may takdang presyo, maaari itong maging pinakaligtas at pinakaepektibong opsyon, lalo na kapag sinamahan ng makatwirang antas ng pag-ulit at sentido komun.
