Cultura este adesea ignorată și neînțeleasă, dar este un factor cheie responsabil pentru performanța unei companii. Dacă nu ne gestionăm cultura, vom ajunge să facem practici greșite care, în cele din urmă, ne vor afecta obiectivele de afaceri.
Înțelegerea culturii actuale a unei organizații
Cultura ne spune despre valorile și normele din cadrul unui grup sau companie. Identifică ceea ce este important, precum și modul în care oamenii se abordează și lucrează între ei.
CULTURA = „Cum se pot face lucrurile inteligent pentru succes”
Să luăm exemplul unei echipe de asistență pentru clienți. Cultura acelei echipe ar trebui să fie de așa natură încât să ajungă la 97-98% din satisfacția clienților.
Ținând cont de încântarea clienților, în primul rând trebuie să fie politicoși, chiar și în situații dificile, trebuie să fie buni ascultători pentru a evita confuzia, trebuie să acorde prioritate lucrării în funcție de cerințe.
Să ne oprim o clipă și să ne punem câteva întrebări:
- Care este cultura companiei mele acum?
- Cât de bine se aliniază această cultură cu obiectivele mele de afaceri sau cu KRA-urile?
- La ce probleme mă pot aștepta din cauza nealinierii?
Pentru fiecare organizație, 4C joacă un rol vital
Acum, să analizăm cultura unei organizații care dezvoltă software. Există multe echipe implicate pentru construirea și întreținerea unei singure unități software. Toate aceste echipe au obiective și cultură separate.
diferența dintre mutabil și imuabil
Acest proces începe după ce cerințele au fost confirmate de client.
Dezvoltatorii respectă liniile directoare de codificare definite de organizația lor și instrumentele de programare precum compilatoarele, interpreții, depanatorii etc. sunt folosiți pentru a genera codul. Diferite limbaje de programare la nivel înalt, cum ar fi C, C ++, Pascal, Java și PHP sunt utilizate pentru codare.
Împart pachetul complet în foldere mici și apoi dezvoltă coduri mici în consecință.
Etapa 1 : Aceste unități mici de coduri sunt apoi împânzite pentru a forma o unitate mare. În timp ce se integrează cipurile mai mici, trebuie efectuată o testare la nivel de proiect cunoscută sub numele de testare de integrare.
Etapa 2 : După integrarea cu succes, este implementată într-un sistem fals. Acest sistem fictiv are o configurație similară cu cea a mașinii client sau a mașinii în care acest proiect trebuie să fie implementat în cele din urmă.
Etapa 3 : În cele din urmă, după testarea tuturor caracteristicilor dintr-un sistem fictiv, proiectul este implementat pe serverul de producție sau pe mașina client.
Deși acest proces pare a fi foarte lin și ușor în cuvinte, în termeni tehnici este foarte greu de realizat.
Să vedem cu ce probleme ne-am putea confrunta:
Etapa 1 :
Clientul este mereu în căutare de modificări pentru a îmbunătăți calitatea produsului. De cele mai multe ori când s-a făcut prima iterație, clientul va sugera câteva modificări. Când dezvoltatorii primesc modificările, încep să le încorporeze, ceea ce influențează integrarea, ducând la versiuni defecte.
Etapa 2:
De cele mai multe ori, testerii sau alte tipuri de operațiuni nu vor fi la curent cu noile modificări care trebuie făcute. De îndată ce primesc codul de la dezvoltatori, încep să le testeze. În timp ce în back-end, dezvoltatorii încă fac modificările.
Deoarece nu primesc suficient timp pentru a implementa noi modificări, ajung să dezvolte coduri ineficiente cu care se confruntă cu alte probleme de rețea și baze de date, ceea ce întârzie din nou timpul de livrare.
Când în cele din urmă livrează codurile către echipa de operațiuni, li se lasă un timp foarte mic pentru a crea și implementa noi cazuri de testare. Așa că omite multe dintre cazurile de testare pe care le realizează mai târziu că acestea au fost de mare prioritate.
Etapa 3:
Deși practic versiunea pare să fie pregătită pentru producție, însă rezultatele sunt complet neașteptate. Construirea eșuează și apar o serie de erori.
Apoi, pentru fiecare eroare apărută, trebuie să urmărească de ce s-a produs, unde s-a produs, ce modificări trebuie făcute pentru a o depăși, vor exista modificări în codurile altora pentru a o face compatibilă cu cele anterioare. În cele din urmă, pentru toate aceste erori, trebuie generat un raport de erori.
Eșecul se datorează erorilor de sistem datorate ignoranței dezvoltatorului bazei de date în ceea ce privește eficiența codului, ignoranței testerului în numărul de cazuri de testare etc.
Deoarece clientul păstrează întotdeauna termenul limită, angajații implicați în realizarea lor se concentrează doar în versiunea finală, chiar dacă trebuie să compromită calitatea generală.
Deși aceasta pare a fi o problemă în coordonarea muncii, acesta este de fapt eșecul culturii adoptate.
Acest lucru se întâmplă din cauza dependenței mari de procesele manuale. Alergând încoace și încolo în aceeași echipă din cauza lipsei de cunoștințe din diferite domenii, lipsa accesului sau poate fi lipsa de interes crește propria noastră povară și durere.
Este timpul să fim versatili. S-ar putea fi dificil să stăpânești toate procesele implicate într-un sistem, dar putem fi șoferul tuturor, stăpânind unul dintre ele. Apoi, numai noi putem automatiza sistemul sau îl putem face suficient de inteligent pentru a recupera mai degrabă decât pentru a reveni.
Acum, s-ar putea să te gândești de ce?
Pentru că cel pe care îl stăpânești este foarte dependent de ceilalți. Deci, pentru a cunoaște punctul de dependență, trebuie să înțelegem întregul sistem.
Deci, să ne gândim la un proces de schimbare a culturii. Înainte de asta, aveți răspunsul la întrebările de mai jos?
- Unde eșuează cultura ta actuală?
- De ce doriți să schimbați procesul?
- Ați identificat în mod clar toate modificările necesare?
- Ați obținut feedback și buy-in de la toți acționarii afectați?
- Ați revalidat disciplina procesului, datele și sistemul de măsurare pentru schimbare?
Deci, acum, când avem răspunsul la toate, ne gândim la o revoluție în sistemul nostru. Cum va avea loc această revoluție? Se poate realiza numai atunci când ucidem ceea ce suntem acum. Se pierde mult timp în migrarea codului între echipe. Trebuie să aducem procesul acolo unde putem face integrare continuă și implementare continuă.
Acest proces de integrare și implementare continuă îl face mai agil. Aducerea acestei agilități este considerată a fi cultura DevOps.
DevOps este practica inginerilor de operațiuni și dezvoltare care participă împreună la întregul ciclu de viață al serviciului, de la proiectare prin procesul de dezvoltare până la suportul de producție.
Nu este ușor să schimbi sistemul de lucru în timp. Efectuarea unei tranziții de succes este mai degrabă renovarea sistemului, decât reconstruirea.
ce este indexof în javascript
Acum să vedem cum putem realiza acest lucru. Pot exista două modalități de abordare.
1) De sus în jos
2) De jos în sus
Afundându-ne mai adânc în aceste tehnici, vom realiza care este cea mai potrivită pentru organizația noastră.
În abordarea de sus în jos, putem merge la conducerea superioară și le putem cere schimbări în toate echipele. Dacă conducerea este convinsă, putem începe să lucrăm la asta.
Dar probabilitatea de a obține răspunsul ca „NU” este destul de mare. Acest lucru se datorează faptului că schimbarea sistemului poate duce organizația la instabilitate.
Trebuie să analizeze structura organizației, veniturile, nivelul de interes al clientului etc. Dar cel mai important factor care îi îndepărtează de la ieșirea din vechiul sistem este că nu pot vedea imagine de ansamblu a ceea ce poate fi realizat și cât de ușor poate fi realizat cu cel mai nou.
În acest caz, putem căuta a doua abordare pentru a obține această imagine de ansamblu.
Abordarea de jos în sus necesită voluntariat. Aici trebuie să luăm o echipă mică și o sarcină mică și să o executăm în modelul DevOps.
Privind în partea tehnică a acestui model, avem diverse seturi de instrumente sofisticate care fac munca mai eficientă și mai rapidă. Dar, instrumentele singure nu sunt suficient de capabile să creeze un mediu de colaborare denumit DevOps.
Crearea unui astfel de mediu necesită să vă gândiți de la cutie, de ex. evaluarea și realinierea modului în care oamenii gândesc despre echipele lor, afacerea și clienții.
Reunirea unui nou set de instrumente este mai simplă decât schimbarea culturii organizaționale. Promovând dezvoltatorii master anti-sociali, permițând integrarea codului ineficient, implementarea codurilor care nu au fost testate corect, punerea vina pe capul celuilalt, considerând că echipa de operațiuni este o prostie nu sunt cele mai bune practici pe care le urmăm pentru a permite afacerea și creează valoare pentru clienții noștri.
Nu instrumentele, ci oamenii care le folosesc fac procesul complex. A spune la un nivel abstract, mai degrabă decât a colecta idei și comportamente, a fi deschis față de ele ne duce pe o cale luminoasă.
Să începem cu o echipă formată din 6 membri și o poveste în 3 puncte. În primul rând, trebuie să spargem echipa pe care o numim ca dezvoltatori, operațiuni, testere etc. Le considerăm pe toate ca una, spunem „DevOps”. Când primim cerințele, trebuie să analizăm zonele de risc. Ținând cont de secțiunile mai adânci ale mării și hellip .. Începem să navigăm.
Acum, trebuie să vă gândiți „care este factorul x al acestor integrări continue și implementări continue care scad probabilitatea de eșec”.
Cu o viziune și un proces îmbunătățit, putem aborda managementul prezentând o imagine clară a rezultatelor, cum ar fi cât de lin a fost procesul, cum a fost redus riscul de eșec, cum a fost finalizată sarcina înainte de termen, etc.
Acum, putem vizualiza clar modul în care întregul proces a fost optimizat din punct de vedere tehnic și cultural, având o retrospecție după fiecare iterație.
Edureka a fost special curatată care te ajută să stăpânești concepte despre Puppet, Jenkins, Ansible, SaltStack, Chef printre altele.
Ai o întrebare pentru noi? Menționați-le în secțiunea de comentarii și vă vom răspunde.
cum se creează o serie de obiecte în java
Postări asemănatoare: