Kultuuri ignoreeritakse ja mõistetakse sageli valesti, kuid siiski on see ettevõtte tegevuse põhitegur. Kui me ei hakka oma kultuuri haldama, teeme lõpuks valesid tavasid, mis mõjutavad lõpuks meie ärieesmärke.
Organisatsiooni praeguse kultuuri mõistmine
Kultuur räägib meile grupi või ettevõtte väärtustest ja normidest. See teeb kindlaks nii olulise kui ka selle, kuidas inimesed üksteisele lähenevad ja töötavad.
KULTUUR = 'Kuidas asju edu saavutamiseks nutikalt teha'
Võtame näiteks klienditoe meeskonna. Selle meeskonna kultuur peaks olema selline, et nad saavutaksid lõpuks 97–98% klientide rahulolust.
Pidades silmas klientide rõõmu, peavad nad kõigepealt olema viisakad, isegi keerulistes olukordades peavad nad olema head kuulajad, et vältida segadust, et nad peavad töö prioriteetseks seadma vastavalt nõudmisele.
Peatume hetkeks ja esitame endale mõned küsimused:
- Milline on minu ettevõtte kultuur praegu?
- Kui hästi on see kultuur minu ärieesmärkide või KRA-dega kooskõlas?
- Milliseid probleeme võin oodata vale joonduse tõttu?
Iga organisatsiooni jaoks on 4C-del oluline roll
Vaatame nüüd tarkvara arendava organisatsiooni kultuuri. Ühe tarkvaraüksuse ehitamiseks ja hooldamiseks on palju meeskondi. Kõigil neil meeskondadel on eraldi eesmärgid ja eraldi kultuur.
mis on java java
See protsess algab pärast seda, kui klient on nõuded kinnitanud.
Arendajad järgivad oma organisatsiooni määratletud kodeerimisjuhiseid ja koodi loomiseks kasutatakse programmeerimistööriistu, näiteks kompilaatoreid, tõlke, silureid jne. Kodeerimiseks kasutatakse erinevaid kõrgetasemelisi programmeerimiskeeli nagu C, C ++, Pascal, Java ja PHP.
Nad jagavad kogu paketi väikesteks kaustadeks ja arendavad seejärel vastavalt välja väikesed koodid.
1. etapp : Seejärel ühendatakse need väikesed koodide ühikud suureks üksuseks. Väiksemate kiipide integreerimise ajal tuleb läbi viia projekti tasemel testimine, mida nimetatakse integreerimise testimiseks.
2. etapp : Pärast edukat integreerimist juurutatakse see näivsüsteemi. Sellel mannekeenisüsteemil on sarnane konfiguratsioon kui kliendimasinal või masinal, kus see projekt tuleb lõplikult juurutada.
3. etapp : Lõpuks, pärast mannekeenisüsteemi kõigi funktsioonide testimist juurutatakse projekt tootmisserverisse või kliendiseadmesse.
Kuigi see protsess näib olevat sõnades väga sujuv ja lihtne, on seda tehnilises mõttes väga raske saavutada.
Vaatame, millised probleemid võivad meil tekkida:
1. etapp :
Klient otsib alati toote kvaliteedi parandamiseks muudatusi. Enamasti, kui esimene kordamine tehti, soovitab klient teha mõned muudatused. Kui arendajad saavad muudatused kätte, hakkavad nad neid kaasama, mis mõjutab integreerumist, mille tulemuseks on katkenud järkud.
2. etapp:
Enamasti ei ole testijad ega muud operatsioonipoisid teadlikud uutest muudatustest, mis tuleb teha. Niipea kui nad arendajatelt koodi saavad, hakkavad nad neid testima. Taustal töötavad arendajad endiselt muudatusi.
Kuna neil pole piisavalt aega uute muudatuste rakendamiseks, töötavad nad lõpuks välja ebaefektiivsed koodid, mis seisavad silmitsi muude võrgu- ja andmebaasiprobleemidega, mis viivitab jällegi nende edastamise aega.
Kui nad koodid operatsioonimeeskonnale lõpuks edastavad, jääb neile uute testijuhtumite loomiseks ja juurutamiseks väga vähe aega. Nii jätavad nad vahele paljud testjuhtumid, millest nad saavad hiljem aru, et need olid esmatähtsad.
3. etapp:
Ehkki näib, et järk-järgult on valmis tootmist alustama, on tulemused siiski täiesti ootamatud. Ehitamine ebaõnnestub ja esineb mitmeid vigu.
andmestruktuurid ja algoritmid Java-s
Seejärel peavad nad iga vea korral jälgima, miks see juhtus, kus see tekkis, milliseid muudatusi tuleb selle ületamiseks teha, kas muudetakse teiste koode, et see ühilduks eelmistega. Lõpuks tuleb kõigi nende vigade jaoks luua veateade.
Ebaõnnestumine on tingitud süsteemivigadest, mis tulenevad andmebaasi arendaja teadmatusest koodi efektiivsuses, testija teadmatusest testjuhtumite arvus jne.
Kuna klient hoiab tähtaega alati kitsas, keskenduvad nende saavutamisega seotud töötajad lõplikus versioonis ainult siis, kui nad peavad üldist kvaliteeti kahjustama.
Kuigi see näib olevat probleem töö koordineerimisel, see on tegelikult omaksvõetud kultuuri läbikukkumine.
See juhtub suure sõltuvuse tõttu manuaalsetest protsessidest. Jooksmine ühele meeskonnale edasi-tagasi, kuna puuduvad teadmised erinevast valdkonnast, puudub juurdepääs või võib olla huvi puudumine, suurendab meie endi koormust ja valu.
On viimane aeg, et peame olema mitmekülgsed. Kõigi süsteemiga seotud protsesside juhtimine võib olla keeruline, kuid me võime olla kõigi tungraud, hallata üht nende seas. Siis ainult meie saame oma süsteemi automatiseerida või muuta selle piisavalt arukaks, et taastuda, mitte tagasipöördumisi.
Nüüd võite mõelda, miks?
Sellepärast, et see, keda te valdate, sõltub suuresti teistest. Nii et sõltuvuspunkti teadmiseks peame mõistma kogu süsteemi.
Mõelgem siis kultuuri muutmise protsessile. Kas teil on enne seda vastus allolevatele küsimustele?
- Kus teie praegune kultuur ebaõnnestub?
- Miks soovite protsessi muuta?
- Kas olete kõik vajalikud muudatused selgelt tuvastanud?
- Kas olete saanud tagasisidet ja sisseostu kõigilt mõjutatud sidusrühmadelt?
- Kas olete muutmise protsessidistsipliini, andmed ja mõõtesüsteemi uuesti kinnitanud?
Niisiis, kui meil on kõigile vastus olemas, mõtleme oma süsteemi revolutsioonile. Kuidas see revolutsioon aset leiab? Seda saab saavutada ainult siis, kui tapame selle, mis me praegu oleme. Meeskondade vahelise koodi migreerimisel raisatakse palju aega. Peame viima protsessi selleni, et saaksime teha pidevat integreerimist ja pidevat juurutamist.
See pideva integreerimise ja juurutamise protsess muudab selle väledamaks. Selle väleduse toomist peetakse DevOpsi kultuuriks.
DevOps on tegevus ja arendusinsenerid, kes osalevad koos kogu teenuse elutsüklis, alates disainist kuni arendusprotsessi ja lõpetades tootmistoega.
Töösüsteemi pole aja jooksul lihtne muuta. Eduka ülemineku eesmärk on süsteemi uuendamine, mitte ümberehitamine.
Vaatame nüüd, kuidas me selle saavutame. Lähenemiseks võib olla kaks võimalust.
1) ülevalt alla
2) alt üles
Neisse tehnikatesse süvenedes saame aru, mis sobib meie organisatsioonile kõige paremini.
Ülalt alla lähenemise korral võime minna kõrgema juhtkonna juurde ja paluda neil kõigis meeskondades muudatusi teha. Kui juhtkond on siis veendunud, võime sellega tegelema hakata.
Kuid tõenäosus saada vastus “EI” on üsna suur. Seda seetõttu, et süsteemi muutmine võib viia organisatsiooni ebastabiilsuseni.
Nad peavad uurima organisatsiooni struktuuri, tulusid, kliendi huvitaset jne. Kuid kõige olulisem tegur, mis neid vanast süsteemist välja tõrjub, on see, et nad ei näe suur pilt sellest, mida on võimalik saavutada ja kui sujuvalt seda uuemaga saavutada.
Sellisel juhul võime selle suure pildi saamiseks otsida teist lähenemist.
Alt üles lähenemisviis nõuab vabatahtlikku tööd. Siin peame võtma väikese meeskonna ja väikese ülesande ning täitma selle DevOps Modelis.
Vaadates selle mudeli tehnilist külge, on meil mitmeid komplekteeritud tööriistu, mis muudavad töö tõhusamaks ja kiiremaks. Kuid tööriistad üksi ei ole piisavalt võimelised koostöökeskkonna loomiseks, mida nimetatakse DevOpsiks.
Sellise keskkonna loomine eeldab kastist välja mõtlemist nt. selle hindamine ja ümberkorraldamine, kuidas inimesed mõtlevad oma meeskondadest, ärist ja klientidest.
Uue tööriistakomplekti kokkupanek on lihtsam kui organisatsioonikultuuri muutmine. Asotsiaalsete põhiarendajate edendamine, ebaefektiivsete koodide integreerimise võimaldamine, nõuetekohaselt testimata koodide juurutamine, üksteisele süüdistuste esitamine, operatsioonimeeskonna rumalaks pidamine ei ole parimad tavad, mida järgime äri võimaldamiseks ja loovad väärtust meie klientidele.
Mitte muud tööriistad, vaid inimesed, kes neid kasutavad, muudavad protsessi keerukaks. Ideede ja käitumise kogumise asemel abstraktsel tasemel ütlemine viib neile avatud olemine helgele teele.
Alustame 6-liikmelise meeskonnaga ja 3-punktilise looga. Esiteks peame lõhkuma meeskonna, keda kutsume arendajate, operatsioonide, testijatena jne. Me peame neid kõiki üheks, ütleme 'DevOps'. Nõuete saamisel peame analüüsima riskitsoone. Pidades silmas sügavamaid sektsioone merest & hellip .. Hakkame purjetama.
Nüüd peate mõtlema, 'mis on nende pideva integreerimise ja pideva juurutamise x-tegur, mis vähendab ebaõnnestumise tõenäosust'.
Täiustatud visiooni ja protsessi abil saame läheneda juhtkonnale, pannes tulemustest selge pildi, näiteks kui sujuv oli protsess, kuidas vähendati ebaõnnestumise riski, kuidas ülesanne enne ajajoont täideti jne.
Nüüd võime selgelt visualiseerida, kuidas kogu protsessi optimeeriti tehnilisel ja kultuurilisel pinnal, tehes iga iteratsiooni järel tagasivaate.
Edureka on spetsiaalselt kureerinud mis aitab teil omandada kontseptsioone muu hulgas Nuku, Jenkinsi, Ansible'i, SaltStacki ja peakoka ümber.
Kas teil on meile küsimus? Mainige neid kommentaaride jaotises ja me võtame teiega ühendust.
mis on javas žetoon
Seonduvad postitused: