كيف فعلنا SCRUM

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

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

لماذا تحمل مثل هذا الخطر إذا كان يمكنك الذهاب بطريقة مختلفة تماما؟

لماذا SCRUM

عندما نتعرف على المشروع ، هناك فهم "نعلم أننا لا نعرف هذا" ، وحتى "لا نعرف أين حدود ما لا نعرفه" تساعد SCRUM



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

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

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

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

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

هذا يعني أنه بعد التكرار الأول ، يتلقى العميل وظائف مفيدة للغاية ، وإن كانت صغيرة ، ولكنها تعمل ، ويقوم بفحصها في الواقع العملي ، ويقدم ملاحظات على الفور.



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

كان هذا هو الحال معنا ، دعونا نرى؟

نريد أن نتحدث عن طريقتنا في تكييف إطار SCRUM الكلاسيكي للعمل على نظام تحكم آلي لأكاديمية A + للتربية الحديثة - وهذا هو مركز تعليمي حديث في كييف ، والذي يضم مدرسة ، ورياض أطفال ، ومركز تنمية مبكرة ، والموسيقى والرقص والرياضة المدارس والاستوديوهات الفنية ومركز لدراسة اللغات الأجنبية. في المجموع ، يحضر أكثر من ألف طفل حوالي 150 دورة تدريبية مختلفة في الأكاديمية.

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

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

يلزم تكييف SCRUM مع كل مشروع محدد

كيف يبدأ العملاء والمقاولون العمل على SCRUM؟

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









خلال التدريب المشترك الذي استمر ثلاثة أيام ، قمنا باستخدام ما يسمى بمنظر المروحية ، بتشكيل النظام المستقبلي بالسكتات الدماغية الكبيرة وثبته على خط مؤقت في شكل Project RoadMap.

عرض مروحية - وصفًا عامًا أو رأيًا عن موقف ما ، بدلاً من وصف مفصل


خارطة طريق المنتجات العالمية

ما هي استنتاجاتنا بعد هذه المرحلة؟

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

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

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

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

جميع الترتيبات لدينا في قائمة قصيرة.

الخطوة رقم 1: تحليل الأعمال والتكيف مع المنهجية

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

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



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

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









تراكم منتجاتنا من 203 قصص ، مجمعة بشكل مريح حسب القطاع


مثال قصة المستخدم

ما هي استنتاجاتنا بعد هذه المرحلة؟

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

Sprint - الفترة الزمنية التي يتم خلالها إنشاء "جاهز" ، أي منتج مناسب للاستخدام والإصدار

الخطوة رقم 2: تخطيط العدو. كيف تكيفنا مع سبرينت التخطيط

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



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

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

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

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

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


سبرينت سبيل المثال تراكم

المجلة الإلكترونية بعد العدو الأول

التبسيط والافتراضات للسباق الأول . في النظام - 2 مستخدمين: المعلم والآباء ؛ فئة واحدة - 5 "أ" ؛ التكوين الفعلي للفئة ، إدخالها يدوياً مباشرة من خلال استعلامات SQL. الجدول الزمني الحالي ل 5 "A" ، شكلت أيضا مباشرة من خلال الإدخال في الجدول.

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

ما الذي تعطيه القيمة الحقيقية: الأداء الرقمي للفئة الحقيقية ، والتقييمات الحالية ، واحتمال الإعداد التلقائي للتقارير الشهرية والفصلية والفصلية.

قصة المستخدم رقم 2 : تقرير أسبوعي للآباء عن الأداء في البريد.

ما هي القيمة المضافة: إبلاغ أولياء الأمور بالأداء الحالي ؛ تعليقات المعلم على الواجب المنزلي ؛ الحد الأدنى ولكن التحليلات الحقيقية.

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

سفياتوسلاف ، مالك المنتج

كمرجع : من أجل إصلاح الإصدار النهائي (المثالي) ، كان علينا العودة إلى المجلة الإلكترونية للعديد من سباقات السرعة.


هذا ما كانت تبدو عليه المجلة بعد العدو الأول ، لكن كان من الممكن بالفعل العمل معها.


تم استلام هذه النسخة من المجلة الإلكترونية بعد 12 سباقًا مباشرًا ويمكن عرضها للآباء.

مثال حي آخر لنهج SCRUM التكراري هو مُنشئ الجدول الزمني.

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

استغرق الأمر ثلاثة سباقات لتحسينه إلى "محرر بصري". تم تبديل التركيز على التطوير عدة مرات ، ولكن مع بداية العام الدراسي ، تلقى العميل مصممًا للجدول الزمني يعمل بكامل طاقته ، وبمساعدة قام بتقديم الجدول من أول (A ، B ، C ، D) إلى طلاب الصف الثامن في غضون ساعة واحدة فقط.

دعونا نتبع المسار "محرر وحشي لمشرف حقيقي" - "محرر بصري" - "مصمم جدول"

وكيف قمت بوضع الجدول الزمني من قبل؟

تم وضع الجدول على أوراق لاصقة من ورقة Whatman A1 يدويًا: رسمت ، مظللة بعلامات ملونة ، لاصق. استغرق المعلم الرئيسي أسابيع وشهور للقيام بذلك.


الإصدار الأول من المحرر: "محرر وحشي للمشرف" - الذي وضع الجدول الزمني لعام 2018


الإصدار الثاني المحسّن بمساعدة الجدول 2018/2019


مصمم الجدول - النسخة النهائية

ما هي استنتاجاتنا بعد هذه المرحلة؟

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

كيفية جعل فريق يقيم قصة المستخدم بشكل واقعي

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

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

مقياس التقييم ، أو SCRUM-poker

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

لاحظ أن تسلسل القيم على البطاقات غير خطي. على سبيل المثال ، لا يوجد شيء بين 13 و 21. لماذا هذا



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

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

مهم جدا : يجب على كل عضو في الفريق إعطاء تقييم. لماذا؟

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

نعرض هذا بمثال التباين الواسع في تقدير إحدى القصص. كانت القصة تسمى Buzz .

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

حالة مشرق: الطنانة

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

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


الطنانة في التنفيذ النهائي

حالة مشرق: الطنانة

نحن نناقش بين المطورين مدى تقديرنا لمقدار العمل في تاريخ نبضات Google.



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

ما هي الاستنتاجات التي توصلنا إليها فيما يتعلق بمنهجية التقييم

1. نعم ، من الطبيعي أن يقدم مصمم QA و UX تقييمًا للتاريخ الفني.
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

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



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

الوظائف المتقاطعة: الفريق جاهز لأداء أي مهمة لإطلاق المنتج ،

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

تجربة الجميع قيمة لإيجاد الحل الأكثر فعالية.

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

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. من الضروري تحويل التركيز وفهم أن SCRUM يوميًا ضروري للتواصل وليس للإدارة.
3. ينبغي لكل سباق لاحق أن يأخذ في الاعتبار تجربة السابقة.

كيفية إجراء اجتماع SCRUM اليومي

الخطوة رقم 4: كيف أجرينا عرضا للنتائج. لدينا التكيف من العرض التجريبي

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

كيفية معرفة ما إذا كان الحل يناسب العميل

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





ما هي الاستنتاجات التي استخلصناها من منهجية عرض النتائج

1. تكوين إلزامي للعرض التوضيحي: مالك المنتج ، وسيد scrum ، وممثلو العملاء والمستخدمون النهائيون الذين سيعملون مع الأداة ، والفريق.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

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



كيفية التأمين ضد تكرار الأخطاء

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

: . Scrum Master sprint backlog, . , , — — . , . . , , :

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

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

بافيل كاميشوف ، مدرب رشيق

نعم ، يتطلب SCRUM التضمين النشط لجميع أعضاء الفريق. بالنسبة للأنشطة مثل الاستمالة والتخطيط و SCRUM اليومية ، استغرق الأمر حوالي 12 ٪ من الوقت المدفوع - وهذا هو نوع من ثمن الشفافية والقدرة على التنبؤ والحد من المخاطر.

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

بافيل كاميشوف ، مدرب رشيق لكروم أوكرانيا

12٪ كثير ، لكن الأمر يستحق ذلك ، لأن سعر استخدام المنهجية في "الشلال" الكلاسيكي هو دور منفصل لمدير المشروع. في المتوسط ​​، يتم إنفاق حوالي 15 ٪ من تكلفة التطوير على الإدارة في قطاع السوق لدينا.

ما هي الاستنتاجات التي استخلصناها من المنهج الرجعي

1. بالنسبة لنا ، يعد الحدث الرجعي هو الحدث الثاني الأكثر أهمية في SCRUM بعد التخطيط للسباق.
2. يتحدث كل عضو في الفريق حتى يكون الجميع في نفس حقل المعلومات.
3. كل تغيير له سعر. يجب أن توافق على أمر الشراء لتضمين القصص الفنية والساعات المنهجية في تراكم الركض.
4. يتم دفع الساعات المنهجية من قبل العميل.

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

الخطوة رقم 6: كيف قمنا بتكييف تحسين تراكم المنتجات ، أو الاستمالة

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



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


نتائج الاستمالة

كان مالك المنتج لدينا كفء للغاية ، لذلك كان لدينا دائمًا أفق رؤية كاف لكيفية تطوير النظام ، ونفذنا عملية التحسين بانتظام. في الواقع ، تعد الشفافية أحد المبادئ الأساسية لـ SCRUM.


يبدو وكأنه خطة الاستمالة

ما هي الاستنتاجات التي توصلنا إليها بشأن منهجية التنقيح

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

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

فشل

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

العمل على أنماط مألوفة

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

وجدنا من العادة أنهم نظموا في شلال متسلسل مألوف.

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

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

عمل إضافي على وظائف لا لزوم لها

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

لماذا خطأ: لا يمكن اختبار هذه الأداة إلا في المراحل اللاحقة ، لأنها تحتاج إلى بيانات متراكمة ، والتي لم تكن موجودة في ذلك الوقت.

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

يساوي المستخدمين المتقدمين

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

الخلاصة: تأكيد القصة في العملاء العادية.

استنتاجات عامة

الاستنتاج رقم 1

المرونة الاحترافية: يتيح لك SCRUM أن تكون فريقًا فعالًا

تعتمد نتائج كل سباق على المهام التمهيدية ، والكفاءة ، والتنسيق ، ومسؤولية الفريق ، وردود فعل الجودة.

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

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

الاستنتاج رقم 2

حول الاستخدام الأكثر كفاءة للموارد

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

SCRUM - عندما يتم تأمين كلا الطرفين ضد المخاطر

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

العملاء

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

يدفع العميل مبلغًا ثابتًا لكل سباق ، ويجعل عمله خطوة واحدة أكثر كفاءة

المؤدي

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

كل سباق يزيد من مستوى كفاءة المؤدي ، ويسرعه في تنفيذ المشروع.

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

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

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

ربما لفترة طويلة كان الجميع مهتمًا بمعرفة المنتج نفسه ، والذي ظهر.

حصل العميل على منتج ممتاز: مجموعة من الأدوات لمدرسة حديثة يمكنها تحويلها بسرعة إلى مدرسة مستقبلية