الديون الفنية التي تؤدي إلى أزمة الشركة

تراكم الديون التقنية قد يؤدي إلى حدوث أزمة بين شركتك. ولكن قد يصبح أيضًا محركًا قويًا للتغييرات الهائلة في العمليات والمساعدة في عمليات تبني الممارسات الهندسية. سأخبرك عن ذلك على سبيل المثال الخاص بي.



نما فريق Dodo Pizza IT من مطورين يخدمان دولة واحدة إلى 60 شخصًا يخدمون 12 دولة على مدار 7 سنوات. بصفتي Scrum Master و XP Coach ، ساعدت الفرق في إنشاء عمليات وتبني ممارسات هندسية ، لكن هذا الاعتماد كان بطيئًا جدًا. لقد كان من الصعب بالنسبة لي أن أجعل الفرق تحافظ على جودة الكود عالية عندما تعمل فرق متعددة على منتج واحد. لقد وقعنا في فخ التفضيل لميزات العمل على التفوق التقني وتراكم الكثير من الديون التقنية المعمارية. عندما أطلق التسويق حملة إعلانية ضخمة في عام 2018 ، لم نتمكن من تحمل العبء وسقطنا. كان عار. لكن خلال الأزمة ، أدركنا أننا قادرون على العمل عدة مرات بكفاءة أكبر. دفعتنا الأزمة إلى إحداث تغييرات ثورية في العمليات والإدخال السريع لأفضل الممارسات الهندسية المعروفة.

خلفية

قد تعتقد أن Dodo Pizza هي شبكة بيتزا منتظمة. ولكن في الواقع Dodo Pizza هي شركة لتكنولوجيا المعلومات تصادف بيع البيتزا . يعتمد عملنا على منصة Dodo IS - القائمة على الحوسبة السحابية ، والتي تدير جميع العمليات التجارية ، بدءًا من اتخاذ الأمر ، ثم الطهي والتشطيب إلى إدارة المخزون وإدارة الأفراد واتخاذ القرارات. في 7 سنوات فقط ، نمنا من مطورين يقدمان بيتزا واحدة إلى أكثر من 70 مطورًا يقدمان 470+ بيتزا في 12 دولة.

عندما انضممت إلى الشركة قبل عامين ، كان لدينا 6 فرق وحوالي 30 مطورًا. تحتوي قاعدة بيانات Dodo IS على حوالي 1 مليون سطر من التعليمات البرمجية. كان لديها بنية متجانسة والتغطية اختبارات وحدة القليل جدا. لم يكن لدينا اختبارات API / UI بحلول ذلك الوقت. كانت جودة كود النظام مخيبة للآمال. لقد عرفنا ذلك وحلمنا بمستقبل مشرق عند تقسيم المتراصة إلى العشرات من الخدمات وإعادة كتابة أكثر أجزاء النظام فظاعة. نحن حتى نرسم مخطط "أن نكون معماريين" ، لكن بصراحة لم نفعل شيئًا تقريبًا تجاه الدولة المستقبلية. كان هدفي الأساسي هو تعليم الممارسات الهندسية للمطورين وبناء عملية تطوير ، وجعل 6 فرق تعمل على منتج واحد .

مع نمو الفريق ، عانينا من نقص العمليات والممارسات الهندسية الواضحة أكثر. أصبحت إصداراتنا أكبر وأطول لأن المزيد من المطوّرين ساهموا في النظام ، لكننا لم نختبر اختبارات الانحدار الآلية وبالتالي أهدرنا المزيد من الوقت في التراجع اليدوي مع كل إصدار. لقد عانينا من العديد من التغييرات التي أجراها 6 فرق في فروع منفصلة. عندما قامت الفرق بدمج تغييراتها في فرع واحد قبل الإصدار ، فقد اعتدنا في بعض الأحيان على فقد ما يصل إلى 4 ساعات لحل تعارضات الدمج.

القرف يحدث

في عام 2018 ، شغّل التسويق أول حملة إعلانية فدرالية على التلفزيون . لقد كان حدثًا ضخمًا بالنسبة لنا. لقد أنفقنا 100 مليون روبل (1.5 مليون دولار) لتمويل الحملة - وهو مبلغ كبير بالنسبة لنا. فريق تكنولوجيا المعلومات على استعداد للحملة أيضا. لقد قمنا تلقائيًا بتبسيط عملية النشر الخاصة بنا - الآن باستخدام زر واحد في TeamCity ، يمكننا نشر المتراصة في 12 دولة. لقد بحثنا في اختبارات الأداء وأجرينا تحليل الثغرات الأمنية. بذلنا قصارى جهدنا ولكن واجهنا مشاكل غير متوقعة.

كانت الحملة الإعلانية رائعة. ذهبنا من 100 إلى 300 أوامر / دقيقة. كانت هذه أخبار جيدة. كانت الأخبار السيئة أن Dodo IS لم تستطع تحمل مثل هذا الحمل وتوفي. لقد حققنا حدود التوسع الرأسي ولم نتمكن من التعامل مع الطلبات بعد الآن. أعيد تشغيل النظام كل 3 ساعات. كل دقيقة من وقت التوقف عن العمل كلفتنا ملايين المال ، وكذلك فقدت الاحترام من العملاء الغاضبين.

عندما جئت إلى Dodo قبل عامين بصفتي كبير موظفي Agile ، كانت لدي رغبة كبيرة في تكوين فريق صغير لدينا - حوالي 12 شخصًا ، فريق حلم. بدأت على الفور تقديم الممارسات الهندسية. اعتمدت معظم الفرق البرمجة الزوجية واختبار الوحدة و DDD قريبًا. ولكن ليس كل شيء كان سهلا. اضطررت إلى التغلب على مقاومة المطورين ومالك المنتج وفريق الدعم.

على عكس الممارسات الهندسية ، لم يحبذ الجميع فكرة فرق العمل. اعتاد المطورون على التفكير في أن فريقًا يركز على مكون واحد يقوم بكتابة كود أفضل. لم يكن من الواضح كيف يتم الجمع بين التطور السريع لميزات الأعمال مع إعادة الهيكلة الضخمة التي طال انتظارها لنظام معقد. دفق مستمر من الأخطاء يتطلب أيضا اهتمام مستمر. فضل فريق الدعم وجود فريق خاص بهم يركز على إصلاح الخلل فقط. اعتدت العديد من الفرق على العمل في فروع منفصلة وكانت خائفة من الاندماج بشكل متكرر. لقد أصدرنا ما لا يزيد عن مرة واحدة في الأسبوع ، واستغرق كل إصدار وقتًا طويلاً ، وتطلب مقدارًا هائلاً من الارتداد اليدوي ودعم اختبارات واجهة المستخدم. حاولت إصلاحه ، لكن التغييرات في عملي كانت بطيئة ومجزأة.

قصة السقوط والصعود

الحالة الأولية: العمارة المتجانسة

سعياً وراء سرعة تطوير ميزات الأعمال ، لم نفكر دائمًا في الحلول التقنية جيدًا. قلة الخبرة أثرت علينا أيضًا. في البداية ، لم تستطع الشركة تحمل توظيف أفضل المطورين. لقد عملنا مع المتحمسين الذين وافقوا على المساعدة في إنشاء Dodo IS ، المؤمن بمؤسس الشركة - Fedor وعملنا تقريبًا من أجل الغذاء (البيتزا بالطبع). قام المطورون الذين انضموا إلى الفريق لاحقًا باتباع الهيكل المعمول به والذي أصبح قديمًا. لذلك كان لدينا تطبيق متجانسة مع قاعدة بيانات واحدة ، تحتوي على جميع البيانات من جميع المكونات في مكان واحد. المتعقب ، الخروج ، الموقع ، واجهة برمجة التطبيقات للصفحات المقصودة - عملت جميع مكونات النظام مع قاعدة بيانات واحدة ، والتي أصبحت عنق الزجاجة. خلقت العمارة متجانسة لدينا مشاكل متجانسة. أدى نشر مدونة واحدة إلى انقطاع خدمة تسجيل الخروج من المطعم.

قصة حقيقية

لتوضيح مدى هشاشة بنية متجانسة ، سأقدم مثال واحد فقط. بمجرد توقف جميع مطاعمنا في روسيا عن قبول الطلبات بسبب نشر مدونة. كيف يمكن أن يحدث هذا؟

في يوم من الأيام ، نشر الرئيس التنفيذي لدينا - Fedor منشورًا على مدونته. هذا المنصب اكتسب شعبية بسرعة. يوجد عداد على موقع الويب الخاص بمدونة Fedor يُظهر عددًا من البيتزا في سلسلتنا وإجمالي الإيرادات لكل مطاعم البيتزا. في كل مرة يقرأ شخص ما مدونة فيدور ، يرسل خادم الويب طلبًا إلى قاعدة البيانات الرئيسية لحساب الإيرادات. أثقلت هذه الطلبات قاعدة البيانات وتوقفت عن تقديم الطلبات من تسجيل الخروج من المطعم. لذلك عطل منشور مدونة شهير عمل سلسلة المطاعم بأكملها. لقد حللنا المشكلة بسرعة ، لكن كانت علامة واضحة (من بين أشياء أخرى كثيرة) على أن بنيتنا غير قادرة على تلبية احتياجات العمل ويجب إعادة تصميمها. لكننا تجاهلنا هذه العلامات. قمنا بتطبيق حلول سريعة وسهلة (مثل إضافة نسخة متماثلة للقراءة فقط من قاعدة البيانات الرئيسية) ، ولكن لم يكن لدينا أي خريطة طريق لإعادة تصميم التقنية.

العمارة المتجانسة جيدة للبدء لأنها بسيطة. ولكن لا يمكن أن تصمد أمام الحمولة العالية كونها نقطة فشل واحدة.

فشل مبكر في عام 2017

14 فبراير هو عيد الحب . الجميع يحب هذه العطلة. بالنسبة إلى العشاق لتهنئة بعضهم البعض ، في 14 فبراير ، نقوم بصنع بيتزا خاصة - بيبيروني على شكل قلب. سوف أتذكر 14 فبراير 2017 إلى الأبد ، لأنه في هذا اليوم ، عندما كانت جميع مطاعم البيتزا تعمل بكامل طاقتها ، بدأت Dodo IS في الانخفاض. في كل بيتزا لدينا 4-5 أقراص لتتبع الطلب الذي يجعل صانع البيتزا يصنع العجينة أو يوضع المكونات أو يخبز أو يرسل إلى التسليم. بلغ عدد مطاعم البيتزا 300+ ، قام كل قرص بتحديث حالته عدة مرات في الدقيقة. خلقت كل هذه الطلبات مثل هذا الحمل الضخم على قاعدة البيانات التي توقف خادم SQL عن الصمود وبدأت قاعدة البيانات في الفشل. وضعت Dodo IS في اللحظة الأكثر ملائمة - خلال ذروة المبيعات. كان هناك موسم عطلة مزدحم: 23 فبراير (يوم الجيش والبحرية) ، 8 مارس (يوم المرأة العالمي) ، 1 مايو (يوم التضامن الدولي للعمال) و 9 مايو (يوم النصر في الحرب العالمية الثانية). خلال هذه الأعياد ، كنا نتوقع نمو طلبات أكبر.

اليوم الذي سأموت فيه . بمعرفة خطط النمو الخاصة بنا والحد الأقصى للحمل الذي يمكننا تحمله ، اكتشفنا كم من الوقت يمكننا البقاء على قيد الحياة ، أي عندما يصبح الحمل الأقصى اليوم منتظمًا. التاريخ المتوقع لهرمجدون المتوقع في حوالي ستة أشهر - في أغسطس أو سبتمبر. كيف تشعر أن تعيش ، ومعرفة تاريخ وفاتك؟

وقف تطوير الميزة لمدة عام . جنبا إلى جنب مع الرئيس التنفيذي لشركة فيدور ، كان علينا اتخاذ قرار شاق. ربما يكون أحد أصعب القرارات في تاريخ الشركة. توقفنا عن تطوير ميزات العمل. كنا نظن أننا سنتوقف لمدة 3 أشهر ، ولكن سرعان ما أدركنا أن حجم الدين الفني كان كبيرًا جدًا بحيث لا تكون فترة الثلاثة أشهر كافية ، وعلينا مواصلة العمل بشأن المسائل الفنية وتأجيل الأعمال المتراكمة. في الواقع ، مع 6 فرق عملنا ميزة تجارية واحدة فقط خلال العام المقبل. بقية الوقت ، انخرطت الفرق في سداد الديون الفنية. كلفنا هذا الدين الكثير - أكثر من 1.5 مليون دولار.

بعض التحسينات بعد عام

خلال العام ، حققنا هذه الإنجازات البارزة:

• لقد قمنا بتجهيز وتسريع خط أنابيب التوزيع الخاص بنا. سابقا ، كان النشر شبه اليدوي. نشرنا في 10 دول في حوالي ساعتين.
• بدأ تقسيم متراصة. تم تقسيم الجزء الأكثر تحميلًا من النظام - المتعقب - إلى خدمة منفصلة ، مع قاعدة البيانات الخاصة به. يتواصل المتعقب الآن مع بقية النظام من خلال قائمة انتظار للأحداث.
• بدأنا في فصل أمين صندوق التسليم - المكون الثاني الذي يخلق حمولة عالية.
• أعد كتابة نظام مصادقة المستخدم والجهاز.

تمكن المهندس المعماري لدينا من تراكم التقنية. استخدمنا التغييرات المعمارية لدفع التراكم. كان لكل فريق الحرية في فعل ما هو صواب لإنشاء بنية مفيدة. للسنة مع الفرق السادسة التي قطعناها على أنفسنا للعمل ميزة واحدة فقط قيمة. بقية الوقت ، عملت الفرق على الديون الفنية. يبدو أننا يمكن أن نفخر بأنفسنا. لكن أمامنا كان هناك خيبة أمل كبيرة.

فشل أثناء الحملة التسويقية الفيدرالية. أزمة الثقة الثانية.

من السهل تراكم الديون الفنية ، ولكن من الصعب جدًا سدادها. من غير المحتمل أن تكون قادرًا على فهم المبلغ الذي ستتكلفه مسبقًا.

على الرغم من أننا قضينا عاماً كاملاً في محاربة الديون الفنية ، إلا أننا لم نكن مستعدين لحملة التسويق الضخمة وواجهنا أعمالنا. تثق في قطرات ، تخسره في الدلاء. وكان علينا أن نكسبها مرة أخرى.

لقد فاتنا اللحظة التي كان من الضروري فيها إبطاء سرعة تطوير ميزات العمل ومعالجة الديون الفنية. لقد فات الأوان عندما لاحظنا. نضع تحت الحمل مرة أخرى. تعطل النظام وإعادة تشغيله كل 3 ساعات. خسر عملنا عشرات الملايين من روبل.



ولكن بفضل الأزمة ، رأينا أنه في الظروف القاسية يمكننا أن نعمل عدة مرات بكفاءة أكبر. أصدرنا 20 مرة في اليوم. عمل الجميع كفريق واحد ، مع التركيز على هدف واحد. خلال أسبوعين من الأزمة ، قمنا بما كنا نخشاه من البدء من قبل لأننا اعتقدنا أن الأمر سيستغرق شهورًا من العمل. ترتيب غير متزامن ، اختبارات الأداء ، سجلات واضحة ليست سوى جزء صغير من ما فعلناه. كنا حريصين على الاستمرار في العمل بشكل فعال ، ولكن من دون العمل الإضافي والضغط.

الدروس المستفادة

بعد رجعي ، قمنا بإعادة هيكلة عملياتنا بالكامل. أخذنا إطار عمل LeSS واستكملناه بالممارسات الهندسية. خلال الأشهر القليلة المقبلة ، حققنا طفرة في اعتماد الممارسات الهندسية. استنادًا إلى إطار عمل LeSS ، قمنا بتنفيذ واستمرار استخدام:

• تراكم واحد ؛
• فرق ميزة كاملة الوظائف ومتعددة المكونات ؛
• البرمجة الزوجية ؛
• محاولة الغوغاء البرمجة.
• تكامل مستمر حقيقي ، يعني تكاملات متعددة للكود من 9 فرق في فرع واحد ؛
• إدارة التكوين مبسطة مع التنمية القائمة على الجذع.
• النشرات المتكررة: النشر المستمر للخدمات الميكروية ، والإصدارات المتعددة يوميًا للترابط ؛
• لا يوجد فريق ضمان الجودة منفصل ، خبراء ضمان الجودة هم جزء من فرق التطوير.

6 ممارسات اخترناها بعد الأزمة

1. قوة التركيز . قبل الأزمة ، كان كل فريق يعمل على تراكمه ومتخصص في مجاله. في الأعمال المتراكمة ، كانت هناك مهام متحللة بدقة ، اختار الفريق العديد من المهام لسباق العدو. لكن خلال الأزمة ، عملنا بشكل مختلف تمامًا. لم يكن للفرق مهام محددة ، فقد كان لديهم هدف كبير صعب. على سبيل المثال ، يجب أن يتعامل تطبيق الجوّال وواجهة برمجة التطبيقات مع 300 طلب في الدقيقة ، بغض النظر عن السبب. الأمر متروك للفريق كيفية تحقيق الهدف. تقوم الفرق نفسها بصياغة الفرضيات والتحقق منها بسرعة في الإنتاج والتخلص منها. وهذا هو بالضبط ما أردنا مواصلة القيام به. الفرق لا تريد أن تكون المبرمجين البكم ، فهم يريدون حل المشاكل.

تتجلى قوة التركيز في حل المشكلات المعقدة. على سبيل المثال ، خلال الأزمة ، أنشأنا مجموعة من اختبارات الأداء على الرغم من أننا لم تكن لدينا خبرة. لقد جعلنا أيضًا منطق تلقي طلب غير متزامن. لقد فكرنا فيه لفترة طويلة وتحدثنا معه ، ويبدو لنا أن هذه مهمة صعبة وطويلة للغاية. لكن اتضح أن الفريق قادر تمامًا على القيام بذلك في غضون أسبوعين ، إذا لم يتم صرف انتباههم وتركيزهم بالكامل على المشكلة.

2. hackathons العادية . لقد أحببنا العمل في الوضع عندما تستهدف جميع الفرق هدفًا واحدًا وقررنا في بعض الأحيان ترتيب مثل هذه "الاختراقات". لا يمكن القول أننا ننفذها بانتظام ، ولكن كان هناك عدة مرات. على سبيل المثال ، كان هناك hackathon 500 خطأ عندما قامت جميع الفرق بتنظيف السجلات وإزالة أسباب 500 خطأ على الموقع وفي API. كان الهدف هو الحفاظ على سجلات نظيفة. عندما تكون السجلات نظيفة ، تكون الأخطاء الجديدة مرئية بوضوح ، يمكنك بسهولة تكوين قيم العتبة للتنبيهات. إنه مشابه لاختبارات الوحدة - لا يمكن أن يكون أحمر قليلاً.

مثال آخر على hackathon هو الأخطاء. اعتدنا أن يكون لدينا تراكم أخطاء كبير ، وكانت بعض الأخطاء في تراكم لسنوات. يبدو أنهم لن ينتهيوا أبدا. وكل يوم كان هناك جديدة. عليك أن تجمع بطريقة أو بأخرى بين العمل على الأخطاء وعناصر التراكم العادية.


3. فرق المشروع المؤقتة لفرق ميزة مستقرة . كانت هناك قصة مضحكة مع فرق المشروع. خلال الأزمة ، قمنا بتشكيل فرق النمر من الأشخاص الأكثر مهارة لهذه المهمة. بعد انتهاء الأزمة ، قررت الفرق مواصلة هذه الممارسة وحل الفرق. على الرغم من حقيقة أنني لم أحب هذه الفكرة على الإطلاق ، إلا أنني سمحت لهم بالمحاولة. في أسبوعين فقط (سباق واحد) ، في الماضي التالي ، تخلت الفرق عن هذه الممارسة (هذا القرار جعلني سعيدًا جدًا). لقد جربوا وفهموا سبب الراحة في العمل في فريق عمل مستقر. حتى لو كان الفريق يفتقر إلى بعض المهارات ، فيمكنهم التعلم تدريجياً. ولكن يتم تشكيل روح الفريق والدعم والمساعدة المتبادلة لفترة طويلة ، ويستغرق الأمر أشهر. فرق المشروع على المدى القصير باستمرار في مرحلة تشكيل واقتحام. يمكنك تحمله لبضعة أسابيع ، لكن لا يمكنك العمل بهذه الطريقة طوال الوقت. من الجيد أن الفرق حاولت وفهمت فوائد فرق الميزات الثابتة.

4. تخلص من التراجع اليدوي . قبل الأزمة ، أصدرنا مرة واحدة في الأسبوع ، وخلال الأزمة - عشرات المرات في اليوم. نحن أحب قدرتنا على الإفراج في كثير من الأحيان. لقد قدرنا مدى ملاءمة إجراء تغيير بسيط ونشره بسرعة والحصول على تعقيبات على الفور من الإنتاج. لذلك ، غيّرنا منهجنا تجاه الإصدارات ، مما أثر على نهج البرمجة والتصميم. الآن نحن نصدر باستمرار ، كل 1-2 أيام. كل شيء في فرع ديف يذهب إلى الإنتاج. حتى لو لم تكن بعض الميزات جاهزة ، فلا يوجد سبب لعدم إصدار الكود. إذا لم نرغب في إظهار ميزة غير جاهزة بعد للمستخدمين ، فإننا نخفيها باستخدام ميزة تبديل الميزات. ساعدنا هذا النهج في تطوير خطوات صغيرة.

وضعنا هدفًا للتخلص من الانحدارات اليدوية. استغرقنا 1.5 سنة للوصول إليه. لكن وجود هدف طموح طويل الأجل يجعلك تفكر في الخطوات المؤدية إلى الهدف.


5. اختبار الأداء هو جزء من اختبار الانحدار . خلال الأزمة أنشأنا مجموعة من اختبارات الأداء. لقد كانت منطقة جديدة تمامًا بالنسبة لنا. ومع ذلك ، خلال أسبوعين فقط ، تمكنا من إنشاء بعض اختبارات الأداء باستخدام أدوات Visual Studio. ساعدتنا هذه الاختبارات ليس فقط في تدهور الأداء. استخدمناهم لإضافة تحميل الاصطناعية إلى خادم الإنتاج لتحديد حدود الأداء. على سبيل المثال ، إذا كان حمل الإنتاج العضوي هو 100 طلب / دقيقة وقمنا بإضافة 50 طلبًا / دقيقة أخرى بمساعدة اختبارات الأداء لدينا ، يمكننا معرفة ما إذا كان بإمكان خوادم الإنتاج معالجة الحمل المتزايد. حالما نلاحظ استثناءات أو زيادة زمن الوصول ، نوقف الاختبار. عند إجراء هذه التجارب ، اكتشفنا الحمل الأقصى الذي يمكن لخوادم الإنتاج الخاصة بنا التعامل معه ، وما هي النقطة الفعالة.

في العام المقبل ، تجاوزنا اختبارات الأداء لفريق PerformanceLab ذي الخبرة. جلسوا مع المطورين وأفراد البنية التحتية لدينا ، وساعدونا في إنشاء مجموعة قوية من اختبارات الأداء. الآن نقوم بإجراء هذه الاختبارات أسبوعيًا ونقدم تعليقات سريعة إلى فرق التطوير إذا تأثر الأداء.

تم تحسين بعض الممارسات الهندسية بشكل تكراري. على سبيل المثال ، الإصدارات المتكررة. بدأنا بدورات إصدار أسبوعية ، مدعومة باختبار يدوي بطيء وهش. قمنا بتطوير ميزات لمدة أسبوع واختبارها لمدة أسبوع آخر. ولكن كان من الصعب الحفاظ على التغييرات التي تم إجراؤها بواسطة عدة خلال أسبوع. ثم جربنا إصدارات فريق معزولة ، عندما تم إصدار التغييرات التي أجراها فريق واحد فقط. لكن هذه العملية فشلت لأن كل فريق اضطر إلى الانتظار في قائمة الانتظار لعدة أسابيع. ثم تعلمت الفرق فوائد التكامل المتكرر وبدأنا في ممارسة الإصدارات المرتبطة بتغيرات فرق متعددة. بدأ المطورون في تجربة Feature Toggle والدفع إلى ميزات الإنتاج غير المكتملة. في النهاية توصلنا إلى تكامل مستمر وإصدارات متعددة يوميًا للحصول على متجانسة ونشر مستمر للخدمات الميكروية.



حالة أخرى مثيرة للاهتمام هي مع قسم ضمان الجودة لدينا. اعتدنا ألا يكون لدينا فريق لضمان الجودة ، بدلاً من ذلك كان لدينا اختبار يدوي. أدركنا الحاجة إلى التشغيل الآلي للاختبار ، لقد شكلنا فريق ضمان الجودة ، ولكن منذ اليوم الأول عرف هذا الفريق أنه سيتم حلها في يوم من الأيام. بعد 6 أشهر ، قام الفريق بأتمتة سيناريوهات العمل الرئيسية الخاصة بنا ، وبمساعدة من المطورين ، كتب لغة مناسبة خاصة بالمجال (DSL) لاختبارات الكتابة. انهار الفريق ، وانضم مهندسو الجودة إلى فرق العمل. الآن فرق أنفسهم تطوير وصيانة الاختبارات الذاتية.

