Dezvoltare Orientată Pe Comportament
Tradus de
ScribdTranslationsDezvoltare Orientată Pe Comportament
Tradus de
ScribdTranslationsBDD (Dezvoltare Conduită de Comportament)
Dezvoltare Orientată pe Comportament
Pentru ce serveș te:
BDD serve pentru a crea teste ș i a integra reguli de afaceri cu limbajul de
programare, concentrându-se pe comportamentul software-ului. În plus, îmbunătăț eș te încă
comunicarea între echipele de dezvoltare ș i testare, crescând
împărtăș irea cunoș tinț elor între ele.
În ce situaț ie este util:
Această metodologie este utilă în proiectele de software agile, care sunt construite în mai multe
iteraț ii ș i suferă modificări pe parcursul ciclului lor de viaț ă. Cu cât este mai mare
proiect, cu atât mai dificilă va fi comunicarea. Cu toate acestea, BDD propune o modalitate eficientă de
rezolvă aceste probleme.
Resumo
Când studiezi Ingineria Software, înveț i că orice sistem are un
timp de viaț ă util, ș i că o serie de factori pot contribui la creș terea sau
diminua ț i acest timp: arhitectură, modelare, tehnologie utilizată, acceptare a
piaț ă, etc. Cu toate acestea, nici o companie nu dezvoltă un sistem gândindu-se la zi
în care el va înceta să satisfacă nevoile clientului său, deș i aceasta este o
adevăr cert.
În acest ciclu, sistemul petrece cea mai mare parte a timpului suferind modificări. Ș i acestea
manipulările, fie ele corective sau nu, pot îmbunătăț i sau înrăutăț i sistemul,
în func ț ie de modul în care sunt implementate. Gândindu-mă la acesta ș i la altele
probleme, Kent Beck a prezentat lumii în 2003, prin intermediul cărț ii sale “Test-
Dezvoltare condusă de teste”, o tehnică pentru a crea sisteme bazate pe teste care vizează
a garanta calitatea ș i funcț ionalitatea software-ului pe parcursul acestui ciclu.
Deș i TDD este o tehnică testată ș i aprobată de mari dezvoltatori agil,
multe echipe de dezvoltare încă cad în câteva capcane ș i gre ș eli
înț elegeri de tipul: de unde să încep, ce să testez ș i ce să nu testez. Asta fără a menț iona
că cei care scriu testele sunt dezvoltatorii, dar când echipa de
calitatea va testa, ea se îngrijorează de comportamentul sistemului ș i nu de
teste unitare. În acest fel, nu există o comunicare eficientă între cele două echipe în
nivel de cod
Pentru a face aplicarea TDD-ului mai simplă ș i a ajuta echipele de dezvoltare
pentru a rezolva problemele menț ionate mai sus, a apărut Dezvoltarea Condusă de Comportament
(BDD).
Ce este TDD?
Dezvoltare Dirijată de Teste (TDD)
este o tehnică de dezvoltare a software-ului care se bazează pe un ciclu scurt de
repetiț ii. În primul rând, dezvoltatorul scrie un caz de test automatizat
ce define o o îmbunătăț ire dorită sau o nouă funcț ionalitate. Apoi, este produs
cod care poate fi validat prin test. Ulterior, acest cod va fi refactorizat
pentru a-l supune standardelor acceptabile.
Kent Beck a declarat în 2003 că TDD încurajează designuri de cod simple ș i inspirează
încredere. Din punctul de vedere al lui Robert C. Martin, autorul cărț ii „Agile Software
Dezvoltare”, obiectivul TDD este specificarea ș i nu validarea, adică este
modalitate de a gândi prin nevoile proiectului înainte de a scrie codul
funcț ional.
BDD, evoluț ia
BDD este o tehnică de dezvoltare agilă care îș i propune să integreze regulile de afaceri cu
limbaj de programare, concentrându-se pe comportamentul software-ului. În plus, poate-
se spune de asemenea că BDD este evoluț ia TDD-ului. Acest lucru se datorează faptului că testele încă orientează
dezvoltarea, adică mai întâi se scrie testul ș i apoi codul.
Focusul pe BDD este limbajul ș i interacț iunile folosite în procesul de dezvoltare
de software. Dezvoltatorii care se bucură de aceste tehnici scriu testele
în limba sa nativă în combinaț ie cu limbajul ubicuu.
Aceasta le permite să se concentreze pe motivul pentru care codul trebuie creat, în loc de
detalii tehnice ș i de asemenea permite o comunicare eficientă între echipele de
dezvoltare ș i teste.
Limbaj Ubicuu: este un limbaj structurat in jurul modelului de domeniu si folosit de toț i
membrii echipei pentru a conecta toate activităț ile lor cu software-ul. Într-o echipă de
dezvoltatorii sunt: jargonurile tehnice, terminologiile discuț iilor de zi cu zi sau un limbaj
neobiș nuit pentru persoanele din alte departamente.
Limbajul de afaceri folosit în BDD este extras din poveș ti sau specificaț ii
furnizate de client în timpul colectării cerinț elor. Unele cadre
utilizăm conț inutul poveș tilor scrise într-un fiș ier text ca scenarii pentru
os teste. Când Dan North a prezentat acest concept în 2003, el a sugerat un
standard pentru scrierea acestor fiș iere.
Avantajele utilizării BDD
Când Dan North vorbeș te despre BDD, el întotdeauna clarifică că scopul nu este de a anula
practici TDD, dimpotrivă, este de a adăuga la ele o serie de alte
avantaje, printre care se pot enumera:
•Comunicare între echipe: în majoritatea companiilor de dezvoltare
software-ul este dificil de realizat, deoarece dezvoltatorii ș i testatorii trebuie să colaboreze
pentru a atinge un obiectiv. BDD facilitează această integrare deoarece testerii pot
scrie scenariile de teste pentru ca dezvoltatorii să le implementeze;
•Împărtăș irea cunoș tinț elor: cu dezvoltatori ș i testeri
lucrând împreună, de-a lungul timpului, unul va transfera cunoș tinț ele sale pentru
outro, creând astfel o echipă multifuncț ională;
•Documentaț ie dinamică: unele echipe agile afirmă că nu documentează
sistemă deoarece întreț inerea acestor artefacte este costisitoare. Folosind cadrele de
BDD aceste artefacte sunt generate dinamic fără niciun efort suplimentar.
Unii, inclusiv, generează rapoarte în format HTML, ceea ce va facilita o consultare.
posterior
• Viziunea de ansamblu: Fergus O’Connell, în lucrarea sa „Cum să conduci cu succes o afacere în tehnologia avansată
Organizaț ii Bazate pe Proiect” (Artech House, 1999), prezintă o relaț ie a
principalele motive care duc proiectele de software la eș ec. Primul dintre ele este: „
obiectivele proiectului nu sunt bine definite ș i împărtă ș ite între to ț i
implicaț i”. Din acest motiv, BDD sugerează ca analistii/testerii să scrie.
scenarii înainte ca testele să fie implementate, ș i în acest fel
dezvoltatorii vor avea o imagine de ansamblu a obiectivului proiectului înainte de a-l codifica.
Nu există nicio îndoială că dezvoltarea unei aplicaț ii ghidate de teste este o practică
extrem de benefic. Rezultatul este un cod de bună calitate, cu coeziune ridicată ș i cu
număr redus de bug-uri, oferind astfel o durată de valabilitate lungă ș i
mentenanț e mai ieftine în viitor. Cu toate acestea, a începe în lumea testelor nu este
nimic uș or.
Sursă:Invalid input. Please provide text for translation.
comportament-bdd/21127
Un Product Backlog este o listă de func ț ionalităț i dorite ale unui produs, adică,
requisitos pe care un client se aș teaptă să le primească la finalul proiectului, descrise cu propriile sale
limbaj. Punctul central al Scrum este crearea ProductBacklog-ului, este în el că proiectul
începe.
Refinarea Product Backlog-ului are loc de obicei în:
Nivel General (împărtăș it între toate echipele)
Nivel Echipa
Nivel Multi-echipe
Îmbunătăț irea generală a Product Backlog
Regulile LeSS ridică întrebările: cum să decizi care echipe sunt
suscetibile de a implementa elementele? Există probleme de scară precum:
întelegere comună, coordonare, muncă comună, estimări aliniate
este echilibrul între specializare ș i agilitate.
O sesiune de PBR General abordează toate aceste aspecte. Pe scurt, efectuaț i o
reuniune PBR General cu reprezentanț ii echipelor înainte de sesiuni
de PBR das echipelor individuale, explorează ce echipe vor putea lucra în
cima de quais item, ș i cre ș teț i învă ț area ș i alinierea. Cei
participanț ii includ Product Owner-ul, experț i în domeniu, ș i atât
toț i membrii tuturor echipelor cât ș i o pereche de reprezentanț i de
fiecare echipă. Reprezentan ț ii sunt, de obicei, prefera ț i, pentru a men ț ine
reuniune mai mică ș i a nu avea pe toată lumea într-o altă reuniune, deș i există o
costo cu transferul ș i dispersia informaț iei.
Fă următoarele:
Împărț iț i articole mari
Fă o analiză foarte simplă a elementului pentru a obț ine o înț elegere
de bază
Estimare articole
Identificaț i elemente legate de muncă colaborativă, muncă
comun sau coordonare
Rafinarea Backlog-ului de Produs - Nivel
Echipă
Când un articol va fi clar realizat doar de o echipă ș i nu va avea
multe relaț ii cu alte articole, aș a că Refinarea Backlog-ului Produsului
va fi făcut în acelaș i mod ca o singură echipă Scrum. Echipa face
rafinare, de preferinț ă împreună cu utilizatorii/clienț ii/părț ile
interesate ș i informează-l pe Product Owner despre modificările (divizii, noi
estimările) în Product Backlog.
Îmbunătă ț irea Product Backlog - Nivel
Multiechipe
PBR Multiechipe apare când mai multe echipe sunt literalmente în
aceea ș i sală în acela ș i timp făcând PBR. Participan ț ii includ
specialiș ti în domeniu, ș i atât toț i membrii tuturor echipelor
cât un grup de reprezentanț i din fiecare echipă.
Care este diferenț a faț ă de PBR General? PBR General include participarea tuturor
echipe, dar un PBR Multiechipe poate implica doar câteva echipe
(ex: două echipe). În plus, este mai probabil ca toț i membrii
participăm, în loc de reprezentanț i.
Realizarea PBR Multiechipă cre ș te cunoa ș terea împărtă ș ită ș i
exploraț i oportunităț ile de coordonare atunci când un grup de echipe
lucrează la elemente sau subiecte strâns legate.
Sursă:[Link]
[Link]
OSprint Backlog este o listă de sarcini la care ScrumTeam se angajează să lucreze în
umSprint. Os itens do Sprint Backlog sunt extrase din Product Backlog de către echipă, pe baza
priorităț ile definite de Product Owner ș i percepț ia echipei asupra timpului care va fi
necesar pentru a completa diversele funcț ionalităț i.
Product Owner este persoana care defineș te elementele care compun Product Backlog ș i le prioritizează.
întâlnirile de planificare a sprintului. O echipă Scrum se uită la Product Backlog priorizat, selectează
articolele cele mai prioritare ș i se angajează să le livreze la finalul unui Sprint (iteraț ie). Aceste
elementele se transformă în Sprint Backlog.
Scrum Master acț ionează ca facilitator al Daily Scrum ș i devine responsabil pentru a elimina
orice obstacole care sunt ridicate de echipă în timpul acestor întâlniri. Rolul
Scrum Master este în mod typic exercitat de un manager de proiect sau de un lider tehnic, dar
în principiu poate fi oricine din echipă.