ScrumBut في فريق التحليلات: قبل الإقلاع

مرحبا يا هبر! اسمي Zhenya. أنا محلل نظام في NORBIT وأحد المبتدئين سكروم ماجستير. لقد كنت أبحث في Scrum لفترة طويلة من أجل دراسة ومحاولة وتقييم قدراتها في فريق المحللين لدينا. والآن ، بعد ركلة خفيفة من محادثة ملهمة مع RP ، أدركت: توقف عن التفكير ، لقد حان الوقت للقيام بذلك.

في هذه المقالة ، سأتحدث عن تجربتنا في الإعداد لاستخدام Scrum المحدود نيابة عن Scrum master: ما فعلناه للبدء. في وقت كتابة هذا التقرير ، تم الانتهاء من سباق 15th. الرحلة طبيعية!


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

كانت خطة عملنا للإطلاق كما يلي:

  • لدراسة وتقييم الوضع الحالي والمطلوب
  • بناء كما هي وتكون نموذجا في مصطلحات ScrumBut ،
  • تقديم وإلهام الفريق

كيف تعلمت ما هو سكرومبوت


أولا غوغل وحصلت على:

يحتوي ScrumBut على بناء جملة معين: (ScrumBut) (السبب) (Workaround). أمثلة ScrumBut: "(نحن نستخدم Scrum ، لكن) (وجود Scrum يومياً كل يوم كبير جدًا) ، (لذلك لا يتوفر لدينا سوى واحد في الأسبوع.)" "(نحن نستخدم Scrum ، لكن) (تعد الأحداث الماضية مضيعة للوقت ،) (لذلك نحن لا نفعلها.) "

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

من المفيد بالنسبة لي في العتاد:

  • دراسة الأدب: Agile- بيان تطوير البرمجيات ، "SCRUM طريقة إدارة المشاريع الثورية" (جوزيف سوذرلاند) ، "Agile-team training" (Lissa Adkins) ؛
  • سلسلة من المشاورات الطويلة والمثيرة للاهتمام مع سيد scrum معتمد نشط ممارسة الكلاسيكية.

كيف يمكنني تقييم الوضع الحالي


بادئ ذي بدء ، استفدت من رؤيتي وطرحت عدة نقاط للتقييم من قبل المديرين.

جمعت آراء أعضاء الفريق وسجلتها.

لقد حصلنا على قائمتين: ما لدينا عند الإدخال وما نريد الحصول عليه.

هنا سأقدم قوائم موحدة ومعممة.

ما لديهم عند المدخل

  1. مشروع كبير لتطوير نظام interpraise.
  2. فرق منفصلة من المطورين والدعم والمحللين.
  3. فريق رائع من المحللين (حوالي 14 شخص).
  4. القدرة على التصرف فقط في إطار فريق من المحللين.
  5. الافراج عن الافراج عن إصدارات النظام.
  6. نموذج إدارة دورة حياة برنامج الشلال.
  7. استحالة التخطيط الصعب ، حيث أن المهام من العميل تأتي في أي وقت.
  8. عبء العمل غير المتكافئ من المحللين.
  9. التوزيع الوظيفي لمناطق فحص المحللين.

ماذا نريد أن نحصل عليه

  1. تكون قادرة على الاستجابة بسرعة لتغيرات العمل.
  2. تأخذ في الاعتبار وتحديد أولويات المهام في العمل
  3. هل لديك توقعات نمو المنتج ممكن.
  4. يمكن أن تسمح لك المسافات القصيرة بتتبع المهام وتسجيلها وإتمامها ، والتنبؤ بدقة أكبر بموعد تحرير المهام.
  5. إنشاء تراكم المهام للمحللين.
  6. في أي وقت ، يعرف المحلل ما يجب القيام به.
  7. تبادل الخبرات في حل المشاكل المعقدة.
  8. كان إنشاء العمل الجماعي بطريقة مثل تبادل المعرفة لطيفًا ومريحًا ومفيدًا للطرفين.
  9. قم بتنظيم Scrum باستخدام Black Jack ، إلخ. :)
  10. جرب أشياء جديدة ، وتحسين روح الفريق. الرجال بارد. لم لا؟

النمذجة


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

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

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

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

عرض تقديمي


انتهت مرحلة التخطيط بعرض تقديمي لفريق العرض التقديمي حول نتائج نموذج "الشروع في العمل معًا" ومناقشة وتصحيح ما لم يجد استجابة من اللاعبين.

Scrum و ScrumBut بشكل خاص هي العمل الجماعي والتماسك والشفافية والقبول العام. لقد كانت لحظة مهمة بدأنا منها بالإلهام.

المصدر

استنتاجات من الاستعدادات الإطلاق


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

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

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

الخطوات الموصوفة أعلاه (دراسة نظرية ، والنمذجة والعرض التقديمي) فعلت الحيلة: لقد بدأنا بنجاح.

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

Source: https://habr.com/ru/post/ar437800/


All Articles