اليوم لدينا تراكم واحد يعمل عليه 9 فرق عمل. فرق الميزات هي فرق مستقرة وعبر وظائف متعددة العناصر. معظم فرقنا هي فرق مميزة.

6. التركيز على الممارسات الهندسية . جميع فرقنا تستخدم البرمجة الزوجية. أنا أعتبر البرمجة الزوجية واحدة من أبسط الممارسات القوية التي تساعد على تطبيق الممارسات الهندسية الأخرى. إذا كنت لا تعرف الممارسة الهندسية التي يجب أن تبدأ ، فإنني أوصي بالبرمجة الزوجية.

النتائج

والنتيجة الرئيسية التي أعطتها الأزمة لنا هي التغيير. استيقظنا وبدأنا في العمل. لقد ساعدتنا الأزمة في رؤية أقصى الفرص المتاحة لنا. لقد رأينا أنه يمكننا العمل عدة مرات بشكل أكثر كفاءة وسرعة في تحقيق أهدافنا. ولكن هذا يتطلب تغيير طريقة العمل العادية. لقد توقفنا عن الخوف من إجراء تجارب جريئة. نتيجة لهذه التجارب ، قمنا خلال العام الماضي بتحسين جودة واستقرار Dodo IS بشكل كبير. إذا لم تتمكن مطاعم البيتزا لدينا من العمل خلال عطلة الربيع في عام 2018 بسبب Dodo IS ، ثم في عام 2019 ، مع نمو يتراوح بين 300 و 450 مطعم بيتزا ، عملت Dodo IS بلا عيب. لقد شهدنا بهدوء ذروة المبيعات في العام الجديد ، خلال الحملة التسويقية الثانية وعطلة الربيع. لأول مرة منذ فترة طويلة ، نحن واثقون من جودة النظام وننام جيدًا في الليل. هذا هو نتيجة الاستخدام المستمر للممارسات الهندسية والتركيز على التميز التقني.

نتائج للعمل

ليست هناك حاجة للممارسات الهندسية في حد ذاتها إذا كانت لا تفيد عملك. نتيجة للتركيز على التميز التقني ، نقوم بتحسين جودة الكود وتطوير ميزات العمل بسرعة يمكن التنبؤ بها. أصبحت الإصدارات حدثًا عاديًا بالنسبة لنا. نقوم بإصدار المونليث كل يومين ، وخدمات أصغر كل بضع دقائق. وهذا يعني أنه يمكننا تقديم قيمة أعمال بسرعة إلى مستخدمينا وجمع الملاحظات بشكل أسرع. بفضل مرونة فرق العمل ، نحصل على سرعة تطور عالية.

اليوم لدينا 480 مطعم بيتزا على الإنترنت ، 400 منها في روسيا. خلال عطلة مايو هذا العام ، كانت هناك مشاكل في معالجة الطلبات في مطاعم البيتزا لدينا مرة أخرى. ولكن هذه المرة كان عنق الزجاجة هو خدمة العملاء في البيتزا. كان Dodo IS يعمل كالساعة ، على الرغم من العدد المتزايد من البيتزا والأوامر.

نتائج للفرق

نستخدم اليوم مجموعة واسعة من الممارسات الهندسية:

1. فرق ميزة متعددة الوظائف وعبر المكون بالكامل.
2. البرمجة الزوجية / برمجة الغوغاء.
3. تكامل مستمر حقيقي ، يعني تكاملات متعددة للكود من 9 فرق في فرع واحد.
4. إدارة التكوين المبسطة مع تطوير جذع.
5. الهدف المشترك لفرق متعددة.
6. موضوع المادة خبير في الفريق.
7. لا يوجد فريق ضمان الجودة منفصل ، خبراء ضمان الجودة هم جزء من فرق التطوير.
8. في نهاية المطاف استبدال التراجع اليدوي مع autotests.
9. سياسة الخلل صفر.
10. تراكم الديون الفنية.
11. وقف الخط كسائق لتسريع خط أنابيب النشر.

فهي تساعد 9 فرق في العمل على رمز مشترك ومنتج واحد يتضمن عشرات المكونات - موقع للجوال وسطح المكتب ، وتطبيق للجوال على iOS و Android ، ومكتب خلفي عملاق مع تسجيل النقد ، والتتبع ، وعرض المطعم ، والحساب الشخصي والتحليلات والتنبؤ.

