ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 111
Abonament PDF

Business Analysis în metodologia Agile

Mădălina Kaszoni
Business Analyst @ PitechPlus



MANAGEMENT

Filozofia Agile a pornit de la un manifest de patru principii dedicate echipelor de software development. În timp, aceasta a crescut considerabil și s-a dezvoltat în diferite frameworkuri, înlocuind în final tradiționala metodologie Waterfall.

Faptul că în Agile nu vedem definit un rol de business analyst, cum de altfel nu vedem definite multe roluri în afara celor tehnice, este pentru că aceasta ar încălca principiul Agile fundamental : colaborarea. Metodologia nu reprezintă în sine un proces de analiză a nevoilor de business, ci un proces de software development gândit să aducă cât mai multă valoare businessului.

Avem nevoie de un BA într-o echipă de software development?

Da și nu. Echipele Agile ar trebui, teoretic, să fie cross funcționale și capabile să se organizeze atât de bine încât să poată livra un proiect end-to-end. Și de cele mai multe ori sunt așa, mai ales dacă avem implicat un Product Owner (PO). Totuși, realitatea este diferită și deseori, PO-ul reprezintă clientul, iar echipa de development nu are resurse pentru a acoperi atât identificarea nevoilor de business, cât și obținerea și documentarea cerințelor. Un BA integrat în echipa de software development cunoaște contextul proiectului, mecanismele care ar putea face munca echipei mai eficientă, dar mai ales colaborează și aliniază stakeholderii interni și externi - pe care nu e mereu ușor să îi găsești disponibili.

Ce atribuții îi rămân unui BA în metodologia Agile?

Definirea nevoilor de business și documentarea lor:

Scrierea și rafinarea taskurilor:

Scrierea de User stories (US) diferă de la organizație la organizație și depinde mult de proiect. Conform multor frameworkuri Agile, aceasta poate fi o responsabilitate care alternează între BA și PO, însă aportul adus de un BA este să le alinieze la criteriile INVEST - să se asigure că sunt independente, negociabile, valoroase, estimabile, dimensionate corect și testabile. Rafinarea US are loc împreună cu echipa de development la sfârșitul unui sprint și are ca scop pregătirea backlogului pentru sprintul următor.

Prioritizarea funcționalităților:

Frameworkurile Agile sunt create pentru a minimiza efortul și a maximiza rezultatele obținute. Prin urmare, prioritizarea joacă un rol foarte important. Cum schimbarea constantă ce revine odată cu descoperirea de noi informații are impact asupra backlogului, e nevoie de o persoană care să cunoască foarte bine industria, nevoile clientului și statusul proiectului pentru a putea pune cap la cap informațiile și a putea face recomandări pentru prioritizare.

Prin clarificare:

Într-o echipă experimentată în lucrul Agile, un BA se regăsește intermediind conversații și decizii dificile între stakeholderi. Acest rol poate fi unul ambiguu în metodologia Agile, dar un lucru e clar: un BA obține și oferă informațiile potrivite la momentul potrivit astfel încât dezvoltarea proiectului să prospere. Această responsabilitate de clarificare sintetizează foarte bine întrebarea cel mai des adresată de către un BA: cum pot să ajut? Un BA va fi acolo să se asigure că toți cei implicați în proiect au toate informațiile necesare pentru a putea să-și facă treaba cât mai bine, e acolo să clarifice atât nelămuririle privind statusul proiectului pentru client, cât și întrebările echipei privind flowul de business.

Acceptance criteria și User Acceptance Testing:

O altă responsabilitate importantă a unui BA este să se asigure că în cadrul fiecărui US avem definite acceptance criteria înainte de implementare. Aceste criterii de acceptare descriu, de fapt, limitările funcționalităților și regulile care servesc ca punct de plecare pentru construirea cazurilor de testare de către Quality Assurer (QA). Cât despre User Acceptance Testing (UAT), este pasul final în orice proiect de software development - momentul în care utilizatorii testează software-ul și validează schimbările dacă acestea le îndeplinesc nevoile reale. Un BA participă activ în planificarea și efectuarea UAT pentru a se asigura că proiectul livrat aduce într-adevăr valoare.

În compania noastră, distribuția set-up-ului echipei per proiect conține în proporție de 80% și alocarea unui BA atunci când vorbim de software development. Dacă vorbim de presales, echipele pe care le numim Client Engagement Team sunt întotdeauna o combinație UX + BA + Solution Architect, foarte importantă în această fază inițială de discovery. Obiectivul nostru este de a participa în mod activ la munca în echipă de și a avea echipe cât mai independente care să lucreze eficient, deschis și transparent.

Așadar, rolul de BA a fost mereu unul Agile. Necesită colaborare, adaptare constantă, acceptare a schimbării, leadership și empatie. Chiar dacă pare dificil să explicăm toate aceste responsabilități bunicilor, pe scurt, un BA este liantul dintre client și echipa tehnică. Cea mai des întâlnită întrebare pe care o vei primi de la un BA este: ,,Cum pot să ajut?"

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects