غالبًا ما يتم تجاهل الثقافة وإساءة فهمها ، ومع ذلك فهي عامل رئيسي مسؤول عن أداء الشركة. إذا لم ندير ثقافتنا ، فسننتهي بممارسات خاطئة ستؤثر في النهاية على أهداف أعمالنا.
فهم الثقافة الحالية للمؤسسة
تخبرنا الثقافة عن القيم والمعايير داخل مجموعة أو شركة. إنه يحدد ما هو مهم وكذلك كيفية تعامل الناس مع بعضهم البعض والعمل معهم.
CULTURE = 'كيف يمكن عمل الأشياء بذكاء لتحقيق النجاح'
لنأخذ مثال فريق دعم العملاء. يجب أن تكون ثقافة هذا الفريق بحيث ينتهي بهم الأمر بتحقيق 97-98٪ من رضا العملاء.
مع مراعاة فرحة العملاء ، يجب أولاً وقبل كل شيء أن يكونوا مهذبين ، حتى في المواقف الصعبة ، يحتاجون إلى أن يكونوا مستمعين جيدين لتجنب الارتباك الذي يحتاجونه لتحديد أولويات العمل وفقًا للمتطلبات.
دعنا نتوقف لحظة ونطرح بعض الأسئلة على أنفسنا:
كيفية تغيير المضاعفة إلى كثافة العمليات في جافا
- ما هي ثقافة شركتي الآن؟
- ما مدى توافق هذه الثقافة مع أهداف عملي أو KRAs؟
- ما هي المشاكل التي يمكن أن أتوقعها بسبب المحاذاة الخاطئة؟
لكل منظمة ، تلعب 4Cs دورًا حيويًا
الآن ، دعونا نلقي نظرة على ثقافة مؤسسة تطوير البرمجيات. هناك العديد من الفرق المشاركة لبناء وصيانة وحدة برمجية واحدة. كل هذه الفرق لها أهداف منفصلة وثقافة منفصلة.
تبدأ هذه العملية بعد أن يتم تأكيد المتطلبات من قبل العميل.
يتبع المطورون إرشادات الترميز التي تحددها مؤسستهم وأدوات البرمجة مثل المجمعين والمترجمين الفوريين والمصححين وما إلى ذلك التي تُستخدم لإنشاء الكود. تستخدم لغات البرمجة عالية المستوى المختلفة مثل C و C ++ و Pascal و Java و PHP للترميز.
يقسمون الحزمة الكاملة إلى مجلدات صغيرة ثم يطورون رموزًا صغيرة وفقًا لذلك.
المرحلة 1 : يتم بعد ذلك تجميع هذه الوحدات الصغيرة من الرموز لتشكيل وحدة كبيرة. أثناء دمج الشرائح الأصغر ، يجب إجراء اختبار على مستوى المشروع يُعرف باسم اختبار التكامل.
المرحلة الثانية : بعد التكامل الناجح ، يتم نشره في نظام وهمي. هذا النظام الوهمي له تكوين مشابه لتكوين جهاز العميل أو الجهاز حيث يجب نشر هذا المشروع أخيرًا.
المرحلة 3 : أخيرًا ، بعد اختبار جميع الميزات في نظام وهمي ، يتم نشر المشروع في خادم الإنتاج أو جهاز العميل.
على الرغم من أن هذه العملية تبدو سلسة للغاية وسهلة الكلمات ، إلا أنها صعبة للغاية من الناحية الفنية.
دعونا نرى ما هي المشاكل التي قد نواجهها:
المرحلة 1 :
يبحث العميل دائمًا عن تغييرات لتحسين جودة المنتج. في معظم الأوقات عند إجراء التكرار الأول ، سيقترح العميل بعض التغييرات. عندما يتلقى المطورون التغييرات ، يبدأون في دمجها مما يؤثر على التكامل الذي يؤدي إلى إنشاءات معطلة.
المرحلة الثانية:
في معظم الأوقات ، لن يكون المختبرين أو غيرهم من رجال العمليات على دراية بالتغييرات الجديدة التي سيتم إجراؤها. بمجرد حصولهم على الشفرة من المطورين ، يبدأون في اختبارها. بينما في النهاية الخلفية ، لا يزال المطورون يقومون بإجراء التغييرات.
نظرًا لأنهم لا يحصلون على الوقت الكافي لتنفيذ التغييرات الجديدة ، فإنهم ينتهي بهم الأمر إلى تطوير رموز غير فعالة يواجهون مشكلات أخرى في الشبكة وقواعد البيانات مما يؤخر وقت التسليم مرة أخرى.
عندما يقومون بتسليم الرموز أخيرًا إلى فريق العمليات ، لا يُترك لهم سوى الحد الأدنى من الوقت لإنشاء حالات اختبار جديدة وتنفيذها. لذا فقد تخطوا العديد من حالات الاختبار التي أدركوا لاحقًا أنها كانت ذات أولوية عالية.
المرحلة 3:
على الرغم من أن التصميم يبدو أنه جاهز لبدء الإنتاج ، إلا أن النتائج غير متوقعة تمامًا. فشل البناء وحدث عدد من الأخطاء.
ثم بالنسبة لكل خطأ حدث ، يجب عليهم تتبع سبب حدوث ذلك ، وأين حدث ، وما هي التغييرات التي يجب إجراؤها للتغلب عليها ، وهل سيكون هناك تغيير في أكواد الآخرين لجعلها متوافقة مع الرموز السابقة. أخيرًا ، لجميع هذه الأخطاء ، يجب إنشاء تقرير خطأ.
يرجع الفشل إلى أخطاء في النظام بسبب جهل مطور قاعدة البيانات بكفاءة الكود ، وجهل المختبر في عدد حالات الاختبار ، إلخ.
نظرًا لأن العميل يحافظ دائمًا على الموعد النهائي ضيقًا ، فإن الموظفين المشاركين في تحقيقها يركزون فقط في الإصدار النهائي حتى لو اضطروا إلى التنازل عن الجودة الشاملة.
على الرغم من أن هذا يبدو مشكلة في تنسيق العمل ، هذا في الواقع هو فشل الثقافة المعتمدة.
يحدث هذا بسبب الاعتماد الكبير على العمليات اليدوية. إن الركض إلى نفس الفريق ذهاباً وإياباً بسبب نقص المعرفة بمجال مختلف ، ونقص الوصول أو قد يكون عدم الاهتمام يزيد من أعبائنا وألمنا.
لقد حان الوقت لأن نكون متعددي الاستخدامات. قد يكون من الصعب أن تتحكم في جميع العمليات التي ينطوي عليها النظام ، ولكن يمكننا أن نكون جاك للجميع ، ونتقن واحدة من بينها. عندها فقط يمكننا أتمتة نظامنا أو جعله ذكيًا بما يكفي للتعافي بدلاً من التراجع.
الآن ، ربما تفكر لماذا؟
ذلك لأن الشخص الذي تتقنه يعتمد بشكل كبير على الآخرين. لذا لمعرفة نقطة التبعية ، نحتاج إلى فهم النظام بأكمله.
هياكل البيانات والخوارزميات جافا
لذلك دعونا نفكر في عملية لتغيير الثقافة. قبل ذلك ، هل لديك إجابة على الأسئلة التالية؟
- أين تفشل ثقافتك الحالية؟
- لماذا ترغب في تغيير العملية؟
- هل حددت بوضوح جميع التغييرات المطلوبة؟
- هل حصلت على تعليقات وتأييد من جميع أصحاب المصلحة المتأثرين؟
- هل قمت بإعادة التحقق من عملية الانضباط والبيانات ونظام القياس للتغيير؟
لذلك ، الآن عندما يكون لدينا الجواب للجميع ، نفكر في ثورة في نظامنا. كيف ستحدث هذه الثورة؟ لا يمكن تحقيقه إلا عندما نقتل ما نحن عليه الآن. يضيع الكثير من الوقت في ترحيل الكود بين الفرق. علينا أن نجلب العملية حيث يمكننا القيام بالتكامل المستمر والنشر المستمر.
عملية التكامل والنشر المستمرة هذه تجعلها أكثر مرونة. يعتبر جلب هذه الرشاقة بمثابة ثقافة DevOps.
DevOps هي ممارسة العمليات ومهندسي التطوير الذين يشاركون معًا في دورة حياة الخدمة بأكملها ، من التصميم إلى عملية التطوير إلى دعم الإنتاج.
ليس من السهل تغيير نظام العمل بمرور الوقت. إن إجراء انتقال ناجح هو تجديد النظام بدلاً من إعادة بنائه.
الآن دعونا نرى كيف يمكننا تحقيق ذلك. يمكن أن يكون هناك طريقتان للتعامل.
1) من أعلى إلى أسفل
2) من الأسفل إلى الأعلى
بالتعمق في هذه التقنيات ، سوف ندرك ما هو الأنسب لمنظمتنا.
في النهج من أعلى إلى أسفل ، يمكننا الانتقال إلى الإدارة العليا ونطلب منهم إجراء تغييرات عبر جميع الفرق. إذا اقتنعت الإدارة ، فيمكننا البدء في العمل عليها.
لكن احتمال الحصول على الإجابة بـ 'لا' مرتفع للغاية. ذلك لأن تغيير النظام يمكن أن يؤدي بالمنظمة إلى عدم الاستقرار.
يتعين عليهم النظر في هيكل المنظمة ، والإيرادات ، ومستوى اهتمام العميل ، وما إلى ذلك. ولكن العامل الأكثر أهمية الذي يدفعهم للخروج من النظام القديم هو أنهم لا يستطيعون رؤية صورة كبيرة لما يمكن تحقيقه ومدى سلاسة تحقيقه مع الإصدار الأحدث.
في هذه الحالة ، يمكننا البحث عن الطريقة الثانية للحصول على هذه الصورة الكبيرة.
النهج من أسفل إلى أعلى يدعو إلى التطوع. هنا علينا أن نأخذ فريقًا صغيرًا ومهمة صغيرة وننفذها في نموذج DevOps.
بالنظر إلى الجانب التقني لهذا النموذج ، لدينا مجموعة متنوعة من الأدوات المتطورة التي تجعل العمل أكثر كفاءة وسرعة. ولكن ، الأدوات وحدها ليست قادرة بما يكفي لإنشاء بيئة تعاونية يشار إليها باسم DevOps.
يتطلب إنشاء مثل هذه البيئة التفكير خارج الصندوق ، على سبيل المثال تقييم وإعادة تنظيم كيف يفكر الناس في فرقهم ، والأعمال التجارية والعملاء.
يعد تجميع مجموعة جديدة من الأدوات أسهل من تغيير الثقافة التنظيمية. من خلال الترويج للمطورين الرئيسيين المناهضين للمجتمع ، والسماح بدمج التعليمات البرمجية غير الفعالة ، ونشر الرموز التي لم يتم اختبارها بشكل صحيح ، وإلقاء اللوم على رأس بعضنا البعض ، واعتبار فريق العمليات غبيًا ، ليست أفضل الممارسات التي نتبعها لتمكين الأعمال وخلق قيمة لعملائنا.
ليست الأدوات ، بل الأشخاص الذين يستخدمونها هم من يجعل العملية معقدة. أن نقول على مستوى مجرد بدلاً من جمع الأفكار والسلوكيات ، فإن الانفتاح عليها يأخذنا إلى طريق مشرق.
لنبدأ بفريق مكون من 6 أعضاء وقصة من 3 نقاط. أولاً ، يتعين علينا كسر الفريق الذي نطلق عليه اسم المطورين والعمليات والمختبرين وما إلى ذلك. فنحن نعتبرهم جميعًا واحدًا ، مثل 'DevOps'. عندما نتلقى المتطلبات ، نحتاج إلى تحليل مناطق الخطر. مع الأخذ في الاعتبار الأجزاء العميقة من البحر والهيل .. نبدأ الإبحار.
كيف نفعل لقوة جافا
الآن ، يجب أن تفكر في 'ما هو العامل x لهذه التكامل المستمر والنشر المستمر الذي يقلل من احتمال الفشل'.
من خلال الرؤية والعملية المحسّنة ، يمكننا الاقتراب من الإدارة بوضع صورة واضحة للنتائج مثل مدى سلاسة العملية ، وكيف تم تقليل مخاطر الفشل ، وكيف تم إكمال المهمة قبل الجدول الزمني ، إلخ.
الآن ، يمكننا أن نتخيل بوضوح كيف تم تحسين العملية برمتها على أسس فنية وثقافية من خلال الرجوع إلى الماضي بعد كل تكرار.
قامت Edureka برعاية خاصة يساعدك على إتقان المفاهيم حول Puppet و Jenkins و Ansible و SaltStack و Chef وغيرها.
لديك سؤال لنا؟ أذكرها في قسم التعليقات وسنعاود الاتصال بك.
المنشورات ذات الصلة: