Trei strategii se pot aplica unui sistem: împinge (push), trage (pull) sau o combinație între cele două împinge-trage. Dacă ar fi să ne referim la o linie de producție, într-o strategie de tip împinge creăm produse sperând să răspundem unei nevoi. Ieșirile procesului nostru creează stocuri de produse care așteaptă a fi consumate. Gestionarea acestor stocuri poate fi costisitoare, iar elementele din stoc se devalorizează cu trecerea timpului. Într-o strategie de tip trage începem munca abia în momentul în care este confirmată cererea, ducând la cicluri de răspuns mai lungi și la gâtuirea procesului când numărul de cereri este prea mare.
Pentru o mai bună înțelegere, voi face o analogie cu gestiunea comenzilor la restaurant.
| Strategie | Descriere | Consecință |
|---|---|---|
| Împinge | Putem avea meniuri deja pregătite sperând ca clienții să consume din acea selecție. | Cicluri mai mici de servire odată cu riscul de a risipi mâncarea necomandată și rămasă în stocuri. |
| Trage | Clientul lansează o comandă, moment în care bucătarul se apucă de gătit. | Cicluri de servire mai mari, însă mâncarea va fi proaspătă și restaurantul nu trebuie să-și bată capul cu mâncarea rămasă. |
| Împinge-trage | Bazându-ne pe istoric putem observa că anumite specialități sunt comandate mai des, ceea ce ne poate determina să pregătim stocuri doar pentru acestea. | Stocurile urmează a fi reumplute atunci când ating anumite limite. Astfel putem obține cicluri de servire mai mici pentru ceea ce se comandă mai des și cicluri mai mari pentru restul. Riscul de a risipi mâncarea continuă să existe, dar este limitat la stocuri mai mici. |
Când vine vorba de industria software, modelul de lucru în cascadă (waterfall) sau ciclul în V (v-model) necesită o strategie de tip împinge. Specificațiile erau create înainte de a fi consumate de dezvoltatori și erau gestionate în stocuri. Într-un proiect agil, kanban sau Scrum, crearea de specificații pe care nimeni nu le poate folosi este considerată risipă. De unde și conceptul de a face lucrurile la timp (JIT, just in time).
Dezvoltarea în flux continuu
După Corey Ladas, extras din cartea Kanban pour l’IT de Laurent Morisseau, într-un sistem de tip trage pentru dezvoltarea software:
- nu construim funcționalități de care nimeni nu are nevoie în acel moment,
- nu facem mai multe specificații decât avem nevoie pentru a scrie cod,
- nu scriem mai mult cod decât putem testa,
- nu testăm mai mult cod decât putem instala și
- nu instalăm mai mult cod decât putem utiliza.
În filozofia lean, să facem mai mult decât ne este necesar este considerat risipă de energie. Pentru a evita risipa, activitățile în amonte sunt legate de cele în aval. Astfel, incrementarea cerințelor este trasă din avalul procesului:
- instalăm doar ceea ce utilizatorul este capabil să utilizeze,
- testăm doar ce suntem capabil să instalăm,
- scriem codul doar pentru ce suntem capabili să testăm,
- facem specificațiile doar pentru ce putem scrie cod și
- specificăm doar ce are nevoie clientul.
În IT, obstacolul trecerii la un sistem de tip trage, de dezvoltare în flux continuu, nu mai este de ordin tehnic, ci mai degrabă ține de limitele celor care gândesc sistemul. Iar provocarea dezvoltării în flux continuu constă în găsirea unui echilibru între numărul de elemente care intră permanent în sistem și viteza traversării sistemului. Cu alte cuvinte, între a accepta multe cereri și a produce repede.
Voi reveni atât la această chestiunea de performanță cât și la alte beneficiile ale dezvoltării în flux continuu în articolele următoare.
Citește în continuare…
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 3785 ori