Kultur ignoreres ofte og misforstås, men alligevel er det en nøglefaktor, der er ansvarlig for en virksomheds præstationer. Hvis vi ikke forvalter vores kultur, ender vi med at foretage forkerte fremgangsmåder, som i sidste ende vil påvirke vores forretningsmål.
Forståelse af en organisations nuværende kultur
Kultur fortæller os om værdier og normer inden for en gruppe eller virksomhed. Det identificerer hvad der er vigtigt såvel som hvordan folk nærmer sig og arbejder sammen.
KULTUR = “Hvordan ting kan gøres smart for succes”
Lad os tage eksemplet med et kundesupportteam. Teamets kultur skal være sådan, at de ender med at nå 97-98% af kundetilfredsheden.
Når kunderne glæder sig, skal de først og fremmest være høflige, selv i vanskelige situationer skal de være gode lyttere for at undgå forvirring, de har brug for at prioritere arbejdet efter krav.
Lad os pause et øjeblik og stille et par spørgsmål til os selv:
skabe en række objekter
- Hvad er kulturen i mit firma nu?
- Hvor godt er denne kultur i overensstemmelse med mine forretningsmål eller KRA'er?
- Hvilke problemer kan jeg forvente på grund af forkert justering?
For hver organisation spiller 4C'erne en vigtig rolle
Lad os nu se på kulturen i en softwareudviklingsorganisation. Der er mange teams involveret i at opbygge og vedligeholde en enkelt softwareenhed. Alle disse hold har separate mål og separat kultur.
Denne proces starter, når kravene er bekræftet af klienten.
Udviklere følger kodningsretningslinjerne defineret af deres organisation og programmeringsværktøjer som compilers, tolke, debuggere osv. Bruges til at generere koden. Forskellige programmeringssprog på højt niveau som C, C ++, Pascal, Java og PHP bruges til kodning.
De deler den komplette pakke i små mapper og udvikler derefter små koder i overensstemmelse hermed.
Scene 1 : Disse små enheder af koder er derefter sammenkoblet for at danne en stor enhed. Mens de mindre chips integreres, skal der udføres en test på projektniveau kendt som integrationstest.
Trin 2 : Efter den vellykkede integration implementeres den i et dummy-system. Dette dummy-system har samme konfiguration som klientmaskinen eller den maskine, hvor dette projekt endelig skal implementeres.
Trin 3 : Endelig, efter at have testet alle funktionerne i et dummy-system, implementeres projektet i produktionsserveren eller klientmaskinen.
Selvom denne proces synes at være meget glat og let med ord, er den teknisk set meget vanskelig at opnå.
Lad os se, hvilke problemer vi måske står over for:
Scene 1 :
Kunden er altid på udkig efter ændringer for at forbedre produktets kvalitet. Det meste af tiden, da den første iteration blev udført, vil klienten foreslå et par ændringer. Når udviklerne modtager ændringerne, begynder de at inkorporere dem, hvilket påvirker integrationen, der fører til brudte builds.
Trin 2:
Det meste af tiden vil testere eller andre operationer ikke være opmærksomme på de nye ændringer, der skal foretages. Så snart de får koden fra udviklere, begynder de at teste dem. Mens de er i back-end, foretager udviklerne stadig ændringerne.
Da de ikke får nok tid til at implementere nye ændringer, ender de med at udvikle ineffektive koder, de står over for andre netværks- og databaseproblemer, hvilket igen forsinker deres leveringstid.
Når de endelig leverer koderne til operationsteamet, har de meget minimal tid til at oprette og implementere nye testsager. Så de springer over mange af testsagerne, som de senere indser, at de havde høj prioritet.
Trin 3:
Skønt stort set byggeriet ser ud til at være klar til produktion, men resultaterne er helt uventede. Bygningen mislykkes, og der opstår et antal fejl.
db-browser til sqlite-gennemgang
Så for hver fejl opstod, skal de spore, hvorfor det opstod, hvor det opstod, hvilke ændringer der skal gøres for at overvinde det, vil der være ændringer i andres koder for at gøre det kompatibelt med de foregående. Endelig skal der genereres en fejlrapport for alle disse fejl.
Fejlen skyldes systemfejl på grund af databaseudviklerens uvidenhed om kodeeffektivitet, testers uvidenhed i antal testsager osv.
Da klienten altid holder tidsfristen, koncentrerer de ansatte, der er involveret i at opnå dem, kun i den endelige frigivelse, selvom de skal gå på kompromis med den overordnede kvalitet.
Selvom dette ser ud til at være et problem i koordineringen af arbejdet, dette er faktisk fiaskoen i den vedtagne kultur.
Dette sker på grund af stor afhængighed af manuelle processer. At løbe frem og tilbage i det samme hold på grund af manglende viden om forskellige felt manglende adgang eller måske manglende interesse øger vores egen byrde og smerte.
Det er på høje tid, at vi skal være alsidige. Det kan være svært at være mestrer over alle processer, der er involveret i et system, men vi kan være jack of all og beherske en blandt dem. Så er det kun vi, der kan automatisere vores system eller gøre det intelligent nok til at komme sig i stedet for tilbageførsler.
Nu tænker du måske hvorfor?
Det skyldes, at den, du mestrer, er meget afhængig af andre. Så for at vide om afhængighedspunktet er vi nødt til at forstå hele systemet.
Så lad os tænke på en proces til at ændre kulturen. Før det har du svaret på nedenstående spørgsmål?
- Hvor fejler din nuværende kultur?
- Hvorfor ønsker du at ændre processen?
- Har du klart identificeret alle de nødvendige ændringer?
- Har du fået feedback og buy-in fra alle berørte interessenter?
- Har du fornyet procesdisciplin, data og målesystem til forandringen?
Så nu når vi har svaret på alle, tænker vi på en revolution i vores system. Hvordan vil denne revolution finde sted? Det kan kun opnås, når vi dræber det, vi er nu. En masse tid spildes i migrering af kode blandt holdene. Vi er nødt til at bringe processen, hvor vi kan udføre kontinuerlig integration og kontinuerlig implementering.
Denne proces med kontinuerlig integration og implementering gør den mere adræt. At bringe denne smidighed anses for at være DevOps-kultur.
DevOps er praksis for drifts- og udviklingsingeniører, der deltager sammen i hele servicelevecyklussen, fra design gennem udviklingsprocessen til produktionsstøtte.
Det er ikke let at ændre arbejdssystemet over tid. At gennemføre en vellykket overgang er at renovere systemet snarere end at genopbygge det.
Lad os nu se, hvordan vi kan opnå dette. Der kan være to måder at nærme sig.
1) Top til ned
2) Nederst op
databaseforbindelse i java med mysql
Når vi dyber dybere ned i disse teknikker, vil vi indse, hvilken der er bedst egnet til vores organisation.
I ovenfra og ned tilgang kan vi gå til den højere ledelse og bede dem om at foretage ændringer på tværs af alle holdene. Hvis ledelsen er overbevist om det, kan vi begynde at arbejde på det.
Men sandsynligheden for at få svaret som 'NEJ' er ret høj. Det er fordi ændring af systemet kan føre organisationen til ustabilitet.
De er nødt til at se på strukturen i organisationen, indtægterne, kundens renteniveau osv. Men den vigtigste faktor, der trækker dem tilbage fra at træde ud af det gamle system er, at de ikke kan se stort billede af, hvad der kan opnås, og hvor glat det kan opnås med den nyere.
I dette tilfælde kan vi se efter den anden tilgang til at få dette store billede.
Bottom-up-tilgangen kræver frivillig. Her er vi nødt til at tage et lille team og en lille opgave og udføre det i DevOps Model.
Når vi ser på den tekniske side af denne model, har vi forskellige sæt sofistikerede værktøjer, der gør arbejdet mere effektivt og hurtigt. Men værktøjer alene er ikke i stand til at skabe et samarbejdsmiljø kaldet DevOps.
At skabe et sådant miljø kræver, at du tænker ud af boksen, f.eks. vurdere og omlægge, hvordan folk tænker på deres teams, forretningen og kunderne.
At sammensætte et nyt sæt værktøjer er enklere end at ændre organisationskulturen. Ved at promovere de antisociale masterudviklere, lade ineffektiv kode integreres, implementere koder, der ikke blev testet korrekt, lægge skylden på hinandens hoved og betragte, at driftsteamet var dumt, er ikke den bedste praksis, vi følger for at aktivere forretningen og skabe værdi for vores kunder.
Det er ikke værktøjerne, det er de mennesker, der bruger dem, der gør processen kompleks. At sige på et abstrakt niveau snarere end at samle ideer og adfærd, når vi er åbne overfor dem, fører os til en lys vej.
Lad os starte med et team på 6 medlemmer og en 3-punkts historie. For det første er vi nødt til at bryde det team, vi kalder som udviklere, operationer, testere osv. Vi betragter dem alle som én, siger “DevOps”. Når vi modtager kravene, skal vi analysere risikozoner. Husk de dybere sektioner af havet og hellip .. Vi begynder at sejle.
Nu skal du tænke 'hvad er x-faktoren ved denne kontinuerlige integration og kontinuerlige implementering, der mindsker sandsynligheden for fiasko'.
Med den forbedrede vision og proces kan vi henvende os til ledelsen og sætte det klare billede af resultaterne, som hvor glat processen var, hvordan risikoen for fiasko blev reduceret, hvordan opgaven blev afsluttet inden tidslinjen osv.
Nu kan vi tydeligt visualisere, hvordan hele processen blev optimeret på teknisk og kulturel grund ved at have tilbagevenden efter hver iteration.
Edureka har specielt kurateret det hjælper dig med at mestre koncepter omkring Puppet, Jenkins, Ansible, SaltStack, Chef blandt andre.
Har du et spørgsmål til os? Nævn dem i kommentarfeltet, så vender vi tilbage til dig.
Relaterede indlæg: