La culture est souvent ignorée et mal comprise, mais elle est un facteur clé responsable de la performance d’une entreprise. Si nous ne gérons pas notre culture, nous finirons par faire de mauvaises pratiques qui finiront par affecter nos objectifs commerciaux.
Comprendre la culture actuelle d'une organisation
La culture nous renseigne sur les valeurs et les normes au sein d'un groupe ou d'une entreprise. Il identifie ce qui est important ainsi que la manière dont les gens se rapprochent et travaillent les uns avec les autres.
CULTURE = 'Comment faire les choses intelligemment pour réussir'
Prenons l'exemple d'une équipe de support client. La culture de cette équipe doit être telle qu'elle finit par atteindre 97 à 98% de satisfaction client.
En gardant à l'esprit le plaisir du client, ils doivent avant tout être polis, même dans des situations difficiles, ils doivent être de bons auditeurs pour éviter toute confusion dont ils ont besoin pour hiérarchiser le travail en fonction des besoins.
Arrêtons-nous un instant et posons-nous quelques questions:
- Quelle est la culture de mon entreprise maintenant?
- Dans quelle mesure cette culture est-elle alignée sur mes objectifs commerciaux ou mes KRA?
- À quels problèmes puis-je m'attendre en raison d'un mauvais alignement?
Pour chaque organisation, les 4C jouent un rôle essentiel
Examinons maintenant la culture d'une organisation de développement de logiciels. De nombreuses équipes sont impliquées dans la création et la maintenance d'une seule unité logicielle. Toutes ces équipes ont des objectifs distincts et une culture distincte.
python __init__ soi
Ce processus démarre une fois que les exigences ont été confirmées par le client.
Les développeurs suivent les directives de codage définies par leur organisation et des outils de programmation tels que des compilateurs, des interprètes, des débogueurs, etc. sont utilisés pour générer le code. Différents langages de programmation de haut niveau tels que C, C ++, Pascal, Java et PHP sont utilisés pour le codage.
Ils divisent le package complet en petits dossiers, puis développent de petits codes en conséquence.
Étape 1 : Ces petites unités de codes sont ensuite matraquées pour former une grande unité. Lors de l'intégration des puces plus petites, un test au niveau du projet doit être effectué, appelé test d'intégration.
Étape 2 : Une fois l'intégration réussie, il est déployé dans un système factice. Ce système factice a une configuration similaire à celle de la machine cliente ou de la machine sur laquelle ce projet doit être finalement déployé.
Étape 3 : Enfin, après avoir testé toutes les fonctionnalités d'un système factice, le projet est déployé sur le serveur de production ou sur la machine cliente.
Bien que ce processus semble être très fluide et facile en termes de mots, en termes techniques, il est très difficile à réaliser.
Voyons les problèmes auxquels nous pourrions être confrontés:
Étape 1 :
Le client est toujours à la recherche de changements pour améliorer la qualité du produit. La plupart du temps, lorsque la première itération a été effectuée, le client proposera quelques changements. Lorsque les développeurs reçoivent les modifications, ils commencent à les incorporer, ce qui a un impact sur l'intégration conduisant à des versions interrompues.
Étape 2:
La plupart du temps, les testeurs ou autres opérateurs ne seront pas au courant des nouveaux changements à apporter. Dès qu'ils reçoivent le code des développeurs, ils commencent à les tester. Alors que sur le back-end, les développeurs apportent toujours les modifications.
Comme ils n'ont pas assez de temps pour mettre en œuvre de nouveaux changements, ils finissent par développer des codes inefficaces, ils sont confrontés à d'autres problèmes de réseau et de base de données qui retardent à nouveau leur délai de livraison.
Lorsqu'ils livrent enfin les codes à l'équipe des opérations, ils n'ont que très peu de temps pour créer et mettre en œuvre de nouveaux cas de test. Ils sautent donc de nombreux cas de test dont ils se rendent compte plus tard qu'ils étaient hautement prioritaires.
Étape 3:
Bien que pratiquement la version semble prête pour la production, les résultats sont complètement inattendus. La construction échoue et un certain nombre de bogues se produisent.
qu'est-ce que anaconda pour python
Ensuite, pour chaque bug survenu, ils doivent suivre pourquoi cela s'est produit, où cela s'est produit, quels changements doivent être faits pour le surmonter, y aura-t-il des changements dans les codes des autres pour le rendre compatible avec les précédents. Enfin, pour tous ces bogues, un rapport de bogue doit être généré.
L'échec est dû à des erreurs système dues à l'ignorance du développeur de la base de données en matière d'efficacité du code, à l'ignorance du testeur en nombre de cas de test, etc.
Comme le client respecte toujours les délais, les employés impliqués dans leur réalisation ne se concentrent que sur la version finale, même s'ils doivent compromettre la qualité globale.
Bien que cela semble être un problème de coordination du travail, c'est en fait l'échec de la culture adoptée.
Cela se produit en raison d'une grande dépendance vis-à-vis des processus manuels. Aller et venir dans la même équipe en raison d'un manque de connaissance de différents domaines, d'un manque d'accès ou d'un manque d'intérêt, augmente notre propre fardeau et notre propre douleur.
Il est grand temps que nous soyons polyvalents. Il peut être difficile de maîtriser tous les processus impliqués dans un système, mais nous pouvons être le maître de tous, maîtriser l'un d'entre eux. Alors seulement, nous pouvons automatiser notre système ou le rendre suffisamment intelligent pour récupérer plutôt que pour les annulations.
Maintenant, vous vous demandez peut-être pourquoi?
C’est parce que celui que vous maîtrisez dépend fortement des autres. Donc, pour connaître le point de dépendance, nous devons comprendre l'ensemble du système.
Pensons donc à un processus pour changer la culture. Avant cela, avez-vous la réponse aux questions ci-dessous?
- Où votre culture actuelle échoue-t-elle?
- Pourquoi souhaitez-vous changer le processus?
- Avez-vous clairement identifié tous les changements requis?
- Avez-vous obtenu des commentaires et l'adhésion de toutes les parties prenantes concernées?
- Avez-vous revalidé la discipline du processus, les données et le système de mesure du changement?
Ainsi, maintenant que nous avons la réponse à tous, nous pensons à une révolution dans notre système. Comment cette révolution aura-t-elle lieu? Cela ne peut être réalisé que lorsque nous tuons ce que nous sommes maintenant. Beaucoup de temps est perdu dans la migration du code entre les équipes. Nous devons amener le processus où nous pouvons faire une intégration continue et un déploiement continu.
Ce processus d'intégration et de déploiement continus le rend plus agile. Apporter cette agilité est considéré comme une culture DevOps.
DevOps est la pratique des ingénieurs d'exploitation et de développement participant ensemble à l'ensemble du cycle de vie du service, de la conception au processus de développement en passant par le support de production.
Il n'est pas facile de changer le système de travail au fil du temps. Réussir la transition, c'est rénover le système plutôt que reconstruire.
Voyons maintenant comment nous pouvons y parvenir. Il peut y avoir deux manières d'aborder.
1) De haut en bas
2) De bas en haut
En approfondissant ces techniques, nous réaliserons celle qui convient le mieux à notre organisation.
Dans l'approche descendante, nous pouvons nous adresser à la direction supérieure et leur demander de faire des changements dans toutes les équipes. Si la direction est convaincue, nous pouvons commencer à y travailler.
Mais la probabilité d'obtenir la réponse «NON» est assez élevée. C’est parce que changer le système peut conduire l’organisation à l’instabilité.
Ils doivent examiner la structure de l’organisation, les revenus, le niveau d’intérêt du client, etc. Mais le facteur le plus important qui les empêche de sortir de l’ancien système est qu’ils ne peuvent pas voir une vue d'ensemble de ce qui peut être réalisé et de la facilité avec laquelle il peut être réalisé avec le plus récent.
Dans ce cas, nous pouvons rechercher la deuxième approche pour obtenir cette vue d'ensemble.
L'approche ascendante requiert du bénévolat. Ici, nous devons prendre une petite équipe et une petite tâche et l'exécuter dans DevOps Model.
En regardant dans le côté technique de ce modèle, nous avons divers ensembles d'outils sophistiqués qui rendent le travail plus efficace et plus rapide. Mais les outils seuls ne sont pas assez capables de créer un environnement collaboratif appelé DevOps.
La création d'un tel environnement vous oblige à sortir des sentiers battus, par ex. évaluer et réaligner la façon dont les gens pensent de leurs équipes, de l'entreprise et des clients.
Mettre en place un nouvel ensemble d'outils est plus simple que de changer la culture organisationnelle. En promouvant les maîtres développeurs antisociaux, en permettant l'intégration de code inefficace, en déployant des codes qui n'ont pas été correctement testés, en se blâmant mutuellement, considérer l'équipe des opérations comme stupide ne sont pas les meilleures pratiques que nous suivons pour permettre à l'entreprise et créer de la valeur pour nos clients.
Ce ne sont pas les outils, ce sont les personnes qui les utilisent qui rendent le processus complexe. Dire à un niveau abstrait plutôt que de collecter des idées et des comportements, être ouvert à eux nous emmène sur un chemin lumineux.
Commençons par une équipe de 6 membres et une histoire en 3 points. Premièrement, nous devons rompre l'équipe que nous appelons en tant que développeurs, opérations, testeurs, etc. Nous les considérons tous comme un, disons «DevOps». Lorsque nous recevons les exigences, nous devons analyser les zones de risque. En gardant à l'esprit les sections les plus profondes de la mer et hellip .. Nous commençons à naviguer.
Maintenant, vous devez vous demander «quel est le facteur x de cette intégration continue et du déploiement continu qui diminue la probabilité d'échec».
Avec une vision et un processus améliorés, nous pouvons approcher la direction en lui donnant une image claire des résultats, comme la fluidité du processus, la réduction du risque d'échec, la manière dont la tâche a été achevée avant le calendrier, etc.
Maintenant, nous pouvons clairement visualiser comment l'ensemble du processus a été optimisé sur le plan technique et culturel en ayant une rétrospective après chaque itération.
Edureka a spécialement organisé qui vous aide à maîtriser les concepts autour de Puppet, Jenkins, Ansible, SaltStack, Chef entre autres.
Vous avez une question pour nous? Mentionnez-les dans la section commentaires et nous vous recontacterons.
java convertit le double en entier
Articles Similaires: