ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 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 17
Abonament PDF

Performance... what now?!

Mihai Șerdean
QA Test Manager



TESTARE

Iată o situație obișnuită în zilele de astăzi: o companie află despre Agile și decide să adopte "procesul agile". Echipa de conducere a companiei creează un plan al tranziției care include: training, coaching și consultanță. Monitorizarea avansului se face întrebând: câte echipe sunt agile? Pentru că atunci când vom fi peste 80%, am terminat tranziția și vom fi agile. Nu?

Greșit. Cât de agile este o companie nu contează cu adevărat. Singurul lucru care contează este agilitatea: cât de repede poate o companie să se adapteze schimbării. Agilitatea este proprietatea organizației, nu a echipelor. Îmbunătățirea agilității presupune de obicei folosirea practicilor agile și lean la nivelul echipelor, dar nu doar atât.

Cine are nevoie de mai multă agilitate?

Dacă ne uităm în acest mod, atunci este evident că nu toate companiile au nevoie de agilitate. În special o companie nu are nevoie de agilitate dacă toate criteriile următoare se aplică:

  • are un model de business puternic care aduce un profit remarcabil,
  • nu vrea să se extindă pe alte piețe sau să creeze alte modele de business,
  • clienții au un ciclu de punere în producție foarte lung (1-2 ani).

Spitalele sunt un exemplu de client care nu vrea să își schimbe software-ul mai des de două ori pe an. Contabilii sunt de asemenea cunoscuți pentru a fi utilizatori conservatori care preferă mai puține update-uri. Unele practici agile pot să structureze mai bine munca realizată în asemenea contexte, dar valoarea pe care o aduc afacerii va fi limitată. În mod sigur, nu toate spitalele sau nu toți contabilii se potrivesc acestui model, în consecința fiecare afacere trebuie să se decidă în funcție de contextul propriu.

Dacă întoarcem acest argument, ajungem să aflăm care sunt motivele pentru a crește agilitatea unei companii:

  • când piața o forțează să furnizeze calitate îmbunătățită mai repede,
  • atunci când piața s-a schimbat și afacerea trebuie să se adapteze,
  • când afacerea trebuie să intre pe o nouă piață,
  • atunci când afacerea trebuie să crească repede.

Observați că vorbim despre creșterea agilității. Orice afacere are un anumit nivel de agilitate, problema este cum să o creștem pentru a răspunde forțelor externe care o obligă la schimbare.

Măsurarea agilității. O utopie?

Putem să măsurăm agilitatea unei companii? A o măsura direct este evident foarte riscant și foarte scump, pentru că am avea nevoie să aplicăm forțe externe asupra companiei și să observăm cât de repede se adaptează.

Putem, totuși, să analizăm evenimentele trecute și să discutăm situații ipotetice. De exemplu "ce ar trebui să facem pentru a reduce ciclul de punere în producție de la un an la șase luni?". Dacă răspunsul este "acest lucru ar fi imposibil" sau "acest lucru ar fi foarte dificil", atunci agilitatea în mod clar nu este un punct forte. Un alt exemplu: "cât de repede puteți crea un produs complet nou de la o idee pe care o aveți astăzi?". Dacă răspunsul este "un an" sau "6 luni", în mod sigur e loc de mai bine pentru că trei luni este o perioadă uzuală pentru acest gen de activitate.

La acest moment nu există nici o listă clară de întrebări pe care le putem adresa pentru a măsura agilitatea. Întrebările interesante sunt foarte dependente de contextul afacerii și obiectivele sale. Aici experiența unui coach agile cu diverse organizații devine foarte utilă.

Principii și practici pentru a sprijini creșterea agilității

Odata ce s-a decis ce trebuie îmbunătățit, este timpul pentru a crea un experiment si pentru a ne concentra pe principii și practici.

Principiile sunt fundația oricărei tranziții, iar practicile definesc cum putem face anumite lucruri. De exemplu, principiul agile, comunicarea față în față definit drept "cea mai eficientă metodă de a transmite informaţii înspre şi în interiorul echipei de dezvoltare, conduce la practica de a avea echipe colocate și de a organiza întâlniri cum ar fi Daily Scrum, Planning sau Retrospectiva, unde toată echipa este prezentă fizic oricând posibil. Principiul de a avea feedback rapid și des se traduce în practica prin:

  • a lua feedback de la clienți pe dezvoltări,
  • dezvoltatorii să scrie teste unitare astfel încât primesc un feedback rapid în legătură cu corectitudinea schimbărilor făcute de ei,
  • integrare continuă a modificărilor pentru a permite feedback rapid pe schimbările realizate,
  • feedback "neînfricat" între membrii echipei pentru a îmbunătăți colaborarea în echipă.

Principiile sunt structura de rezistență a tranziției: oricând scopul unei practici nu e înțeles bine, principiile ajuta la luarea unei decizii pentru a opri practica respectivă sau pentru a îmbunătăți modul cum este pusă în aplicare.

Unele practici sunt foarte importante pentru agilitate. De exemplu, o echipă cu adevărat auto-organizată care poate lua decizii singură, în niște limite setate de manageri, poate permite schimbări mult mai rapide decât un model decizional centralizat. Deși mecanismul echipelor auto-organizate este adesea neintuitiv și poate părea haotic, este dovedit ca fiind funcțional și este parte a unui nou tip de management care se ocupă de sisteme complexe, numit de obicei Management 3.0.

Uneori rațiuni practice împiedică echipele de la aplicarea unui anumit principiu; de aceea practicile ar trebui adaptate pentru a echilibra aceste lipsuri. De exemplu, echipele care sunt forțate să lucreze într-un mod distribuit ar trebui ajutate prin utilizarea unor conexiuni non-stop video și audio pe un ecran mare, care poate părea aproape la fel ca și cum ar lucra în același birou. De asemenea, călătorii ale membrilor echipelor între birouri pentru a se cunoaște mai bine va întări colaborarea.

Dacă cei care conduc afacerea au o dorință serioasă de a crește agilitatea ei, nu se vor opri la practici organizaționale precum adoptarea Scrum pentru toate echipele. Schimbări în alte zone sunt adesea necesare. Haideți să ne uităm îndeaproape la câteva dintre ele.

Ciclul de release

Reducerea acestui ciclu de la un an la o lună sau mai puțin nu este posibilă, după cum consideră cei mai iscusiți practicieni din industrie, fără a schimba practicile tehnice care sunt folosite. Agilitatea la acest nivel are nevoie de design software flexibil, teste automate, specificații executabile, integrare continuă și refactoring zilnic. În articolul precedent "Agilitatea presupune Craftsmanship" s-a explicat în detaliu de ce. Articolul "Building Changeability in Design" http://www.mozaicworks.com/blog/building-changeability-in-design - explorează rolul pe care îl are design-ul software atunci când schimbarea este la ordinea zilei.

Feedback

Principiul de a avea un feedback rapid tinde să se răspândească și către alte departamente, în special către HR. Dacă departamentul de HR obișnuia să facă evaluări bianuale, dezvoltatorii cu comportament agile cer evaluări mai dese ale performanțelor proprii. Practici cum ar fi întâlniri lunare one-on-one cu managerii direcți, feedback lunar de tipul "360 degrees" sau feedback continuu între membrii echipei ajută la îndeplinirea acestei nevoi.

Management 3.0

Rolul managementului se schimbă spre mai puțin control direct și mai mult către leadership. Unele dintre deciziile luate în mod uzual de manageri sunt delegate către echipe auto-organizate, iar managerul devine coach și ajută membrii echipelor în luarea deciziilor. La această situație nu se ajunge peste noapte ci necesită o perioadă de tranziție; vizualizarea ariilor de responsabilitate și a nivelurilor de delegare ale echipei este de ajutor atât pentru management cât și pentru echipe pentru a înțelege noul lor rol pe drumul pe care au pornit. Odata ce acest lucru s-a întâmplat, managerii au mai mult timp și energie pentru a se concentra pe gândire strategică.

Business Agility

Probabil cea mai dificilă zonă de schimbat este cea de business. Agilitatea este măsurată la acest nivel în termeni de cât de repede poate compania să intre pe o nouă piață sau să își schimbe modelul de business. Practicile și principiile "lean" joacă un rol important pentru acest tip de schimbare. Primul pas este de a identifica fluxurile de valoare ale noului model de business, adică pentru ce vor plăti clienții și care sunt pașii care trebuie făcuți pentru a crea această valoare. Dacă aceste lucruri sunt necunoscute, este timpul pentru a defini niște ipoteze și de a le valida prin experimente în modul Lean Startup (vezi articolul precedent despre Lean Startup). Odata ce fluxul de valoare este clar este vremea să:

  • îl vizualizăm;
  • măsurăm cycle time: timpul scurs între momentul în care începe o dezvoltare și aceasta este finalizată;
  • măsurăm lead time: timpul scurs între momentul în care un utilizator a cerut ceva nou și momentul în care dezvoltarea este plătită;
  • îmbunătățirea continuă a fluxului de valoare prin eliminarea zonelor unde valoarea este blocată și prin eliminarea risipei (orice nu ajută la dezvoltarea unor elemente de valoare).

Îmbunătățirea Continuă

Îmbunătățirea continuă este partea cea mai dificilă deoarece necesită adesea decizii dificile de business și management. Coaching-ul ajută foarte mult la menținerea ritmului de îmbunătățire; acestea sunt adesea invizibile pentru membrii echipei din cauza obișnuinței cu procesul curent de lucru.

Concluzii

Agile și Lean nu contează în sine. Agilitatea contează. Agilitatea este proprietatea unei companii definită ca viteza cu care se schimbă când este nevoită. Companiile au cel mai adesea nevoie să se schimbe atunci când sunt forțate de piață, când decid să intre într-o piață nouă sau când o plănuiesc creștere accelerată.

Pentru a îmbunătăți agilitatea, trebuie definite în primul rând foarte clar obiectivele de business. Urmează adoptarea setului de principii și practici utile din agile și lean, ținând tot timpul cont de obiectivele de business. Practicile de la nivelul echipei precum cele definite de Scrum sau XP sunt doar o mică parte din îmbunătățirea agilității. Managerii trebuie să își modifice rolul de la cel tradițional la unul de leadership și gândire strategică. Departmentele HR trebuie să își adapteze procesele de evaluare pentru a permite feedback rapid și des, chiar dacă este transmis direct între membrii echipei. Liderii afacerii trebuie să se îndepărteze de viziunea tradițională de departamente compartimentalizate și să perceapă businessul ca flux de valoare, bottlenecks și eliminarea risipei.

Agilitatea poate fi îmbunătățită și fără modificarea tuturor nivelelor din organizație. Amintiți-vă totuși că întotdeauna puteți face lucrurile mai bine.

NUMĂRUL 149 - Development with AI

Sponsori

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