ما يمكن أن يكون أفضل

قد يبدو أننا أحرزنا بالفعل تقدمًا جيدًا في الممارسات الهندسية ، لكننا في البداية فقط ، لا يزال لدينا مجال للنمو. على سبيل المثال ، نحاول ، ولكن بشكل غير منتظم حتى الآن ، برمجة mob. ندرس نهج الكتابة اختبار BDD. لا يزال لدينا مجال للنمو في CI ، ونحن نفهم أن الاندماج حتى مرة واحدة في اليوم لا يكفي في كثير من الأحيان. وعندما نصل إلى 30 فريقًا ، سيكون من الضروري الاندماج أكثر. ما زلنا في طور الانتقال من TDD إلى ATDD. يجب أن نخلق عملية صنع قرار معمارية مستدامة وقابلة للتطوير.
الشيء الأكثر أهمية هو أننا توجهنا لتعزيز التميز التقني.

نظرًا لحقيقة أن جميع الفرق التسعة تعمل على تراكم مشترك وعلى منتج واحد ، فإن الفرق لديها رغبة قوية في التعاون مع بعضها البعض. لقد تعلموا أن يتخذوا قرارات قوية بأنفسهم.



أبدت بعض الفرق رغبة في استخدام جميع ممارسات XP الـ 12 وطلبت مني المساعدة كـ XP Coach و Scrum Master.

ماذا تعلمنا

أتمنى ألا أترك الأزمة تحدث. كمطور ، شعرت بالمسؤولية الشخصية عن تراكم الديون الفنية الكبيرة جدًا وعدم رفع علم أحمر في وقت سابق:

• الممارسات الهندسية تحمي الأعمال من الأزمة.
• لا تتراكم الديون التقنية. قد يكون بعد فوات الأوان وتكلفة عالية جدا.
• تستغرق التغييرات التطورية عدة مرات أطول من التغييرات الثورية.
• الأزمة ليست دائما شيء سيء. استخدام الأزمة لإحداث ثورة في العمليات.
• ومع ذلك ، مطلوب إعداد تطوري طويل مقدما.
• لا تنفذ عمياء جميع الممارسات التي تحبها. بعض الممارسات تنتظر في الأجنحة ، وعندما يأتي ، ستستخدمها الفرق دون مقاومة. انتظر اللحظة المناسبة.
• صقل وعدل الممارسات حسب السياق الخاص بك.
• مع مرور الوقت ، تبدأ الفرق نفسها في اتخاذ قرارات قوية وتنفيذها. امنحهم بيئة آمنة للمحاولة والفشل والتعلم من الأخطاء.

الديون الفنية تؤدي بنا إلى الأزمة. ولكن من الأزمة ، تعلم كل من المطورين ورجال الأعمال مدى أهمية التركيز على التميز التقني والممارسات الهندسية. استخدمنا الأزمة كمحرك للتغيير الهائل في العمليات والعمليات.

---

شكر وتقدير

أود أن أقول شكراً جزيلاً لجميع الأشخاص الذين ساعدوني في رحلتي من الأزمة إلى تحول LeSS. أشعر باستمرار دعمكم.

شكرا جزيلا للرئيس التنفيذي لدينا ، فيدور Ovchinnikov للثقة. أنت الزعيم الحقيقي للشركة مع ثقافة رشيقة حقيقية.

شكرا جزيلا لديمتري بافلوف ، مالك المنتج لدينا ، صديقي القديم ومدرب مشارك.

شكراً لك أليكس أندرونوف وأندريه موريفسكي لدعمهما لي في دوري.

شكراً جزيلاً لداشا بيانانوفا ، أول رئيس سكروم بدوام كامل ، الذي صدقني ويساعدني ويدعمني دائمًا بكل مبادرتنا. مساعدتكم من الصعب المبالغة في تقديرها.

شكر خاص إلى جوهانا روثمان الذي ساعدني في كتابة هذا التقرير في أي ظرف من الظروف: البقاء في إجازة ، والتعافي بعد المرض. يوحنا ، لقد كان من دواعي سروري أن أعمل معك. مساعدتكم ، ونصيحتك ، والاهتمام بالتفاصيل والاجتهاد هي محل تقدير كبير.