Programarea Extremă (XP) este o metodă agilă de dezvoltare software. Ca și alte metodologii agile, XP are unelte, procese și roluri unice. Creatorul XP, dezvoltatorul american Kent Beck, nu a inventat nimic complet nou, ci a luat cele mai bune practici ale dezvoltării agile și le‑a amplificat la extreme, de aici și numele Programarea Extremă.
Autorul metodologiei, Kent Beck, a condus proiectul Chrysler Comprehensive Compensation System la sfârșitul anilor ’90, unde a aplicat pentru prima dată practicile XP. A documentat experiența sa și conceptul creat în cartea „Programarea Extremă Explicată”, publicată în 1999. Această carte a fost urmată de altele care detaliază practicile XP. Contribuitorii la dezvoltarea metodologiei includ pe Ward Cunningham, Martin Fowler și alții.
Spre deosebire de alte metodologii agile, XP este exclusiv folosit în dezvoltarea software-ului. Nu poate fi aplicat în alte afaceri sau în viața de zi cu zi, cum ar fi Scrum, Kanban sau Lean.
Scopul XP este de a face față cerințelor constant schimbătoare pentru produsul software și de a îmbunătăți calitatea dezvoltării. Prin urmare, XP este potrivit pentru proiecte complexe și incerte.
XP se învârte în jurul a patru activități esențiale: codare, testare, proiectare și ascultare. În plus, Programarea Extremă are valori fundamentale: simplitate, comunicare, feedback, curaj și respect.
13 Practici ale Programării Extreme
1. Echipa întreagă
Toți participanții la proiect care folosesc XP lucrează ca o echipă unică. Această echipă trebuie să includă un reprezentant al clientului, de preferat un utilizator final real, familiarizat cu afacerea. Clientul stabilește cerințele produsului și prioritizează funcționalitatea. Analiștii de afaceri pot asista clientul. Din partea executanților, echipa include dezvoltatori, testeri, uneori un antrenor care îndrumă echipa și un manager care furnizează resurse.
2. Joc de planificare
Planificarea în XP are loc în două etape: planificarea lansării și planificarea iterației.
- Planificarea lansării: Echipa de programare se întâlnește cu clientul pentru a determina funcționalitatea dorită pentru următoarea lansare, de obicei în 2 – 6 luni. Deoarece cerințele clientului sunt adesea vagi, dezvoltatorii le clarifică și le descompun în sarcini care pot fi finalizate într‑o zi sau mai puțin. Clientul trebuie să înțeleagă mediu operațional în care produsul va funcționa.
Sarcinile sunt înregistrate pe carduri, iar clientul le prioritizează. Dezvoltatorii estimează apoi timpul necesar pentru fiecare sarcină. Odată ce sarcinile sunt descrise și estimate, clientul revizuiește documentația și aprobă începutul lucrărilor. Pentru succesul proiectului, este critic ca clientul și echipa de programare să joace pe același teren: clientul alege funcționalitatea cu adevărat necesară în cadrul bugetului, iar programatorii aliniază în mod corespunzător cerințele clientului cu capacitățile lor. - Planificarea iterației: Se desfășoară la fiecare două săptămâni, uneori mai frecvent sau mai rar. Clientul este prezent pentru a defini funcționalitatea pentru următoarea iterație și a face modificări în cerințele produsului.
3. Lansări mici
Lansările XP sunt frecvente, dar cu funcționalitate limitată. Această abordare face mai ușor testarea și menținerea operabilității sistemului și furnizează clientului funcționalitate cu valoare de afaceri la fiecare iterație.
4. Teste ale clientului
Clientul specifică teste automate de acceptare pentru a verifica funcționalitatea produsului. Echipa scrie aceste teste și le folosește pentru a testa codul.
5. Proprietate colectivă a codului
În XP, orice dezvoltator poate modifica orice parte a codului, deoarece codul nu aparține autorului său, ci întregii echipe.
6. Integrare continuă
Părțile noi ale codului sunt integrate în sistem imediat — echipele XP lansează o nouă versiune la fiecare câteva ore sau mai frecvent. Această practică asigură că impactul modificărilor recente asupra sistemului este vizibil imediat. Dacă o nouă bucată de cod strică ceva, identificarea și corectarea erorii este mult mai ușoară.
7. Standarde de codare
Cu proprietatea colectivă a codului, adoptarea unor standarde comune de codare este crucială pentru a face codul să pară că a fost scris de un singur profesionist. Echipele pot dezvolta standardele lor sau pot adopta altele existente.
8. Metafora sistemului
Metafora sistemului este o comparație cu ceva familiar pentru a crea o viziune comună în cadrul echipei. De obicei, persoana care dezvoltă arhitectura și vede sistemul în ansamblu concepe metafora.
9. Ritm sustenabil
Echipele XP lucrează la productivitate maximă menținând un ritm sustenabil. Programarea Extremă descurajează munca suplimentară și promovează o săptămână de lucru de 40 de ore.
10. Dezvoltare condusă de teste (TDD)
Una dintre cele mai provocatoare practici în XP. Programatorii scriu teste înainte de a scrie codul care urmează să fie testat. Această abordare asigură că fiecare bucată de funcționalitate este complet acoperită de teste. Când dezvoltatorii se angajează cu codul, testele unității sunt rulate imediat, iar toate testele trebuie să treacă, asigurându-se că echipa se îndreaptă în direcția corectă.
11. Programare în pereche
Imaginează-ți doi dezvoltatori lucrând la un singur computer pe o singură bucată de funcționalitate. Această practică este programarea în pereche, cea mai controversată practică în XP. Zicala „două capete sunt mai bune decât unul” ilustrează bine esența ei. Din două soluții pentru o problemă, cea mai bună este aleasă, codul este optimizat imediat, iar erorile sunt depistate înainte de a apărea, rezultând un cod curat înțeles de amândoi dezvoltatorii.
12. Design simplu
Designul simplu în XP înseamnă a face doar ceea ce este necesar acum, fără a încerca să prezici funcționalitatea viitoare. Designul simplu și refactorizarea continuă creează un efect sinergic — când codul este simplu, este mai ușor de optimizat.
13. Refactorizare
Refactorizarea este procesul continuu de îmbunătățire a designului sistemului pentru a îndeplini cerințele noi. Include eliminarea duplicatelor de cod, creșterea coeziunii și reducerea cuplajului. XP impune refactorizarea constantă, astfel încât designul codului să rămână întotdeauna simplu.
Avantajele și dezavantajele XP
XP este controversat și adesea criticat de cei care nu au reușit să‑l implementeze. Cu toate acestea, beneficiile sale sunt evidente atunci când echipa utilizează pe deplin cel puțin o practică XP.
Beneficiile efortului de a urma XP includ:
- Satisfacția clientului: Clienții primesc produsul de care au nevoie, chiar dacă nu au inițial o viziune clară.
- Flexibilitate: Echipa face rapid modificări de cod și adaugă noi funcționalități datorită designului simplu al codului, planificării frecvente și lansărilor.
- Fiabilitate: Codul funcționează întotdeauna datorită testării constante și integrării continue.
- Menținere: Echipa pune cu ușurință în aplicare codul deoarece este scris conform unui standard unic și este constant refactorizat.
- Productivitate: Ritmul rapid de dezvoltare datorită programării în pereche, fără muncă suplimentară și implicarea clientului.
- Cod de înaltă calitate
- Reducerea riscurilor: Riscurile de dezvoltare sunt reduse, deoarece responsabilitatea este distribuită în mod uniform, iar proiectul nu este pus în pericol de plecarea sau sosirea membrilor echipei.
- Eficiența costurilor: Costurile de dezvoltare sunt mai mici, deoarece echipa se concentrează pe cod, mai degrabă decât pe documentație și întâlniri.
În ciuda avantajelor sale, XP nu funcționează întotdeauna și are mai multe slăbiciuni:
- Implicarea clientului: Succesul depinde de implicarea clientului, care poate fi dificil de realizat.
- Termene imprevizibile: Este dificil să prezici costurile de timp ale proiectului deoarece lista completă de cerințe este necunoscută la început.
- Dependență de nivelul de competență: XP depinde mult de nivelul de competență al programatorilor și funcționează cel mai bine cu profesioniști seniori.
- Rezistența managementului: Managementul se opune adesea programării în pereche, punând la îndoială necesitatea de a plăti doi programatori în loc de unul.
- Cost: Întâlnirile frecvente cu programatorii pot fi costisitoare pentru clienți.
- Schimbări culturale: Implementarea XP necesită schimbări culturale semnificative.
- Lipsa de structură: Lipsa de structură și documentație a XP îl face nepotrivit pentru proiecte mari.
- Cerințe non-funcționale: Cerințele funcționale sunt dificile de descris ca povești de utilizator în metodologiile agile.
Principiile XP
În prima sa carte, Kent Beck a conturat următoarele principii ale XP: simplitate, comunicare, feedback și curaj. Într‑o ediție ulterioară, a adăugat un al cincilea principiu — respect.1. Simplitate
Dezvoltarea XP începe cu cea mai simplă soluție care satisface nevoia funcțională actuală. Membrii echipei iau în considerare doar ceea ce trebuie să facă acum și nu încorporează funcționalități care s‑ar putea dovedi necesare în viitor.
2. Comunicare
Comunicarea în XP se desfășoară în mod direct, nu prin documentație. Echipa comunică activ unii cu ceilalți și cu clientul.
3. Feedback
Feedbackul în XP este implementat în trei moduri:
- Feedback de sistem: Prin testarea constantă a modulelor.
- Feedback al clientului: Clientul este parte a echipei și participă la redactarea testelor de acceptare.
- Feedback al echipei: În timpul planificării, privind estimările timpului de dezvoltare.
4. Curaj
Unele practici XP sunt atât de neobișnuite încât necesită curaj și auto-control constant.5. Respect
Respectul în XP înseamnă respectarea echipei și respect de sine. Membrii echipei nu ar trebui să facă modificări care să rupă compilarea, testele modulelor sau să încetinească lucrul colegilor. Fiecare membru își propune cea mai înaltă calitate a codului și designului.
Implementarea XP și fluxul de lucru
Kent Beck recomandă implementarea XP pentru a rezolva problemele din proiect. Echipa selectează cea mai urgentă problemă și o rezolvă folosind una dintre practicile XP. Apoi, trec la următoarea problemă, folosind o altă practică. Această abordare asigură că problemele motivează adoptarea XP, iar echipa învață treptat toate instrumentele metodologiei.
Pentru a implementa XP într-un proiect existent, adoptă treptat practicile sale în următoarele domenii:
- Testare: Echipa creează teste înainte de a scrie noul cod și refactorizează treptat codul vechi.
- Design: Echipa refactorizează continuu codul vechi, de obicei înainte de a adăuga noi funcționalități.
- Planificare: Echipa trebuie să interacționeze strâns cu clientul.
- Management: Managerii se asigură că toți membrii echipei respectă noile reguli.
- Dezvoltare: Începe prin organizarea stațiilor de lucru pentru programarea în pereche și încurajează perechile să programeze cea mai mare parte a timpului.
Exemplu de flux de lucru folosind XP
Cine folosește XP
Conform unui sondaj din 2016 realizat de VersionOne, doar 1% dintre companiile agile folosesc XP în forma sa pură. Alte 10% folosesc un hibrid între Scrum și XP.Deși XP nu este cea mai comună metodologie, practicile sale sunt utilizate de cele mai multe companii care angajează metodologii agire. De exemplu, Pivotal Software, Inc. își atribuie succesul XP.
Pivotal Software, Inc.
Pivotal Software, Inc. dezvoltă analize de afaceri bazate pe big data și oferă servicii de consultanță. Produsele lor sunt utilizate de corporații precum Ford, Mercedes, BMW, GAP, Humana, bănci majore, agenții guvernamentale și companii de asigurări.
Pivotal militează pentru metodologiile agile ca fiind esențiale pentru dezvoltarea modernă. Printre variantele agile, au ales XP, o abordare câștig-câștig pentru clienți și echipele de programare. Ziua de lucru începe cu întâlniri stand-up și se încheie la 18:00 — fără muncă suplimentară. Pivotal folosește jocuri de planificare, programare în pereche, testare constantă, integrare continuă și alte practici XP.
Ce să citești pentru a înțelege XP
- „Programarea Extremă Explicată”, „Planificarea Programării Extreme”, „Dezvoltare condusă de teste” de Kent Beck: Aceste cărți de la creatorul XP oferă o înțelegere detaliată a metodologiei și avantajelor sale.
- „Refactorizare: Îmbunătățirea designului codului existent” de Martin Fowler: O carte a unui coautor XP care explică principiile și tehnicile de refactorizare.
- „Programarea Extremă Aplicată: Jucând pentru a câștiga” de Ken Auer și Roy Miller: Un ghid practic pentru practicile XP cu exemple.
Instrumente pentru implementarea XP în echipe
Redmine
Un manager de sarcini gratuit și open-source, cu caracteristici precum suport pentru mai multe proiecte, management flexibil al sarcinilor, diagrame Gantt, urmărirea timpului, managementul documentației și crearea sarcinilor prin email.
Basecamp
Un serviciu simplu, prietenos pentru utilizatori, pentru colaborarea în proiecte, inclusiv un manager de sarcini, panouri de mesaje, chat încorporat, stocare de fișiere și calendar.
Jira
Un serviciu robust conceput pentru dezvoltatorii de proiecte agile, combinând un tracker de erori și un instrument de management al proiectelor, cu multe caracteristici și opțiuni de sincronizare.
Worksection
Un serviciu sigur pentru lucrul la proiecte, care permite setarea sarcinilor și controlul procesului, urmărirea corespondenței, personalizarea filtrelor, urmărirea timpului și a finanțelor, precum și gestionarea fișierelor.
Concluzie
Programarea Extremă este o metodologie agilă axată pe producerea de cod funcțional de înaltă calitate, cu o arhitectură simplă. Scopul său este de a reduce incertitudinea în proiecte și de a răspunde flexibil la cerințele schimbătoare ale produsului.
XP este exclusiv pentru dezvoltarea software-ului și nu poate fi adaptat la alte afaceri.
Este una dintre cele mai dificile metodologii de implementat datorită celor treisprezece practici ale sale. Cu toate acestea, practicile sale sunt folosite pe scară largă în proiectele agile, dovedindu-și eficiența.
Autorii recomandă stăruința în stăpânirea practicilor XP în timp ce se rezolvă problemele proiectului. Dacă observi beneficiile, continuă în aceeași direcție. Nu există nicio obligație de a implementa XP pe o bază de tot sau nimic. Până la urmă, metodologiile agile ar trebui să fie flexibile în aplicare — adaptându-se nevoilor specifice ale echipei de proiect.