عمليات مرنة في فريق تكنولوجيا المعلومات

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

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

لماذا لا سكروم

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

في رأيي ، المشاكل الرئيسية للكروم هي:

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

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

الفريق

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

كما هو الحال معنا

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

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

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

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

نحاول تسجيل الوقت لكل مهمة ، على الأقل 75 ٪ من وقت العمل. بهذا نحقق هدفين:

1. نحن نسعى إلى القضاء على قتلة الوقت: المهام التي كانت تستغرق وقتًا طويلاً ، ولكنها لم تحقق الفوائد المتوقعة.
2. نقوم بتقييم المهام على أساس ما تم بالفعل ، وبالتالي زيادة دقة التقييم.

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

يؤدي

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

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

عملية التحسين المستمر هي أساس فريقنا.