Testu vadīta izstrāde

TDDTestu vadīta izstrāde ir dažādu programmu izstrādes process, kura pamatā ir īsu izstrādes ciklu atkārtošana. Šādu programmu izstrādes procesu izveidoja jeb drīzāk no jauna atklāja Kents Beks, kurš uzskata, ka šī tehnika ne tikai palīdz izstrādāt vienkāršākus un saprotamākus programmu dizainus, bet arī spēj iedvesmot izstrādātāja pašapziņu, jo biežā ciklu atkārtošana ļauj programmētājam iegūt pārliecību par sevi un programmu, kuru tas izstrādā.

Veidojot programmas ar šādas testu vadītas sistēmas palīdzību, ir jāizpilda trīs  soļi, kuri ir jāveic katrā programmas stadijā, tātad tie tiks atkārtoti vairākas reizes. Šie soļi ir:

  • vispirms programmētājam ir jāuzraksta automātisks testa gadījums, kurā tiek definēti vēlamie programmas uzlabojumi vai jaunās šīs programmas funkcijas, šis tests noteikti pirmā testēšanas reizē izgāzīsies, taču tieši tāpēc tu uzlabosi savu programmu, kamēr tā spēs izturēt testu;
  • nākamais solis ir izstrādāt pēc iespējas mazāku kodu, kurš spētu veiksmīgi izturēt iepriekšējā solī izstrādāto testu;
  • un treškārt programmas veidotājs restrukturē no jauna izveidoto kodu, lai tas atbilstu pieņemamie standartiem.

Pēc tam, kad ir izdarīti šie soļi un ir iegūts jauns kods, atkal jārada tests, jāuzlabo esošais kods un jātestē tas, kā rezultātā tu iegūsi arvien labāku programmas kodu.

Saka, ka šāda programmu izstrādes metode ir visai saistīta ar ekstrēmās programmēšanas, kas arī ir programmu izstrādes metodoloģija, konceptu, kurā programmas tiek vispirms testētas un tad uzlabotas.

Izstrādājot programmas ar šādas metodes palīdzību tu iegūsi vairākus šādas izstrādes labumus, piemēram, šāda izstrāde ļauj izstrādās tīrākus, skaidrākus un vienkāršākus kodus, kuri spēj sasniegt tieši tos pašus rezultātus, ko spēj sarežģīti un gari kodi. Kā arī izstrādātais kods var būt vienkāršāks nekā mērķa modeļa kods, taču tevis izveidotais kods joprojām spēs izturēt visus testus un pārbaudes, kas ir lieliski, jo vienkāršāks un īsāks kods nozīmē, ka programmētājam ir iespēja vairāk koncentrēties uz citiem programmas aspektiem. Kā arī kodi, kuri ir rakstīti šīs metodes rezultātā, ir daudz elastīgāki, modulārāki un tos ir iespējams vairāk izstiept, kas nozīmē vieglāku operēšanu ar tiem.

Šī testu vadīta programmu izstrādes metode ir lieliska tiem, kuri vēlas uzrakstīt īsāku un vienkāršāku kodu, un tiem, kuri zina, ka tiem netraucē papildus testu izstrāde. Šāda veida izstrāde ļaus tev būt ne tikai daudz pārliecinātākam par savu programmu, jo tu būsi to testējis ikvienā tās izstrādes posmā, bet programma pati par sevi būs daudz labāka un veiksmīgāka.

Ūdenskrituma modelis

udenskrituma modelisŪdenskrituma modelis ir viens no pirmajiem programmatūra izstrādes procesiem, kas ticis standartizēts jau tālajā 1970. gadā un tiek izmantots programmatūras izstrādes procesā. Ūdenskrituma modelis pašos pirmsākumos radās ārpus programmēšanas industrijas, citās sfērās, kur bija nepieciešama sekvenciāla darbību veikšana, lai nonāktu līdz ikviena projekta galapunkta. Arī programmatūras izstrādes industrijas aizsākumos, tas tika izmantots, pārņemot to no citām industrijām un adaptējot informācijas produktu izstrādei.
Pats ūdenskrituma modelis nosaka, ka visai programmas izstrādei ir jāseko pilnīgi secīgām fāzēm, kas tiek sadalītas noteiktos laikos un katras fāzes izpildes beigās notiek tās analizēšana un nonāk pie nākamās fāzes. Programmas izstrādes veidā tas varētu būt, kā programmas izstrādes sadalīšana pa programmēšanu, testēšanu un implementāciju, bet šeit uzreiz rodas virkne nepilnības. Šis modelis var būt efektīvi implementēts tikai tad, ja projekta prasības ir pilnībā zināmas jau pirms projekta sākuma, bet programmatūras izstrādē šādi gadījumi ir diezgan reti, un pati programma aug un attīstās līdz ar tās izveidi un tādēļ ūdenskrituma modelis nav no tiem efektīvākajiem izstrādes procesu veidiem

Vai Agile darbavietā vēl vajadzīgi menedžeri?

agileTā kā Agaile kļūst par ar vien nozīmīgāku lielu kompāniju daļu, mainās arī dažādu kompānijas darbinieku lomas un pienākumi. Kompānijas izdod milzīgas naudas summas, lai izskolotu un trenētu savus darbiniekus būt labākajiem Projektu Menedžeriem, taču mūsdienās lielāko daļu Projektu Menedžera pienākumu var veikt Agaile komandas, kā rezultātā šie menedžeri vairs firmās kļūs arvien mazāk pieprasīti.

Arī tādu amati kā Biznesa analizētājs un QA profesionālis kļūst arvien retāk pieprasīti, jo arvien vairāk spēj padarīt Scrum, kas ir Agile procesu rāmis. Šis daudzfunkcionālais Agile spēj būt stratēģisks un organizēts, taču tas nespēj vienkārši izveidot augsta līmeņa programmu attīstības komandas. Tāpēc no šī var secināt, ka lai gan programmu izstrādes procesā nav nepieciešami menedžeri, kuri pārskata komandas katru kustību, ir nepieciešami atsevišķi cilvēki, kuri palīdzēs aptvert, izstrādāt un izpildīt šīs programmas aprises, lai var sākties tās izstrādes process.

Tāpēc, manuprāt, jautājums “Vai Agile darbvietā vēl vajadzīgi menedžeri” ir nepareizs. Šeit būtu jājautā: “Kā organizācijas spēs sevi pārveidot un kā pašreizējos Projektu Menedžeru loma mainīsies un uzlabosies nākotnē”. Bet lai vispār varētu uzdot šo jautājumu, ir nepieciešams skaidri izprast, kurā virzienā Agile un menedžera profesijas attīstīsies. Un, lai to izprastu, jau vien ir nepieciešamas vadošās profesijas kā menedžeri, lai būtu iespējams apjaust un izstrādāt šos attīstības virzienus.

Kā agile metodoloģija dažreiz nestrādā

agile methodologyJaunā kompānijās, kur tiek sākts jauns darbs pie kādiem projektiem parasti pieņem darbā jaunus cilvēkus un metodoloģija, kas tiek izmantota šīs kompānijas projektu izpildē parasti tiek pielietota visos tās aspektos. Tomēr lielās kompānijas, kuras tradicionāli strādājušas ar citiem menedžmenta modeļiem un cenšas pārvērst visu savu struktūru uz agile metodoloģiju bieži vien saskaras ar lielām grūtībām, jo, vai nu tām nav skaidrs, kas tad īsti agile ir, vai arī mazliet šo sistēmu pamēģinot neliekas ka tā strādā, tāpēc tā tiek atmesta un visi tās principi tiek nomelnoti, sakot ka tā nestrādā. Tā vien šķiet, ka visi lielākie mīti un nomelnojumi ir atspēkoti vienā vai otrā interneta rakstā, tomēr šodien došu jums ieskatu dažos no tiem un likšu jums padomāt par to, kā jums Agile metodoloģija kādreiz ir pievīlusi un vai tā bija pašas sistēmas vaina vai tomēr implementācijas.

Agile nestrādā lielās komandās?

Šim apgalvojumam ir savs pamatojums, jo Agile metodoloģija tik tiešām ir domāta priekš mazām un kompaktām komandām, kas savā starpā var darboties un veidot projektus inovatīvi un pēc iespējas efektīvi. Tomēr lielākiem projektiem parasti ir vajadzīgas lielākas komandas un tas nozīmē daudz vairāk cilvēku, kur Agile tik tiešām nestrādās. Bet šādos gadījumos pareizais ceļš būtu tieši šo komandu sadalīšana mazākos segmentos un katrai mazajai komandai strādājot pēc Agile principiem piespēlēt kādus konkrētus darbus, lai komanda pati tiek ar tiem galā.

Agile ir domāta tikai priekš jaunām kompānijām?

Ir taisnība, ka Agile metodoloģija pārsvarā tiek izmantota jaunās kompānijās jeb tā saucamajos Startups, jo jaunie kompāniju vadītāji nereti redz lielu potenciālu šādam domāšanas veidam un tātad arī to cenšas implementēt, tomēr tas nenozīmē, ka kompānijai augot un attīstoties ir jāveido lielāka un lielāka birokrātija, jo tas nebūt nav efektīvi. birokrātija, projektu vadītāji un citādas struktūras padara inovāciju par nenozīmīgu soli un pārmaiņu veikšana nereti ir neiespējama, kas ilgtermiņā kompāniju novedīs tikai pie sliktiem rezultātiem. Agile metodoloģija, ja tā tiek pielietota pareizi derēs gan mazām gan lielām kompānijām!

Agile metodoloģija vienkārši nestrādā?

Šādi apgalvojumi parasti nāk no indivīdiem, kas ir kontroles kāri un cenšas visus savus darbiniekus pēc iespējas vairāk piezemēt un, liekot tiem dažādus darbus pārtraukt to kreatīvo domāšanu. Tieši tāpēc, ka Agile ir pilnīgi savādāka sistēma, kur viss, ko katrs komandas biedrs dara ir redzams un nav tādi augstāki menedžeri uz kuriem visi skatās ar bailēm ir tas, kas padara šo sistēmu efektīvu un tādēļ arī tā tiek aizvien vairāk un vairāk pielietota mūsdienu kompānijās.

Šīs ir tikai dažas no lietām, ko cilvēki saka par šo metodoloģiju, un noteikti ka ir vēl daudz citu lietu, kas var likties dīvainas vai, kas arī nestrādā, tomēr vienmēr nevajag pakļauties uz vecajiem instinktiem un aizvien vairāk domāt tieši pār nākotni un to, kā tas varētu uzlabot jūs un cilvēkus jums apkārt.

Getting Things Done jeb darbu kārtošanas sistēma

Getting Things Done jeb darbu kārtošanas sistēma ir 2001. gadā izdota grāmata un sistēma, kas palīdz cilvēkiem dalīt savu laiku un būt produktīvākiem. GDT sistēma ir balstīta uz konceptu, ka mūsu smadzenes ir salīdzinoši neefektīvas, kad tām ir jāatceras dažādas lietas, tāpēc Deivids Allens(David Allen) izgudroja sistēmu, kas ikvienam ļauj savus darāmos darbus pierakstīt noglabāt un pēc tam pareizajā laikā atgūt, lai par tiem vairs nebūtu jādomā.

getting things done

Deivids ir parasts puisis, kas visu savu dzīvi ir lēkājis no vienas vietas uz otru un nemaz nav domājis par to, cik produktīvs viņš ir, tomēr gadu gaitā viņam izdevies izveidot sistēmu, kā sakārot savus ikdienas plānus, lai vieglāk katru dienu būtu atcerēties, kas šajā dienā ir darāms, kā arī pierakstīt darbus uz nākotnes laikiem, jo vienkārši paturot tos prātā mēs nespējam atcerēties vairāk kā tikai dažas lietas vienlaicīgi.

Būtībā mūsu smadzenes ir kā dators, kas nepārtraukti darbojas un ja mums ir vajadzīgs kaut ko atcerēties, tad prasti brīvos brīžos, kad mēs neko nedarām šīs darbības ienāk mūsu prātā un mēs varam tūlītēji atcerēties to kas bija darāms, tomēr, ja pašlaik nav laiks to izdarīt, tad domu aizmirst tik vienkārši nav iespējams un mēs nekādu progresu šajā darbā neveicam, bet tikai atkārtojam to ko mēs jau zinām. Tas nozīmē, ka pareizi izveidota sistēma, kas mums atgādināt par dažādiem darbiem un dotu paziņojumus par to, kas ir jāizdara ir nepieciešama, lai mēs varētu atcerēties to, kas ir jādara un izdarīt to tieši tajā laikā, kad tas ir jādara nevis domāt par nākotnes darbu jau pāris dienas iepriekš.

Deivids savā GTD sistēmā uzstāda šādu veidu, kā mēs varētu labāk sakārtot savus darbu un tas ir: izveidot 31 dažādas atvilktnes, vai virtuālās aploksnes, kur mēs ieliekam katras mēneša dienas darāmos darbus, un katrā atvilktnē visi darbi tiek sakārtoti vēl pa mazākiem gabaliem, lai, piemēram, būtu skaidrs, ka šāds darbs jāizdara no rīta, un šāds darbs jāveic vakarā. Deivids stāsta arī par to, ka ir vajadzīgs veidot dažāda konteksta plānošanas, kas ir ikdienas plānošana, iknedēļas plānošana, ikmēneša plānošana un ikgadējā plānošana, kur katrā no šīm darbībām ir jāuzstāda cits konteksts, jo ikgadējā plānošanā diezin vai jūs varēsit sastādīt ikdienas darāmo darbu plānu, tomēr jūs tajā varat nostādīt galvenos mērķus un atskatīties uz pagājušo gadu un to, kā jums ir veicies ar iepriekšējo mērķu izpildi.

Šī sistēma ir domāta ikvienam, bet tā noteikti palīdzēs tieši programmatūras izstrādātajiem un to vadītājiem, kā arī uzņēmējiem, jo šiem cilvēkiem parasti ir visvairāk darbi, kas ir jāpilda  un kuri prasa nemitīgu atcerēšanos un aizņem vietu jūsu smadzenēs.

Efektīvi aksesuāri Agile metaddoloģijas pielietotājiem

Agile metodoloģijas piekritējiem varētu būt nederīgas daudz un dažādas iekārtas, kas varētu pacelt produktivitāti, un palīdzēt jums labāk un ātrāk izstrādāt ikvienu projektu mazinot traucēkļus. Šodien došu jums ieskaitu tikai 5 no šādiem efektivitātes paaugstinošiem priekšmetiem.

Android Dok-stacija

Pirmais, uz ko katram Agile piekritējam būtu jāskatās ir tā sauktās dok stacijas, jeb plikņi, priekš Android vai Apple telefoniem, kas būtībā ir paliktnis, kas spēj lādēt jūsu viedtelefonu, kā arī saslēgt to ar datoru un arī turēt to ergonomiskā pozīcijā. Šādas iekārtas Latvijā pagaidām vēl nav ieguvušas popularitāti, bet citās pasaules vietās tās noteikti ir ievērojami vairāk lietotas, jo būtībā jūs iegādājoties šādu iekārtu varat nemitīgi savu telefonu uzturēt ar pilnu akumulatoru un arī uzstādīt, lai kad tas ir dok-stacijā ievietots jums rādītos jaunākie sociālo ierakstu signāli vai citi jums svarīgi atjauninājumi, bet ja vēlaties pārlikt mūziku vai failus no datora uz  telefonu ar dokstacijā iebūvēto USB savienojumus tas būs viegli un ātri izdarāms.

Vairāk apr Dok-Stacijām lasit šeit: www.dockingstationhq.com

Gudrais pulkstenis

Gudrie pulksteņi ir nākotnes tehnoloģija, kuras pirmās iterācijas sāk jau parādīties šobrīd no Samsung kompānijas puses, un lai gan tie vēl nav izplatīti, tos jau ir iespējams visai efektīvi lietot kopā ar jūsu viedtelefonu kā atgādinājumu vai citu atjauninājumu iegūšanai. Šādi pulksteņi noteikti būs nākotnē visai izplatīti, jo tajos bez ierastajām laika un datuma funkcijām ir daudz un dažādas citas iespējas, kā lasīt SMS, pārslēgt dziesmas, kas skan no jūsu viedtelefona Bluetooth austiņās vai citādi manipulēt ar citām tehnoloģijām. Šādi efektīvi izmantojot šos pulksteņus visai krasi iespējams samazināt šādām darbībām veltīto laiku, un tas noteikti ieinteresēs Agile ekspertus.

Vairāk par Samsung Galaxy Gear šeit: Samsung.com

Google brilles

Gandrīz ik viens, kas ir saistīts ar jaunajām tehnoloģijām būs dzirdējis par Google interaktīvajām brillēm, kas ļauj jums lietot brilles, kā viedtelefonu ar balss komandām un žestiem, bet attēlus redzēt mazā ekrānā, kas tiek projecēts uz briļļu augšpusē izvietota ekrāna. Būtībā šādas brilles vēl nav nonākušas plašākā apgrozījumā, tomēr par noteiktu samaksu ikvienam jau ir iespējams tās iegādāties un pēc atsaucēm jāsaka, ka ar šādu iekārtu ikdienas dzīve vairs nebūs tāda, ka agrāk, jo tās ļaus jums sazināties ar draugiem, sērfot internetā un veikt video, foto uzņēmumus bez liekām darbībām un tūlītēji, kas ir ļoti efektīvi. Ja projektā visiem projektā iesaistītajiem būtu šādas brilles, tās varētu savienot vienotā tīklā, lai projekta vadītājs varētu vērot, ko katrs darbinieks dara, un neskaidrību jautājumā varētu notikt saziņa starp cilvēkiem bez liekas staigāšanas vai datora darba virsmas nomaiņas.

Vairāk pag google brillēm šeit: Google

Taimeris

Lai vai cik jocīgi neliktos, bet parasts virtuves taimeris arī var būt uzskatāms par efektīvos projektos izmantotu ierīci, jo strikti laika un atpūtas nosprausti laiki dod mums mazāk stresa, un kā gan labāk noteikt noteiktus laikus, kā ar taimeri. Ir pieejami dažādi veidu un stilu taimeri, tomēr Agile projektiem vislabākie taimeri būs tādi, kuriem iespējams uzstādīt dažādus laikus un atkārtojumus, lai būtu iespējams uzstādīt laiku vienā dienā un to izmantot visu nedēļu, kā arī iestādīt SCRUM mītiņu laikus un kopējos projekta atrādīšanas laikus.

