Kultura je pogosto prezrta in napačno razumljena, kljub temu pa je ključni dejavnik, ki je odgovoren za uspešnost podjetja. Če ne bomo upravljali s svojo kulturo, bomo na koncu delali napačne prakse, ki bodo na koncu vplivale na naše poslovne cilje.
Razumevanje trenutne kulture organizacije
Kultura nam govori o vrednotah in normativih znotraj skupine ali podjetja. Ugotavlja, kaj je pomembno, pa tudi, kako ljudje pristopajo in delajo drug z drugim.
KULTURA = 'Kako lahko stvari pametno naredimo za uspeh'
Vzemimo za primer skupino za podporo strankam. Kultura te ekipe bi morala biti takšna, da na koncu doseže 97-98% zadovoljstva strank.
kaj je paket v javi
Upoštevajoč zadovoljstvo strank, najprej morajo biti vljudni, tudi v težkih situacijah morajo biti dobri poslušalci, da se izognejo zmedi, da bi morali prednostno delo razvrstiti glede na zahteve.
Za trenutek se ustavimo in si zastavimo nekaj vprašanj:
- Kakšna je kultura mojega podjetja zdaj?
- Kako dobro je ta kultura usklajena z mojimi poslovnimi cilji ali KRA-ji?
- Katere težave lahko pričakujem zaradi neusklajenosti?
Za vsako organizacijo imajo 4C ključno vlogo
Zdaj pa poglejmo kulturo organizacije, ki razvija programsko opremo. Za izdelavo in vzdrževanje ene same programske enote sodeluje veliko skupin. Vse te ekipe imajo ločene cilje in ločeno kulturo.
Ta postopek se začne po potrditvi zahtev s strani stranke.
Razvijalci sledijo smernicam kodiranja, ki jih določa njihova organizacija, za ustvarjanje kode pa se uporabljajo programska orodja, kot so prevajalniki, tolmači, razhroščevalniki itd. Za kodiranje se uporabljajo različni programski jeziki na visoki ravni, kot so C, C ++, Pascal, Java in PHP.
Celoten paket razdelijo v majhne mape in nato razvijejo majhne kode.
1. stopnja : Te majhne enote kod se nato udarijo v veliko enoto. Med integracijo manjših čipov je treba izvesti testiranje na ravni projekta, znano kot integracijsko testiranje.
2. stopnja : Po uspešni integraciji se uvede v lažni sistem. Ta navidezni sistem ima podobno konfiguracijo kot odjemalski stroj ali stroj, kjer je treba ta projekt dokončno razviti.
3. stopnja : Na koncu se po preizkusu vseh funkcij v navideznem sistemu projekt uvede v produkcijski strežnik ali odjemalski stroj.
Čeprav se zdi, da je ta postopek zelo gladek in preprost z besedami, ga je v tehničnem smislu zelo težko doseči.
Poglejmo, s katerimi težavami bi se lahko soočili:
1. stopnja :
Naročnik je vedno v iskanju sprememb za izboljšanje kakovosti izdelka. Večino časa, ko je bila izvedena prva ponovitev, bo stranka predlagala nekaj sprememb. Ko razvijalci prejmejo spremembe, jih začnejo vključevati, kar vpliva na integracijo, ki vodi do pokvarjenih zgradb.
2. stopnja:
Preizkuševalci ali drugi operaterji večinoma ne bodo seznanjeni z novimi spremembami. Takoj ko dobijo kodo od razvijalcev, jo začnejo testirati. Medtem ko na zadnji strani razvijalci še vedno spreminjajo.
Ker ne dobijo dovolj časa za izvedbo novih sprememb, na koncu razvijejo neučinkovite kode, s katerimi se soočajo z drugimi težavami z omrežjem in bazami podatkov, kar spet zamuja s časom dostave.
Ko končno dostavijo kode operativni skupini, jim ostane zelo malo časa za ustvarjanje in izvajanje novih testnih primerov. Tako preskočijo številne testne primere, za katere so kasneje ugotovili, da so bili zelo pomembni.
def __init__ python
Faza 3:
Čeprav se zdi, da je praktično gradnja pripravljena za proizvodnjo, vendar so rezultati povsem nepričakovani. Gradnja ne uspe in se pojavijo številne napake.
Potem morajo za vsako napako slediti, zakaj se je zgodila, kje se je zgodila, katere spremembe je treba narediti, da bi jo odpravili, ali se bodo spremenile kode drugih, da bodo združljive s prejšnjimi. Za vse te napake je treba ustvariti poročilo o napakah.
Napaka je posledica sistemskih napak zaradi nevednosti razvijalca baze podatkov glede učinkovitosti kode, neznanja preizkuševalca v številu testnih primerov itd.
Ker stranka vedno drži rok natančno, se zaposleni, ki sodelujejo pri njihovem doseganju, skoncentrirajo le v končni izdaji, tudi če morajo ogroziti splošno kakovost.
Čeprav se zdi, da je to težava pri usklajevanju dela, to je pravzaprav neuspeh sprejete kulture.
To se zgodi zaradi velike odvisnosti od ročnih procesov. Tek v isti ekipi zaradi neznanja različnih področij, pomanjkanja dostopa ali pomanjkanja zanimanja povečuje lastno breme in bolečino.
Skrajni čas je, da moramo biti vsestranski. Morda je težko obvladati vse procese, ki sodelujejo v sistemu, vendar smo lahko vsi, ki obvladujemo enega izmed njih. Takrat lahko samo svoj sistem avtomatiziramo ali naredimo dovolj inteligentnega, da se lahko povrne, namesto da bi ga vrnili nazaj.
Zdaj morda razmišljate, zakaj?
To je zato, ker je tisti, ki ga obvladate, zelo odvisen od drugih. Da bi vedeli o odvisni točki, moramo razumeti celoten sistem.
Zato si omislimo postopek za spremembo kulture. Ali imate pred tem odgovor na spodnja vprašanja?
- Kje propade vaša trenutna kultura?
- Zakaj želite spremeniti postopek?
- Ste jasno opredelili vse zahtevane spremembe?
- Ste od vseh prizadetih deležnikov prejeli povratne informacije in odkup?
- Ste za spremembo ponovno potrdili procesno disciplino, podatke in merilni sistem?
Zdaj, ko imamo odgovor na vse, pomislimo na revolucijo v našem sistemu. Kako bo potekala ta revolucija? To lahko dosežemo le, če ubijemo to, kar smo zdaj. Pri selitvi kode med ekipe zapravimo veliko časa. Vpeljati moramo postopek, kjer lahko neprestano povezujemo in neprekinjeno uvajamo.
Ta postopek nenehne integracije in uvajanja ga naredi bolj gibčnega. Prinašanje te okretnosti velja za kulturo DevOps.
DevOps je praksa operativnih in razvojnih inženirjev, ki sodelujejo v celotnem življenjskem ciklusu, od zasnove prek razvojnega procesa do podpore proizvodnji.
Sčasoma ni enostavno spremeniti delovnega sistema. Uspešen prehod je prenova sistema in ne obnova.
Zdaj pa poglejmo, kako lahko to dosežemo. Obstajata lahko dva načina za pristop.
1) Od zgoraj navzdol
2) Spodaj navzgor
Če se poglobimo v te tehnike, bomo ugotovili, katera je najprimernejša za našo organizacijo.
Pri pristopu od zgoraj navzdol se lahko obrnemo na višje vodstvo in jih prosimo za spremembe v vseh ekipah. Če je takrat vodstvo prepričano, lahko začnemo delati na tem.
Toda verjetnost, da boste dobili odgovor z 'NE', je precej velika. To je zato, ker lahko sprememba sistema pripelje organizacijo do nestabilnosti.
Preučiti morajo strukturo organizacije, prihodke, stopnjo zanimanja stranke itd. Toda najpomembnejši dejavnik, ki jih potegne nazaj iz starega sistema, je, da ne vidijo velika slika o tem, kaj je mogoče doseči in kako gladko je mogoče doseči z novejšim.
V tem primeru lahko poiščemo drugi pristop, da dobimo to veliko sliko.
Pristop od spodaj navzgor zahteva prostovoljce. Tu moramo vzeti majhno ekipo in majhno nalogo ter jo izvesti v modelu DevOps.
Če pogledamo tehnično plat tega modela, imamo nabor dovršenih orodij, ki omogočajo delo bolj učinkovito in hitro. Toda samo orodja niso dovolj sposobna ustvariti sodelovalnega okolja, imenovanega DevOps.
Ustvarjanje takšnega okolja od vas zahteva, da razmišljate nenavadno npr. ocenjevanje in preoblikovanje, kako ljudje razmišljajo o svojih skupinah, podjetju in kupcih.
Sestavljanje novega nabora orodij je preprostejše kot spreminjanje organizacijske kulture. S spodbujanjem razvijalcev protisocialnih mojstrov, omogočanjem integracije neučinkovite kode, uvajanjem kod, ki niso bile pravilno preizkušene, postavljanjem krivde drug drugemu na glavo, če ocenjujemo, da je operativna skupina neumna, niso najboljše prakse, ki jim sledimo za omogočanje poslovanja in ustvariti vrednost za naše stranke.
Proces ni zapleten zaradi orodij, temveč zaradi ljudi, ki jih uporabljajo. Če rečemo na abstraktni ravni, ne pa da zbiramo ideje in vedenja, nas odprtje vodi do svetle poti.
Začnimo z ekipo s 6 člani in zgodbo s tremi točkami. Najprej moramo razbiti ekipo, ki jo imenujemo razvijalci, operaterji, preizkuševalci itd. Vse imamo za eno, recimo »DevOps«. Ko prejmemo zahteve, moramo analizirati območja tveganja. Upoštevajoč globlje odseke morja in hellip .. Začnemo jadrati.
Zdaj morate razmišljati, 'kaj je faktor x te nenehne integracije in neprekinjene uporabe, ki zmanjša verjetnost okvare'.
java scanner dobil naslednji char -
Z izboljšano vizijo in postopkom lahko pristopimo k vodstvu in mu damo jasno sliko rezultatov, na primer kako gladko je potekal postopek, kako se je zmanjšalo tveganje za neuspeh, kako je bila naloga zaključena pred časovno premico itd.
Zdaj si lahko jasno predstavljamo, kako je bil celoten postopek optimiziran na tehničnem in kulturnem terenu, tako da imamo retrospekcijo po vsaki ponovitvi.
Edureka je posebej kurator ki vam pomaga obvladati koncepte med drugim Lutka, Jenkins, Ansible, SaltStack, Chef.
Imate vprašanje za nas? Omenite jih v oddelku za komentarje in javili se vam bomo.
Sorodne objave: