Kujutise allikas: pixabay.com

Äärmuslik programmeerimine

Kujutage ette: uue toote tarkvaraarendusprojekt, mis põhineb esmakordse turuletoomise eelistel, on just teie ettevõtte radarile ilmunud. Äärmusliku programmeerimise traditsioonilised meetodid, kus klient teab „täpselt”, mida nad tahavad, on väljas. Teie meeskond on väike ja koosneb noortest spetsialistidest, kes reageerivad tõenäoliselt hästi radikaalsele projektijuhtimismudelile. Millised on teie võimalused?

Tõenäoliselt ütlete muidugi Agiilne projektijuhtimine! Kuid millist metoodikat soovite kasutada? Võimalusi on mitu: ühe jaoks on tohutult populaarne Scrum: see hõlmab lühikeste „sprintide“ loomist, mis põhineb kliendi ülesannete mahajäämusel. Ja siis on veel Kanban, mis töötab optimeerides tööd. Samuti on olemas Extreme Programming, sageli lühendatud XP-ks, mis keskendub traditsiooniliste programmeerimismudelite positiivsete aspektide võimendamisele, et need töötaksid oma maksimaalse potentsiaalini.

Äärmuslik programmeerimine on väga populaarne (ehkki mitte nii populaarne kui Scrum) metoodika, mis on keskendunud muutuvate klientide nõudmistele. Esimest äärmuslikku programmeerimisprojekti alustas Kent Beck Chrysleri juures 1996. aasta märtsis. Oma 1999. aasta raamatus Extreme Programming Explained: Embrace Change kirjeldas ta tarkvara arendamise aspekte.

Kent Beck oli ka testipõhise arenduse pioneer, mis pani radarile juhtumitestimise kui paranduse sellesse, kuidas toona asju tehti: ridade ja koodiridade kirjutamist ning seejärel testimist. Ta oli ka üks Agile Manifesti allkirjastajaid, aidates manifesti kujundamisel muuta äärmusliku programmeerimistarkvara kirjutamisviisi.

Äärmusliku programmeerimise viis väärtust, mis põhineb seletataval on:

Suhtlus

Äärmuslik programmeerimine ei sõltu ulatuslikust dokumentatsioonist. Tegelikult soovitatakse äärmist programmeerimisdokumentatsiooni ainult vajaduse korral. Seega tugineb metoodika suuresti suhtlemisele meeskonnaliikmete vahel ja ka kasutajatega.

Lihtsus

See on Extreme Programmingu keskmes. Metoodika soosib lihtsaid kujundusi, mitte ei mõtle liiga kaugele tulevikku, vaid keskendub tänapäeva nõuetele, muutes programmi ise piisavalt jõuliseks, et lisada tuleviku esitatavad nõuded.

Tagasiside

See oluline edasi-tagasi liikumine eristab agiilsesid süsteeme üldiselt ja eriti ekstreemset programmeerimist muudest tarkvaraprojektihaldusmetoodikatest. Pidev tagasiside võib toimida erineval viisil, kuid need kõik töötavad selle nimel, et muuta süsteem tugevamaks ja usaldusväärsemaks.

Tagasiside võib olla erineva maitsega:

  • Programmist endast: Koodi testitakse kogu projekti arendustsükli jooksul jõuliselt, et arendajad saaksid muudatusi rakendada.
  • Kliendilt: see on enamiku Agile süsteemide oluline osa. Kliendid kirjutavad aktsepteerimistestid, millel arendus põhineb, ja see moodustab arendusprotsessi selgroo. Kõik iteratsioonid edastatakse kliendile ka perioodilise tagasiside saamiseks.
  • Meeskonnalt: kui uus kasutusjuhtum / lugu on loodud, naaseb meeskond viivitamatult kulude ja ajakava prognoosimisega, tugevdades nõudeid nende tekkimisel. Äärprogrammeerimisel ei oma "keegi" ühtegi koodi ja seetõttu soovitatakse äärmuslikes programmeerimismeeskondades tagasisidet üksteise koodi kohta.

Julgus

See võib tunduda kummaline väärtus tarkvaraarenduse ekstreemses programmeerimises, sobides rohkem armee või merejalaväelaste moodi! Mõelge siiski sellele: tarkvaraprojekte on juba pikka aega häirinud traditsioonilised juhtimise äärmuslikud programmeerimismeetodid; turvaline mugava dokumenteerimise ja hierarhia korral, mis ei võimalda uuendusi. See väärtus on näide ekstreemse programmeerimise tuumast: olge valmis hüppama, ilma et oleks vaja langevarju! Vaadake seda erinevat projektijuhtimisstiili ja olge valmis vastutama, loobuma hierarhiast ning vastutustundlik ja töötama, ilma et oleksite ise kõike alguses teadnud.

Austa

Austus, viies väärtus, lisati hiljem ja see tähendab austust teiste ja iseenda vastu. See tähendab ka austust kirjutatava koodi ning kliendi ootuste ja vajaduste vastu. See väärtus on aluseks ka erinevate sidusrühmade vahelisele suhtlusele.

Äärmiselt programmeerimisprojekti tegevused

Äärmuslik programmeerimine eristab projekti nelja lihtsat tegevust. Nemad on:

  • Kodeerimine : äärmuslik programmeerimine peab seda kõige olulisemaks tegevuseks. "Ilma koodita pole midagi, " ütleb Extreme Programmingu asutaja Kent Beck.
  • Testimine : kood on just see, kui seda ei testita. Äärmuslik programmeerimine suhtub testimisse obsessiivselt, kasutades üksuseteste, et kinnitada, et kood töötab, ja kliendi loodud aktsepteerimisteste, mis kinnitavad, et kood testib seda, mida tuleb testida.
  • Kuulamine: Kuulamine, näiteks suhtluse põhiväärtus, on tegevus, mis nõuab, et arendajad mitte ainult ei kuuleks kliente, vaid kuulaksid ka tegelikult seda, mida nad tahavad. Arendamine ja ettevõtlus on kaks erinevat asja ja sageli ei suuda arendajad aru saada konkreetse otsuse ärilistest juhtumitest. Kuulamise tegevuse aluseks on nii kliendi kui ka arendaja vajadused.
  • Kujundamine : see võib teid üllatada, et tarkvaraarendusprojektis pannakse sageli nii oluline ja esmane kavandamise tegevus lõppu. Selle põhjuseks on asjaolu, et ekstreemne programmeerimine soovib teadlikult juhtida inimesi eemale "kujunda ja arenda" mõtteviisist, mida tööstus on aastaid toetanud. Projekteerimise tähtsust ei tohi piirata. Pigem on hea ja minimaalne disain projekti üks tunnusjooni.

Väärtustest ja tegevustest lähtuvad ekstreemse programmeerimise 12 põhimõtet, mille on välja töötanud selle asutaja, oma raamatus Extreme Programming Explained.

  • Plaanimäng
  • Paari programmeerimine
  • Testipõhine areng
  • Terve meeskond
  • Pidev integratsioon
  • Kujunduse täiustamine
  • Väikesed väljaanded
  • Kodeerimisstandardid
  • Kollektiivse koodi omandiõigus
  • Lihtne disain
  • Süsteemi metafoor
  • Jätkusuutlik tempo

Mõned neist äärmuslikest programmeerimistavadest, mis kõik on seotud tarkvaratehnika parimate tavadega, erinevad üldistest Agile metoodikatest. Allpool selgitatakse mõnda äärmise programmeerimise tava:

  1. Plaanimäng

See on projekti planeerimise osa, millele viidatakse kui “Planeerimise mängule”. See hõlmab järgmise iteratsiooni ja vabastamise kavandamist, konsulteerides kasutaja / kliendiga, samuti meeskondade sisemist kavandamist nende tööülesannete jaoks, millega nad töötavad.

  1. Paari programmeerimine

