Katra tehnoloģiju organizācija mūsdienās, šķiet, praktizē ātru programmatūras izstrādes metodoloģiju vai tās versiju. Vai vismaz viņi tic, ka dara. Neatkarīgi no tā, vai esat jauns lietpratīgu lietojumprogrammu izstrādē vai pirms vairākiem gadu desmitiem esat apguvis programmatūras izstrādi, izmantojot ūdenskrituma programmatūras izstrādes metodiku, šodien jūsu darbu vismaz ietekmē veiklā metodika.
Bet kas ir veiklā metodika, un kā to vajadzētu praktizēt programmatūras izstrādē? Kā veiklā attīstība praktiski atšķiras no ūdenskrituma? Kas ir veikls programmatūras izstrādes dzīves cikls vai veikls SDLC? Un kas ir skrāpīgs veikls pret Kanbanu un citiem veikliem modeļiem?
Agile tika oficiāli uzsākta 2001. gadā, kad 17 tehnologi izstrādāja Agile manifestu. Viņi uzrakstīja četrus galvenos veiklās projektu vadības principus ar mērķi izstrādāt labāku programmatūru:
- Indivīdi un mijiedarbība procesos un rīkos
- Darba programmatūra, izmantojot visaptverošu dokumentāciju
- Klientu sadarbība līguma sarunu laikā
- Atbildot uz izmaiņām, ievērojot plānu
Pirms veiklības: ūdenskrituma metodikas laikmets
Tādas vecas rokas kā es atceras laikus, kad ūdenskrituma metodika bija programmatūras izstrādes zelta standarts. Programmatūras izstrādes procesam pirms kodēšanas sākuma bija nepieciešama daudz dokumentu. Kāds, parasti biznesa analītiķis, vispirms uzrakstīja biznesa prasību dokumentu, kurā tika attēlots viss lietojumprogrammai nepieciešamais bizness. Šie biznesa prasību dokumenti bija gari, detalizēti aprakstot visu: vispārējo stratēģiju, visaptverošās funkcionālās specifikācijas un vizuālo lietotāja saskarnes dizainu.
Tehnologi paņēma uzņēmējdarbības prasību dokumentu un izstrādāja paši savu tehnisko prasību dokumentu. Šis dokuments definēja lietojumprogrammas arhitektūru, datu struktūras, objektorientētos funkcionālos dizainus, lietotāja saskarnes un citas nefunkcionālas prasības.
Šis ūdenskrituma programmatūras izstrādes process beidzot sāks kodēšanu, pēc tam integrāciju un visbeidzot testēšanu, pirms lietojumprogramma tika uzskatīta par gatavu ražošanai. Viss process varētu viegli aizņemt pāris gadus.
Bija paredzēts, ka mēs, izstrādātāji, zināsim “specifikāciju”, kā tika saukta visa dokumentācija, tāpat kā to darīja dokumentu autori, un mēs bieži bijām sodīti, ja aizmirsām pareizi ieviest galveno detaļu, kas izklāstīta 200. lpp. 77. lpp. lapas dokumentu.
Toreiz arī pati programmatūras izstrāde nebija viegla. Daudziem izstrādes rīkiem bija nepieciešama specializēta apmācība, un mūsdienās esošā atvērtā koda vai komerciālās programmatūras komponentu, API un tīmekļa pakalpojumu tuvumā nebija neviena. Mums bija jāattīsta zema līmeņa lietas, piemēram, datu bāzu savienojumu atvēršana un datu apstrāde ar vairāku pavedienu palīdzību.
Pat pamata lietojumprogrammām komandas bija lielas, un saziņas rīki bija ierobežoti. Mūsu tehniskās specifikācijas bija tas, kas mūs pielīdzināja, un mēs tos izmantojām kā Bībele. Ja prasība mainītos, mēs ļautu biznesa vadītājiem veikt ilgu pārskatīšanu un parakstīties, jo komunikācija par izmaiņām komandā un koda labošana bija dārga.
Tā kā programmatūra tika izstrādāta, pamatojoties uz tehnisko arhitektūru, vispirms tika izstrādāti zemāka līmeņa artefakti un pēc tam atkarīgie artefakti. Uzdevumi tika piešķirti pēc prasmēm, un datu bāzu inženieriem bija ierasts vispirms izveidot tabulas un citus datu bāzes artefaktus, kam sekoja lietojumprogrammu izstrādātāji, kas kodēja funkcionalitāti un biznesa loģiku, un pēc tam beidzot tika pārklāts lietotāja interfeiss. Pagāja mēneši, pirms kāds redzēja, ka lietojumprogramma darbojas, un līdz tam ieinteresētās personas sāka skūpstīties un bieži vien gudrāk par to, ko viņi patiešām vēlējās. Nav brīnums, ka izmaiņu ieviešana bija tik dārga!
Ne viss, ko jūs nolikāt lietotāju priekšā, nedarbojās, kā paredzēts. Dažreiz lietotāji vispār neizmantoja kādu funkciju. Citreiz spēja bija ļoti veiksmīga, taču tai bija nepieciešama pārbūve, lai atbalstītu nepieciešamo mērogojamību un veiktspēju. Ūdenskrituma pasaulē šīs lietas uzzinājāt tikai pēc programmatūras izvietošanas pēc ilga izstrādes cikla.
Saistītais video: kā patiešām darbojas veiklā metodika
Šķiet, ka visi runā par veiklu programmatūras izstrādi, taču daudzām organizācijām nav skaidras izpratnes par procesa darbību. Lai ātri sasniegtu ātrumu, noskatieties šo piecu minūšu video.
Virziens uz veiklu programmatūras izstrādi
Izgudrotā 1970. gadā, ūdenskrituma metodoloģija bija revolucionāra, jo tā ieviesa disciplīnu programmatūras izstrādē, lai nodrošinātu skaidru sekošanu. Tas tika balstīts uz ūdenskrituma ražošanas metodi, kas iegūta no Henrija Forda 1913. gada montāžas līnijas jauninājumiem, kas nodrošināja pārliecību par katru ražošanas procesa posmu, lai garantētu, ka gala produkts vispirms atbilst specifikācijai.
Kad ūdenskrituma metodika nonāca programmatūras pasaulē, skaitļošanas sistēmas un to lietojumi parasti bija sarežģīti un monolīti, un to izpildei bija nepieciešama disciplīna un skaidrs rezultāts. Arī prasības, salīdzinot ar mūsdienām, mainījās lēnām, tāpēc liela mēroga centieni nebija tik problemātiski. Faktiski sistēmas tika veidotas, pieņemot, ka tās nemainīsies, bet būs mūžīgi kaujas kuģi. Vairāku gadu termiņi bija izplatīti ne tikai programmatūras izstrādē, bet arī ražošanā un citās uzņēmuma darbībās. Bet ūdenskrituma stingrība kļuva par Ahileja papēdi interneta laikmetā, kur bija nepieciešams ātrums un elastība.
Programmatūras izstrādes metodoloģija sāka mainīties, kad izstrādātāji sāka strādāt pie interneta lietojumprogrammām. Liels agrīnais darbs tika veikts jaunizveidotajos uzņēmumos, kur komandas bija mazākas, tika izvietotas un bieži vien tām nebija tradicionālās datorzinātnes. Bija finansiāls un konkurētspējīgs spiediens, lai vietnes, lietojumprogrammas un jaunas iespējas ātrāk nonāktu tirgū. Izstrādes rīki un platformas ātri mainījās.
Tas daudziem no mums, kas strādā jaunuzņēmumos, lika apšaubīt ūdenskrituma metodiku un meklēt veidus, kā efektīvāk darboties. Mēs nevarējām atļauties visu detalizēto dokumentāciju veikt sākumā, un mums bija nepieciešams vairāk iteratīvs un sadarbības process. Mēs joprojām debatējām par izmaiņām prasībās, taču bijām atvērtāki eksperimentiem un pielāgošanai galalietotāju vajadzībām. Mūsu organizācijas bija mazāk strukturētas, un mūsu lietojumprogrammas bija mazāk sarežģītas nekā uzņēmuma mantotās sistēmas, tāpēc mēs bijām daudz atvērtāki būvēšanai, salīdzinot ar lietojumprogrammu pirkšanu. Vēl svarīgāk ir tas, ka mēs centāmies attīstīt uzņēmumus, tāpēc, kad mūsu lietotāji mums teica, ka kaut kas nedarbojas, mēs biežāk izvēlējāmies tos klausīties.
Stratēģiski svarīgas kļuva mūsu prasmes un spēja ieviest jauninājumus. Jūs varētu savākt visu vēlamo naudu, bet jūs nevarētu piesaistīt talantīgus programmatūras izstrādātājus, kas spētu strādāt ar strauji mainīgajām interneta tehnoloģijām, ja jūs pret viņiem izturētos kā pret padotiem kodētājiem, kas verdziski seko “spec”. Mēs noraidījām projektu vadītājus, kuri ieradās ar gala – gala grafikiem, kuros aprakstīts, kas mums jāattīsta, kad jāpiegādā lietojumprogrammas, un dažreiz pat tas, kā strukturēt kodu. Mums bija briesmīgi sasniegt trīs un sešu mēnešu grafikus, kurus ūdenskrituma projektu vadītāji izstrādāja un nemitīgi atjaunināja.
Tā vietā mēs sākām viņiem pastāstīt, kā jāveido interneta lietojumprogrammas, un mēs sniedzām rezultātus pēc grafika, kuru mēs sastādījām iteratīvi. Izrādās, ka mums nebija tik slikti izpildīt to, ko mēs teicām, kad apņemamies to darīt mazos, no vienas nedēļas līdz četrām nedēļām.
2001. gadā grupa pieredzējušu programmatūras izstrādātāju sapulcējās un saprata, ka viņi kopīgi praktizē programmatūras izstrādi atšķirīgi no klasiskās ūdenskrituma metodikas. Un viņi visi nebija jaunizveidoti. Šī grupa, kurā ietilpa tehnoloģiju korektori Kents Beks, Martins Faulers, Rons Džefrišs, Kens Švāberis un Džefs Saterlends, nāca klajā ar Agile manifestu, kas dokumentēja viņu kopīgo pārliecību par to, kā jādarbojas modernam programmatūras izstrādes procesam. Viņi uzsvēra sadarbību dokumentācijas jomā, pašorganizēšanos, nevis stingru pārvaldības praksi un spēju pārvaldīt pastāvīgas pārmaiņas, nevis ieslēgt stingru ūdenskrituma attīstības procesu.
No šiem principiem dzima veiklā programmatūras izstrādes metodika.
Lomas veiklā metodikā
Veikls programmatūras izstrādes process vienmēr sākas, definējot lietotājus un dokumentējot redzējuma izklāstu par risināmo problēmu, iespēju un vērtību apjomu. Produkta īpašnieks uztver šo redzējumu un sadarbojas ar daudznozaru komandu (vai komandām), lai īstenotu šo redzējumu. Šeit ir lomas šajā procesā.
Lietotājs
Veiklie procesi vienmēr sākas, domājot par lietotāju vai klientu. Šodien mēs tos bieži definējam ar lietotāju personām, lai ilustrētu dažādas lomas programmatūras atbalstītajā darbplūsmā vai dažāda veida klientu vajadzības un uzvedību.
Produkta īpašnieks
Pats veiklais izstrādes process sākas ar kādu, kuram ir jābūt klienta balsij, ieskaitot visas iekšējās ieinteresētās puses. Šī persona iztulko visas atziņas, idejas un atsauksmes, lai izveidotu produkta redzējumu. Šīs produkta vīzijas bieži ir īsas un vienkāršas, taču tās tomēr parāda priekšstatu par to, kas ir klients, kādas vērtības tiek risinātas, un stratēģiju, kā tās uzrunāt. Es varu iedomāties, ka Google sākotnējā vīzija izskatījās apmēram tāda: "Atvieglosim ikvienam, kam ir piekļuve internetam, atrast atbilstošas vietnes un tīmekļa vietnes ar vienkāršu, uz atslēgvārdiem balstītu saskarni un algoritmu, kas cienījamus avotus ierindo meklēšanas rezultātos augstāk."
Mēs šo cilvēku saucam par produkta īpašnieks. Viņa pienākums ir definēt šo vīziju un pēc tam sadarboties ar attīstības komandu, lai to īstenotu.
Lai strādātu ar izstrādes komandu, produkta īpašnieks sadala produkta redzējumu lietotāju stāstu sērijā, kas sīkāk izskaidro, kas ir mērķa lietotājs, kāda problēma viņam tiek atrisināta, kāpēc risinājums viņiem ir svarīgs un kādi ierobežojumi un pieņemšanas kritēriji nosaka risinājumu. Produkta īpašnieks nosaka šo lietotāju stāstu prioritāti, un komanda tos pārskata, lai pārliecinātos, ka viņiem ir kopīga izpratne par to, kas no viņiem tiek prasīts.
Programmatūras izstrādes komanda
Izveicībā izstrādes komanda un tās locekļu atbildība atšķiras no tradicionālās programmatūras izstrādes.
Komandas ir daudzdisciplināras un sastāv no daudzveidīgas cilvēku grupas ar prasmēm paveikt darbu. Tā kā galvenā uzmanība tiek pievērsta darbojošās programmatūras piegādei, komandai ir jāpabeidz pilnībā funkcionējošas lietojumprogrammas. Tātad datu bāze, biznesa loģika un lietotāja saskarne daļa tiek izstrādāta un pēc tam demonstrēta, nevis visa lietojumprogramma. Lai to izdarītu, komandas dalībniekiem ir jāsadarbojas. Viņi bieži tiekas, lai pārliecinātos, ka visi ir saskaņoti ar to, ko viņi veido, kas ko dara un kā tieši tiek izstrādāta programmatūra.
Papildus izstrādātājiem programmatūras izstrādes komandās atkarībā no programmatūras projekta veida var būt kvalitātes nodrošināšanas (QA) inženieri, citi inženieri (piemēram, datu bāzēm un aizmugures sistēmām), dizaineri un analītiķi.
Scrum, Kanban un citi veiklie ietvari
Daudzi veiklie ietvari, kas nodrošina specifiku par izstrādes procesiem un veiklu izstrādes praksi, saskaņoti ar programmatūras izstrādes dzīves ciklu.
Tiek saukts vispopulārākais veiklais ietvars scrum. Tas koncentrējas uz piegādes ritmu, ko sauc par a sprints un sanāksmju struktūras, kas ietver:
- Plānošana - kur tiek noteiktas sprinta prioritātes
- Apņemšanās - kur komanda izskata lietotāju stāstu sarakstu vai uzkrājumu un izlemj, cik daudz darba var paveikt sprinta laikā
- Ikdienas rezerves sanāksmes - lai komandas varētu paziņot jaunumus par savu attīstības stāvokli un stratēģijām)
Sprints beidzas ar demonstrācijas sanāksmi, kurā funkcionalitāte tiek parādīta produkta īpašniekam, kam seko retrospektīva sanāksme, kurā komanda apspriež, kas izdevās labi un kas ir jāuzlabo viņu procesā.
Daudzas organizācijas nodarbina skrāpju meistarus vai trenerus, lai palīdzētu komandām pārvaldīt skrāpējuma procesu.
Lai gan dominē scrum, ir arī citi veiklie ietvari:
- Kanban darbojas kā fan-in un fan-out process, kurā komanda izvelk lietotāju stāstus no ieplūdes dēļa un virza tos pa pakāpenisku izstrādes procesu, līdz tie ir pabeigti.
- Dažas organizācijas izmanto hibrīdu ātru un ūdenskrituma pieeju, izmantojot veiklus procesus jauniem lietojumiem un ūdenskritumu mantotajiem.
- Ir arī vairākas sistēmas, kas ļauj organizācijām pielāgot praksi vairākām komandām.
Kaut arī veiklās ietvarstruktūras nosaka procesu un sadarbību, veiklās izstrādes prakses ir specifiskas programmatūras izstrādes uzdevumu risināšanai, kas veikti saskaņoti ar veiklu sistēmu.
Piemēram, piemēram:
- Dažas komandas pieņem pāru programmēšanu, kur divi izstrādātāji kodē kopā, lai iegūtu augstākas kvalitātes kodu un ļautu vecākiem vecākiem izstrādātājiem padomāt par jaunākajiem.
- Progresīvākas komandas pieņem testētu attīstību un automatizāciju, lai nodrošinātu, ka pamatfunkcionalitāte nodrošina gaidītos rezultātus.
- Daudzas komandas arī pieņem tehniskos standartus, lai izstrādātāja interpretācija par lietotāja stāstu nenodrošinātu tikai vēlamo funkcionalitāti, bet arī atbilstu drošībai, koda kvalitātei, nosaukumu piešķiršanas noteikumiem un citiem tehniskajiem standartiem.
