సంస్కృతి తరచుగా విస్మరించబడుతుంది మరియు తప్పుగా అర్ధం చేసుకోబడుతుంది, అయినప్పటికీ ఇది కంపెనీ పనితీరుకు కారణమయ్యే ముఖ్య అంశం. మేము మా సంస్కృతిని నిర్వహించకపోతే, చివరికి మా వ్యాపార లక్ష్యాలను ప్రభావితం చేసే తప్పుడు పద్ధతులు చేయడం ముగుస్తుంది.
సంస్థ యొక్క ప్రస్తుత సంస్కృతిని అర్థం చేసుకోవడం
ఒక సమూహం లేదా సంస్థలోని విలువలు మరియు నిబంధనల గురించి సంస్కృతి చెబుతుంది. ఇది ముఖ్యమైనది మరియు ప్రజలు ఒకరినొకరు ఎలా సంప్రదించాలో మరియు ఎలా పనిచేస్తుందో గుర్తిస్తుంది.
జావాలో అనామక తరగతి అంటే ఏమిటి
సంస్కృతి = “విజయానికి విషయాలు ఎలా తెలివిగా చేయవచ్చు”
కస్టమర్ మద్దతు బృందం యొక్క ఉదాహరణను తీసుకుందాం. ఆ బృందం యొక్క సంస్కృతి 97-98% కస్టమర్ సంతృప్తిని సాధించే విధంగా ఉండాలి.
కస్టమర్ ఆనందాన్ని దృష్టిలో ఉంచుకుని, మొదట వారు మర్యాదపూర్వకంగా ఉండాలి, క్లిష్ట పరిస్థితులలో కూడా వారు మంచి శ్రోతలు కావాలి, గందరగోళాన్ని నివారించడానికి వారు అవసరానికి అనుగుణంగా పనికి ప్రాధాన్యత ఇవ్వాలి.
ఒక క్షణం ఆగి, కొన్ని ప్రశ్నలను మనలో మనం అడగండి:
- ఇప్పుడు నా కంపెనీ సంస్కృతి ఏమిటి?
- ఈ సంస్కృతి నా వ్యాపార లక్ష్యాలు లేదా KRA లతో ఎంతవరకు సరిపోతుంది?
- తప్పుగా అమర్చడం వల్ల నేను ఏ సమస్యలను ఆశించగలను?
ప్రతి సంస్థకు, 4 సి లు కీలక పాత్ర పోషిస్తాయి
ఇప్పుడు, సాఫ్ట్‌వేర్ అభివృద్ధి చెందుతున్న సంస్థ యొక్క సంస్కృతిని పరిశీలిద్దాం. ఒకే సాఫ్ట్‌వేర్ యూనిట్‌ను నిర్మించడానికి మరియు నిర్వహించడానికి చాలా జట్లు ఉన్నాయి. ఈ జట్లన్నింటికీ ప్రత్యేక లక్ష్యాలు మరియు ప్రత్యేక సంస్కృతి ఉన్నాయి.
క్లయింట్ ద్వారా అవసరాలు నిర్ధారించబడిన తర్వాత ఈ ప్రక్రియ ప్రారంభమవుతుంది.
డెవలపర్లు వారి సంస్థ నిర్వచించిన కోడింగ్ మార్గదర్శకాలను అనుసరిస్తారు మరియు కోడ్‌ను రూపొందించడానికి కంపైలర్లు, వ్యాఖ్యాతలు, డీబగ్గర్స్ వంటి ప్రోగ్రామింగ్ సాధనాలను ఉపయోగిస్తారు. సి, సి ++, పాస్కల్, జావా మరియు పిహెచ్‌పి వంటి వివిధ ఉన్నత-స్థాయి ప్రోగ్రామింగ్ భాషలను కోడింగ్ కోసం ఉపయోగిస్తారు.
అవి పూర్తి ప్యాకేజీని చిన్న ఫోల్డర్‌లుగా విభజించి, తదనుగుణంగా చిన్న కోడ్‌లను అభివృద్ధి చేస్తాయి.
దశ 1 : ఈ చిన్న యూనిట్ల సంకేతాలు పెద్ద యూనిట్‌ను ఏర్పరుస్తాయి. చిన్న చిప్‌లను అనుసంధానించేటప్పుడు, ఇంటిగ్రేషన్ టెస్టింగ్ అని పిలువబడే ప్రాజెక్ట్-స్థాయి పరీక్షను నిర్వహించాలి.
దశ 2 : విజయవంతమైన ఏకీకరణ తరువాత, ఇది డమ్మీ సిస్టమ్‌లోకి అమర్చబడుతుంది. ఈ డమ్మీ సిస్టమ్ క్లయింట్ మెషీన్ లేదా ఈ ప్రాజెక్ట్ చివరకు అమలు చేయాల్సిన మెషీన్ మాదిరిగానే ఉంటుంది.
స్టేజ్ 3 : చివరగా, డమ్మీ సిస్టమ్‌లోని అన్ని లక్షణాలను పరీక్షించిన తరువాత, ప్రాజెక్ట్ ప్రొడక్షన్ సర్వర్ లేదా క్లయింట్ మెషీన్‌లో అమర్చబడుతుంది.
ఈ ప్రక్రియ చాలా మృదువైనది మరియు పదాలలో సులభం అనిపించినప్పటికీ, సాంకేతిక పరంగా ఇది సాధించడం చాలా కఠినమైనది.
మేము ఎదుర్కొనే సమస్యలను చూద్దాం:
దశ 1 :
ఉత్పత్తి యొక్క నాణ్యతను మెరుగుపరచడానికి క్లయింట్ ఎల్లప్పుడూ మార్పుల కోసం వెతుకుతాడు. మొదటి పునరావృతం జరిగిన చాలా సమయం, క్లయింట్ కొన్ని మార్పులను సూచిస్తుంది. డెవలపర్లు మార్పులను స్వీకరించినప్పుడు, వారు వాటిని చేర్చడం ప్రారంభిస్తారు, ఇది విరిగిన నిర్మాణాలకు దారితీసే సమైక్యతను ప్రభావితం చేస్తుంది.
దశ 2:
ఎక్కువ సమయం, పరీక్షకులు లేదా ఇతర ఆపరేషన్ కుర్రాళ్ళు చేయవలసిన కొత్త మార్పుల గురించి తెలియదు. డెవలపర్‌ల నుండి వారు కోడ్ పొందిన వెంటనే, వారు వాటిని పరీక్షించడం ప్రారంభిస్తారు. బ్యాక్ ఎండ్‌లో ఉన్నప్పుడు డెవలపర్లు ఇప్పటికీ మార్పులు చేస్తున్నారు.
క్రొత్త మార్పులను అమలు చేయడానికి వారికి తగినంత సమయం లభించనందున, వారు ఇతర నెట్‌వర్క్ మరియు డేటాబేస్ సమస్యలను ఎదుర్కొంటున్న అసమర్థ కోడ్‌లను అభివృద్ధి చేస్తారు, ఇది వారి డెలివరీ సమయాన్ని మళ్లీ ఆలస్యం చేస్తుంది.
తరగతి జావా యొక్క ఉదాహరణ
వారు చివరకు కోడ్‌లను ఆపరేషన్స్ బృందానికి పంపినప్పుడు, కొత్త పరీక్ష కేసులను సృష్టించడానికి మరియు అమలు చేయడానికి వారికి చాలా తక్కువ సమయం మిగిలి ఉంటుంది. అందువల్ల వారు చాలా పరీక్షా కేసులను దాటవేస్తారు, అవి అధిక ప్రాధాన్యతని కలిగి ఉన్నాయని వారు తరువాత తెలుసుకుంటారు.
3 వ దశ:
వాస్తవంగా బిల్డ్ ఉత్పత్తికి సిద్ధంగా ఉన్నట్లు అనిపించినప్పటికీ, ఫలితాలు పూర్తిగా .హించనివి. బిల్డ్ విఫలమవుతుంది మరియు అనేక దోషాలు సంభవిస్తాయి.
ప్రతి బగ్ సంభవించినప్పుడు, అది ఎందుకు సంభవించిందో, ఎక్కడ సంభవించిందో, దాన్ని అధిగమించడానికి ఏ మార్పులు చేయవలసి ఉందో వారు ట్రాక్ చేయాలి, మునుపటి వాటితో అనుకూలంగా ఉండటానికి ఇతర సంకేతాలలో మార్పు ఉంటుంది. చివరగా, ఈ దోషాలన్నింటికీ, బగ్ రిపోర్ట్ రూపొందించబడాలి.
కోడ్ యొక్క సామర్థ్యంలో డేటాబేస్ డెవలపర్ యొక్క అజ్ఞానం, పరీక్ష కేసుల సంఖ్యలో టెస్టర్ యొక్క అజ్ఞానం మొదలైన వాటి కారణంగా సిస్టమ్ లోపాలు వైఫల్యానికి కారణం.
క్లయింట్ ఎల్లప్పుడూ గడువును గట్టిగా ఉంచుతున్నందున, వాటిని సాధించడంలో పాల్గొన్న ఉద్యోగులు మొత్తం నాణ్యతతో రాజీ పడాల్సి వచ్చినప్పటికీ తుది విడుదలలో మాత్రమే దృష్టి పెడతారు.
పని సమన్వయంలో ఇది సమస్యగా అనిపించినప్పటికీ, ఇది వాస్తవానికి స్వీకరించబడిన సంస్కృతి యొక్క వైఫల్యం.
మాన్యువల్ ప్రక్రియలపై పెద్దగా ఆధారపడటం వల్ల ఇది జరుగుతుంది. వివిధ రంగాలలో ప్రాప్యత లేకపోవడం లేదా ఆసక్తి లేకపోవడం వల్ల ఒకే జట్టులో పరుగెత్తటం మన స్వంత భారం మరియు నొప్పిని పెంచుతుంది.
మేము బహుముఖ ప్రజ్ఞాశాలి కావాల్సిన అధిక సమయం ఇది. వ్యవస్థలో పాల్గొన్న అన్ని ప్రక్రియలకు ప్రావీణ్యం పొందడం కష్టం కావచ్చు, కాని మనం అందరికీ జాక్ కావచ్చు, వాటిలో ఒకదానిని మాస్టరింగ్ చేయవచ్చు. అప్పుడు మాత్రమే మన సిస్టమ్‌ను ఆటోమేట్ చేయవచ్చు లేదా రోల్‌బ్యాక్‌ల కంటే కోలుకునేంత తెలివితేటలు చేయవచ్చు.
ఇప్పుడు, మీరు ఎందుకు ఆలోచిస్తూ ఉండవచ్చు?
దీనికి కారణం, మీరు మాస్టరింగ్ చేస్తున్నది ఇతరులపై ఎక్కువగా ఆధారపడి ఉంటుంది. కాబట్టి డిపెండెన్సీ పాయింట్ గురించి తెలుసుకోవాలంటే మనం మొత్తం వ్యవస్థను అర్థం చేసుకోవాలి.
కాబట్టి సంస్కృతిని మార్చడానికి ఒక ప్రక్రియ గురించి ఆలోచిద్దాం. దీనికి ముందు మీకు ఈ క్రింది ప్రశ్నలకు సమాధానం ఉందా?
- మీ ప్రస్తుత సంస్కృతి ఎక్కడ విఫలమవుతుంది?
- మీరు ప్రక్రియను ఎందుకు మార్చాలనుకుంటున్నారు?
- అవసరమైన అన్ని మార్పులను మీరు స్పష్టంగా గుర్తించారా?
- మీరు ప్రభావిత వాటాదారులందరి నుండి అభిప్రాయాన్ని పొందారా?
- మార్పు కోసం మీరు ప్రక్రియ క్రమశిక్షణ, డేటా మరియు కొలిచే వ్యవస్థను తిరిగి ధృవీకరించారా?
కాబట్టి, ఇప్పుడు మనందరికీ సమాధానం ఉన్నప్పుడు, మన వ్యవస్థలో ఒక విప్లవం గురించి ఆలోచిస్తాము. ఈ విప్లవం ఎలా జరుగుతుంది? మనం ఇప్పుడు ఉన్నదాన్ని చంపినప్పుడు మాత్రమే అది సాధించవచ్చు. జట్ల మధ్య కోడ్ వలసలో చాలా సమయం వృధా అవుతుంది. మేము నిరంతర సమైక్యత మరియు నిరంతర విస్తరణ చేయగల ప్రక్రియను తీసుకురావాలి.
నిరంతర సమైక్యత మరియు విస్తరణ యొక్క ఈ ప్రక్రియ మరింత చురుకైనదిగా చేస్తుంది. ఈ చురుకుదనాన్ని తీసుకురావడం డెవొప్స్ సంస్కృతిగా పరిగణించబడుతుంది.
డెవొప్స్ అంటే ఆపరేషన్స్ మరియు డెవలప్మెంట్ ఇంజనీర్లు డిజైన్ నుండి డెవలప్మెంట్ ప్రాసెస్ ద్వారా ప్రొడక్షన్ సపోర్ట్ వరకు మొత్తం సేవా జీవితచక్రంలో కలిసి పాల్గొంటారు.
కాలక్రమేణా పని వ్యవస్థను మార్చడం అంత సులభం కాదు. విజయవంతమైన పరివర్తన చేయడం అంటే పునర్నిర్మాణం కాకుండా వ్యవస్థను పునరుద్ధరించడం.
ఇప్పుడు మనం దీన్ని ఎలా సాధించవచ్చో చూద్దాం. చేరుకోవడానికి రెండు మార్గాలు ఉండవచ్చు.
1) పై నుండి క్రిందికి
2) బాటమ్ అప్
ఈ పద్ధతుల గురించి లోతుగా డైవింగ్ చేస్తే, ఇది మా సంస్థకు బాగా సరిపోతుందని మేము గ్రహిస్తాము.
టాప్ డౌన్ విధానంలో, మేము ఉన్నత నిర్వహణకు వెళ్లి, అన్ని జట్లలో మార్పులు చేయమని వారిని అడగవచ్చు. అప్పుడు మేనేజ్‌మెంట్‌కు నమ్మకం ఉంటే, మేము దానిపై పనిచేయడం ప్రారంభించవచ్చు.
కానీ “లేదు” అని సమాధానం పొందే సంభావ్యత చాలా ఎక్కువ. వ్యవస్థను మార్చడం సంస్థను అస్థిరతకు దారితీస్తుంది.
వారు సంస్థ, రాబడి, క్లయింట్ యొక్క ఆసక్తి స్థాయి మొదలైన వాటి యొక్క నిర్మాణాన్ని పరిశీలించాలి. కాని పాత వ్యవస్థ నుండి బయటపడకుండా వారిని వెనక్కి తీసుకునే ముఖ్యమైన అంశం ఏమిటంటే వారు చూడలేరు క్రొత్తదానితో ఏమి సాధించవచ్చో మరియు ఎంత సజావుగా సాధించవచ్చో పెద్ద చిత్రం.
జావాలో క్యూ డేటా నిర్మాణం
ఈ సందర్భంలో, ఈ పెద్ద చిత్రాన్ని పొందడానికి మేము రెండవ విధానం కోసం చూడవచ్చు.
బాటమ్ అప్ విధానం వాలంటీర్ కోసం పిలుస్తుంది. ఇక్కడ మనం ఒక చిన్న బృందాన్ని మరియు ఒక చిన్న పనిని తీసుకొని దానిని DevOps మోడల్‌లో అమలు చేయాలి.
ఈ మోడల్ యొక్క సాంకేతిక వైపు చూస్తే, మన దగ్గర వివిధ రకాల అధునాతన సాధనాలు ఉన్నాయి, ఇవి పనిని మరింత సమర్థవంతంగా మరియు వేగంగా చేస్తాయి. కానీ, DevOps గా సూచించబడే సహకార వాతావరణాన్ని సృష్టించడానికి సాధనాలు మాత్రమే సరిపోవు.
అటువంటి వాతావరణాన్ని సృష్టించడానికి మీరు పెట్టె నుండి ఆలోచించాల్సిన అవసరం ఉంది ఉదా. ప్రజలు తమ జట్లు, వ్యాపారం మరియు కస్టమర్ల గురించి ఎలా ఆలోచిస్తారో అంచనా వేయడం మరియు గుర్తించడం.
సంస్థాగత సంస్కృతిని మార్చడం కంటే కొత్త సాధనాల సమితిని ఉంచడం చాలా సులభం. సంఘ విద్రోహ మాస్టర్ డెవలపర్‌లను ప్రోత్సహించడం ద్వారా, అసమర్థమైన కోడ్‌ను ఏకీకృతం చేయడానికి అనుమతించడం, సరిగ్గా పరీక్షించని కోడ్‌లను అమలు చేయడం, ఒకరి తలపై ఒకరిపై ఒకరు నిందలు వేయడం, ఆపరేషన్స్ బృందం తెలివితక్కువదని భావించడం ద్వారా వ్యాపారాన్ని ప్రారంభించడానికి మేము అనుసరిస్తున్న ఉత్తమ పద్ధతులు కాదు మరియు మా కస్టమర్ల కోసం విలువను సృష్టించండి.
ఇది సాధనాలు కాదు, వాటిని ఉపయోగించే వ్యక్తులు ప్రక్రియను క్లిష్టతరం చేస్తారు. ఆలోచనలు మరియు ప్రవర్తనలను సేకరించడం కంటే వియుక్త స్థాయిలో చెప్పడం, వాటికి బహిరంగంగా ఉండటం మమ్మల్ని ఒక ప్రకాశవంతమైన మార్గానికి తీసుకువెళుతుంది.
6 సభ్యుల బృందం మరియు 3-పాయింట్ల కథతో ప్రారంభిద్దాం. మొదట, మేము డెవలపర్లు, ఆపరేషన్లు, పరీక్షకులుగా పిలిచే బృందాన్ని విచ్ఛిన్నం చేయాలి. మేము వారందరినీ ఒకటిగా భావిస్తాము, “DevOps” అని చెప్పండి. మేము అవసరాలను స్వీకరించినప్పుడు మేము ప్రమాద మండలాలను విశ్లేషించాలి. సముద్రం & హెల్లిప్ యొక్క లోతైన విభాగాలను దృష్టిలో ఉంచుకుని .. మేము నౌకాయానం ప్రారంభిస్తాము.
ఇప్పుడు, మీరు 'ఈ నిరంతర సమైక్యత మరియు వైఫల్యం యొక్క సంభావ్యతను తగ్గించే నిరంతర విస్తరణ యొక్క x- కారకం ఏమిటి' అని ఆలోచిస్తూ ఉండాలి.
మెరుగైన దృష్టి మరియు ప్రక్రియతో, ప్రక్రియ ఎంత సున్నితంగా ఉందో, వైఫల్య ప్రమాదం ఎలా తగ్గింది, కాలక్రమానికి ముందు పని ఎలా పూర్తయింది వంటి ఫలితాల యొక్క స్పష్టమైన చిత్రాన్ని ఉంచే నిర్వహణను మేము సంప్రదించవచ్చు.
ఇప్పుడు, ప్రతి పునరావృతం తర్వాత పునరాలోచన ద్వారా మొత్తం ప్రక్రియ సాంకేతిక మరియు సాంస్కృతిక మైదానంలో ఎలా ఆప్టిమైజ్ చేయబడిందో మనం స్పష్టంగా చూడవచ్చు.
ఎడురేకా ప్రత్యేకంగా క్యూరేట్ చేసింది ఇది పప్పెట్, జెంకిన్స్, అన్సిబుల్, సాల్ట్‌స్టాక్, చెఫ్ చుట్టూ ఉన్న భావనలను నేర్చుకోవడంలో మీకు సహాయపడుతుంది.
మాకు ప్రశ్న ఉందా? వ్యాఖ్యల విభాగంలో వాటిని ప్రస్తావించండి మరియు మేము మిమ్మల్ని సంప్రదిస్తాము.
సంబంధిత పోస్ట్లు: