diferența dintre programarea extremă și Scrum

un procent notabil de companii utilizează acum managementul de proiect agil ca abordare a satisfacerii cerințelor pieței. Conform noilor cercetări, 55% dintre companiile care rămân la buget și finalizează peste 80% din proiectele lor la timp folosesc cadre de management de proiect Agile.

proiectele Agile ar putea avea mai mult succes decât metodologiile tradiționale de management de proiect cu doar 28%, dar aceasta din urmă este din ce în ce mai puțin eficientă în a răspunde nevoilor în schimbare ale unui client. Acest lucru se datorează caracteristicilor unice ale metodologiilor tradiționale de management de proiect:

• acestea sunt rulate într-o serie de etape secvențiale fixe: inițiere, planificare, execuție, monitorizare și închidere.
• pun accentul pe procese liniare, documentare, planificare în avans și prioritizare.

pe de altă parte, este managementul de proiect agil, a cărui definiție este reiterată de Fraza la fel de agilă ca o maimuță. Când spui că cineva sau ceva este la fel de agil ca o maimuță, înseamnă că sunt foarte rapizi și au capacitatea de a se mișca rapid și ușor. Managementul de proiect agil și dezvoltarea de software agil își iau calitățile de bază din aceasta.

dezvoltarea de software Agile, adesea menționată mononim ca Agile, se referă la furnizarea treptată de software de calitate întreprinderilor și companiilor. Această natură a unui proces de livrare în curs de desfășurare provine din necesitatea ca întreprinderile să se adapteze la cerințele în schimbare și să rămână competente pe piață. Ca rezultat, succesul în dezvoltarea de software agil este măsurat de capacitatea echipei de a livra continuu.

raționamentul care stă la baza dezvoltării de software Agile este că diferite proiecte au nevoie de linii de acțiune diferite. Având în vedere acest lucru, proiectele Agile se bazează pe anumite valori. O astfel de valoare este concentrarea pe abilități, comunicare și comunitate pentru a permite agilitatea și eficiența, spre deosebire de concentrarea asupra proceselor.

alte valori Agile includ:

• prioritizarea software-ului de lucru față de documentația completă
• prioritizarea colaborării clienților față de negocierea contractului
• prioritizarea răspunsului la schimbare față de urmărirea unui plan.

în sensul cel mai de bază, puteți privi Agile ca diverse abordări ale dezvoltării de software care sunt specifice livrării incrementale, colaborării în echipă, planificării continue și învățării continue. Aceste caracteristici limitează o livrare unică la sfârșit și fac loc modificărilor în curs.

o echipă agilă este formată din șase părți cu roluri diferite de jucat. Cu toate acestea, într-o echipă agilă, toată lumea se concentrează pe livrarea unui produs de înaltă calitate. Produsul sau proiectul se referă la noua aplicație mobilă, joc sau software personalizat care urmează să fie dezvoltat. Membrii echipei includ:

1. client: ajută la definirea produsului/proiectului, de asemenea, cunoscut sub numele de proprietar de produs
2. programator: ajută la produs / proiect
3. Tester: Ajută la verificarea produsului / proiectului funcționează așa cum este definit
4. Tracker: ajută aduna și prezenta valori utile
5. antrenor: ajută ghida echipa spre succes
6. Coordonator (opțional): ajută la gestionarea comunicării externe.

clienții joacă un rol special, deoarece își asumă responsabilitatea pentru funcționalitatea produsului și designul orientat către utilizator. Există, de asemenea, analiști de afaceri, proprietari de produse, testeri și alții care ajută la definirea produsului și la consilierea clientului.

dezvoltatorii, arhitecții și asistența tehnică sunt responsabili de proiectarea, dezvoltarea și întreținerea internă a produsului. Un antrenor vă ghidează echipa, ajutând la elaborarea propriilor reguli și protocoale. Antrenorul profesionist ajută echipele să crească până la punctul în care nu mai au nevoie de el.

coordonatorii echipei sunt înlocuiți de rolurile unui manager, manager de proiect și Scrum Master. Ei aranjează programe, gestionează cererile primite și rezolvă problemele interpersonale.

există o varietate de cadre Agile. Ele sunt, de asemenea, denumite metodologii sau abordări. Acestea includ Scrum, Kanban, Extreme Programming (XP), Crystal, Lean, Feature Driven Development (FDD) și Dynamic Systems Development Method (DSDM). Alegerea celei potrivite pentru un anumit proiect poate confunda chiar și echipele de dezvoltare cu experiență. Cheia pentru a diminua această confuzie este înțelegerea diferențelor dintre ele.

cele două metodologii Agile discutate în acest articol vor fi Scrum și Extreme Programming (XP). Este esențial să aveți cunoștințe despre aceste metodologii pentru succesul proiectului dvs. Ambele cadre Agile se bazează pe anumite principii și oferă orientări clare pentru dezvoltarea de produse/software. Amintiți-vă, Agile în sine este doar o listă de valori și descrie o mare varietate de practici care se conformează acestor valori.

care este metodologia Scrum și cum funcționează?

Scrum este un cadru eficient pentru organizarea muncii. Are un proces simplu și circular, cu două elemente constante de inspecție și adaptare. Primul este crearea și menținerea listelor de sarcini ordonate fără milă, cunoscute sub numele de restanțe de produse. Al doilea element se referă la prioritizarea elementelor dedicate diferitelor etape în dezvoltarea proiectului în perioade scurte de timp. Acestea se numesc sprinturi și, în această perioadă de timp, Echipa scrum se străduiește să atingă obiective predeterminate și convenite de comun acord.

o echipă Scrum este formată dintr-un proprietar de produs, un maestru Scrum și o echipă de dezvoltare care lucrează împreună și livrează în conformitate cu simplitatea cadrului printr-un nivel ridicat de comunicare între ele. Rolul proprietarului produsului este de a traduce obiectivele clientului înapoi la Echipa Scrum. Ei sunt membrii echipei care știu ce vrea clientul și valoarea relativă de afaceri a acestor vrea.

un Scrum Master este facilitatorul unei echipe de dezvoltare agile. Deși rolul a fost creat ca parte a cadrului Scrum, termenul este folosit și de echipe care nu urmăresc în mod explicit Scrum. Responsabilitățile Scrum Master includ abordarea dinamicii echipei, eliminarea obstacolelor și asigurarea unor relații bune de lucru în cadrul echipei.

Scrum project management se bazează în principal pe o echipă inter-funcțională și auto-organizată și este adesea descrisă în termenii rezultatului dorit. Scrum vă permite să vă adaptați cerințelor pieței în continuă schimbare, constrângerilor tehnologice și inovațiilor. Cheia constă în procesul continuu de lucru asupra problemelor prioritare până la finalizare.

Echipa lucrează la dezvoltarea și testarea fiecărui element cu prioritate ridicată prin șapte pași:

• formularea cerințelor
• UI/UX design
• dezvoltare
• testare completă
• integrare
• documentație
• aprobare finală.fiecare cerință luată în considerare în timpul unui sprint ar trebui să fie complet construită, testată și apoi aprobată sau respinsă.

  proiectele sunt construite tangibil, increment cu increment. Aceste creșteri tangibile sunt apoi prezentate părților interesate pentru feedback. Noile cerințe generate de feedback-ul lor sunt plasate în restanțele de produse și prioritizate în funcție de sarcinile existente. Aceasta se numește ciclul scrum.

  prin urmare, ciclul scrum este rulat din nou și din nou. Fluxul constant de feedback și concentrarea asupra articolelor cu cea mai mare prioritate reflectă satisfacția clienților și livrarea rapidă de cea mai bună calitate. Scrum poate fi folosit pe orice proiect complex. Beneficiază în mod specific proiectele:

  • cu echipe inter-funcționale;
  • fără întreruperi constante din activitățile de afaceri de zi cu zi;
  • care necesită o buclă de feedback rapid;
  • care utilizează feedback-ul părților interesate pentru a prioritiza sarcinile pentru următorul sprint.

  evenimentele Scrum oferă oportunitatea de a adera la valoarea agilă a prioritizării comunicării continue. Aceasta include Sprint, sprint Planning, Daily Scrum și Sprint Review.

  echipa de dezvoltare este responsabilă pentru desfășurarea Scrum-ului zilnic, care este o întâlnire internă scurtă, zilnică, ținută într-un interval de timp de 15 minute. Scrum Master se asigură că întâlnirea nu este întreruptă și că participă fiecare membru al echipei care lucrează pentru finalizarea unui sprint dat.

  planificarea sprintului este utilizată pentru a planifica munca care trebuie efectuată în timpul sprintului. Întâlnirea este împărțită în două părți. Prima parte determină obiectivele sprintului, în timp ce a doua parte determină modul în care obiectivul va fi atins.

  O revizuire Sprint se face la sfârșitul sprint și este utilizat pentru a evalua realizările în timpul sprint. De asemenea, este folosit pentru a decide ce trebuie făcut în următorul sprint pe baza comunicării dintre proprietarul produsului și echipa de dezvoltare. Echipa se întâlnește pentru a aborda care au fost cele mai importante momente ale sprintului și ce probleme au fost găsite.

  

  care este metodologia XP și cum funcționează?

  Extreme Programming (XP) este un mod ușor, eficient, cu risc scăzut, flexibil, previzibil și științific de a dezvolta software. Își derivă numele din luarea elementelor practicilor tradiționale de inginerie software la niveluri” extreme”. XP este o metodologie agilă cu anumite caracteristici. Acesta este conceput pentru a lucra cu proiecte care nu sunt constrânse brusc de mediul de calcul existent, și în cazul în care un loc de muncă rezonabil de teste de executare se poate face într-o fracțiune de zi.XP funcționează cel mai bine pentru echipele mici și mijlocii care dezvoltă software care lucrează în mijlocul cerințelor vagi sau în schimbare rapidă. În timpul procesului de dezvoltare, echipa construiește o versiune completă a sistemului aproximativ la fiecare 6-8 săptămâni. XP utilizează feedback rapid și comunicare eficientă pentru a obține cele mai multe din valoarea livrată prin:

  • abordare specifică de planificare
  • client La fața locului
  • testare continuă.

  niciuna dintre ideile din programarea extremă nu este nouă. Cele mai multe dintre ele sunt la fel de vechi ca programarea în sine. Acesta este destinat să îmbunătățească capacitatea de reacție și calitatea software-ului pe măsură ce cerințele se schimbă. În plus, promite să reducă riscul proiectului, să îmbunătățească capacitatea de reacție la schimbările de afaceri, să îmbunătățească productivitatea pe tot parcursul vieții unui sistem și să adauge distracție la construirea software—ului în Echipe-toate în același timp.

  o abordare XP pune accentul pe implicarea și testarea clienților. Clientul din XP are oportunități frecvente de a schimba direcția echipei de dezvoltare XP dacă circumstanțele se schimbă. Vă puteți gândi la XP ca la o ceapă. Stratul cel mai interior este programarea. Stratul de mijloc constă dintr-un set de practici orientate spre echipă. Stratul exterior definește procesul prin care o echipă de programare interacționează cu clienții săi.

  programarea extremă duce principiile tradiționale la niveluri extreme printr-o serie de practici. Domeniile majore de practică în XP sunt împărțite în trei straturi: practici de programare, practici de echipă și procese. În cazul în care o practică este slabă, punctele forte ale altor practici vor acoperi slăbiciunea.

  practicile XP includ:

  • design simplu
  • programare pereche
  • testare constantă
  • integrare continuă
  • refactorizare
  • standarde de codificare
  • versiuni mici.

  practica epuizantă, dar productivă prin care XP revizuiește Codul tot timpul este cunoscută sub numele de programare pereche. Programarea perechilor este practica de a avea doi oameni care lucrează simultan împreună la toate codurile de producție ca parteneri deplini pentru a oferi un design constant și o revizuire a codului. În XP, perechile se schimbă de obicei de câteva ori pe zi și se programează cu o tastatură, un mouse și un monitor.

  integrarea continuă este practica integrării sistemului de mai multe ori pe zi de fiecare dată când o sarcină este finalizată de un dezvoltator (pereche). Reduce disputele de dezvoltare și stabilește un sfârșit natural al unui episod de dezvoltare. Integrarea în XP este susținută de teste precum testarea unității și testarea funcțională.

  testarea unității se face continuu de către toți programatorii pentru ca dezvoltarea să continue. Testele unitare verifică funcționalitatea de bază a unui program, acționează ca o plasă de siguranță constantă și sprijină proiectarea, codificarea și refactorizarea. Pe de altă parte, testarea funcțională (denumită și testare de acceptare) este făcută de clienți pentru a demonstra că funcțiile sunt terminate. Testele funcționale determină, de asemenea, comportamentul general al sistemului.

  integrarea continuă este posibilă în XP deoarece este susținută de teste și pentru că XP prevede un design mai simplu prin refactorizare. Refactorizarea în XP este practica restructurării unui program sau a implementării unei caracteristici fără a schimba comportamentul sistemului. Acest lucru se face pentru a simplifica, a elimina duplicarea, a îmbunătăți comunicarea sau a adăuga flexibilitate.

  proiectele XP au trei faze, și anume faza de planificare a lansării, faza de iterație și faza de lansare. Clienții descriu nevoile lor ca povești prezentate pe scurt. În faza de planificare a lansării, clientul scrie povești, programatorii le estimează, iar Clientul alege ordinea în care vor fi dezvoltate poveștile.

  în faza de iterație, clientul scrie teste și răspunde la întrebări, în timp ce programatorii dezvoltă software conform poveștilor. Faza de iterație oferă software Gata de plecare. În al treilea rând, în faza de lansare, programatorii instalează software-ul, iar clientul aprobă rezultatul.

  programarea extremă reușește în cazurile în care se așteaptă ca funcționalitatea sistemului să se schimbe la fiecare câteva luni. De asemenea, este utilizat într-o situație în care clientul necesită un nou sistem până la o anumită dată, ceea ce aduce un risc ridicat. Deoarece XP este utilizat pentru proiecte cu risc ridicat și proiecte cu termene de livrare specifice, necesită Echipe mici cu maximum 30 de persoane.

  ce au în comun XP și Scrum?

  atât Scrum, cât și Extreme Programming împart procesul de dezvoltare în sprinturi, au o întâlnire de planificare înainte de începerea dezvoltării și identifică poveștile utilizatorilor în timpul acestor întâlniri. Întreprinderile își descriu nevoile ca povești prezentate pe scurt, care sunt expresii informale. Se spune că povestea este auzită odată ce nevoia lor (reprezentată de poveste) a fost construită în cod. de asemenea, ambele implică o întâlnire de planificare înainte de fiecare sprint. Obiectivele lor principale sunt, de asemenea, similare. Atât Scrum, cât și XP se concentrează pe livrarea unui produs de înaltă calitate către client cât mai repede posibil.

  ?

  Aflați mai multe despre diferențele fundamentale dintre Waterfall și Agile.

  care este diferența dintre Scrum și XP?

  una dintre întrebările standard adresate legate de Agile este modul în care programarea extremă se compară cu Scrum, deoarece ambele sunt cele mai importante metodologii ale Agile. Înțelegerea diferențelor lor ajută la alegerea cadrului potrivit pentru un anumit proiect. Scrum vs XP diferă în șase zone proeminente: în accentul lor principal, sprinturi, în modul în care se adaptează schimbărilor, în rolul proprietarului produsului, în modul în care prioritizează sarcinile și, în cele din urmă, în valorile lor. Să aruncăm o privire mai atentă:

  focus principal

  principala diferență între Scrum și Extreme Programming este accentul lor principal. Scrum este puternic axat pe managementul în sine. Se ocupă de activitatea desfășurată în afară de codificare, deoarece nu oferă prea mult accent tehnic și ingineresc asupra modului în care se face efectiv munca sau a modului în care este construit efectiv un produs.

  Scrum determină modul de planificare și analiză a rezultatelor, precum și modul de creștere a productivității. Este mai preocupat de productivitate și de cât de productiv este produsul expedibil la sfârșitul sprintului. Scrum are, de asemenea, roluri de echipă bine definite, ceremonii organizate și artefacte informaționale.

  Pe de altă parte, programarea extremă se concentrează pe abordarea bazată pe teste. Principiile sale sunt cele mai bune practici inginerești duse la extrem. XP vine cu practici de bază care se concentrează pe furnizarea de calitate a software-ului livrat cu programare și codificare cu accent tehnic.

  Extreme Programming se concentrează pe tehnici de inginerie și feedback, cum ar fi programarea perechilor și dezvoltarea testabilă. Cu programare pereche, dezvoltatorii Cod simultan și de a face alte controale. Acest lucru asigură calitatea codului și economisește timp. Înțelegerea comună este predominantă în echipă în ceea ce privește determinarea standardelor de codificare și, de asemenea, proprietatea colectivă a codului.

  XP se spune adesea că este o programare pereche egală; cu toate acestea, nu este complet adevărat. În timp ce XP include această practică, este format din încă 11 practici, inclusiv scrierea testelor unitare în primul rând, integrarea continuă și așa mai departe. Este important să rețineți că proiectele care decid să utilizeze cadrul XP trebuie să se asigure că toate cele 12 linii directoare sunt respectate. Omiterea oricăreia dintre ele poate face întregul proces ineficient.

  sprinturi

  unul dintre principiile importante ale Agile este de a oferi creșteri shippable la perioade mici de timp numite sprinturi. Ambele cadre folosesc sprinturile ca etape de dezvoltare și trebuie să prezinte clientului un sistem de lucru la sfârșitul fiecărui sprint. Fiecare are abordări diferite față de aceste iterații ale cutiei de timp.

  Scrum sprints durează două până la patru săptămâni, iar lungimea lor este destul de flexibilă. Cu toate acestea, sub XP, există iterații mai scurte de una (uneori două) săptămâni pentru a dezvolta un sistem de lucru. Săptămânile în cauză ar trebui să fie săptămâni de lucru de 40 de ore pentru a vă asigura că dezvoltatorii nu se epuizează.

  scopul unui XP sprint nu este axat pe Lansarea produsului, ci pe crearea unui sistem funcțional fără erori. La rândul său, Scrum sprints ar trebui să aibă ca rezultat un produs de lucru.

  acomodarea modificări

  în Scrum, odată ce caracteristicile care urmează să fie puse în aplicare pentru sprint curent sunt decis, nu noi modificări sunt permise să fie incluse în sprint în timp ce este în curs de desfășurare. Odată ce planificarea sprintului este făcută, este imposibil să se introducă modificări în timpul sprintului. Prin urmare, clientul trebuie să aștepte până la sfârșitul său pentru a face acest lucru.

  există mai multă flexibilitate în programarea extremă în această privință. Sub XP, dezvoltatorii nu fac o caracteristică nouă până când nu este necesară. Modificările pot fi făcute de client în timpul sprintului în sine – și sunt încurajați să fie făcuți în primele etape de dezvoltare. Există prevederi pentru elemente noi care urmează să fie aduse. Există, de asemenea, dispoziții pentru înlocuirea articolelor existente în sprintul actual care nu sunt încă pornite.

  Product owner

  dacă o întreprindere utilizează Scrum, toată comunicarea cu product owner în timpul dezvoltării în sine este făcută de scrum master. Partea principală se referă la prioritizarea poveștilor utilizatorilor pentru fiecare sprint și la asigurarea faptului că acestea sunt complet clare pentru dezvoltatori.

  în cazul în care o întreprindere utilizează XP, clientul este cel care comunică cu echipa de dezvoltatori. El sau ea acordă prioritate și poveștilor utilizatorilor, cere să facă modificări și oferă feedback cu privire la rezultatele sprinturilor. În plus, clientul trebuie să fie întotdeauna disponibil pentru comunicare.

  prioritizarea sarcinilor

  într-un proiect Scrum, product owner determină prioritatea sarcinilor de dezvoltare într-un sprint, în timp ce dezvoltatorii determină ordinea acțiunilor lor. Ei pot alege sarcinile în sprint și le pot face în orice ordine, atâta timp cât finalizează sarcina până la sfârșitul sprintului.

  Pe de altă parte, nu există o astfel de flexibilitate pentru proiectele XP. Echipele XP urmează comenzi stricte în funcție de prioritate și cerință. Clientul decide ordinea sarcinilor, iar echipa trebuie să o urmeze fără nicio abatere.

  valori

  cele două cadre, Scrum vs XP, au unele diferențe de valori. Rețineți că orice metodologie agilă este mai mult decât reguli. Este o filozofie care determină abordarea dezvoltării.

  deși au valorile curajului și respectului în comun, celelalte sunt diferite. Valorile Scrum includ deschiderea, concentrarea și angajamentul, în timp ce XP prețuiește comunicarea, simplitatea și feedback-ul.

  

  concluzie

  Un nou proiect este conceput și trebuie dezvoltat. Întrebări importante pentru a cere sunt ceea ce se întâmplă atunci când există o plângere, și ceva trebuie să fie optimizat? Cum răspundeți la timp? Cum puteți să livrați software care se potrivește nevoilor dvs. sau clienților dvs. în continuă schimbare?cadrul Agile de dezvoltare Software răspunde la acestea, deoarece oferă treptat software de calitate întreprinderilor și companiilor, ceea ce permite răspunsuri regulate la cerințele în schimbare pentru a concura pe piață. Cele două cadre discutate, Scrum și XP, se concentrează pe livrarea unui produs de înaltă calitate către client cât mai repede posibil.

  nu există un cadru universal cel mai potrivit pentru toate cazurile – fiecare dintre ele are argumente pro, contra și cazuri de utilizare. Dacă nu știți cum să vă stabiliți pe un singur cadru, ceea ce puteți face este să combinați Scrum și XP. Multe companii profită deja de utilizarea metodologiilor hibride și integrează tehnicile XP în fluxurile de lucru Scrum/Kanban/Lean și puteți fi unul dintre ele. Dacă nu știți de unde să începeți, contactați-ne și vă vom ajuta să vă implementați ideea în viață.

  aveți nevoie de o echipă calificată?

  deblocați noi oportunități de afaceri cu echipa de dezvoltare dedicată de primă clasă.

  intra in contact intra in contact