قدمت شركة تويوتا مصطلح "كايزن" ، وقد كتب الكثير عنه في كتب سميكة من سلسلة تويوتا تاو.
يُطلق على كايزن أيضًا "عملية التحسين المستمر". عادةً ما يرتبط بالإنتاج الصناعي للسيارات والناقلات ، جيدًا ، أو على الأقل مع التحكم في العملية. يقولون القليل عن التطوير ، لكن كايزن مناسبة تمامًا لتطوير البرمجيات.
علاوة على ذلك ، سوف تتعرف على العديد من الحالات التي قادت المؤلف تدريجياً إلى فهم كايزن في التنمية.
سلسلة من المشاكل
حدثت الحالة الأولى مباشرة في رأس السنة ، الساعة 20:00. تحطمت القرص الصلب على الخادم وبسبب ذلك كان من الضروري الابتعاد عن إعداد السلطات والانتقال على وجه السرعة إلى موسكو إلى موقع تبادل حركة المرور لتغيير الجهاز المعطلة.
بعد القرص الصلب ، أحرقت اللوحة الأم. لقد غيروا كل شيء ، لكنهم قرروا بعد ذلك معرفة سبب حدوث ذلك.
أوضح المسؤولون المألوفون أنك بحاجة إلى توخي الحذر الشديد بشأن أجهزة الخادم ، وليس لشراء أي مكان وحجز كل شيء وعلى كل مستوى.
تقرر تغيير الخادم وتوخي الحذر عند اختيار مزود. نظرنا إلى أجهزة الخادم وطلبنا التوصيات واخترنا خادمًا يعمل لاحقًا دون توقف ودون انقطاع لمدة 7 سنوات. يستمر في العمل الآن ، على الرغم من مرور 5 سنوات منذ ترك المؤلف ذلك العمل.
مر بعض الوقت وحدث حريق في الموقع. نجا الخادم بأعجوبة. ثم الجميع هز جيدا ، ل كان هناك خطر التدمير الكامل للأعمال.
بعد ذلك ، تم إنشاء مرآة للموقع وقاعدة البيانات في موقع منفصل ومستقل تمامًا في الطرف الآخر من المدينة. وبمجرد استخدامها.
كانت هناك أيضًا حالة عندما بدأت حركة المرور على الموقع الذي تم إطلاقه للتو ، وفجأة توقفت تمامًا ، لم تستطع تحمل العبء.
بعد الدراسة ، أصبح من الواضح أن شركة الاستعانة بمصادر خارجية التي أنشأت الموقع جعلت من ذلك أنها لا تحتجز أكثر من 200 شخص في اليوم. مضحك وحزين.
بعد ذلك ، تقرر التخلي عن الاستعانة بمصادر خارجية وتشكيل فريق التطوير الخاص بك.
بعد إنشاء الفريق ، واجهنا مشكلة واحدة أخرى - تسبب تصحيح أي خطأ في حدوث عدد كبير من الأخطاء الجديدة. أي تغييرات طغت تقريبا الموقع بأكمله.
يستلزم كل إصلاح عددًا كبيرًا جدًا من المشكلات. عندما قمنا بتحليل الموقف ، أدركنا أننا بحاجة إلى تغيير كل شيء بشكل أساسي بشكل عام - جميع العناصر الداخلية. ثم تم إعادة بناء الموقع بالكامل بالكامل ، وتم قلب هيكله بالكامل رأسًا على عقب. وفقط بعد ذلك تغير الوضع تغيرا جذريا واختفت المشاكل تماما.
القضاء على السبب الجذري
تم توحيد كل هذه الحلول بشيء واحد - كانت جميعها تهدف إلى ضمان عدم ظهور المشكلة الجذرية الكامنة وراءها مرة أخرى ، بحيث يتم القضاء عليها تمامًا. من الكلمة على الإطلاق. ولن تتكرر هذه المشكلة مرة أخرى.
هل تفهمين
الابتدائية: تعطل جهاز الكمبيوتر - أدركنا أنه يجب علينا اختيار الأجهزة المناسبة ، والتي لن تفشل أبدا.
اشتعلت النيران في الموقع - قاموا بعمل نسخة لاستبعاد حدوث حالة مماثلة في المستقبل.
ثم لم تعرف الكلمات شيئًا كيزن.
5 لماذا
ليس السبب الجذري للمشكلة دائمًا على السطح ، في بعض الأحيان يكون عليك الحفر فيه.
أعطيت مثالا جيدا في أحد كتب تويوتا تاو. في المصنع ، تم اكتشاف أن إحدى الآلات كانت خامدة لفترة طويلة من اليوم.
لماذا لديه فواصل في العمل؟ اتضح أن الجهاز يتوقف عن التنظيف.
حول الجهاز هو رقائق والأوساخ. بطبيعة الحال ، إذا كان هناك حلاقة حولها ، فيجب إزالتها ، وإلا فإنه من المستحيل العمل. هل هذا صحيح؟
لكن كايزن يقول: عليك أن تحفر إلى السبب الجذري.
لماذا سقوط رقاقة؟ تأتي الإجابة على الفور: تتراكم الشرائح لأنها لا تذهب إلى أي مكان - لا يحتوي الجهاز على جهاز يسمح بإزالته وجمعه. إذا كان هناك مثل هذا الجهاز ، فلا يجب إيقاف الجهاز.
حسنًا ، دعنا نتوصل إلى حل يتيح إزالة هذه الشريحة من الجهاز وجعلها لا تتوقف عن التنظيف على الإطلاق. هذا الحل هو بالفعل تقنية بحتة وبسيطة للغاية.
هناك تقنية بسيطة للغاية لتحديد السبب الجذري: طريقة "5 لماذا" المعروفة.
توصي Kaizen باستخدامه للوصول إلى أسفل الأسباب الجذرية.
النظر باستمرار في أسباب المشكلة ، واحدة تلو الأخرى:
- لماذا تتوقف الآلة؟ لأن التنظيف يتم.
- لماذا يتم التنظيف؟ لأن الرقائق والأوساخ تطير من الجهاز.
- لماذا تطير الرقائق والأوساخ؟ لأنها لا تبتعد عن الجهاز.
بمساعدة "5 لماذا" نجد السبب الجذري ، والتوصل إلى حل للقضاء عليه ، وتعيين شخص مسؤول والمواعيد النهائية ، والتحقق على أساس أسبوعي من تحقيق النتيجة.
فقط ضع في اعتبارك أن أي مشكلة يمكن حلها بطرق باهظة الثمن ورخيصة.
يقول كيزن: أولا اختيار أرخص وسيلة. وعادة ما يكون أبسط وأفضل.
كيزن في تطوير البرمجيات
والآن بعض الأمثلة الحديثة من حياة فريق تطوير البرمجيات.
فيل جوبز
يقوم الفريق بنشر أفضل ممارساتهم في Prod من خلال إطلاق Jenkins. في الواقع ، Jenkins هو sheduler مثل crontab التي يمكن تشغيل وظائف مجدولة. وكان الفريق مثل هذا العمل.
بمجرد اكتشاف أن Prod-Jobs انخفض 5 مرات على التوالي مع حالة الفشل. ولم يهتم أحد بهم ، على الرغم من حقيقة أنه في الواقع ، يجب أن يكون كل ملف على Prod بمثابة إنذار عالمي.
ثم بدأوا في معرفة السبب باستخدام طريقة "5 لماذا":
- لماذا انقلبت الوظائف خمس مرات ولم يهتم أحد؟ لأن الجميع يتلقى باستمرار إخطارًا بالوظائف الشاغرة ، فهناك الكثير منهم ، وأصبحوا مألوفين
- لماذا أصبحت مألوفة؟ لأن كل يوم تقريبًا نتلقى نوعًا من الإخطارات ، تفشل ولا تفشل. نحن لا نرى الفرق. إنهم لم يهتموا بهم فقط.
- لماذا لا تأتي الإخطارات كل يوم؟ نظرًا لأن أحد المطورين يختبر وظيفة جديدة تسقط ، وتذهب الإخطارات المتعلقة بها إلى الجميع. الوظيفة ليست مهمة في الوقت الحالي ، لذلك توقف الجميع عن الانتباه إلى الإخطارات منها ، وفي الوقت نفسه ، من جميع الوظائف الأخرى.
كان القرار شفافًا: بالنسبة لوظائف الاختبار ، لن يتم إرسال إعلامات حول الملفات إلى أي شخص باستثناء مالك الوظيفة ، وحتى إذا كان يحتاجها.
بالإضافة إلى ذلك ، تم تسجيله رسميًا أن أي إخطار من الوظيفة يمثل حالة طارئة استثنائية يجب على الجميع الاستجابة لها.
سقطت النصي
المثال الثاني هو مشكلة في تطبيق QlikView.
بمجرد إخبار الفريق بأن تقارير QlikView كانت مختلفة إلى حد ما. يبدو أن كل شيء يعمل ، لكن البيانات ليست هي نفسها. لقد بدأوا في فهم المشكلة.
اتضح أن البرنامج النصي للتحميل لم ينجح حتى النهاية. لماذا لم تنجح حتى النهاية؟ نظرًا لوجود الكثير من التعليمات البرمجية في البرنامج النصي وفي مكان ما في الوسط كان مشغل تصحيح الخروج Exit Script - لقد نسوا ببساطة إزالته ولم يلاحظوه. تحول الموقف عندما سقط البرنامج النصي للتنزيل ، وكانت البيانات قديمة.
لماذا لم تلاحظ هذا؟ لأن الاختبار لم تظهر هذا بسبب الهندسة المعمارية. تم تقسيم التطبيق إلى جزأين مستقلين (البرنامج النصي للخلف / التنزيل والأمام) ، وهكذا. كان هناك الكثير من البيانات ، حاولوا عدم إعادة تشغيلها مرة أخرى ، حتى لا تضيع الكثير من الوقت في هذا.
تم تصنيعها خصيصًا بحيث لا تكون الواجهة الأمامية متصلة بنص التحميل. لقد أخذ ملف بيانات معين وأظهره. لم يكن من الواضح أن ملف البيانات هذا قديم ، أي أنه كان من المستحيل تحديد وجود خطأ فيه.
ما الذي تم اختراعه لتجنب وضع مماثل في المستقبل؟
سأل الفريق أنفسهم السؤال التالي: كيف نتأكد من ملاحظة مثل هذا الموقف في المستقبل؟ كيفية توضيح أن البرنامج النصي للتحميل لم يعمل حتى النهاية؟
تقرر تسجيل التسمية في بداية البرنامج النصي ، وحذفها في النهاية. أي إذا لم يتم حذف التصنيف ، فهذا يعني أن البرنامج النصي لم يكمل التنزيل حتى النهاية. التحقق من أنه في حالة وجود علامة ، فإنه سيعرض لافتة حمراء على أرضية الصفحة مع إشعار حول المشكلة.
وبالتالي ، على الرغم من أن احتمال ظهور مثل هذه المشكلات لم يستبعد بالكامل ، فقد أصبح معروفًا عنها على الأقل. حل بسيط رخيصة.
فقدان البيانات على إعادة التشغيل
تلقت خدمة مراقبة الويب البيانات من المدرجات الصناعية. بشكل دوري ، كان لا بد من الانتهاء منه وتصحيحه ، وكل تصحيح يتطلب إعادة تشغيل الكمبيوتر. على الرغم من أن عملية إعادة التشغيل استمرت بضع ثوانٍ ، إلا أن البيانات الصناعية والهاوية قد تكون مضمونة في ذلك الوقت. كان من المستحيل خسارتها ، لذلك قرر الفريق تحليل المشكلة بعمق أكبر.
أوضحت الأسئلة "5 لماذا" أن السبب الجذري للمشكلة هو العمارة - فلم تكن تسمح بذلك. بغض النظر عن مدى تشديد الخدمة ، وبغض النظر عن ما فعلوه بها ، كل هذا ، كل ذلك يعود إلى إعادة تشغيل الكمبيوتر.
حل الهيكل الجديد المشكلة مرة واحدة وإلى الأبد - تم تقسيم الخدمة إلى قسمين مستقلين ، وهما استقبال البيانات ومعالجتها. تم فصل هذه الأجزاء جسديًا ، أي يمكنك إيقاف تشغيل المعالج بأمان ، بينما استمر تلقي البيانات في العمل وحفظ كل ما يتعلق به. والأهم من ذلك ، تم عمل جهاز استقبال البيانات بحيث لا يحتاج إلى إعادة تشغيل. يمكن إيقاف تشغيل المعالجات بأمان وتعديلها وتحميلها دون الحاجة إلى القلق بشأن إمكانية فقد البيانات.
يبدو أن DevOps موجود ، لكن لا يبدو أنه موجود
DevOps هو شيء سحري. يبدو أن هناك ، ولكن في الوقت نفسه يحدث أيضا أنه غير موجود.
نشر أحد المطورين أفضل ممارساته على منصة الاختبار. على الرغم من حقيقة أنه استخدم DevOps ، "فجأة" اتضح أن اختبار البدلاء كان متصلاً بقاعدة البيانات القتالية. تم فقد جزء من البيانات بشكل لا رجعة فيه.
بدأنا في معرفة ذلك. اتضح أن المطور لم يلاحظ أنه كان يستخدم سلسلة معركة الاتصال.
السبب الجذري هو أنه كان على المطور تغيير سلسلة الاتصال يدويًا لمختلف المنصات والخوادم.
ماذا يقول كايزن؟ هذا صحيح! يجب أن نتوصل إلى مثل هذا الحل لإزالة المشكلة تمامًا ، أي إزالة الحاجة لتغيير الخط يدويا.
وتم تنفيذ الحل - بدأت سلسلة الاتصال يتم اختيارها تلقائيًا وفقًا للخادم الذي كان يعمل عليه. تم حل المشكلة مرة واحدة وإلى الأبد.
أعتقد أنك قد فهمت بالفعل من خلال الأمثلة المذكورة أعلاه أنه يمكن التعبير عن جوهر التحسين المستمر في عبارة واحدة بسيطة - للقضاء تمامًا على تكرار المشكلة.
النتائج الرئيسية - جزء لا يتجزأ من كايزن
نتيجة كايزن هي الإدراك وليس الفكرة.
إن التوصل إلى حل ليس بالأمر الصعب ، بل من الصعب تنفيذه.
لكل قرار يتم اتخاذه ، من المهم تقديم نتائج رئيسية ، أي فهم من يحتاج إلى القيام بماذا وبأي تاريخ.
كيف تفهم أنك حققت نتيجة ناجحة؟
لنأخذ مثالا على سلسلة الاتصال. ما النتيجة
المادية التي ستعتبر النجاح هنا؟ سوف يتحقق النجاح عندما:
- سيتم إنشاء مكتبة لتحديد سلسلة الاتصال تلقائيًا ،
- سيقوم المطور ببناء مكتبة لنفسه وإطلاق برنامجه بنجاح.
يجب أن يتخذ كلا الخطوتين تاريخًا معينًا بواسطة بعض الأشخاص. فقط مع كلتا الخطوتين يمكن أن نفترض أن النجاح قد تحقق.
النتائج الرئيسية هي معايير النجاح ؛ كايزن لا يعمل بدونها. النجاح هو التنفيذ.
الحل الوحيد الذي سيتم تنفيذه هو الذي سيسمح لك بإزالة المشكلة في المستقبل ، لذلك عند الحديث عن كايزن يعني دائمًا أن عليك تنفيذ كل ما تم اختراعه.
في أي مكان آخر يمكن تطبيق ذلك
كما رأيت على الأرجح من الأمثلة ، يمكن ويجب أن تستخدم كايزن في تحليل الحادث. في الواقع ، تم إنشاؤه لهذا الغرض.
تعتبر الحوادث في مجموعات الدعم الفني والبنية التحتية وتطوير المنتجات مثالية.
بالنسبة للترميز ، يمكنك هنا تحليل الشفرة الخاصة بك ومعرفة كيفية تغييرها من أجل إزالة المشاكل الموجودة بشكل دائم.
نعم ، و Agile-retro سيئة السمعة هي أيضًا كايزن ، لأنه في هذه الاجتماعات يتم تحليل المشكلات من أجل العدو ، يتم طرح الأسئلة "5 لماذا" ، ويتم اتخاذ خطوات لمنع المشاكل. كايزن الأكثر طبيعية!
تعمل تقنية كايزن نفسها بشكل جيد في تطوير البرمجيات ، فهي سهلة الاستخدام ومناسبة تمامًا للاستخدام في الأمور الشخصية.
سر النجاح بسيط: قم بإزالة المشكلات واحداً تلو الآخر ، ثم لن تبقى على الإطلاق. هذا هو التحسين المستمر.
تستخدم تويوتا نفسها كايزن في الإنتاج بنجاح ساحق. نتائجها تتحدث عن نفسها: عيوب الإنتاج ليست سوى 3 عيوب لكل 1،000،000 أجزاء.
لماذا لا تطبق ذلك بنفسك؟
الآن يتم ضخك رسميا. إذا سمعت مثل هذا المصطلح ، فسوف تعرف ما هو عليه.
والنجاح في عملك.