A kultúrát gyakran figyelmen kívül hagyják és félreértik, mégis kulcsfontosságú tényező a vállalat teljesítményéért. Ha nem kezeljük kultúránkat, akkor rossz gyakorlatokat fogunk végezni, amelyek végső soron befolyásolják üzleti céljainkat.
A szervezet jelenlegi kultúrájának megértése
A kultúra mesél nekünk egy csoporton vagy cégen belüli értékekről és normákról. Meghatározza a fontosakat, valamint azt, hogy az emberek hogyan viszonyulnak egymáshoz és működnek együtt.
KULTÚRA = 'Hogyan lehet okosan megoldani a dolgokat a siker érdekében'
Vegyünk egy ügyfélszolgálati csapat példáját. A csapat kultúrájának olyannak kell lennie, hogy végül az ügyfelek elégedettségének 97-98% -át érjék el.
Figyelembe véve a vásárló örömét, mindenekelőtt udvariasaknak kell lenniük, nehéz helyzetben is jó hallgatóknak kell lenniük, hogy elkerüljék a zavart, és a munkát a követelményeknek megfelelően kell előtérbe helyezniük.
Álljunk meg egy pillanatra, és tegyünk fel magunknak néhány kérdést:
- Mi a vállalatom kultúrája most?
- Mennyire illeszkedik ez a kultúra üzleti céljaimhoz vagy KRA-mhoz?
- Milyen problémákra számíthatok az eltérés miatt?
Minden szervezet számára a 4C-k létfontosságú szerepet játszanak
Most nézzük meg egy szoftverfejlesztő szervezet kultúráját. Sok csapat vesz részt egyetlen szoftveregység felépítésében és karbantartásában. Mindezeknek a csapatoknak külön céljaik és kultúrájuk van.
Ez a folyamat azután kezdődik, hogy az ügyfél megerősítette a követelményeket.
A fejlesztők a szervezetük által meghatározott kódolási irányelveket követik, és programozási eszközöket, például fordítókat, tolmácsokat, hibakeresőket stb. Használnak a kód létrehozására. Különböző magas szintű programozási nyelveket, például C, C ++, Pascal, Java és PHP használnak kódoláshoz.
Felosztják a teljes csomagot kis mappákra, majd ennek megfelelően kis kódokat fejlesztenek ki.
1. szakasz : Ezeket a kis kódegységeket aztán összedobják, hogy egy nagy egységet alkossanak. A kisebb chipek integrálása közben projektszintű tesztelést kell végrehajtani, amelyet integrációs tesztnek nevezünk.
2. szakasz : A sikeres integráció után egy dummy rendszerbe telepítik. Ez a próbabábu rendszere hasonló konfigurációval rendelkezik, mint az ügyfélgép vagy annak a gépnek a konfigurációja, ahol ezt a projektet végre kell telepíteni.
3. szakasz : Végül a próbabábu rendszer összes funkciójának tesztelése után a projekt telepítésre kerül a termelési kiszolgálóra vagy az ügyfélgépre.
Bár ez a folyamat szavak szerint nagyon gördülékeny és könnyű, technikai szempontból nagyon nehéz megvalósítani.
Nézzük meg, milyen problémákkal szembesülhetünk:
mi a szkenner osztály java-ban
1. szakasz :
Az ügyfél mindig változásokat keres, hogy javítsa a termék minőségét. Az első iteráció legtöbbször az ügyfél javasol néhány módosítást. Amikor a fejlesztők megkapják a változásokat, elkezdik beépíteni őket, ami kihat az összetört építéshez vezető integrációra.
2. szakasz:
Legtöbbször a tesztelők vagy más operációs srácok nem lesznek tisztában az új változtatásokkal. Amint megkapják a kódot a fejlesztőktől, elkezdik tesztelni őket. Míg a háttérben a fejlesztők még mindig változtatnak.
Mivel nem kapnak elegendő időt az új változások végrehajtására, végül nem hatékony kódokat fejlesztenek ki, más hálózati és adatbázis-problémákkal szembesülve, amelyek ismét késleltetik a kézbesítés idejét.
Amikor végül átadják a kódokat az operációs csapatnak, nagyon minimális idő áll rendelkezésükre új tesztesetek létrehozására és végrehajtására. Tehát kihagynak sok olyan tesztesetet, amelyekről később rájönnek, hogy ezek kiemelt fontosságúak voltak.
3. szakasz:
Bár úgy tűnik, hogy az összeállítás gyakorlatilag készen áll a gyártásra, de az eredmények teljesen váratlanok. Az összeállítás meghiúsul, és számos hiba fordul elő.
Ezután minden hiba után nyomon kell követni, hogy ez miért, hol történt, milyen változtatásokat kell végrehajtani a legyőzéséhez, változnak-e mások kódjai, hogy kompatibilisek legyenek az előzőekkel. Végül, ezekhez a hibákhoz hibajelentést kell készíteni.
A meghibásodás oka az adatbázis-fejlesztő tudatlansága a kód hatékonyságában, a tesztelő tudatlansága a tesztesetek száma miatt stb.
Mivel az ügyfél mindig szigorúan tartja a határidőket, az elérésükben részt vevő alkalmazottak csak akkor koncentrálnak a végső kiadásra, még akkor is, ha kompromittálniuk kell az általános minőséget.
hogyan lehet egy programot megszüntetni a java-ban
Bár ez problémának tűnik a munka összehangolásában, ez tulajdonképpen az elfogadott kultúra kudarca.
Ez a kézi folyamatoktól való nagy függőség miatt következik be. Ha ugyanabban a csapatban futunk ide-oda, a különböző területek ismeretének hiánya vagy az érdeklődés hiánya miatt megnő a saját terheink és fájdalmaink.
Itt az ideje, hogy sokoldalúak legyünk. Nehéz lehet elsajátítani a rendszerben részt vevő összes folyamatot, de lehetünk mindennek a főnöke, elsajátítva egyet közülük. Akkor csak mi automatizálhatjuk a rendszert, vagy elég intelligenssé tehetjük a helyreállításhoz, nem pedig a visszaállításhoz.
Most arra gondolhat, miért?
Ez azért van, mert az, akit sajátítasz el, nagymértékben függ másoktól. Tehát a függőségi pont megismeréséhez meg kell értenünk az egész rendszert.
Gondoljunk tehát a kultúra megváltoztatásának folyamatára. Előtte megvan a válasz az alábbi kérdésekre?
- Hol bukik meg a jelenlegi kultúrád?
- Miért akarja megváltoztatni a folyamatot?
- Világosan azonosította az összes szükséges változtatást?
- Kapott visszajelzést és felvásárlást az összes érintett érdekeltől?
- Meghosszabbította a változás fegyelmét, adatait és mérőrendszerét?
Tehát, amikor mindenre megvan a válasz, a rendszerünk forradalmára gondolunk. Hogyan fog lezajlani ez a forradalom? Csak akkor érhető el, ha megöljük azt, ami most vagyunk. Nagyon sok időt pazarol a kódok migrációja a csapatok között. Meg kell hoznunk a folyamatot, ahol folyamatos integrációt és folyamatos telepítést tudunk végezni.
Ez a folyamatos integráció és telepítés folyamata agilisabbá teszi. Ennek a mozgékonyságnak a megvalósítását DevOps-kultúrának tekintjük.
A DevOps az a művelet és fejlesztési mérnök gyakorlata, amely együttesen vesz részt a szolgáltatás teljes életciklusában, a tervezéstől a fejlesztési folyamaton át a gyártás támogatásáig.
Nem könnyű az idő múlásával megváltoztatni a működő rendszert. A sikeres átmenet a rendszer felújítása, nem pedig újjáépítése.
Most nézzük meg, hogyan érhetjük el ezt. Kétféleképpen lehet megközelíteni.
1) Felülről lefelé
__init__ a pythonban
2) Alulról felfelé
Mélyebben belemerülve ezekbe a technikákba rájövünk, hogy melyik a legalkalmasabb a szervezetünk számára.
A fentről lefelé irányuló megközelítésben elmehetünk a felső vezetéshez és megkérhetjük őket, hogy végezzenek változtatásokat az összes csapatban. Ha a vezetőség meg van győződve róla, elkezdhetjük a munkát.
De annak a valószínűsége, hogy a választ „NEM” -ként kapják, meglehetősen nagy. Ez azért van, mert a rendszer megváltoztatása instabilitáshoz vezetheti a szervezetet.
Meg kell vizsgálniuk a szervezeti struktúrát, a bevételeket, az ügyfelek érdeklődésének szintjét, stb. De a legfontosabb tényező, amely visszahúzza őket a régi rendszerből való kimozduláshoz, az, hogy nem látják a nagy kép arról, hogy mit lehet elérni és milyen simán lehet elérni az újabbal.
Ebben az esetben megkereshetjük a második megközelítést ennek a nagy képnek a megszerzéséhez.
Az alulról felfelé építkező megközelítés önkéntes munkát igényel. Itt egy kis csapatot és egy kis feladatot kell elvégeznünk, amelyet a DevOps Model-ben kell végrehajtanunk.
A modell technikai oldalát megvizsgálva számos kifinomult eszköz áll rendelkezésre, amelyek hatékonyabbá és gyorsabbá teszik a munkát. De az eszközök önmagukban nem elégségesek a DevOps néven emlegetett együttműködési környezet létrehozására.
Egy ilyen környezet létrehozásához meg kell gondolni a dobozból pl. annak értékelése és átalakítása, hogy az emberek hogyan gondolkodnak a csapataikról, az üzletükről és az ügyfelekről.
Egy új eszközkészlet összeállítása egyszerűbb, mint a szervezeti kultúra megváltoztatása. Az antiszociális mesterfejlesztők népszerűsítésével, a nem hatékony kódok integrálásának lehetővé tételével, a nem megfelelően tesztelt kódok telepítésével, egymás felelősségre vonásával, az operatív csapat hülyeségének tekintésével nem a legjobb gyakorlat, amelyet követünk az üzleti élet lehetővé tételéhez és értéket teremtsenek ügyfeleink számára.
Nem az eszközök, hanem az azokat használó emberek teszik bonyolulttá a folyamatot. Absztrakt szinten mondani, nem pedig ötleteket és magatartást gyűjteni, ha nyitottak vagyunk rájuk, világos útra vezetünk.
Kezdjük egy 6 tagú csapattal és egy 3 pontos történettel. Először is meg kell bontanunk azt a csapatot, amelyet fejlesztőként, műveletekként, tesztelőként stb. Hívunk. Mindegyiket egynek tekintjük, mondjuk „DevOps”. Amikor megkapjuk a követelményeket, elemeznünk kell a kockázat zónáit. Szem előtt tartva a tenger mélyebb szakaszait & hellip .. Vitorlázni kezdünk.
Most arra kell gondolnia, hogy „mi ennek a folyamatos integrációnak és folyamatos telepítésnek az x-tényezője, amely csökkenti a kudarc valószínűségét”.
A továbbfejlesztett jövőkép és folyamat segítségével megközelíthetjük a menedzsmentet, így tiszta képet kapunk az eredményekről, például arról, hogy mennyire volt gördülékeny a folyamat, hogyan csökkenthető a kudarc kockázata, hogyan teljesült a feladat az idővonal előtt, stb.
Most már egyértelműen szemléltethetjük, hogyan optimalizálták az egész folyamatot technikai és kulturális alapokon azáltal, hogy minden egyes iteráció után visszatekintést végeztünk.
Edureka speciálisan kurátora Ez segít elsajátítani többek között a Báb, a Jenkins, az Ansible, a SaltStack, a Chef körüli koncepciókat.
Van egy kérdésünk? Említse meg őket a megjegyzések részben, és mi kapcsolatba lépünk Önnel.
Kapcsolódó hozzászólások: