Kultur ignoreras ofta och missförstås, men det är en nyckelfaktor som är ansvarig för företagets resultat. Om vi inte hanterar vår kultur kommer vi att göra fel praxis som i slutändan kommer att påverka våra affärsmål.
Förstå en organisations nuvarande kultur
Kultur berättar om värderingar och normer inom en grupp eller ett företag. Den identifierar vad som är viktigt och hur människor närmar sig och arbetar med varandra.
föränderliga och oföränderliga föremål i java
KULTUR = “Hur saker kan göras smart för framgång”
Låt oss ta exemplet på ett kundsupportteam. Det teamets kultur bör vara sådan att de slutar uppnå 97-98% av kundnöjdheten.
Med tanke på kundglädje måste de först vara artiga, även i svåra situationer måste de vara bra lyssnare för att undvika förvirring, de behöver prioritera arbetet enligt krav.
Låt oss pausa ett ögonblick och ställa några frågor till oss själva:
- Vad är kulturen i mitt företag nu?
- Hur väl är den här kulturen i linje med mina affärsmål eller KRA?
- Vilka problem kan jag förvänta mig på grund av feljustering?
För varje organisation spelar 4C: erna en viktig roll
Låt oss nu titta på kulturen i en programvara som utvecklar organisationen. Det finns många team involverade för att bygga och underhålla en enda mjukvaruenhet. Alla dessa lag har separata mål och separat kultur.
Denna process startar efter att kraven har bekräftats av klienten.
Utvecklare följer kodningsriktlinjerna som definieras av deras organisation och programmeringsverktyg som kompilatorer, tolkar, avlusare etc. används för att generera koden. Olika högnivåprogrammeringsspråk som C, C ++, Pascal, Java och PHP används för kodning.
De delar upp hela paketet i små mappar och utvecklar sedan små koder därefter.
Steg 1 : Dessa små kodenheter klubbas sedan för att bilda en stor enhet. Samtidigt som de mindre chipsen integreras måste en testning på projektnivå utföras, så kallad integrationstest.
Steg 2 : Efter den lyckade integrationen distribueras den i ett dummy-system. Detta dummy-system har liknande konfiguration som för klientmaskinen eller maskinen där projektet äntligen måste distribueras.
Steg 3 : Slutligen, efter att ha testat alla funktioner i ett dummy-system, distribueras projektet till produktionsservern eller klientmaskinen.
Även om denna process verkar vara mycket smidig och enkel i ord, är det tekniskt mycket svårt att uppnå.
Låt oss se vilka problem vi kan möta:
Steg 1 :
Kunden letar alltid efter förändringar för att förbättra produktens kvalitet. För det mesta när den första iterationen gjordes, kommer klienten att föreslå några ändringar. När utvecklarna får ändringarna börjar de integrera dem som påverkar integrationen som leder till trasiga byggnader.
Steg 2:
För det mesta kommer testarna eller andra operationskillar inte att vara medvetna om de nya ändringarna som ska göras. Så snart de får koden från utvecklare börjar de testa dem. Medan back-end gör utvecklarna fortfarande ändringarna.
Eftersom de inte får tillräckligt med tid för att genomföra nya ändringar, slutar de utveckla ineffektiva koder som de står inför andra nätverks- och databasproblem som försenar deras leveranstid igen.
När de äntligen levererar koderna till operationsteamet har de mycket liten tid att skapa och implementera nya testfall. Så de hoppar över många testfall som de senare inser att de hade hög prioritet.
Steg 3:
Även om praktiskt taget byggnaden verkar vara redo att gå i produktion, men resultaten är helt oväntade. Byggningen misslyckas och ett antal fel uppstår.
För varje fel som inträffat måste de spåra varför det inträffade, var det inträffade, vilka ändringar som måste göras för att övervinna det. Kommer det att ändras i andras koder för att göra det kompatibelt med de tidigare. Slutligen, för alla dessa buggar, måste en bugrapport skapas.
Felet beror på systemfel på grund av databasutvecklarens okunnighet om kodens effektivitet, testarens okunnighet i antal testfall etc.
Eftersom klienten alltid håller tidsgränsen koncentreras de anställda som är involverade i att uppnå dem bara i den slutliga utgåvan även om de måste kompromissa med den övergripande kvaliteten.
Även om detta verkar vara ett problem i samordningen av arbetet, detta är faktiskt misslyckandet med den antagna kulturen.
Detta händer på grund av stort beroende av manuella processer. Att springa fram och tillbaka i samma team på grund av bristande kunskap om olika fältbrist eller tillgångsbrist ökar vår egen börda och smärta.
skapa en parameter i tablå
Det är hög tid att vi måste vara mångsidiga. Det kan vara svårt att bemästra alla processer som är inblandade i ett system, men vi kan vara jacken för alla och bemästra en bland dem. Då bara vi kan automatisera vårt system eller göra det tillräckligt intelligent för att återhämta sig snarare än återgång.
Nu kanske du funderar på varför?
Det beror på att den du behärskar är mycket beroende av andra. Så för att veta om beroendepunkten måste vi förstå hela systemet.
Så låt oss tänka på en process för att förändra kulturen. Innan det har du svaret på frågorna nedan?
- Var misslyckas din nuvarande kultur?
- Varför vill du ändra processen?
- Har du tydligt identifierat alla nödvändiga ändringar?
- Har du fått feedback och inköp från alla berörda intressenter?
- Har du förnyat processen disciplin, data och mätsystem för förändringen?
Så nu när vi har svaret för alla tänker vi på en revolution i vårt system. Hur kommer denna revolution att ske? Det kan bara uppnås när vi dödar det vi är nu. Mycket tid slösas bort i migrering av kod bland lagen. Vi måste ta processen där vi kan göra kontinuerlig integration och kontinuerlig distribution.
Denna process med kontinuerlig integration och distribution gör den mer smidig. Att föra denna smidighet anses vara DevOps-kultur.
DevOps är praxis för drifts- och utvecklingsingenjörer som deltar tillsammans i hela tjänstens livscykel, från design till utvecklingsprocessen till produktionsstöd.
Det är inte lätt att ändra arbetssystemet över tiden. Att göra en framgångsrik övergång är att renovera systemet snarare än att bygga om.
Låt oss nu se hur vi kan uppnå detta. Det kan finnas två sätt att närma sig.
1) Upp och ner
2) Uppifrån och upp
När vi dyker djupare in i dessa tekniker kommer vi att inse vilka som passar bäst för vår organisation.
I uppifrån och ner-metoden kan vi gå till den högre ledningen och be dem om att göra ändringar i alla lag. Om ledningen är övertygad då kan vi börja arbeta med det.
Men sannolikheten för att få svaret som ”NEJ” är ganska hög. Det beror på att förändring av systemet kan leda organisationen till instabilitet.
De måste titta på organisationsstrukturen, intäkterna, kundens intressenivå etc. Men den viktigaste faktorn som drar dem tillbaka från att kliva ut ur det gamla systemet är att de inte kan se helhetsbild av vad som kan uppnås och hur smidigt det kan uppnås med den nyare.
java-kommando för att avsluta programmet
I det här fallet kan vi leta efter den andra metoden för att få denna stora bild.
Nedifrån och upp-metoden kräver frivilliga. Här måste vi ta ett litet team och en liten uppgift och utföra det i DevOps Model.
När vi tittar på den tekniska sidan av den här modellen har vi olika uppsättningar sofistikerade verktyg som gör arbetet mer effektivt och snabbt. Men bara verktyg är inte tillräckligt kapabla för att skapa en samarbetsmiljö som kallas DevOps.
Att skapa en sådan miljö kräver att du tänker ur lådan, t.ex. utvärdera och anpassa hur människor tänker på sina team, verksamheten och kunderna.
Att sätta ihop en ny uppsättning verktyg är enklare än att förändra organisationskulturen. Genom att främja de antisociala masterutvecklarna, låta ineffektiv kod integreras, distribuera koder som inte testades ordentligt, sätta klander på varandras huvud, med tanke på att driftsteamet är dumt är inte de bästa metoderna vi följer för att möjliggöra verksamheten och skapa värde för våra kunder.
Det är inte verktygen, det är människorna som använder dem som gör processen komplex. Att säga på en abstrakt nivå snarare än att samla idéer och beteenden, att vara öppen för dem tar oss till en ljus väg.
Låt oss börja med ett team med 6 medlemmar och en 3-punktshistoria. Först måste vi bryta teamet vi kallar som utvecklare, operationer, testare, etc. Vi betraktar dem alla som en, säger “DevOps”. När vi får kraven måste vi analysera riskzonerna. Med tanke på de djupare delarna av havet och hellip .. Vi börjar segla.
Nu måste du tänka 'vad är x-faktorn för denna kontinuerliga integration och kontinuerliga distribution som minskar sannolikheten för misslyckande'.
Med den förbättrade visionen och processen kan vi närma oss ledningen med en tydlig bild av resultaten som hur smidig processen var, hur risken för misslyckande minskades, hur uppgiften slutfördes före tidslinjen etc.
Nu kan vi tydligt visualisera hur hela processen optimerades på teknisk och kulturell grund genom att ha retrospektion efter varje iteration.
Edureka har special curated som hjälper dig att behärska koncept bland bland annat Puppet, Jenkins, Ansible, SaltStack, Chef.
Har du en fråga till oss? Nämn dem i kommentarfältet så återkommer vi till dig.
Relaterade inlägg: