من متراصة إلى فرق وحدات

الشركات الكبيرة في كثير من الأحيان يحزنون على مشكلة القدرة على التكيف والمناورة. بتعبير أدق ، تقريبًا من الغياب الكامل لكل منهما.

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



إليك موقف آخر: يتم تغيير واجهة برمجة التطبيقات (API) ، تحتاج إلى تشغيل عاجل إلى قسم الواجهة الخلفية لمعرفة التفاصيل ، ثم العودة إلى الجبهات (iOS / Android / web). علاوة على ذلك ، بعد مناقشة تصويباتك مع الجبهات ، تحتاج إلى العودة إلى الخلف والتحدث عن متطلباتنا. لقد كان مرهقًا للغاية ، وفقدان وقت الفريق ، ومطور فردي وأعصاب جميع المهتمين.

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

ميزة عون

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

ولكن استمرت السعادة بالضبط حتى مرضت ميزة OUNER بالضبط قبل العدو. تم حل الوهم الكامل للتهدئة ، وعدنا إلى حيث بدأنا.

الاستمالة العامة

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

دردشات

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

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

ميزة فريق

ثم جاء أحد متاجر البقالة واقترح تجربة تنسيق الميزة. ماذا يعني هذا: يتم أخذ مطورين من كل نظام أساسي (iOS و Android و web و backend) واختبارين) ويتم تشكيل فريق جديد.

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

الحكم الذاتي
الفريق الذي يذهب إلى الاجتماعات معًا يكون مستقلاً قدر الإمكان عن الآخرين. الرابط الرئيسي من التبعيات الخارجية هو المنتج.

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

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

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

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

نتيجة لذلك ، تمكنا من تحقيق المزايا التالية:

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

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

شكرا لك

وسنحصل قريبًا على mitap لمطوري iOS.