Saturs
- Īss pārskats par programmatūras izstrādes dzīves ciklu
- Kāpēc veikls attīstības process ir atšķirīgs?
- Veikla prakse
- Kāpēc iet veikli?
- Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Izņemšana:
Šī programmatūras izstrādes metode veicina sadarbību un elastību, lai palīdzētu piegādāt augstas kvalitātes produktu.
Ap Agile programmatūras inženierijas un lietojumprogrammu izstrādes pasaulē ir bijis daudz baudu. Veikls nav jēdziens, bet gan domāšanas veids. Kā norāda nosaukums, tā koncentrējas uz elastīgumu un dinamiskumu. Šī metodika arī novērš izolāciju starp programmatūras izstrādes fāzēm un mudina izstrādes komandu sadarboties ar kvalitātes analītiķiem. Tas arī uzsver klientu iesaisti augstas kvalitātes produkta izstrādē, būvēšanā un piegādē. Šeit labi apskatiet Agile, kā tā darbojas, kā arī dažus šīs populārās programmatūras izstrādes metodes paraugpraksi.
Īss pārskats par programmatūras izstrādes dzīves ciklu
Programmatūras izstrādes dzīves cikls (SDLC) ir programmatūras risinājumu radīšanas process vai esošo struktūru modificēšana, kas paredzētas konkrētas problēmas risināšanai. Tas ietver dažādas darbības, kas tiek veiktas loģiskā secībā. Tradicionālajos SDLC modeļos šie ir soļi, kas tiek veikti viens pēc otra, un parasti tiek veikti atsevišķi:
- Prasību apkopošana no klientiem
- Sistēmas un iespējamības analīze
- Projektēšana un modelēšana
- Kodēšana vai ieviešana
- Pārbaude
- Izvietošana un piegāde
- Apkopes un izmaiņu pieprasījumi
Tipiskā programmatūras izstrādes ciklā faktiskie lietotāji vai klienti tiek iesaistīti prasību apkopošanas procesā un pēc tam beta testēšanas laikā. Tomēr šī tradicionālā modeļa problēma ir tā, ka cikla uzturēšanas daļa kļūst par sarežģītu un diezgan dārgu lietu. Daudzas reizes sistēmā nav iespēju veikt uzlabojumus vai izmaiņas. Sliktākajā gadījumā izstrādātā vai izstrādātā programmatūra neatbilst faktiskajām klientu specifikācijām un vēlmēm, kas nozīmē, ka attīstības komandai var nākties visu procesu sākt no jauna.
Kāpēc veikls attīstības process ir atšķirīgs?
Visizplatītākajiem tradicionālajiem SDLC modeļiem - ūdenskrituma modelim, ātras pielietošanas modelim, iteratīvajam modelim, spirāles modelim utt. - ir savs plusu un mīnusu komplekts. Pagāja gadi, pirms cilvēki varēja reāli analizēt, cik reāli bija šie modeļi. Tie lieliski iekļaujas ideālos scenārijos, taču vienmēr ir praktiski, kad runa ir par reālās pasaules lietojumiem. Tā rezultātā programmatūras izstrādes komandas saskārās ar daudz izaicinājumiem. Daži no parasto SDLC modeļu ierobežojumiem ietver:
- Tie neļauj mainīt prasības vēlākajos posmos, jo tās ir iesaldētas programmatūras prasību specifikācijas dokumentā. Atsevišķos gadījumos lietotāju cerības tiek uzskatītas par nepamatotām vai pārprastām.
- Galalietotāji sistēmu neredz, kamēr tā nav pabeigta. Tas dod ļoti maz iespēju ierosinājumiem un izmaiņām.
- Tradicionālā SDLC var radīt milzīgu komunikāciju plaisu starp izstrādātājiem un testētājiem, jo tās ir atsevišķas fāzes, un starp abām pusēm nav sadarbības.
- Pārbaudi baltajā lodziņā nevar veikt efektīvi.
Agile izmantošana atrisina daudzas no šīm problēmām, jo tā nevis soli pa solim, bet gan drīzāk kalpo kā filozofija un ietvars, kura mērķis ir palīdzēt komandām sadarboties, reaģēt uz izmaiņām un izveidot gatavu produktu, kas ietver lielāku ieguldījumu no visiem ballītes, ieskaitot lietotājus.
Veikla prakse
Agile metodikas parādīšanās ir ne mazāk kā revolucionāra programmatūras izstrādes metodoloģijas reforma, jo tā nodrošina pietiekami daudz vietas, lai projekta komandas būtu radošas un daudzpusīgas, vienlaikus uzņemoties kolektīvu atbildību par katru produkta posmu. Sekojot veiklīgajam ceļam, atsevišķi programmatūras izstrādes komandas dalībnieki var sagatavot prātu, lai aptvertu nenoteiktību, tiktu galā ar izmaiņām un izveidotu labāku produktu kā procesu, nevis kā atsevišķu, nepievienotu darbību.
Lai arī nav visaptverošu veiklības principu saraksta, ir dažas prakses, kuras veikls pauž. Tie ietver:
- Testa vadīta izstrāde (TDD)
Ideālā gadījumā izstrādātājiem vispirms vajadzētu uzrakstīt testa gadījumus funkcionalitātei, kuru viņi gatavojas kodēt. Tas nodrošinās labas kvalitātes kodu, kura izņēmuma gadījumos ir mazāk iespējama. Šis process palīdz arī pārliecināties, ka tiek ņemtas vērā lietotāju specifikācijas. - Pāru programmēšana
Agile izstrādē programmētāji parasti strādā pie vienas un tās pašas problēmas pāros, kur viens cilvēks raksta kodu (draiveris), bet otrs pārskata kodu un sniedz idejas un ieteikumus (navigators). Tas palielina produktivitāti un samazina kodu, kas nepieciešams koda pārskatīšanai. - Kodu atkārtošana
Kodu atkārtošana nozīmē koda sadalīšanu mazākos un vienkāršākos moduļos, kas ideālā scenārijā var (un tam vajadzētu) pastāvēt neatkarīgi. Tas lielā mērā uzlabo koda lasāmību, pārbaudāmību un uzturēšanu. - Aktīva ieinteresēto personu līdzdalība
Ievērojot noteikta laika perioda regulārus intervālus (sauktus par “ss”), klientiem jāsaņem ievērojams programmatūras prototips. Tas ļauj izstrādātājiem saņemt atsauksmes par to, ko viņi veido, kad iet. - Uztveriet prasības kā prioritāru kaudzīti
Agile kategorijā ir svarīgi kategorizēt prasības, ņemot vērā to nozīmīgumu. Tas var ietvert gan netiešas, gan skaidras klientu cerības uz izstrādājamo programmatūras produktu. Programmatūras izstrādes komandai kolektīvi jānovērtē laiks un resursi, ko viņi iegulda objekta ieviešanā, un tas jākartē, pamatojoties uz lietotāju prasībām un relatīvo secību, kādā viņi risinās katru projekta daļu. - Regresijas pārbaude
Regresijas pārbaude ietver visas lietojumprogrammas funkcionalitātes pārbaudi pēc jaunas funkcijas pievienošanas vai koda esošās funkcionalitātes modificēšanas. Tas palīdz pārliecināties, ka izmaiņas nav salauzušas esošo kodu.
Kāpēc iet veikli?
Agile izraksta noteiktas prakses, taču tas tās neuzspiež programmatūras izstrādes komandai. Galu galā, ja pielāgojumiem un novirzēm nav iespēju, Agile mērķis tiek lielā mērā zaudēts. Pat dažu veiklās attīstības aspektu iekļaušana projektā var palīdzēt programmatūras izstrādes komandām tikt galā ar neparedzētiem izaicinājumiem un galu galā efektīvākā veidā izveidot labāku produktu.
Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Jūs nevarat uzlabot savas programmēšanas prasmes, ja nevienam nerūp programmatūras kvalitāte.