See hõlmab kahte inimest, kes töötavad mingi koodi kallal. Üks inimene, mida nimetatakse klaviatuuriks, tippib koodi, teine ​​aga monitori, jälgib koodi, kommenteerides ja täpsustades seda, kuna selleks võib tekkida vajadus. Need kaks inimest vahetavad sageli oma rolle. On tõestatud, et see parandab märkimisväärselt koodi tõhusust. See ei pruugi sobida kõigi arengustsenaariumitega ja seda tuleb enne Extreme Programmingule registreerumist kaaluda.

  1. Testipõhine areng

Kõik kirjutatud kood vaadatakse üle ühikute kaupa, st kõigepealt testitakse iga kooditükki, mis suudab midagi teha. Äärmuslik programmeerimine paneb palju rõhku testimisele. See aitab kinnitada, et kood töötab, ja seega saab seda kaaluda lisamiseks ekstreemse programmeerimise projekti ise. See on analoogne ühikatsetega koolis: testitakse väikseid andmeid, et õpetaja / õpilane saaks kursuse parandusi teha ja ei ujuks iga-aastaste eksamite ajal!

  1. Kujunduse täiustamine (reaktoriseerimine)

Oma lihtsuse omadusel põhinevate XP projektide eesmärk on kirjutatud koodi pidevat täiustamist. See tähendab, et kogu koodi (ja mõnikord ka andmebaasi) täiustatakse alati. Refaktorimine ei lisa funktsioone; see lihtsalt parandab olemasolevat koodi. Muudab selle rangemaks ja selgemaks. See sarnaneb kirjatüki redigeerimise, selle poleerimise ja paremaks muutmisega.

  1. Lihtne disain

Äärprogrammeerimisel ei lisata funktsioone enne, kui see on spetsiaalselt nõutud. Isegi kui kood, mille kallal praegu töötatakse, on väga sarnane sellega, mida tulevikus võib vaja minna, võetakse see kasutusele alles siis, kui see on kokku lepitud kui kasutajalugu.

  1. Süsteemi metafoor

See hõlmab kõigi nimetamistavade standardimist nii, et nende eesmärk ja funktsioon on hõlpsasti dešifreeritavad. Näiteks võivad või toimingud aidata programmeerijatel nende funktsionaalsust mõista. Seda tuleks teha kogu ekstreemse programmeerimisprojekti vältel, nii et kõigil oleks lihtne koodi vaadata ja seda vastavalt vajadusele muuta või paremaks muuta.

Rollid ekstreemse programmeerimisprojekti raames:

Nagu Scrumil, on ka ekstreemsel programmeerimisel igas projektis mõned määratud rollid. Nüüd ei pea rolle alati täitma erinevad inimesed ja inimene võib võtta mitu rolli.

Äärmise programmeerimise rollid on:

  • Klient : iseenesest mõistetav. Projekti põhjus. Ta otsustab, mida projekt tegema peab. Ta pakub kasutaja lugusid.
  • Programmeerija : See on inimene, kes:
    • Teeb lugusid, millega klient välja tuleb
    • Loob lugudest välja programmeerimisülesanded
    • Rakendab kasutaja lugusid
    • Testib koodi ühiku kaupa
  • Treener : Treener tagab üldiselt, et projekt on õigel teel, ja hüppab vajadusel ka appi.
  • Jälgija : jälgija teeb programmeerijatele kindlaksmääratud intervalliga konkreetseid järelepärimisi. Tavaliselt kontrollib ta programmeerijate edusamme, pakkudes vajadusel abi mitmel viisil: varrukate üleskeeramisel ja koodiga otse abistamisel, treenerile teada andmisel või vastavalt vajadusele kliendiga kohtumise seadmisel.
  • Tester : töötab toimimisteste. Tester ei tee ühikatseid, mida juhivad programmeerijad ise.
  • Doomsayer: Nagu nimest järeldada võib, sarnaneb see musta mütsiga Edward De Bono grupimõtlemise süsteemis. Igaüks võiks olla näitleja, kes tavaliselt märgib potentsiaalsed probleemid ja aitab hoida probleeme õiges perspektiivis.
  • Juhataja : Äärmusliku programmeerimise projekti juht sarnaneb pigem planeerijaga, tagades, et koosolekud toimuvad plaanipäraselt, ja tagades, et koosolekute ajal vastu võetud otsused antakse edasi vastavale isikule, enamasti jälitajale. Juhataja ei ütle inimestele siiski, mida ja millal teha. Seda teevad klient ja / või kasutajalood ise.
  • Kulla omanik : kulla omanik on isik, kes projekti rahastab. See võib olla klient, kuid mitte tingimata.

