كيفية تنظيم الإصدار

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

كيف تستعد للافراج؟

اختيار شخص مسؤول

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

تخصيص التقويم

حدد تاريخًا في تقويم الشركة وتأكد من معرفة جميع أصحاب المصلحة.

جعل الجدول على ويكي

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

ملاحظات الإصدار

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

إعلان داخلي

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

أثناء الإصدار

إنشاء الإصدار الغداء

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

إرسال الإخطار

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

جعل العلامة

تأكد من عمل علامة عند الانتهاء من الإصدار ، وشد الإصلاحات في فرع التطوير.

جعل الافراج عن نفسها

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

زر واحد الإصدار

أسطوري. بالطبع ، كلما كان العامل البشري أقل مشاركة في الإصدار ، كان ذلك أفضل. ولكن هذا أمر طبيعي ، إن لم يكن كل شيء يمكن أن يكون آليا.

إذا حدث كل شيء على النحو المخطط

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

بعد الافراج

لمراقبة

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

تقرير النجاح والفشل

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

لإجراء بأثر رجعي

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

ترتيب البيتزا والاحتفال

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

البدء في التحضير للإصدار التالي

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

كيف تصدر شركات أخرى؟

سبوتيفي

سوف Spotify الافراج في كثير من الأحيان بناء على ممارسة قطار الإصدار. كما يشير اسم هذه الممارسة ، فإن الإصدار مشابه جدًا للقطار: أي شخص لم ينته من عمله ينتظر الإصدار التالي. تتمثل مزايا هذا النهج في أن الفريق الفاشل لا يؤخر تسليم المنتج ولا يحاول دفع المهام غير المكتملة. ونتيجة لذلك ، لا تمزق الهواتف المحمولة الخاصة بهم في الليل ، ولا يظهر فريق العمل في حقائب العمل تحت العينين في الصباح. بالطبع ، لن ينجح هذا النهج لشركة الاستعانة بمصادر خارجية: لن يدفع العميل مقابل العمل غير المكتمل. بصراحة: أحب ثقافة الشركة ، أنصحك بمشاهدة مقطع فيديو (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) حول كيفية عمله.

الحجز

هؤلاء الرجال هم أيضا رائع جدا. تستند إصداراتها إلى اختبارات A / B. افترض أن هناك إصدارًا مستقرًا حاليًا - الإصدار A ، وهناك إصدار انتهى منه المطور للتو - الإصدار B. إذا كان KPI أفضل في الإصدار B ، فمن الجدير زيادة النسبة المئوية للمستخدمين لهذا الإصدار. إذا كان الإصدار B أسوأ ، فهناك خياران: الإصدار B ببساطة غير مستقر أو مجرد ميزة لا يحتاج إليها أحد. هذا النهج مناسب لشركة تهتم بمنتجها العامل ، لكن على الأرجح لن تحدث ثورة. إذا كنت مهتمًا بمعرفة المزيد حول التصنيع اللين ، اقرأ كتاب Lean Startup (http://theleanstartup.com/).