Sovint s’ignora i s’entén malament la cultura, tot i que és un factor clau responsable del rendiment d’una empresa. Si no gestionem la nostra cultura, acabarem fent pràctiques equivocades que afectaran els nostres objectius comercials.
Comprendre la cultura actual d’una organització
La cultura ens parla dels valors i normes dins d’un grup o empresa. Identifica allò que és important i també com s’acosten i treballen les persones.
CULTURA = 'Com es poden fer les coses de manera intel·ligent per tenir èxit'
Posem l’exemple d’un equip d’atenció al client. La cultura d’aquest equip ha de ser tal que acabi aconseguint el 97-98% de la satisfacció del client.
Tenint en compte el plaer del client, primer de tot han de ser educats, fins i tot en situacions difícils han de ser bons oients per evitar confusions i han de prioritzar el treball segons els requisits.
Parem un moment i fem-nos algunes preguntes:
- Quina és la cultura de la meva empresa ara?
- Quin grau d’alineació té aquesta cultura amb els meus objectius comercials o KRA?
- Quins problemes puc esperar per desalineació?
Per a totes les organitzacions, els 4C tenen un paper vital
Ara, examinem la cultura d’una organització que desenvolupa programari. Hi ha molts equips implicats en la creació i el manteniment d’una sola unitat de programari. Tots aquests equips tenen objectius i cultura separats.
diferència entre jquery i javascript
Aquest procés s'inicia després que el client hagi confirmat els requisits.
Els desenvolupadors segueixen les directrius de codificació definides per la seva organització i s’utilitzen eines de programació com ara compiladors, intèrprets, depuradors, etc. per generar el codi. Per codificar s’utilitzen diferents llenguatges de programació d’alt nivell com C, C ++, Pascal, Java i PHP.
Divideixen el paquet complet en carpetes petites i després desenvolupen codis petits en conseqüència.
Etapa 1 : Totes aquestes petites unitats de codis es formen una unitat gran. Mentre s’integren els xips més petits, s’ha de realitzar una prova a nivell de projecte coneguda com a prova d’integració.
Etapa 2 : Després de la integració reeixida, es desplega en un sistema fictici. Aquest sistema fictici té una configuració similar a la de la màquina client o de la màquina on s’ha de desplegar finalment aquest projecte.
Etapa 3 : Finalment, després de provar totes les funcions d'un sistema fictici, el projecte es desplega al servidor de producció o a la màquina client.
Tot i que aquest procés sembla ser molt senzill i senzill, en termes tècnics és molt difícil d’aconseguir.
Vegem quins problemes ens podem trobar:
Etapa 1 :
El client sempre busca canvis per millorar la qualitat del producte. La majoria de les vegades que es va fer la primera iteració, el client suggerirà alguns canvis. Quan els desenvolupadors reben els canvis, comencen a incorporar-los, cosa que afecta la integració que condueix a les construccions trencades.
Etapa 2:
La majoria de les vegades, els verificadors o altres operadors no seran conscients dels nous canvis que s’han de fer. Tan bon punt reben el codi dels desenvolupadors, comencen a provar-los. Mentre que a la part posterior, els desenvolupadors segueixen fent els canvis.
Com que no tenen prou temps per implementar nous canvis, acaben desenvolupant codis ineficients que afronten altres problemes de xarxa i de bases de dades, que de nou retarden el seu temps de lliurament.
Quan finalment lliuren els codis a l'equip d'operacions, es queda un temps mínim per crear i implementar nous casos de prova. Per tant, se salten molts dels casos de prova que més endavant s’adonen que eren d’alta prioritat.
Etapa 3:
Tot i que pràcticament la versió sembla estar preparada per a la producció, els resultats són completament inesperats. La compilació falla i es produeixen diversos errors.
Llavors, per cada error produït, han de fer un seguiment de per què s’ha produït, on s’ha produït, quins canvis s’han de fer per superar-lo, hi haurà canvis en els codis d’altres per fer-lo compatible amb els anteriors. Finalment, per a tots aquests errors, s’ha de generar un informe d’errors.
El fracàs es deu a errors del sistema a causa del desconeixement de l'eficiència del codi del desenvolupador de la base de dades, del desconeixement del nombre de casos de proves, etc.
Com que el client sempre manté els terminis ajustats, els empleats implicats en aconseguir-los només es concentren a la versió final, fins i tot si han de comprometre la qualitat general.
Tot i que sembla ser un problema en la coordinació del treball, això és realment el fracàs de la cultura adoptada.
Això passa per una gran dependència dels processos manuals. Córrer d’un costat a l’altre en el mateix equip a causa de la manca de coneixement de camps diferents, la manca d’accés o la manca d’interès augmenta la nostra pròpia càrrega i dolor.
És hora que hàgim de ser versàtils. Pot ser difícil dominar tots els processos implicats en un sistema, però podem ser el jack de tots, dominant-ne un. Aleshores, només nosaltres podem automatitzar el nostre sistema o fer-lo prou intel·ligent per recuperar-se en lloc de fer canvis.
Ara, podríeu estar pensant per què?
És perquè el que domineu depèn molt dels altres. Per tant, per conèixer el punt de dependència, hem d’entendre tot el sistema.
Pensem, doncs, en un procés per canviar la cultura. Abans teniu la resposta a les preguntes següents?
- On falla la vostra cultura actual?
- Per què voleu canviar el procés?
- Heu identificat clarament tots els canvis necessaris?
- Heu obtingut comentaris i accions de totes les parts interessades afectades?
- Heu revalidat la disciplina del procés, les dades i el sistema de mesura del canvi?
Per tant, ara, quan tenim la resposta a tots, pensem en una revolució en el nostre sistema. Com tindrà lloc aquesta revolució? Només es pot aconseguir quan matem el que som ara. Es perd molt de temps en la migració de codi entre els equips. Hem d’aportar el procés on podem fer una integració i un desplegament continu.
Aquest procés d’integració i desplegament continu el fa més àgil. Portar aquesta agilitat es considera cultura DevOps.
DevOps és la pràctica d’enginyers d’operacions i desenvolupament que participen junts en tot el cicle de vida del servei, des del disseny fins al procés de desenvolupament fins al suport a la producció.
No és fàcil canviar el sistema de treball al llarg del temps. Fer una transició amb èxit és renovar el sistema, en lloc de reconstruir-lo.
com retallar a Java
Ara anem a veure com podem aconseguir-ho. Hi ha dues maneres d’abordar-les.
1) De dalt a baix
2) De baix cap amunt
Aprofundint en aquestes tècniques, ens adonarem de quina és la més adequada per a la nostra organització.
En el plantejament de dalt a baix, podem dirigir-nos a la direcció superior i demanar-los que facin canvis en tots els equips. Si la direcció està convençuda, podem començar a treballar-hi.
Però la probabilitat d'obtenir la resposta com a 'NO' és bastant alta. És perquè canviar el sistema pot portar l’organització a la inestabilitat.
Han d’examinar l’estructura de l’organització, els ingressos, el nivell d’interès del client, etc. Però el factor més important que els fa apartar de l’antic sistema és que no poden veure imatge general del que es pot aconseguir i de la fluïdesa que es pot aconseguir amb el més recent.
En aquest cas, podem buscar el segon enfocament per obtenir aquest panorama general.
L’enfocament de baix a dalt requereix voluntariat. Aquí hem d’agafar un petit equip i una petita tasca i executar-los al model DevOps.
Analitzant la vessant tècnica d’aquest model, disposem de diversos conjunts d’eines sofisticades que fan que el treball sigui més eficient i ràpid. Però les eines per si soles no són prou capaces de crear un entorn de col·laboració anomenat DevOps.
La creació d’un entorn d’aquest tipus requereix que penseu fora de la caixa, per exemple. avaluant i realiniant com la gent pensa sobre els seus equips, el negoci i els clients.
Agrupar un nou conjunt d’eines és més senzill que canviar la cultura organitzativa. Promoure els desenvolupadors mestres antisocials, permetre la integració de codi ineficient, desplegar codis que no s’han provat correctament, posar-se la culpa a l’altre, considerar que l’equip d’operacions és estúpid no són les millors pràctiques que estem seguint per habilitar l’empresa. i crear valor per als nostres clients.
No són les eines, sinó les persones que les utilitzen, les que fan que el procés sigui complex. Dir a nivell abstracte en lloc de recollir idees i comportaments, estar oberts a ells ens porta a un camí brillant.
Comencem amb un equip de 6 membres i una història de tres punts. En primer lloc, hem de trencar l’equip que anomenem com a desenvolupadors, operacions, verificadors, etc. Els considerem tots com un sol, diguem “DevOps”. Quan rebem els requisits, hem d’analitzar les zones de risc. Tenint en compte les seccions més profundes del mar i de l’hellip .. Comencem a navegar.
Ara, heu de pensar 'quin és el factor x d'aquestes integracions i desplegaments continus que disminueixen la probabilitat d'error'.
Amb la visió i el procés millorats, podem acostar-nos a la direcció mostrant una imatge clara dels resultats, com la fluïdesa del procés, la reducció del risc d’error, la finalització de la tasca abans de la cronologia, etc.
Ara, podem visualitzar clarament com s’ha optimitzat tot el procés des del punt de vista tècnic i cultural fent una retrospecció després de cada iteració.
Edureka ha estat especialment curada que us ajuda a dominar conceptes sobre Puppet, Jenkins, Ansible, SaltStack, Chef, entre d’altres.
Tens alguna pregunta? Esmenteu-los a la secció de comentaris i us respondrem.
com convertir-se en enginyer d’ai
Articles Relacionats: