La cultura è spesso ignorata e fraintesa, tuttavia è un fattore chiave responsabile delle prestazioni di un'azienda. Se non gestiamo la nostra cultura, finiremo per fare pratiche sbagliate che alla fine influenzeranno i nostri obiettivi aziendali.
Comprendere la cultura attuale di un'organizzazione
La cultura ci parla dei valori e delle norme all'interno di un gruppo o di un'azienda. Identifica ciò che è importante e il modo in cui le persone si avvicinano e lavorano tra loro.
CULTURA = 'Come si possono fare le cose in modo intelligente per il successo'
Prendiamo l'esempio di un team di assistenza clienti. La cultura di quel team dovrebbe essere tale da raggiungere il 97-98% della soddisfazione del cliente.
Tenendo presente la soddisfazione del cliente, prima di tutto devono essere educati, anche in situazioni difficili devono essere buoni ascoltatori per evitare confusione di cui hanno bisogno per dare priorità al lavoro in base alle esigenze.
Fermiamoci un momento e poniamoci alcune domande:
- Qual è la cultura della mia azienda adesso?
- Quanto è allineata questa cultura con i miei obiettivi aziendali o KRA?
- Quali problemi posso aspettarmi a causa del disallineamento?
Per ogni organizzazione, le 4C giocano un ruolo fondamentale
Ora, diamo un'occhiata alla cultura di un'organizzazione di sviluppo software. Ci sono molti team coinvolti per la creazione e la manutenzione di una singola unità software. Tutte queste squadre hanno obiettivi separati e cultura separata.
Questo processo inizia dopo che i requisiti sono stati confermati dal cliente.
Gli sviluppatori seguono le linee guida di codifica definite dalla loro organizzazione e strumenti di programmazione come compilatori, interpreti, debugger ecc. Vengono utilizzati per generare il codice. Per la codifica vengono utilizzati diversi linguaggi di programmazione di alto livello come C, C ++, Pascal, Java e PHP.
Dividono il pacchetto completo in piccole cartelle e quindi sviluppano piccoli codici di conseguenza.
Fase 1 : Queste piccole unità di codici vengono poi bastonate per formare una grande unità. Durante l'integrazione dei chip più piccoli, è necessario eseguire un test a livello di progetto noto come test di integrazione.
Fase 2 : Dopo la corretta integrazione, viene distribuito in un sistema fittizio. Questo sistema fittizio ha una configurazione simile a quella della macchina client o della macchina in cui questo progetto deve essere finalmente distribuito.
Fase 3 : Infine, dopo aver testato tutte le funzionalità in un sistema fittizio, il progetto viene distribuito nel server di produzione o nella macchina client.
__in se stesso)
Sebbene questo processo sembri molto fluido e facile a parole, in termini tecnici è molto difficile da ottenere.
Vediamo quali problemi potremmo affrontare:
Fase 1 :
Il cliente è sempre alla ricerca di modifiche per migliorare la qualità del prodotto. La maggior parte delle volte, quando è stata eseguita la prima iterazione, il client suggerirà alcune modifiche. Quando gli sviluppatori ricevono le modifiche, iniziano a incorporarle, il che influisce sull'integrazione che porta a build non funzionanti.
Fase 2:
La maggior parte delle volte, i tester o altri ragazzi delle operazioni non saranno a conoscenza delle nuove modifiche da apportare. Non appena ricevono il codice dagli sviluppatori, iniziano a testarli. Mentre nel back-end gli sviluppatori stanno ancora apportando le modifiche.
Poiché non hanno abbastanza tempo per implementare nuove modifiche, finiscono per sviluppare codici inefficienti che devono affrontare altri problemi di rete e database che ritarda nuovamente i tempi di consegna.
Quando finalmente consegnano i codici al team operativo, gli resta un tempo minimo per creare e implementare nuovi casi di test. Quindi saltano molti dei casi di test che si rendono conto in seguito che quelli erano di alta priorità.
Fase 3:
Anche se praticamente la build sembra essere pronta per la produzione, i risultati sono completamente inaspettati. La compilazione non riesce e si verificano numerosi bug.
Quindi, per ogni bug che si è verificato, devono tenere traccia del motivo per cui si è verificato, dove si è verificato, quali modifiche è necessario fare per superarlo, ci saranno modifiche nei codici degli altri per renderlo compatibile con i precedenti. Infine, per tutti questi bug, deve essere generato un rapporto sui bug.
L'errore è dovuto a errori di sistema dovuti all'ignoranza dello sviluppatore del database in termini di efficienza del codice, ignoranza del tester sul numero di casi di test, ecc.
sequenza di fibonacci c ++
Poiché il cliente mantiene le scadenze sempre strette, i dipendenti coinvolti nel realizzarle si concentrano solo nel rilascio finale anche se devono compromettere la qualità complessiva.
Anche se questo sembra essere un problema nel coordinamento del lavoro, questo in realtà è il fallimento della cultura adottata.
Ciò accade a causa della grande dipendenza dai processi manuali. Correre avanti e indietro nella stessa squadra a causa della mancanza di conoscenza di campi diversi, la mancanza di accesso o la mancanza di interesse aumenta il nostro fardello e il nostro dolore.
È ora che dobbiamo essere versatili. Potrebbe essere difficile essere padroni di tutti i processi coinvolti in un sistema, ma possiamo essere il tuttofare, padroneggiarne uno. Solo allora possiamo automatizzare il nostro sistema o renderlo abbastanza intelligente da ripristinarlo anziché ripristinarlo.
Ora, potresti pensare perché?
È perché quello che stai padroneggiando dipende fortemente dagli altri. Quindi, per conoscere il punto di dipendenza, dobbiamo comprendere l'intero sistema.
Quindi pensiamo a un processo per cambiare la cultura. Prima di ciò hai la risposta alle seguenti domande?
- Dove fallisce la tua cultura attuale?
- Perché desideri modificare il processo?
- Hai chiaramente identificato tutte le modifiche richieste?
- Hai ottenuto feedback e buy-in da tutti gli stakeholder interessati?
- Hai riconvalidato la disciplina di processo, i dati e il sistema di misurazione del cambiamento?
Quindi, ora che abbiamo la risposta a tutto, pensiamo a una rivoluzione nel nostro sistema. Come avverrà questa rivoluzione? Può essere raggiunto solo quando uccidiamo ciò che siamo ora. Si spreca molto tempo nella migrazione del codice tra i team. Dobbiamo portare il processo in cui possiamo fare integrazione continua e distribuzione continua.
Questo processo di integrazione e distribuzione continue lo rende più agile. Portare questa agilità è considerata una cultura DevOps.
DevOps è la pratica di operazioni e ingegneri di sviluppo che partecipano insieme all'intero ciclo di vita del servizio, dalla progettazione attraverso il processo di sviluppo al supporto alla produzione.
Non è facile cambiare il sistema di lavoro nel tempo. Effettuare una transizione di successo significa rinnovare il sistema, piuttosto che ricostruirlo.
Ora vediamo come possiamo ottenere questo risultato. Ci possono essere due modi per avvicinarsi.
1) Dall'alto verso il basso
2) Dal basso verso l'alto
Immergendoci più a fondo in queste tecniche, realizzeremo quale è la più adatta alla nostra organizzazione.
come terminare un programma in java
Nell'approccio dall'alto verso il basso, possiamo andare alla dirigenza superiore e chiedere loro di apportare modifiche a tutti i team. Se la direzione è convinta, possiamo iniziare a lavorarci.
Ma la probabilità di ottenere la risposta come 'NO' è piuttosto alta. È perché cambiare il sistema può portare l'organizzazione all'instabilità.
Devono esaminare la struttura dell'organizzazione, le entrate, il livello di interesse del cliente e così via. Ma il fattore più importante che li allontana dall'abbandonare il vecchio sistema è che non riescono a vedere quadro generale di ciò che può essere ottenuto e di quanto agevolmente può essere ottenuto con quello più recente.
In questo caso, possiamo cercare il secondo approccio per ottenere questo quadro generale.
L'approccio dal basso verso l'alto richiede volontariato. Qui dobbiamo prendere un piccolo team e un piccolo compito ed eseguirlo in DevOps Model.
Esaminando il lato tecnico di questo modello, abbiamo vari set di strumenti sofisticati che rendono il lavoro più efficiente e veloce. Tuttavia, gli strumenti da soli non sono in grado di creare un ambiente collaborativo denominato DevOps.
La creazione di un tale ambiente richiede di pensare fuori dagli schemi, ad es. valutare e riallineare il modo in cui le persone pensano ai propri team, al business e ai clienti.
Mettere insieme una nuova serie di strumenti è più semplice che cambiare la cultura organizzativa. Promuovendo gli sviluppatori master anti-social, consentendo l'integrazione di codice inefficiente, distribuendo codici che non sono stati adeguatamente testati, incolpandosi a vicenda, considerare il team operativo come stupido non sono le migliori pratiche che stiamo seguendo per abilitare il business e creare valore per i nostri clienti.
Non sono gli strumenti, ma le persone che li usano a rendere complesso il processo. Dire a livello astratto piuttosto che raccogliere idee e comportamenti, essere aperti ad essi ci porta su un percorso luminoso.
Cominciamo con un team di 6 membri e una storia in 3 punti. In primo luogo, dobbiamo rompere il team che chiamiamo sviluppatori, operazioni, tester, ecc. Li consideriamo tutti come uno, diciamo 'DevOps'. Quando riceviamo i requisiti dobbiamo analizzare le zone di rischio. Tenendo presente le sezioni più profonde del mare e hellip .. Cominciamo a navigare.
Ora, devi pensare 'qual è il fattore x di queste integrazione continua e implementazione continua che diminuisce la probabilità di fallimento'.
Con la visione e il processo migliorati, possiamo avvicinarci alla direzione fornendo un'immagine chiara dei risultati, ad esempio quanto è stato fluido il processo, come è stato ridotto il rischio di fallimento, come l'attività è stata completata prima della tempistica, ecc.
Ora, possiamo visualizzare chiaramente come l'intero processo è stato ottimizzato su un terreno tecnico e culturale grazie alla retrospettiva dopo ogni iterazione.
Edureka ha appositamente curato che ti aiuta a padroneggiare concetti su Puppet, Jenkins, Ansible, SaltStack, Chef tra gli altri.
Hai domande per noi? Menzionateli nella sezione commenti e vi risponderemo.
Post correlati: