علم البيانات الرشيقة - مفاهيم المنهجية Agile scrum methodology concepts
علم البيانات الرشيقة - مفاهيم المنهجية Agile scrum methodology concepts
في هذا الفصل ، سوف نركز على مفاهيم دورة حياة تطوير البرمجيات المسماة "Agile". تساعد منهجية تطوير البرمجيات Agile في بناء برنامج من خلال جلسات زيادة في تكرارات قصيرة من 1 إلى 4 أسابيع حتى يتماشى التطوير مع متطلبات العمل المتغيرة.
هناك 12 مبدأ تصف منهجية Agile بالتفصيل -
إرضاء العملاء
تعطى الأولوية القصوى للعملاء الذين يركزون على المتطلبات من خلال التسليم المبكر والمستمر للبرامج القيمة.
الترحيب بالتغييرات الجديدة
التغييرات مقبولة أثناء تطوير البرنامج. تم تصميم عمليات Agile للعمل من أجل مطابقة الميزة التنافسية للعميل.
توصيل
يتم تسليم برنامج العمل للعملاء في غضون فترة تتراوح من أسبوع إلى أربعة أسابيع.
التعاون
يجب أن يعمل محللو الأعمال ومحللو الجودة والمطورون معًا خلال دورة حياة المشروع بأكملها.
التحفيز
يجب تصميم المشاريع مع عشيرة من الأفراد المتحمسين. يوفر بيئة لدعم أعضاء الفريق الفردي.
محادثة شخصية
المحادثة وجهًا لوجه هي الطريقة الأكثر فعالية وفعالية لإرسال المعلومات إلى فريق التطوير وداخله.
قياس التقدم
قياس التقدم هو المفتاح الذي يساعد في تحديد تقدم المشروع وتطوير البرمجيات.
الحفاظ على وتيرة ثابتة
عملية رشيقة تركز على التنمية المستدامة. يجب أن يكون العمل والمطورون والمستخدمون قادرين على الحفاظ على وتيرة ثابتة مع المشروع.
المراقبة
من الضروري الحفاظ على الاهتمام المنتظم بالتميز التقني والتصميم الجيد لتعزيز الوظيفة الرشيقة.
بساطة
تبقي عملية Agile كل شيء بسيطًا وتستخدم مصطلحات بسيطة لقياس العمل الذي لم يكتمل.
شروط التنظيم الذاتي
يجب أن يكون الفريق الرشيق منظمًا ذاتيًا ويجب أن يكون مستقلاً مع أفضل بنية ؛ تظهر المتطلبات والتصاميم من فرق منظمة ذاتيًا.
راجع العمل review work
من المهم مراجعة العمل على فترات منتظمة حتى يتمكن الفريق من التفكير في كيفية تقدم العمل. ستؤدي مراجعة الوحدة في الوقت المناسب إلى تحسين الأداء.
الوقوف اليومي Agile scrum daily standing
يشير الوقوف اليومي إلى اجتماع الحالة اليومي بين أعضاء الفريق. يوفر تحديثات متعلقة بتطوير البرامج. كما يشير إلى معالجة عقبات تطوير المشروع.
يعد الوقوف اليومي ممارسة إلزامية ، بغض النظر عن كيفية إنشاء فريق رشيق بغض النظر عن موقع مكتبه.
فيما يلي قائمة ميزات الوقوف اليومي -
- يجب أن تكون مدة لقاء الوقوف اليومي حوالي 15 دقيقة. يجب ألا يمتد لفترة أطول.
- يجب أن يتضمن الوقوف مناقشات حول تحديث الحالة.
- عادة ما يقف المشاركون في هذا الاجتماع بنية الاجتماع بسرعة.
قصة المستخدم Agile scrum User story
عادة ما تكون القصة مطلبًا ، والتي تتم صياغتها في جمل قليلة بلغة بسيطة ويجب إكمالها خلال تكرار. يجب أن تتضمن قصة المستخدم الخصائص التالية -
يجب أن تحتوي جميع التعليمات البرمجية ذات الصلة على عمليات تسجيل وصول ذات صلة.
تختبر الوحدة حالات التكرار المحدد.
يجب تحديد جميع حالات اختبار القبول.
القبول من صاحب المنتج أثناء تحديد القصة.
ما هو سكرم؟ what is scrum agile
- زيادة جودة المخرجات
- التعامل بشكل أفضل مع التغيير (وتوقع التغييرات)
- قدم تقديرات أفضل مع قضاء وقت أقل في إنشائها
- كن أكثر سيطرة على جدول المشروع وحالته
يمكن اعتبار سكروم agile scrum كمجموعة فرعية من منهجية أجايل. إنها عملية خفيفة وتتضمن الميزات التالية -
- إنه إطار عمل يتضمن مجموعة من الممارسات التي يجب اتباعها بترتيب متسق. أفضل مثال على Scrum هو متابعة التكرارات أو سباقات السرعة.
- إنها عملية "خفيفة الوزن" مما يعني أن العملية تبقى صغيرة قدر الإمكان ، لتعظيم الناتج الإنتاجي في مدة معينة محددة.
تشتهر عملية سكروم agile scrum بعمليتها المميزة مقارنة بالمنهجيات الأخرى للنهج التقليدي الرشيق. وهي مقسمة إلى الفئات الثلاث التالية -
- الأدوار. Agile scrum Roles
- الآثار Agile Scrum effects
- مربعات الوقت Agile Time Squares
تحدد الأدوار أعضاء الفريق وأدوارهم المدرجة في جميع مراحل العملية. يتكون فريق Scrum من الأدوار الثلاثة التالية -
- سيد سكرم Agile scrum master
- مالك المنتج Agile scrum Product owner
- الفريق agile scrum team
توفر مصنوعات Scrum المعلومات الأساسية التي يجب أن يكون كل عضو على دراية بها. تتضمن المعلومات تفاصيل المنتج والأنشطة المخطط لها والأنشطة المنجزة. المصنوعات اليدوية المحددة في إطار عمل سكروم هي كما يلي -
- تراكم المنتج
- سباق المتراكمة
- الرسم البياني
- زيادة راتب
المربعات الزمنية هي قصص المستخدم التي تم التخطيط لها لكل تكرار. تساعد قصص المستخدم هذه في وصف ميزات المنتج التي تشكل جزءًا من مصنوعات Scrum. تراكم المنتج هو قائمة قصص المستخدمين. يتم ترتيب قصص المستخدمين هذه حسب الأولوية وإرسالها إلى اجتماعات المستخدمين لتحديد أي واحدة يجب تناولها.
Why agile scrum master لماذا سكرم ماستر؟
يتفاعل Scrum Master مع كل عضو في الفريق. دعونا نرى الآن تفاعل Scrum Master مع الفرق والموارد الأخرى.
Agile scrum product owner مالك المنتج
يتفاعل Scrum Master مع مالك المنتج بالطرق التالية -
- البحث عن تقنيات لتحقيق تراكم المنتج الفعال لقصص المستخدمين وإدارتها.
- مساعدة الفريق على فهم احتياجات عناصر تراكم المنتجات الواضحة والموجزة.
- تخطيط المنتج مع بيئة محددة.
- التأكد من أن مالك المنتج يعرف كيفية زيادة قيمة المنتج.
Agile scrum team فريق سكرم
يتفاعل Scrum Master مع الفريق بعدة طرق -
- تدريب المنظمة على اعتماد Scrum.
- تخطيط تطبيقات Scrum لمنظمة معينة.
- مساعدة الموظفين وأصحاب المصلحة على فهم متطلبات ومراحل تطوير المنتج.
- العمل مع Scrum Masters من الفرق الأخرى لزيادة فعالية تطبيق Scrum للفريق المحدد.
Agile scrum organization المنظمة
يتفاعل Scrum Master مع المنظمة بعدة طرق. القليل مذكور أدناه -
- يتفاعل فريق التدريب والسكر مع التنظيم الذاتي ويتضمن ميزة الوظائف المتقاطعة.
- تدريب المنظمة والفرق في المناطق التي لم يتم تبني Scrum بشكل كامل أو لم يتم قبولها.
Agile scrum advantage مميزات سكرم
يساعد Scrum العملاء وأعضاء الفريق وأصحاب المصلحة على التعاون. يتضمن نهجًا مربّعًا زمنيًا وردود فعل مستمرة من مالك المنتج لضمان أن المنتج في حالة صالحة للعمل. يوفر Scrum فوائد لأدوار مختلفة من المشروع.
Agile scrum client الزبون
تعتبر سباقات السرعة أو التكرارات لمدة أقصر ويتم تصميم قصص المستخدم حسب الأولوية ويتم تناولها في التخطيط السريع. إنه يضمن تلبية متطلبات العملاء في كل تسليم سريع. إذا لم يكن الأمر كذلك ، يتم ملاحظة المتطلبات ويتم التخطيط لها واتخاذها للسباق.
Agile Scrum organization منظمة
يمكن أن تركز المنظمة بمساعدة أساتذة Scrum و Scrum على الجهود المطلوبة لتطوير قصص المستخدم وبالتالي تقليل عبء العمل وتجنب إعادة العمل إن وجدت. يساعد هذا أيضًا في الحفاظ على زيادة كفاءة فريق التطوير ورضا العملاء. يساعد هذا النهج أيضًا في زيادة إمكانات السوق.
Scrum products managers مديرو المنتجات
تتمثل المسؤولية الرئيسية لمديري المنتجات في ضمان الحفاظ على جودة المنتج. بمساعدة Scrum Masters ، يصبح من السهل تسهيل العمل ، وجمع الردود السريعة واستيعاب التغييرات إن وجدت. يتحقق مديرو المنتج أيضًا من توافق المنتج المصمم وفقًا لمتطلبات العميل في كل سباق.
Agile scrum development teamفريق التطوير
مع الطبيعة المقيدة بالوقت والاحتفاظ بالسباقات السريعة لفترة زمنية أقل ، يصبح فريق التطوير متحمسًا لرؤية العمل ينعكس وينفذ بشكل صحيح. يزيد منتج العمل كل مستوى بعد كل تكرار أو بالأحرى يمكننا تسميتها "العدو". تصبح قصص المستخدم المصممة لكل سباق أولوية للعملاء تضيف المزيد من القيمة إلى التكرار.
ما هي متطلبات سكروم؟ what is requirement of agile scrum
لا تحدد Scrum متطلبات الشكل فقط ، ولكنها تقول ببساطة إنها مجمعة في Product Backlog ، ويشار إليها عمومًا باسم "Product Backlog Items" أو "PBIs" باختصار. نظرًا لطبيعة Sprint المربوطة بالوقت ، يمكننا أيضًا أن نستنتج أن كل مجموعة يجب أن تتطلب وقتًا أقل بكثير للتنفيذ من مدة Sprint. تستعير معظم مشاريع Scrum ممارسة "XP" (البرمجة القصوى) لوصف طلب الميزة على أنه "قصة مستخدم" ، على الرغم من أن أقلية تستخدم المفهوم الأقدم لـ "واقعة الاستخدام". سوف نوافق على رأي الأغلبية هنا ، وسنصف ثلاثة عناصر لمتطلبات المعايير المعقولة الموجودة في Product Backlogs.
لا تحدد Scrum متطلبات الشكل فقط ، ولكنها تقول ببساطة إنها مجمعة في Product Backlog ، ويشار إليها عمومًا باسم "Product Backlog Items" أو "PBIs" باختصار. نظرًا لطبيعة Sprint المربوطة بالوقت ، يمكننا أيضًا أن نستنتج أن كل مجموعة يجب أن تتطلب وقتًا أقل بكثير للتنفيذ من مدة Sprint. تستعير معظم مشاريع Scrum ممارسة "XP" (البرمجة القصوى) لوصف طلب الميزة على أنه "قصة مستخدم" ، على الرغم من أن أقلية تستخدم المفهوم الأقدم لـ "واقعة الاستخدام". سوف نوافق على رأي الأغلبية هنا ، وسنصف ثلاثة عناصر لمتطلبات المعايير المعقولة الموجودة في Product Backlogs.
قصة المستخدم Agile scrum User story
تصف قصة المستخدم الميزة المرغوبة (المتطلبات الوظيفية) في شكل سردي. عادةً ما يكتب "مالك المنتج" قصص المستخدمين ، وهي مسؤولية "مالك المنتج". التنسيق غير موحد ، ولكن عادةً ما يكون له اسم ، وبعض النصوص الوصفية ، ومراجع إلى المستندات الخارجية (مثل لقطات الشاشة) ، ومعلومات حول كيفية اختبار التنفيذ. على سبيل المثال ، قد تشبه القصة ما يلي:
الاسم:
يدخل Planner جهة اتصال جديدة في دفتر العناوين ، بحيث يمكن للمرء الاتصال بالشخص لاحقًا عن طريق البريد أو البريد الإلكتروني الوصف:
يُدخل المخطط معلومات الاتصال القياسية (الاسم الأول والأخير ، سطرا عنوان الشارع ، المدينة ، الولاية ، الرمز البريدي / البريدي ، البلد ، إلخ) في شاشة إدخال جهة الاتصال. ينقر المرء على "حفظ" للاحتفاظ بالبيانات ، و "إلغاء" لتجاهل البيانات والعودة إلى الشاشة السابقة. كيفية الاختبار: يقوم Tester بإدخال البيانات وحفظها ، والعثور على الاسم في دفتر العناوين ، والنقر عليه. يرى المرء عرضًا للقراءة فقط لشاشة إدخال جهات الاتصال ، مع إدخال جميع البيانات مسبقًا.
العناصر الموجودة في قصة المستخدم هذه هي:
- الاسم: الاسم عبارة أو جملة وصفية. يستخدم المثال منظمة أساسية "دور - عمل - سبب". نمط شائع آخر ، شاعه مايك كوهن ، يتبع القالب "بصفتي <نوع مستخدم> ، أريد <بعض الأهداف> بحيث <سبب ما>". يعد اختيار النموذج أقل أهمية من وجود معيار عملي من نوع ما.
- الوصف: هذا وصف عالي المستوى (منخفض التفاصيل) للحاجة إلى الوفاء بها. للمتطلبات الوظيفية (التي تواجه المستخدم) ، يتم وضع الوصف في شكل سردي. بالنسبة للمتطلبات غير الوظيفية ، يمكن صياغة الوصف بأي شكل يسهل فهمه. في كلتا الحالتين ، المفتاح هو أن مستوى التفاصيل متواضع ، لأن التفاصيل الدقيقة يتم تحديدها أثناء مرحلة التنفيذ ، في المناقشات بين أعضاء الفريق ومالكي المنتجات وأي شخص آخر معني. (هذا هو أحد المفاهيم الأساسية لـ Scrum: يتم تحديد المتطلبات على مستوى يسمح بتقدير تقريبي للعمل المطلوب لتنفيذها ، وليس بالتفصيل.)
- الشاشات والمستندات الخارجية: إذا كانت القصة تتطلب تغييرات في واجهة المستخدم (خاصة التغييرات غير التافهة) ، فيجب أن تحتوي القصة أو ترتبط بنموذج أولي للتغييرات. يجب أيضًا سرد أي مستندات خارجية مطلوبة لتنفيذ القصة.
- كيفية الاختبار: يتم تعريف تنفيذ القصة على أنها كاملة إذا اجتازت جميع اختبارات القبول التي تم تطويرها لها وفقط إذا اجتازتها. يقدم هذا القسم وصفًا موجزًا لكيفية اختبار القصة. بالنسبة للميزة نفسها ، فإن وصف طرق الاختبار قصير ، مع توضيح التفاصيل أثناء التنفيذ ، لكننا نحتاج على الأقل إلى ملخص لتوجيه عملية التقدير.
هناك سببان لتضمين المعلومات حول كيفية اختبار القصة. السبب الواضح هو توجيه تطوير حالات الاختبار (اختبارات القبول) للقصة. السبب الأقل وضوحًا ، ولكنه مهم ، هو أن الفريق سيحتاج إلى هذه المعلومات لتقدير مقدار العمل المطلوب لتنفيذ القصة (نظرًا لأن تصميم الاختبار وتنفيذه جزء من العمل الكلي).
تصف قصة المستخدم الميزة المرغوبة (المتطلبات الوظيفية) في شكل سردي. عادةً ما يكتب "مالك المنتج" قصص المستخدمين ، وهي مسؤولية "مالك المنتج". التنسيق غير موحد ، ولكن عادةً ما يكون له اسم ، وبعض النصوص الوصفية ، ومراجع إلى المستندات الخارجية (مثل لقطات الشاشة) ، ومعلومات حول كيفية اختبار التنفيذ. على سبيل المثال ، قد تشبه القصة ما يلي:
الاسم: يدخل Planner جهة اتصال جديدة في دفتر العناوين ، بحيث يمكن للمرء الاتصال بالشخص لاحقًا عن طريق البريد أو البريد الإلكتروني |
الوصف: يُدخل المخطط معلومات الاتصال القياسية (الاسم الأول والأخير ، سطرا عنوان الشارع ، المدينة ، الولاية ، الرمز البريدي / البريدي ، البلد ، إلخ) في شاشة إدخال جهة الاتصال. ينقر المرء على "حفظ" للاحتفاظ بالبيانات ، و "إلغاء" لتجاهل البيانات والعودة إلى الشاشة السابقة. |
كيفية الاختبار: يقوم Tester بإدخال البيانات وحفظها ، والعثور على الاسم في دفتر العناوين ، والنقر عليه. يرى المرء عرضًا للقراءة فقط لشاشة إدخال جهات الاتصال ، مع إدخال جميع البيانات مسبقًا. |
العناصر الموجودة في قصة المستخدم هذه هي:
- الاسم: الاسم عبارة أو جملة وصفية. يستخدم المثال منظمة أساسية "دور - عمل - سبب". نمط شائع آخر ، شاعه مايك كوهن ، يتبع القالب "بصفتي <نوع مستخدم> ، أريد <بعض الأهداف> بحيث <سبب ما>". يعد اختيار النموذج أقل أهمية من وجود معيار عملي من نوع ما.
- الوصف: هذا وصف عالي المستوى (منخفض التفاصيل) للحاجة إلى الوفاء بها. للمتطلبات الوظيفية (التي تواجه المستخدم) ، يتم وضع الوصف في شكل سردي. بالنسبة للمتطلبات غير الوظيفية ، يمكن صياغة الوصف بأي شكل يسهل فهمه. في كلتا الحالتين ، المفتاح هو أن مستوى التفاصيل متواضع ، لأن التفاصيل الدقيقة يتم تحديدها أثناء مرحلة التنفيذ ، في المناقشات بين أعضاء الفريق ومالكي المنتجات وأي شخص آخر معني. (هذا هو أحد المفاهيم الأساسية لـ Scrum: يتم تحديد المتطلبات على مستوى يسمح بتقدير تقريبي للعمل المطلوب لتنفيذها ، وليس بالتفصيل.)
- الشاشات والمستندات الخارجية: إذا كانت القصة تتطلب تغييرات في واجهة المستخدم (خاصة التغييرات غير التافهة) ، فيجب أن تحتوي القصة أو ترتبط بنموذج أولي للتغييرات. يجب أيضًا سرد أي مستندات خارجية مطلوبة لتنفيذ القصة.
- كيفية الاختبار: يتم تعريف تنفيذ القصة على أنها كاملة إذا اجتازت جميع اختبارات القبول التي تم تطويرها لها وفقط إذا اجتازتها. يقدم هذا القسم وصفًا موجزًا لكيفية اختبار القصة. بالنسبة للميزة نفسها ، فإن وصف طرق الاختبار قصير ، مع توضيح التفاصيل أثناء التنفيذ ، لكننا نحتاج على الأقل إلى ملخص لتوجيه عملية التقدير.
هناك سببان لتضمين المعلومات حول كيفية اختبار القصة. السبب الواضح هو توجيه تطوير حالات الاختبار (اختبارات القبول) للقصة. السبب الأقل وضوحًا ، ولكنه مهم ، هو أن الفريق سيحتاج إلى هذه المعلومات لتقدير مقدار العمل المطلوب لتنفيذ القصة (نظرًا لأن تصميم الاختبار وتنفيذه جزء من العمل الكلي).
قصة agile scrum story
لا تمثل جميع متطلبات التطوير الجديد ميزات تواجه المستخدم ، ولكنها تمثل عملاً هامًا يجب القيام به. تمثل هذه المتطلبات غالبًا ، ولكن ليس دائمًا ، العمل الذي يجب القيام به لدعم الميزات التي تواجه المستخدم. نطلق على هذه المتطلبات غير الوظيفية اسم "القصص الفنية". تحتوي القصص الفنية على نفس العناصر الموجودة في قصص المستخدمين ، ولكن لا يلزم وضعها في شكل سردي إذا لم تكن هناك فائدة من القيام بذلك. تتم كتابة القصص الفنية عادةً بواسطة أعضاء الفريق ، وتتم إضافتها إلى Product Backlog. يجب أن يكون مالك المنتج على دراية بهذه القصص ، وأن يفهم التبعيات بين هذه القصص وقصص المستخدمين من أجل ترتيب (تسلسل) جميع القصص للتنفيذ.
لا تمثل جميع متطلبات التطوير الجديد ميزات تواجه المستخدم ، ولكنها تمثل عملاً هامًا يجب القيام به. تمثل هذه المتطلبات غالبًا ، ولكن ليس دائمًا ، العمل الذي يجب القيام به لدعم الميزات التي تواجه المستخدم. نطلق على هذه المتطلبات غير الوظيفية اسم "القصص الفنية". تحتوي القصص الفنية على نفس العناصر الموجودة في قصص المستخدمين ، ولكن لا يلزم وضعها في شكل سردي إذا لم تكن هناك فائدة من القيام بذلك. تتم كتابة القصص الفنية عادةً بواسطة أعضاء الفريق ، وتتم إضافتها إلى Product Backlog. يجب أن يكون مالك المنتج على دراية بهذه القصص ، وأن يفهم التبعيات بين هذه القصص وقصص المستخدمين من أجل ترتيب (تسلسل) جميع القصص للتنفيذ.
خلل
تقرير العيب هو وصف لفشل المنتج في التصرف بالطريقة المتوقعة. يتم تخزين العيوب في نظام تتبع الأخطاء ، والذي قد يكون أو لا يكون فعليًا نفس النظام المستخدم لتخزين Product Backlog. إذا لم يكن الأمر كذلك ، فيجب على شخص ما (عادةً ما يكون مالك المنتج) إدخال كل عيب في Product Backlog ، للتسلسل والجدولة.
تقرير العيب هو وصف لفشل المنتج في التصرف بالطريقة المتوقعة. يتم تخزين العيوب في نظام تتبع الأخطاء ، والذي قد يكون أو لا يكون فعليًا نفس النظام المستخدم لتخزين Product Backlog. إذا لم يكن الأمر كذلك ، فيجب على شخص ما (عادةً ما يكون مالك المنتج) إدخال كل عيب في Product Backlog ، للتسلسل والجدولة.
ما هي أدوار سكرم؟ what is agile scrum roles
الأدوار الثلاثة المحددة في Scrum هي ScrumMaster ، ومالك المنتج ، والفريق (الذي يتكون من أعضاء الفريق). يعمل الأشخاص الذين يؤدون هذه الأدوار معًا بشكل وثيق ، على أساس يومي ، لضمان التدفق السلس للمعلومات والحل السريع للقضايا.
الأدوار الثلاثة المحددة في Scrum هي ScrumMaster ، ومالك المنتج ، والفريق (الذي يتكون من أعضاء الفريق). يعمل الأشخاص الذين يؤدون هذه الأدوار معًا بشكل وثيق ، على أساس يومي ، لضمان التدفق السلس للمعلومات والحل السريع للقضايا.
سكرم ماستر Agile scrum master
يعد ScrumMaster (يكتب أحيانًا "Scrum Master" ، على الرغم من أن المصطلح الرسمي ليس له مساحة بعد "Scrum") هو المشرف على العملية. ScrumMaster مسؤول عن جعل العملية تسير بسلاسة ، وإزالة العقبات التي تؤثر على الإنتاجية ، وتنظيم وتسهيل الاجتماعات الهامة. تشمل مسؤوليات ScrumMasters
- علم مالك المنتج كيفية زيادة عائد الاستثمار (ROI) ، وتحقيق أهدافه من خلال Scrum.
- تحسين حياة فريق التطوير من خلال تسهيل الإبداع والتمكين.
- تحسين إنتاجية فريق التطوير بأي طريقة ممكنة.
- قم بتحسين الممارسات والأدوات الهندسية بحيث يمكن شحن كل زيادة في الوظائف.
- احتفظ بالمعلومات حول تقدم الفريق محدثًا ومرئيًا لجميع الأطراف.
من الناحية العملية ، يحتاج ScrumMaster إلى فهم Scrum جيدًا بما يكفي لتدريب وتوجيه الأدوار الأخرى ، وتثقيف ومساعدة أصحاب المصلحة الآخرين الذين يشاركون في العملية. يجب أن يحافظ ScrumMaster على وعي دائم بحالة المشروع (تقدمه حتى الآن) فيما يتعلق بالتقدم المتوقع ، والتحقيق في وتسهيل حل أي حواجز تعوق التقدم ، ويكون عمومًا مرنًا بدرجة كافية لتحديد والتعامل مع أي مشكلات تنشأ بأي طريقة مطلوبة. يجب على ScrumMaster حماية الفريق من إزعاج الأشخاص الآخرين من خلال العمل كواجهة بين الاثنين. لا يقوم ScrumMaster بتعيين المهام لأعضاء الفريق ، حيث أن تعيين المهام هو مسؤولية الفريق. نهج ScrumMaster العام تجاه الفريق هو تشجيع وتسهيل اتخاذ القرار وقدرات حل المشكلات ، حتى يتمكنوا من العمل بكفاءة متزايدة وتقليل الحاجة للإشراف. الهدف هو أن يكون لديك فريق ليس فقط مخولًا لاتخاذ قرارات مهمة ، ولكنه يقوم بعمل جيد بشكل روتيني.
يعد ScrumMaster (يكتب أحيانًا "Scrum Master" ، على الرغم من أن المصطلح الرسمي ليس له مساحة بعد "Scrum") هو المشرف على العملية. ScrumMaster مسؤول عن جعل العملية تسير بسلاسة ، وإزالة العقبات التي تؤثر على الإنتاجية ، وتنظيم وتسهيل الاجتماعات الهامة. تشمل مسؤوليات ScrumMasters
- علم مالك المنتج كيفية زيادة عائد الاستثمار (ROI) ، وتحقيق أهدافه من خلال Scrum.
- تحسين حياة فريق التطوير من خلال تسهيل الإبداع والتمكين.
- تحسين إنتاجية فريق التطوير بأي طريقة ممكنة.
- قم بتحسين الممارسات والأدوات الهندسية بحيث يمكن شحن كل زيادة في الوظائف.
- احتفظ بالمعلومات حول تقدم الفريق محدثًا ومرئيًا لجميع الأطراف.
من الناحية العملية ، يحتاج ScrumMaster إلى فهم Scrum جيدًا بما يكفي لتدريب وتوجيه الأدوار الأخرى ، وتثقيف ومساعدة أصحاب المصلحة الآخرين الذين يشاركون في العملية. يجب أن يحافظ ScrumMaster على وعي دائم بحالة المشروع (تقدمه حتى الآن) فيما يتعلق بالتقدم المتوقع ، والتحقيق في وتسهيل حل أي حواجز تعوق التقدم ، ويكون عمومًا مرنًا بدرجة كافية لتحديد والتعامل مع أي مشكلات تنشأ بأي طريقة مطلوبة. يجب على ScrumMaster حماية الفريق من إزعاج الأشخاص الآخرين من خلال العمل كواجهة بين الاثنين. لا يقوم ScrumMaster بتعيين المهام لأعضاء الفريق ، حيث أن تعيين المهام هو مسؤولية الفريق. نهج ScrumMaster العام تجاه الفريق هو تشجيع وتسهيل اتخاذ القرار وقدرات حل المشكلات ، حتى يتمكنوا من العمل بكفاءة متزايدة وتقليل الحاجة للإشراف. الهدف هو أن يكون لديك فريق ليس فقط مخولًا لاتخاذ قرارات مهمة ، ولكنه يقوم بعمل جيد بشكل روتيني.
مالك المنتج Agile scrum Product owner
مالك المنتج هو المسؤول عن المتطلبات. يوفر مالك المنتج "المصدر الوحيد للحقيقة" للفريق فيما يتعلق بالمتطلبات وترتيب التنفيذ المخطط له. من الناحية العملية ، فإن Product Owner هو الواجهة بين الشركة والعملاء والاحتياجات المتعلقة بالمنتج من جانب والفريق من ناحية أخرى يقوم Product Owner بتخزين الفريق من طلبات الميزات وإصلاح الأخطاء التي تأتي من العديد من المصادر ، وهو نقطة الاتصال الوحيدة لجميع الأسئلة المتعلقة بمتطلبات المنتج. يعمل Product Owner عن كثب مع الفريق لتحديد المتطلبات الفنية والمواجهة للمستخدم ، ولتوثيق المتطلبات حسب الحاجة ، ولتحديد ترتيب تنفيذها. يحتفظ مالك المنتج بـ Product Backlog (وهو مستودع لجميع هذه المعلومات) ، الحفاظ على تحديثه وعلى مستوى التفاصيل والجودة التي يتطلبها الفريق. يحدد "مالك المنتج" أيضًا الجدول الزمني للإفراج عن العمل المكتمل للعملاء ، ويقوم بإجراء المكالمة النهائية بشأن ما إذا كانت عمليات التنفيذ تشتمل على الميزات والجودة المطلوبة للإصدار.
الفريق agile scrum team
الفريق عبارة عن مجموعة ذاتية التنظيم ومتعددة الوظائف من الأشخاص الذين يقومون بالعمل العملي لتطوير واختبار المنتج. نظرًا لأن الفريق مسؤول عن إنتاج المنتج ، يجب أن يتمتع أيضًا بالسلطة لاتخاذ قرارات حول كيفية أداء العمل. لذلك فإن الفريق منظم ذاتيًا: يقرر أعضاء الفريق كيفية تقسيم العمل إلى مهام ، وكيفية تخصيص المهام للأفراد ، طوال Sprint. يجب أن يظل حجم الفريق في النطاق من خمسة إلى تسعة أشخاص ، إن أمكن. (العدد الأكبر يجعل الاتصال صعبًا ، بينما العدد الأصغر يؤدي إلى إنتاجية منخفضة وهشاشة). ملاحظة: مصطلح مشابه جدًا ، "فريق سكرم" ، يشير إلى الفريق بالإضافة إلى ScrumMaster ومالك المنتج
خاتمة
Scrum هو إطار عمل فعال يمكنك من خلاله تطوير البرامج في العمل الجماعي. إنه مصمم بالكامل على مبادئ رشيقة. ScrumMaster موجود لمساعدة فريق Scrum وتعاونه بكل طريقة ممكنة. يعمل كمدرب شخصي يساعدك على الالتزام بالخطة المصممة وأداء جميع الأنشطة وفقًا للخطة. يجب ألا تمتد سلطة ScrumMaster إلى أبعد من العملية. يجب أن يكون قادرًا على إدارة كل موقف.
التسميات: Agile Data Science تعلم دروس منهجية التطوير علم البيانات الرشيقة الآجيل
<< الصفحة الرئيسية