Sursa imaginii: pixabay.com

Programare extremă

Imaginează-ți acest lucru: un proiect de dezvoltare software pentru un produs nou, bazat pe avantajul primului pe piață tocmai a fost identificat pe radarul companiei tale. Metodele tradiționale de programare extremă, în care clientul știe „exact” ceea ce își dorește, nu există. Echipa ta este mică și este alcătuită din tineri profesioniști, care este probabil să răspundă bine la un model radical de management de proiect. Care sunt opțiunile dvs.?

Probabil că veți spune, Agile Project Management, desigur! Dar ce metodologie ați dori să folosiți? Există mai multe opțiuni: pentru unul, există Scrum-ul extrem de popular: care implică crearea unor „sprinturi” scurte bazate pe lista de sarcini a clientului. Și apoi, există Kanban, care lucrează la optimizarea conductei de lucru. Există, de asemenea, programare extremă, adesea prescurtată la XP, care se concentrează pe amplificarea aspectelor pozitive ale modelelor tradiționale de programare, astfel încât acestea să funcționeze la potențialul lor maxim.

Programarea extremă este o metodologie extrem de populară (deși nu este la fel de populară ca Scrum) axată pe satisfacerea cerințelor clientului în schimbare. Primul proiect de programare extremă a fost început în martie 1996, de către Kent Beck la Chrysler. În cartea sa din 1999, Extreme Programming Explained: Embrace Change, el a detaliat aspectele pentru dezvoltarea de software.

Kent Beck a fost, de asemenea, pionierul dezvoltării bazate pe teste, care a pus testul cazurilor de utilizare pe radar ca o îmbunătățire a modului în care s-au făcut lucrurile atunci: scrierea liniilor și liniilor de cod și apoi testarea acestuia. El a fost, de asemenea, unul dintre semnatarii originali ai manifestului Agile, ajutând la modelarea manifestului pentru a schimba modul în care a fost scris software-ul de programare extrem.

Cele cinci valori ale programării extreme bazate pe Explicified sunt:

Comunicare

Programarea extremă nu depinde de documentații extinse. De fapt, documentația de programare extremă este sugerată numai atunci când este necesar. Deci, metodologia se bazează foarte mult pe comunicarea dintre membrii echipei și, de asemenea, cu utilizatorii.

Simplitate

Acest lucru este în centrul programării extreme. Metodologia favorizează design-urile simple, nu gândindu-se prea mult în viitor, ci concentrându-se pe cerințele de astăzi, făcând în același timp programul în sine suficient de robust pentru a adăuga cerințele pe care viitorul le ridică.

Părere

Această buclă esențială de a merge înainte și înapoi diferențiază sistemele Agile în general și programarea extremă, în special, de alte metodologii de gestionare a proiectelor software. Feedback-ul continuu poate funcționa în moduri diferite, dar toate lucrează pentru a face sistemul mai puternic și mai fiabil.

Feedback-ul poate avea diferite arome:

  • Din Programul în sine: Codul este testat energic pe parcursul întregului ciclu de dezvoltare a proiectului, astfel încât modificările pot fi implementate de dezvoltatori.
  • De la client: Aceasta este o parte esențială a majorității sistemelor Agile. Clienții scriu testele de acceptare pe care se bazează dezvoltarea și acest lucru constituie coloana vertebrală a procesului de dezvoltare. Toate iterațiile sunt livrate și clientului, pentru un feedback periodic.
  • Din partea echipei: odată ce un nou caz de utilizare / poveste a fost creat, echipa revine imediat cu calcularea costurilor și a cronologiei, confirmând cerințele pe măsură ce apar. În programarea extremă, nicio persoană nu „deține” niciun cod și, prin urmare, în cadrul echipelor de programare extreme, feedback-ul despre codul celuilalt este încurajat.

Curaj

Aceasta poate părea o valoare ciudată în programarea extremă pentru dezvoltarea de software, mai potrivită pentru ceva precum Armata sau pușcașii marini! Cu toate acestea, gândiți-vă la asta: proiectele software sunt de mult timp împiedicate de metodele tradiționale de gestionare a programării extreme; asigurați-vă confortul unei documentații extinse și a unei ierarhii care nu permite inovația. Această valoare exemplifică nucleul programării extreme: fiți gata să sari, fără o parașută dacă vine vorba de asta! Privește acest stil diferit de management al proiectului și fii gata să fii responsabil, să renunți la ierarhie și să fii responsabil și să lucrezi fără să știi totul la început.

Respect

Respectul, a cincea valoare, a fost adăugat mai târziu și înseamnă respect față de ceilalți și de sine. De asemenea, implică respectarea codului scris și pentru așteptările și nevoile clientului. Această valoare stă la baza comunicării între diferite părți interesate.

Activități ale unui proiect de programare extremă

Programarea extremă distinge patru activități simple ale unui proiect. Sunt:

  • Codare : Programarea extremă consideră că aceasta este cea mai importantă activitate. „Fără cod, nu există nimic”, spune Kent Beck, fondatorul Extreme Programming.
  • Testare : Codul este doar dacă nu este testat. Programarea extremă este obsesivă în ceea ce privește testarea, folosind testele unității pentru a confirma că codul funcționează și testele de acceptare generate de client pentru a confirma că codul testează ceea ce trebuie testat.
  • Ascultarea: Ascultarea, exemplificată prin valoarea de bază a comunicării, este o activitate care solicită dezvoltatorilor să nu audă doar clienții, ci să asculte cu adevărat ceea ce doresc. Dezvoltarea și afacerea sunt două lucruri diferite și, deseori, dezvoltatorii nu înțeleg cazul de afaceri al unei anumite decizii. Nevoile clientului, precum și dezvoltatorii, stau la baza activității de „ascultare”.
  • Proiectare : S-ar putea să vă surprindă că într-un proiect de dezvoltare software, activitatea de proiectare, adesea atât de importantă și primară, este plasată la sfârșit. Acest lucru se datorează faptului că programarea extremă dorește în mod intenționat să îi scoată pe oameni din mentalitatea „proiectării și dezvoltării” pe care industria a hrănit-o de mulți ani. Nu este de a limita importanța proiectării. Mai degrabă, un design bun și minim este unul dintre caracteristicile caracteristice ale unui proiect.

Din valori și activități apar cele 12 principii ale programării extreme, așa cum au fost concepute de fondatorul său, în cartea sa, Programare extremă explicată.

  • Planificarea jocului
  • Programare pereche
  • Dezvoltarea condusă de test
  • Intreaga echipa
  • Integrare continuă
  • Îmbunătățirea proiectării
  • Comunicări mici
  • Standarde de codificare
  • Proprietate de cod colectiv
  • Design simplu
  • Metafora sistemului
  • Pace durabil

Unele dintre aceste practici de programare extreme, toate mapate la cele mai bune practici de inginerie software, sunt diferite de metodologiile generice Agile. Unele dintre practicile programării extreme sunt explicate mai jos:

  1. Planificarea jocului

Aceasta este partea de planificare a proiectului, denumită „Joc de planificare”. Acesta include planificarea următoarei iterații și eliberare, în consultare cu utilizatorul / clientul, precum și o planificare internă a echipelor, în ceea ce privește sarcinile cu care vor lucra.

  1. Programare pereche

Aceasta implică două persoane care lucrează la o bucată de cod. O persoană, numită tastatură, introduce codul în timp ce cealaltă, numită monitor, supraveghează codul, comentându-l și rafinându-l, deoarece poate apărea nevoia. Cei doi oameni își schimbă deseori rolurile. Acest lucru a fost dovedit că îmbunătățește semnificativ eficiența codului. Este posibil să nu se potrivească tuturor scenariilor de dezvoltare, iar acest lucru este de luat în considerare înainte de a vă înscrie la Extreme Programming.

  1. Dezvoltare bazată pe teste

Toate codurile scrise sunt revizuite în mod unitar, adică fiecare cod care poate face ceva este testat mai întâi. Programarea extremă pune mult accent pe testare. Acest lucru ajută la confirmarea faptului că codul funcționează, astfel încât acesta poate fi considerat ca fiind inclus în proiectul de programare extremă. Este analog cu testele unitare în școală: informații testate mici, astfel încât profesorul / studentul să poată face corecții ale cursului și să nu se încurce în timpul examenelor anuale!

  1. Îmbunătățirea proiectării (refactorizare)

Proiectele XP, bazate pe caracteristica sa de simplitate, își propun să îmbunătățească continuu codul scris. Aceasta înseamnă că întregul cod (și uneori, și baza de date) este întotdeauna îmbunătățit. Refactorizarea nu adaugă nicio funcționalitate; doar îmbunătățește codul existent. O face mai strânsă și mai clară. Este asemănător cu editarea unei piese de scris, lustruirea și îmbunătățirea acesteia.

  1. Design simplu

În programarea extremă, funcțiile nu sunt adăugate decât sunt necesare în mod special. Chiar dacă codul lucrat în prezent este foarte similar cu ceea ce ar putea fi necesar în viitor, acesta nu este preluat decât dacă este convenit ca o poveste de utilizator.

  1. Metafora sistemului

Aceasta include standardizarea tuturor convențiilor de denumire, astfel încât scopul și funcția sa să fie ușor descifrate. De exemplu, sau operațiunile pot ajuta orice programator să-și înțeleagă funcționalitatea. Aceasta ar trebui realizată pe întregul proiect de programare extremă, astfel încât oricine să fie ușor să privească codul și să-l modifice sau să-l îmbunătățească, după caz.

Roluri în cadrul unui proiect de programare extremă:

La fel ca Scrum, Programarea extremă are câteva roluri desemnate în cadrul fiecărui proiect. Acum, rolurile nu trebuie să fie întotdeauna îndeplinite de persoane distincte, iar o persoană poate ocupa mai mult de un rol.

Rolurile de programare extremă sunt:

  • Client : autoexplicativ. Motivul proiectului. Ea decide ce proiect trebuie să facă. Ea oferă poveștile utilizatorilor.
  • Programator : Aceasta este persoana care:
    • Preia poveștile cu care vine clientul
    • Creează sarcini de programare din povești
    • Implementează poveștile utilizatorilor
    • Testează codul pe unitate
  • Antrenor : În general, antrenorul se asigură că proiectul este pe cale și, de asemenea, sare în ajutor pentru a fi necesar atunci când este necesar.
  • Tracker : Trackerul face anchete specifice programatorilor la un interval stabilit. În mod obișnuit, el verifică evoluția programatorilor, oferind ajutor acolo unde este necesar în mai multe moduri: rularea mânecilor și ajutarea directă a codului, comunicarea antrenorului sau stabilirea unei întâlniri cu clientul, după caz.
  • Tester : execută teste funcționale. Testatorul nu execută teste unitare, care sunt conduse chiar de programatori.
  • Doomsayer: Acest lucru, după cum sugerează și numele, este asemănător cu Pălăria Neagră în sistemul de gândire de grup al lui Edward De Bono. Oricine ar putea fi un Doomsayer, care indică de obicei problemele potențiale și ajută la păstrarea problemelor în perspectiva corectă.
  • Manager : Managerul într-un proiect de programare extremă este mai mult ca un planificator, asigurându-se că întâlnirile au loc așa cum a fost planificat și asigurând că deciziile luate în timpul ședințelor sunt transmise persoanei corespunzătoare, mai des decât următorul. Managerul, însă, nu le spune oamenilor ce trebuie să facă și când să o facă. Acest lucru este realizat chiar de Client și / sau de Poveștile utilizatorului.
  • Proprietar de aur : Gold Owner este persoana care finanțează proiectul. Acesta ar putea fi clientul, dar nu neapărat așa.

Unele dintre rolurile de programare extreme, așa cum este descris mai sus, pot fi combinate, dar unele în mod clar nu pot.

De exemplu, clientul nu poate fi programator. În mod similar, Programatorul și Tracker-ul nu pot fi cu succes aceeași persoană.

Rolurile extreme de programare sunt definite suficient de clar, astfel încât să nu existe confuzii și sunt create pentru o flexibilitate și eficiență maximă.

Dezavantajele programării extreme:

În timp ce susținătorii programării extreme pictează o imagine roz, faptul este că programarea extremă, așa cum sugerează probabil numele, este extrem de dificil de implementat. Fațetele programării extreme pot fi încorporate în proiecte cu mai mult succes decât adoptarea completă a XP.

Unele dintre aspectele negative ale programării extreme sunt:

  • Programarea extremă se dovedește a fi mai eficientă în grupuri mai mici . Eficiența sa în grupuri mai mari este contestată, iar o opțiune mai bună este divizarea echipelor de programare extreme, astfel încât grupurile să fie mai mici.
  • Una dintre caracteristicile cheie ale programării extreme, programarea în perechi nu funcționează bine în multe cazuri . Codificarea complexă poate necesita două capete, dar nu toate sarcinile pot necesita două persoane, a doua persoană fiind o greutate moartă. De fapt, programarea perechilor, dacă unul dintre membri nu este în sincronizare cu celălalt, este unul dintre principalele motive pentru care programarea extremă eșuează în multe cazuri.
  • Dependența de client, până la punctul de a sugera o resursă la fața locului din partea clientului, poate fi profund neobservantă. De asemenea, poate duce la interferențe, atât reale cât și imaginate, în timpul dezvoltării.
  • Programarea extremă asupra simplității poate face foarte dificilă adăugarea la proiectul actual, ceea ce înseamnă un buget mai mare pentru modificări chiar simple, care nu mai rămân simple.
  • Structura ierarhică plană înseamnă că echipa ar trebui să fie întotdeauna concentrată, iar în absența unui manager către tipurile de persoane divergente corrale, o echipă de programare extremă depinde în întregime de maturitatea emoțională a tuturor membrilor echipei, un factor care nu este întotdeauna de încredere. .

Chiar și cu acești factori, programarea extremă rămâne un instrument puternic care trebuie utilizat pentru proiectul potrivit, companiile raportând o creștere multiplă a eficienței lor după adoptarea procesului de programare extremă. Un sistem bazat pe dezvoltator, spre deosebire de Scrum, care este mai mult un sistem bazat pe proces, Extreme Programming, sau cel puțin părți din acesta, poate duce la o revoluție în modul în care dezvoltăm software de programare extremă.

Categorie:

Dezvoltarea antreprenorială