كيف قمنا بتقسيم التطوير إلى فرق (ونسينا أعمال العدو التي لا نهاية لها والمواقف غير المجدية)

أنا PM في خدمة بريد UniSender . قبل 6 سنوات جئت كمبرمج ، وأنا الآن مسؤول عن التفاعل بين فرق المنتج. في السابق ، كان تطويرنا يتكون من فريق موزع واحد ولدينا مشكلتان. ولكن ليس الحمقى والطرق ، ولكن التأخير في سباق العدوانية و ستاندوبس مملة لمدة نصف ساعة.

سوف أخبرك كيف حلناها.

كما قلت ، واجهنا مشكلتين:

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

لبعض الوقت عشنا مع هذه المشاكل ، ثم حاولنا القتال.

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

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

هنا من الضروري أن أقول بضع كلمات عن المنتج.

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

الذهاب إلى كانبان

حدثت أول ثورة واسعة النطاق عندما أدركنا: "سكروم غير مناسب لنا".
قررنا التحول إلى كانبان. بالطبع ، لم نكن تويوتا ولم نبدأ في تنفيذ التنفيذ الكامل. لذلك ، "kanban لدينا" ستكون مختلفة عن "kanban الخاص بك."

سباق السرعة والعمل الجماعي

باختصار حول إصدارنا:

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

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

نتيجة.

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

مستقيم

تم تغيير المواقف - قام بزيارتها ممثل واحد من كل فريق عمل على سباق منفصل.

نتيجة.

• أصبح ستاندوبس مثل ستاندوبس وبدأنا مرة أخرى تنسجم مع دقائق 10-15 القياسية.

وبالتالي ، كنا قادرين على حل المشاكل الحرجة.

ولكن ... بدأ جبل الجليد بأكمله في الظهور من وراء الجزيرة!

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

لقد حللنا بعض المشكلات ، ولكن ظهرت مشاكل جديدة في المقدمة:

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

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

في النهاية ، بدأنا مرة أخرى في التشكيك في حدوث خطأ ما. ثورة جديدة لتكون.

قسم إلى فرق ، مواقف جديدة ، مقدمة لـ Fireteam

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

لا حاجة لكسر نظام العمل ، تحتاج إلى إصلاح اللحظات التي تسبب الألم.

هذا هو ما تغيرنا خلال عملية التطوير.

سباقات السرعة

ما زلنا نعمل على مفهوم "العدو". Sprint هو نطاق عمل "قريب من أسبوعين" للفريق.

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

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

تقسيم إلى فرق

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


على الرغم من أن الباقي لا يزال فريق واحد)

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

ما هو زائد.

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

ما يمكن تحسينه. أرغب في تقديم شهادة بكالوريوس كاملة في الفريق. هذا هو مشكلة لأن VA يبدأ عادة العمل في وقت سابق من بقية الفريق.

فريق العمل

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

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

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

Fireteam

يتم انتخاب كل فريق لمدة أسبوع واحد. يستجيب هذا الأمر لجميع المهيجات الخارجية: مكالمات من الإدارات الأخرى والسلوك غير الطبيعي للخدمة والإصلاحات العاجلة. نحن نسمي هذا الفريق "Fireteam".

ما هو زائد. لا يتم احتساب أسبوع Fireteam تجاه الفريق في وقت العدو. بين مكافحة الحرائق ، يمكن للموظفين التركيز على مهامهم:

• ريفاكتور.
• أكمل مهمة العدو.
• اكتب الوثائق.
• قم بنقل المعرفة مع الفرق الأخرى.

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

مستقيم

قدمنا ​​نوعين من المواقف:

1. فريق. شاركوا فريق يعمل في المشروع.
2. العامة. تقام مرة واحدة في الأسبوع ، ويؤدي كل فريق المشاركة فيها.

ما هو زائد.

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

القصور. لا يزال الفريق يحمل معلومات للفريق.

يؤدي

وبالتالي ، بتغيير العملية تدريجياً ، حللنا معظم المشكلات الملحة:

• قمنا بتجميع فرق مستقرة من 2-3 مطورين و QA. ليس لدى كل فريق الآن أكثر من سباقين ، لا يعمل المشاركون في مشاريع الآخرين.
• كان هناك فريق يعالج الرسائل من الإدارات الأخرى ، ويستجيب للسلوك غير الطبيعي للخدمة والإصلاحات العاجلة. الفرق الأخرى ليست مشتتة من هذه المهام.
• الآن لدى الشركة نوعان من المواقف: الفريق والعامة. يتم إطلاع جميع الموظفين على حالة شؤون العدو ، ويستغرق الوقوف من 5 إلى 10 دقائق قياسية.

حسنا ، نحن نعمل على.