Mõningaid ülalkirjeldatud äärmuslikke programmeerimisrolle saab kombineerida, kuid mõnda selgelt mitte.

Näiteks klient ei saa olla ka programmeerija. Programmeerija ja jälgija ei saa sarnaselt edukalt olla üks ja sama isik.

Äärmised programmeerimisrollid on piisavalt selgelt määratletud, nii et ei tekiks segadust, ning need on loodud maksimaalse paindlikkuse ja tõhususe saavutamiseks.

Äärmusliku programmeerimise puudused:

Ehkki Extreme Programmingu pooldajad maalivad roosilist pilti, on tõsiasi, et Extreme Programmingut, nagu nimigi arvata võib, on äärmiselt keeruline rakendada. Äärmusliku programmeerimise tahke saab projektidesse integreerida edukamalt kui XP täielik kasutuselevõtt.

Mõned ekstreemse programmeerimise negatiivid on:

  • Äärmuslik programmeerimine on osutunud tõhusamaks väiksemates rühmades . Selle tõhusus suuremates gruppides on vaieldav ja parem võimalus on jagada äärmuslikud programmeerimismeeskonnad nii, et rühmad oleksid väiksemad.
  • Äärmusliku programmeerimise üks põhifunktsioone, paariprogrammeerimine ei tööta paljudel juhtudel hästi . Kompleksne kodeerimine võib nõuda kahte pead, kuid mitte kõik ülesanded ei vaja kahte inimest, teine ​​inimene on tühimass. Tegelikult on paariprogrammeerimine, kui üks liikmetest pole teisega sünkroonis, üks peamisi põhjuseid, miks äärmuslik programmeerimine paljudel juhtudel ebaõnnestub.
  • Sõltuvus kliendist kuni selleni, et kliendi poolelt soovitatakse kohapealset ressurssi, võib olla sügavalt häiriv. Samuti võib see arengu käigus kaasa tuua nii reaalseid kui ka kujutletud häireid.
  • Äärmiselt programmeerimise keskendumine lihtsusele võib muuta praeguse projekti lisamise väga keeruliseks, mis tähendab suuremat eelarvet isegi lihtsate muudatuste jaoks, mis ei jää enam lihtsateks.
  • Tasane hierarhiline ülesehitus tähendab, et meeskond peaks alati olema keskendunud ja juhi puudumisel erinevat tüüpi inimesteni, sõltub äärmusliku programmeerimise meeskond täielikult kõigi meeskonnaliikmete emotsionaalsest küpsusest - tegurist, mis pole alati töökindel .

Isegi nende tegurite korral jääb ekstreemne programmeerimine võimsaks tööriistaks, mida saab kasutada õige projekti jaoks, kusjuures ettevõtted teatavad pärast ekstreemse programmeerimisprotsessi kasutuselevõttu nende efektiivsuse mitmekordsest suurenemisest. Arendaja juhitud süsteem, mitte Scrum, mis on rohkem protsessikeskne süsteem, Extreme Programming või vähemalt selle osad, võib viia revolutsioonini ekstreemse programmeerimistarkvara arendamisel.

Kategooria:

Ettevõtluse arendamine