Hostings jūsu projektam

agilerigaday web hostinga veidi

Web projektu izstrādes laikā un gatava projekta testēšanai pabeigta projekta izvietošanai internetā būs nepieciešams kāds no web hostinga veidiem. Atkarībā no izstrādātā projekta lieluma un sarežģītuma ir iespēja izvēlēties no vairāku veidu web hostingiem un serveriem. Lai agile izstrādes komandai nebūtu lieki jātērē laiks konfigurējot un uzturot fizisku web serveri, var izmantot kādu kompāniju piedāvātajiem web hostinga veidiem – dalīto hostingu, VPS, Dedicated serveri, vai iespējams arī mākoņa hostingu. Pirms izlemjat, kurš web hostinga veids būs vispiemērotākais jūsu projektam, apskatiet visus web hostinga un serveru veidus.

Dalītais web hostings

Dalītais web hostings ir populārākais hostinga veids, kas šobrīd ir pieejams. Šo hostinga veidu izmanto miljoniem cilvēku visā pasaulē, dažāda veida un lieluma mājas lapu hostēšanai. Dalītais web hostings arī būs vislētākais, izmaksājot sākot no pāris eiro līdz pāris desmitiem eiro, atkarībā no hostinga kompānijas piedāvājuma. Dalītais hostings būs labāks tieši mazākiem projektiem, ar mazāku lietotāju skaitu un zemākām servera aparatūras prasībām.

VPS

VPS jeb virtuālais privātais serveris nozīmē to, ka uz fiziska servera tiek izveidotas vairāki virtuālie serveri, kas izmanto fiziskā servera resursus. Klients norāda cik daudz servera resursu viņam ir nepieciešams (CPU, RAM, HDD), un hostinga kompānija attiecīgi nokonfigurē servera pēc lietotāja prasībām. Jo augstākas būs jūsu prasības, jo lielākas būs VPS mēneša izmaksas. Atšķirībā no dalītā web hostinga, VPS gadījumā jūsu mājas lapu darbību neietekmēs tas, kādas citas mājas lapas atradīsies uz tā paša servera, uz kura atrodas jūsu virtuālais serveris. Dalītais hostings bieži vien var būt lēns, atkarībā no citu lietotāju mājas lapām, kas ir izvietotas uz tā paša servera. Izvēloties VPS, jums būs arī iespēja nokonfigurēt serveri pēc jūsu pašu vēlmēm, vai arī ļaut hostinga kompānijai nokonfigurēt to jūsu vietā.

Dedicated serveris

Izvēloties šo web hostinga plānu, jūs būtībā iegūstat savā rīcību visu fizisko serveri, taču tā vietā, lai serveris atrastos jūsu mājās vai birojā, tas ir izvietots pie hostinga kompānijas, kas arī attiecīgi par to parūpēsies nodrošinot nepieciešamo vietu, enerģijas resursus un tehnisko atbalstu. Dedicated servera īre izmaksās visdārgāk, parasti sākot no aptuveni 80 eiro mēnesī par vienkāršāko versiju. Hostinga kompānijas piedāvā izvēlēties no dažādu veidu Dedicated hostinga plāniem, sākot ar ekonomijas variantu, kas ietver lēnākas darbības serveri, līdz par augstas ātrdarbības vairāku kodolu serveriem ar vairākiem TB cietā diska vietu un vairāku GB RAM atmiņu. Lai varētu pareizi sakonfigurēt Dedicated serveri, būs nepieciešamas speciālas zināšanas serveru un to programmatūru instalēšana un darbībā.

Mākoņa hostings

Mākoņa hostings ir viens no jaunākajiem web hostinga veidiem. Mākoņa hostings nozīmē to, ka serveru skaitu un resursus, uz kuriem atrodas jūsu veidotā aplikācija vai mājas lapa ir iespējams palielināt vai samazināt atkarībā no vajadzības. Daudzas kompānijas izvēlas savas aplikācijas hostēt tieši uz mākoņa hostinga. Bieži prakse arī web lapu un aplikāciju izstrādātājiem ir izmantot tieši mākoņa hostingu programmatūras izstrādes un testēšanas laikā. Izmantojot mākoņa hostingu, jūs maksājat tik daudz, cik daudz serveru resursus jūs izmantojat, tāpēc nav jāpārmaksā par papildus servera resursiem, kurus iespējams nemaz nevajadzēs. Mākoņa hostings arī var viegli nodrošināt papildus resursus, gadījumos, kad jūsu mājas lapai ir lielāks apmeklētāju skaits un nepieciešama papildus skaitļošanas jauda un cietā diska vieta.

Ja nav skaidrs, kurš hostinga veids ir vispiemērotākais jūsu projekta, daudzas hostinga kompānijas piedāvā iespēju izmēģināt viņu web hostinga servisus, lai jums būtu vieglāk saprast, kurš hostinga veids jūsu projektam derēs vislabāk, gan pēc tehniskajiem parametriem un servisiem, gan pēc cenas.

Agile metode – Extreme programming

Vispārīgi par XP.

XP jeb ekstrēmā programmēšana ir programmatūras izstrādes disciplīna,  kas balstās uz vienkāršumu, komunikāciju, atgriezenisko saiti ar klientu, drosmi  un respektu. Ekstrēmā programmēšana ir veiksmīga tāpēc, ka tās pamatā ir klienta labsajūta un vēlmju izpilde. Tā vietā, lai pabeigtu visu produktu kaut kādā noliktā datumā nākotnē, šī metode ļauj pabeigt produktu tieši tad, kad tas ir vajadzīgs. XP nodrošina nepārtrauktu programmētāju atbildi jebkurām mainīgajām klienta prasībām, kā rezultātā jebkurā izstrādes laikā klients var mainīt kādas programmatūras daļas funkcijas vai uzdevumus un programmētāji turpina veidot programmatūru atbilstoši jaunajām klienta prasībām, kas būtu neiespējami vai daudz sarežģītāk, ja par pamatu programmatūras izstrādē tiktu izmantota ūdenskrituma metodoloģija.

Ekstrēmās programmēšanas pamatā ir komandas darbs. Tas nozīmē, ka gan projekta menedžeri, gan klienti un protams izstrādātāji ir vienlīdzīgi iesaistīti projektā un nepārtraukti sadarbojas viens ar otru uzklausot otras puses viedokli, veicot nepieciešamās izmaiņas, kā arī izstrādāt dažādas programmatūras daļas, balstoties uz klienta mainīgajām prasībām. Komandas, kas izmanto XP ir krietni produktīvākas, jo var strādāt daudz efektīvākā vidē. Lai atrisinātu problēmu pēc iespējas efektīvāk, visa komanda tiek iesaistīta tās risināšanā.

agile-extreme-programming

Programmatūras izstrādātāji, kas vadās pēc Ekstrēmās programmēšanas metodēm patstāvīgi komunicē ar klientiem, kā arī pārējiem projektā iesaistītajiem programmētājiem. Viņi mēģina saglabāta izstrādes procesus, metodes un kodu pēc iespējas vienkāršāku un tīrāku. Programmatūras darbība tiek testēta jau no pirmās izstrādes dienas, tāpēc ir iespējams iegūt jaunāko informāciju par tās darbību, kā arī klienta ir iespēja sekot līdz izstrādes gaitai un pēc iespējas īsākā laikā saņemt jau strādājošu produktu. Pateicoties šai saitei ar klientu, izstrādātāji var veikt nepieciešamās izmaiņas, ja klients tādas ir noteicis pēc produkta apskatīšanas. Šāda sadarbība starp klientu un programmētājiem laikā gaitā veicina respektu vienam pret otru, kas ļauj programmētājiem pielietot jaunākas tehnoloģijas un metodes projekta izstrādē.

Ekstrēmās programmēšanas noteikumi.

Plānošana:

  • Tiek rakstīti lietotāja stāsti

  • Tiek plānotai izlaidienu un izlaidienu grafiks

  • Jāveido daudzi mazi izlaidieni

  • Projekts tiek dalīts vairākās iterācijās

  • Katra iterācija sākas ar iterācijas plānošanu

Menedžēšana:

  • Nodrošināt komandai atvērtu darba vietu

  • Noteikt ilgtspējīgu darba tempu

  • Katra darba dienas iesākas ar komandas apspriede par padarītajiem un darāmajiem darbiem

  • Tiek mērīts projekta izstrādes ātrums

  • Mainīt cilvēkus, kas izstrādā noteiktu uzdevumu, lai nerastos aizture, ja kādam izstrādātājam rodas problēmas pie uzdevuma izpildes

  • Izlabot Ekstrēmās programmēšanas izstrādes metodes, ja projekta izstrādes laikā, tās vairs netiek ievērotas

Projektēšana:

  • Vienkāršums

  • Izvēlēties sistēmas metaforu, lai jauniem cilvēkiem būtu vieglāk iepazīties ar projekta specifiku un nebūtu jāiet cauri lielam skaitam dokumentu

  • Izmantot CRC (Class, Responsibilities, and Collaboration) kartes

  • Izveidot smailes risinājumu, lai samazinātu riskus un spētu atrast atbildes un sarežģītām tehniskām un projektēšanas problēmām

  • Nekādas funkcionalitāte netiek pievienota projekta sākumā

  • Refaktorēt kodu, kad vien tas ir iespējams

Programmēšana:

  • Klientam vienmēr ir taisnība

  • Kods tiek rakstīts pēc noteiktiem standartiem

  • Sākumā ir jāizveido vienības testi

  • Viss ražotnes kods tiek rakstīts pāru programmēšanā

  • Tikai viens pāris integrē kodu noteiktā laikā

  • Veikt integrāciju pēc iespējas biežāk

  • Uzstādīt noteiktu integrācijās datoru

  • Izmantot kolektīvās pieejas

     Testēšana:

  • Visam kodam ir jānodrošina vienības testi

  • Visam kodam ir jāaizpilda vienības testi, lai to varētu izlaist gala versijā un nodot klientam

  • Kad tiek atrasta kļūda, tiek izveidoti jauni testi

  • Pēc iespējas biežāk tiek palaisti akcepttesti un rezultāti tiek publiskoti

Kas ir Agile Metodoloģija?

agile izstrades processAgile, jeb Latviski “Spējā izstrāde” ir programmatūras inžinierijas metodoloģija , kas ir balstīta uz iteratīvu un ciklisku izstrādes procesu, kurā projekts tiek virzīts uz priekšu ar organizētu sadarbību starp mazām komandām. Agile metodoloģija ir balstīta uz iteratīvu izstrādes procesu, lai būtu iespējams viegli un ātri adaptēties izmaiņām programmas specifikācijā un ļauj visai komandai , kas ietver programmētājus, klientu, vadītāju un vēl citas puses, viegli adaptēties un sekot līdzi visam izstrādes procesam.

Agile metodoloģijas pirmsākumi meklējami ap 2001. gadu, kad tika izstrādāts spējās izstrādes manifests, jeb “Manifesto Of Agile Softwere Development” , un kopš tā laika programmatūras izstrādes process nav bijis tāds, kā agrāk, jo metodoloģijā ieļautās mācības par filozofiju, izstrādes ciklu un gaitu, kā arī ierīcēm un programmām, kas tiek izmantotas izstrādes ciklā ir padarījušas dažādu informācijas produktu izstrādi ātrāku, lētāku un efektīvāku.

Agile metodoloģijas paši pirmsākumi vēl pirms 2001. gada ir meklējami jau tālajā 1974. gadā, kad Ņujorkas telefonu sistēmas izstrādē tika pielietotas metodes un iezīmes, kas ļoti atgādina Agile metodes, un tās bija iteratīvs un atkārtots izstrādes process un evolucionārs projekta izstrāde un plānošanas process.

Agile metodoloģijas galvenās vērtības ir:

  • Individuals and interactions over Processes and tools (Indivīdi un mijiedarbības pār procesiem un instrumentiem)
  • Working software over Comprehensive documentation(Strādājoša programma pār visaptverošu dokumentāciju)
  • Customer collaboration over Contract negotiation(Sadarbība ar klientu pār līguma sarunām)
  • Responding to change over Following a plan(Atbildēt uz pārmaiņām pār sekošanu noteiktam plānam)

 

Visi šie principi ļauj Agile programmatūras izstrādes modelim dominēt pār citādu izstrādi, jo šādi ir viegli veicināt projekta izmaiņas, visas iesaistītās puses zina un ir lietas kurā par projekta izstrādi un tā gaitu, un gan klientiem, gan pašiem izstrādātājiem ir lielāka brīvība ,kas veicina komunikāciju un izstrādes efektivitāti.

 

Agile izstrādes metodes

Agile projektu un programmatūras pamatā tiek izmantotas dažādas izstrādes metodes. Katra no metodēm ir veidota noteiktam programmatūras izstrādes ciklam. Programmatūras izstrādes cikls sastāv no 3 galvenajām fāzēm – plānošanas, ieviešanas – testēšanas – dokumentēšanas, izvietošanas un uzturēšanas. Daļa no Agile izstrādes metodēm fokusējas vairāk uz noteiktām izstrādes praksēm, kamēr citas vairāk uz programmatūras izstrādes plānošanu un menedžēšanu. Ir arī tādas metodes, kas nodrošina visu projekta daļu pārklāšanos. Katrai no šīm Agile izstrādes metodēm tiek izmantotas noteiktas prakses, terminoloģija un taktika. Vienas no populārākajām Agile izstrādes metodēm šobrīd ir XP (extreme programming), Scrum un TDD (test driven development).

 agile-metodes

XP – extreme programming jeb ekstrēmā programmēšana.

XP ir viena no populārākajām un visvairāk izmantotajām Agile metodoloģijām. XP ir sakārtota izstrādes metode, kā rezultātā tiek izveidota augstas kvalitātes programmatūra īsā laikā, vairāk kārt atkārtojot šo procesu. XP pamatā ir nepārtraukta klientu iesaistīšana projekta veidošanā, atgriezeniskās saites iterācijas, nepārtraukta testēšana, nepārtraukta plānošana un cieša sadarbība strādājot komandā, lai varētu izveidot strādājošu programmatūru īsos laika intervālos (parasti 1 – 3 nedēļas). XP pamatā ir 4 īpašības – vienkāršums, komunikācija, atgriezeniskā saite un drosme. Extreme programming pamatā klientam ir cieši jāsadarbojas ar izstrādes komandu, lai definētu, mainītu un noteiktu prioritātes programmatūras funkcionalitātei izmantojot lietotāju stāstus. Izstrādes komandai jānodefinē izstrādes plāns, kas nodrošina galveno funkciju izveidi, kā rezultātā iespējams ātrāk nonākt pie strādājošas un pilnībā notestētas programmatūras katras izstrādes iterācijas galā. Vairāku šādu iterāciju rezultātā tiek izstrādāta pabeigta programmatūra pēc klienta prasībām.

 

TDD – test driven development jeb testu vadīta izstrāde

TDD ir programmatūras izstrādes metode, kas paredz ka vienību testēšana tiek pielietota pirmkoda testēšanai. TDD koncepts ir izveidot strādājošu programmatūru pēc iespējas ātrāk, un to pieslīpēt līdz detaļām pēc laika. Pēc katra testa tiek veikta refaktorēšana, un atkārtoti tiek pielietoti tie paši vai līdzīgi testi. Šis process tiek atkārtots tik ilgi, kamēr katra programmatūras vienība funkcionē precīzi kā tas ir noteikts definētajās prasībās. TDD bieži tiek pielietots tieši XP programmu izstrādes laikā. Ar testu vadītu izstrādi ir iespējams izveidot augstas kvalitātes programmatūru īsākā laika periodā. Lai programmētāji un testētāji varētu strādāt pēc TDD metodes, viņiem ir nepieciešams pilnībā izprast, kā programmatūra strādās un tiks izmantota reālā darbā. TDD paredz, ka testēts tiek gan katrs programmatūras modulis, gan visa pilnā programma ar visiem izstrādātajiem moduļiem kopā. Pateicoties katras programmatūras daļas testēšanai jau no porgammatūras izstrādes sākuma, vēlākās izstrādes stadijās tiek ietaupīti naudas un laika resursi programmatūras kļūdu noteikšanai un to novēršanai.

 

Scrum

Scrum ir viens no Agile projektu pārvaldības ietvariem ar plašu pielietojamību dažādu veidu iteratīvu projektu pārvaldībai un kontrolei. Savu popularitāte Scrum ir ieguvis pateicoties tā vienkāršumam, produktivitātei un spējai strādāt kā ietvaram dažādām Agile programmatūras inženierijas praksēm un metodēm, kas tiek izmantotas projektu izstrādē. Scrum ir atpazīstams ar to, ka projekta izstrādes laikā klients var mainīt savas domas, kādai jāizskatās noteiktai sistēmas daļai, vai gala programmatūrai, un izstrādes komandai ir jāreaģē uz šīm prasību izmaiņām un attiecīgi jāizstrādā sistēmas produkts. Tāpat kā citās Agile metodēs, arī Scrum klients cieši sadarbojas ar projekta izstrādes komandu, lai noskaidrotu visas sistēmas funkcijas un sakārtotu tās atkarībā no prioritātes un izvieto tās pie produkta prasībām (Product Backlog).  Produkta prasības sastāv no produkta funkcijām, kļūdu labojumiem, dažādām nefunkcionālajām prasībām un citām svarīgāk lietām, kuras nepieciešams ievērot un īstenot, lai veiksmīgi izveidotu strādājošu programmatūras sistēmu. Pēc klienta prasību un prioritāšu noteikšanas, izstrādes komanda sāk programmatūras daļu izstrādi izmantojot vairākus sprintus. Sprints parasti norit 30 dienas. Kad visi klienta noteiktie uzdevumi no produkta prasībām izpildīti sprinta laikā, nekāda papildus funkcionalitāte vairs netiek pievienota sprintam, izņemot, ja to pievieno kāds no izstrādes komandas. Kad sprints tiek pabeigts, produkta prasības tiek analizēts un noteiktas nākamās prioritātes uzdevumiem un funkcionalitātei, ko būs nepieciešams izstrādāt nākamā sprinta laikā.