🌌 🎱 🖌️ عمل الفريق الموزع في ظروف العزلة الذاتية: حيث لم نلاحظ الفرق تقريبًا 😱 🛶 🏯

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

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

سيبدو شيئًا عاديًا بالنسبة لك بالتأكيد (Agile ، Scrum ، Kanban ، DevOps - واو الاكتشافات!) ، لكن الأمر يشبه الشحن في الصباح: يعلم الجميع أنه مفيد ، ولكن لسبب ما يتم الكسل بانتظام وبقوة كاملة. لذلك نقوم به. ويعمل.

ليس عن بعد ، ولكنه موزع

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

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

- يتم ترتيب دورة حياة كل مهمة من الفكرة إلى الإنتاج بأكبر قدر ممكن من الاتساق: الإجراءات والحالات والانتقال بين المراحل - يتم إضفاء الطابع الرسمي على كل ما هو ممكن (حوالي 90 ٪ من المهام). في الوقت نفسه ، نحاول إبقاء البيروقراطية بسيطة ومفهومة ، وإلا فإنها تتوقف عن أن تكون مفيدة وتبدأ في التدخل ؛

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

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

لكن أول الأشياء أولاً.

المرحلة 0. التخطيط

كل فريق لديه تراكم ، تم تصنيف الجزء العلوي منه وتحديد أولوياته:

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

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

من أجل عدم إطالة وقت العمل في المهمة ، ينخرط الفريق في "البيروقراطية المفيدة": يصوغ المدير وصفًا واضحًا ، ويضع المؤدون الحالات الصحيحة ، وتتدفق المهام من اليسار إلى اليمين على لوح العدو:

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

حسنًا ، كيف يمكن أن يكون ذلك بدون مزامنة يومية ، عندما لا يكون التنظيم الرسمي للعملية كافياً لحل بعض الحالات المعينة ، ومن المرجح أن تتدخل البيروقراطية في العملية. عادةً ما يكون تفصيل المهام حسب الحالات (مفتوح> قيد التقدم> قيد المراجعة> جاهز للاختبار> اختبار> اختبار> جاهز لـ dev> dev> rc> مغلق) كافياً ، ولكن في 10٪ من الحالات تحتاج إلى توضيح شيء ما ، قله بالكلمات ، اشرح " على الأصابع ". بالمناسبة ، أنا مقتنع بأن جميع اجتماعات العمل (بما في ذلك الوقوف) يجب أن تتم باستخدام الاتصال بالفيديو ، وليس عن طريق الصوت فقط ، لأنها تجبر المرء على ترتيب نفسه وضبطه في العمل.

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

حيث فاز الوقت: التزامن ، واتخاذ القرار الجزئي

المرحلة الأولى: التطوير: مفتوح> قيد التنفيذ

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

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

حيث اكتسب الوقت: تقييم مستقل لنقاط القوة والقدرات ، ليس من الضروري دائمًا التغلب على اتصال إنترنت غير مستقر

المرحلة 2. الفحوصات التلقائية: قيد التقدم> قيد المراجعة

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

- مجموعة قياسية من الأدوات للتحليل الثابت: ESLint و Stylelint مع مجموعة غنية من المكونات الإضافية ؛
- الشيكات الثابتة الخاصة بنا: توافر وجودة الترجمات ، التحقق من صحة ملفات yaml ؛
- الأدوات القياسية لاختبار الوحدة: Mocha ، Karma ، PhantomJS ،اسطنبول .
أداة الاختبار الوظيفي والبصري الخاصة بنا ، Hermione ؛
- نبض - لاختبار الأداء - هو أيضا خاص بنا. ذكروه هنا .

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

: — , - —

3. -: in review > ready for test

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

المكان الذي فزت فيه بالوقت: ابحث عن المراجع ذي الصلة والتذكيرات لمعالجة طلب التجمع

المرحلة 4. الاختبار: الاختبار> اختبار

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

يمكن للاختبار:

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

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

المزرعة الجماعية هي مزرعة جهاز اختبار يمكن لأي شخص استخدامها. Android و iOS - نتحقق من التغييرات حتى على أقدم إصدارات الأنظمة وأكثرها صعوبة للدعم ، بحيث تكون خدماتنا متاحة لأي شخص. ولكننا نحاول أيضًا الحصول على سفن رائدة في أقرب وقت ممكن في المزرعة الجماعية و Hypercubes. هل تتذكر "الستارة" (وهي "monobrow") التي ظهرت على iPhone التاسع وجميع المشاكل المرتبطة بها؟

حيث اكتسب الوقت: التخطيط ، والاختبارات التلقائية ، وتوزيع الجهاز: متاح حتى مع العزلة الذاتية

المرحلة الخامسة: التسريب: جاهز لـ fev> dev

يتم اختبار المهمة - حان الوقت لصبها في فرع مشترك.

N.B. , master trunk, dev. . trunk.

عندما يكون هناك الكثير من الحقن (على سبيل المثال ، لدينا أكثر من 30 طلب تجمع في اليوم) ، تنشأ مشكلتان:

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

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

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

المزيد من التفاصيلحول دمج قائمة الانتظار.

حيث يربح الوقت: نحن نمنع حجب الأعطال ، ولا تحتاج إلى التحكم يدويًا في ضخ طلب التجمع

المرحلة 6. الإصدار: RC> مغلق

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

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

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

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

حيث فاز الوقت: التزامن ، صنع القرار الجزئي ،
تم إغلاق الدورة.

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

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

شكرا للقراءة حتى النهاية. أراك في التعليقات!

عمل الفريق الموزع في ظروف العزلة الذاتية: حيث لم نلاحظ الفرق تقريبًا