منهجية Scrum، الدليل الكامل لقادة شركات المنتجات الرقمية

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

تعد منهجية سكرم إطارًا أساسيًا لأي قائد ملتزم ببناء شركة منتجات رقمية.

ADAPT Methodology® هو إطار عمل مميز لتطوير المنتجات الرقمية مصمم لتحويل الشركات التقليدية التي تركز على المشاريع إلى مؤسسات تقودها المنتجات.

مع تطور المجتمع، يحتاج القادة إلى الدعم في كيفية قيادة وتصميم مؤسسات منتجاتهم الرقمية. أدت هذه الحاجة إلى إنشاء ADAPT Methodology®. الآن، دعونا نتعمق في مجتمعات الممارسة لفهم أعمق لهذا الموضوع.

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

يتضمن Scrum أيضًا عناصر مختلفة، بما في ذلك كونه خفيف الوزن وسهل الفهم. ومع ذلك، فمن المسلم به أنه من الصعب إتقانها.

نظرة أعمق على منهجية Scrum

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

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

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

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

فهم Scrum: نظرية Scrum

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

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

الشفافية

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

• جميع المشاركين الذين يشيرون إلى العملية يحتاجون إلى استخدام لغة مشتركة
• أولئك الذين يقومون بالعمل، وكذلك الذين يقبلون النتيجة، يحتاجون إلى تعريف قياسي لـ Definition of Done.

الفحص

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

يضمن المفتشون المهرة أن أي عمليات تفتيش تتم بشكل جيد ومفيدة للغاية.

التكيف

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

وكلما حدث ذلك بشكل أسرع، كلما كان ذلك أفضل لتقليل احتمال حدوث المزيد من الانحراف.

فريق Scrum 

يتكون فريق Scrum الأساسي من ثلاثة أعضاء: مالك المنتج، وفريق التطوير، وScrum Master. تم تصميم هذه الفرق لتكون ذاتية التنظيم ومتعددة الوظائف.

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

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

هدف الفريق هو تحسين المرونة والإبداع والإنتاجية.

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

بالنسبة لأولئك المهتمين بتكوين فريق رائع، فكر في قراءة هاتين المقالتين: "How To Ramp Up A Great Agile Team" و"How To Have A Team Kick Off Meeting".

مالك المنتج

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

يتحمل مالك المنتج المسؤولية الحصرية عن إدارة Product Backlog. هذا يتضمن:

• التعبير بوضوح عن عناصر Product Backlog
• طلب العناصر في Product Backlog لتحقيق المهام والأهداف
• تحسين قيمة العمل الذي يؤديه فريق التطوير
• التأكد من أن قائمة المنتجات المتراكمة مرئية وشفافة وواضحة للجميع

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

مالك المنتج فرد واحد وليس لجنة. في حالة وجود لجنة، يمكنها التعبير عن رغباتها من خلال Product Backlog. يجب توجيه أي تعديلات على الأعمال المتراكمة إلى مالك المنتج.

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

لا يمكن لأحد أن يأمر فريق التطوير بالعمل مع المتطلبات البديلة، ويمنع فريق التطوير من التصرف بناءً على تعليمات من أي شخص آخر.

فريق التطوير

يتكون هذا الفريق من محترفين مخصصين لتقديم زيادة محتملة لمنتج "Done" في نهاية كل Sprint. يمكن لأعضاء الفريق فقط إنشاء الزيادة.

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

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

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

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

وتتطلب الفرق الكبيرة، التي تضم أكثر من تسعة أعضاء، قدراً أكبر بكثير من التنسيق، الأمر الذي يؤدي إلى تعقيد مفرط حتى تتمكن العملية التجريبية من إدارتها بفعالية.
 
عند النظر في حجم فريق التطوير، لا يتم تضمين Product Owner وScrum Master إلا إذا كانا يقومان أيضًا بتنفيذ عمل Sprint Backlog.

Scrum Master

يتحمل Scrum Master مسؤولية التأكد من فهم Scrum وإصداره. إنهم يعملون مع فريق Scrum حتى يتمكنوا من الالتزام بنظرية Scrum وممارساته وقواعده.

إن Scrum Master هو في الأساس القائد الخادم لفريق Scrum. إذا كنت في موقف حيث أنك Scrum Master لفريقين، قم بإلقاء نظرة على: "Your Most Burning Questions About Leading 2 Teams as a Scrum Master".

يساعد Scrum Master الأشخاص الذين ليسوا في فريق Scrum على فهم أي من تفاعلاتهم مع فريق Scrum مفيدة وأيها ليست كذلك.

فهم خدمة Scrum Master

هناك ثلاث مجالات يقدم فيها Scrum Master الخدمة:

خدمة Scrum Master لمالك المنتج

هذا يتضمن:

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

   

خدمة Scrum Master لفريق التطوير

يساعد Scrum Master فريق التطوير من خلال:

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

خدمة Scrum Master للمنظمة

يخدم Scrum Masters المنظمة بعدة طرق، بما في ذلك:

• قيادة وتدريب المنظمة في اعتماد سكروم
• تخطيط تنفيذ سكروم داخل المنظمة
• مساعدة الموظفين وأصحاب المصلحة على فهم Scrum وتطوير المنتجات التجريبية
• تغييرات القيادة التي تعزز إنتاجية فريق Scrum
• التعاون مع Scrum Masters الآخرين لتحسين فعالية تنفيذ Scrum داخل المنظمة
  
  

قيم Scrum

هناك العديد من القيم التي يحتاج فريق Scrum إلى تجسيدها والعيش وفقًا لها. وهي الشجاعة والالتزام والانفتاح والاحترام والتركيز. هذه القيم هي السبب الجذري لتفعيل ركائز Scrum وبناء الثقة مع جميع المشاركين.

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

وهذه هي الطريقة التي يفعلون بها ذلك:

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

أحداث Scrum: أحداث الفحص والتكيف

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

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective 

فهم الـ Sprint

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

يجب أن تحافظ سباقات السرعة على فترات متسقة طوال جهود التطوير بأكملها. يبدأ الـ Sprint الجديد فقط بعد انتهاء الـ Sprint السابق.

يشتمل Sprint على تخطيط Sprint، وDaily Scrums، ومراجعة Sprint، وSprint Retrospective، وأعمال التطوير.

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

يمكن اعتبار كل Sprint بمثابة مشروع مدته شهر وله هدف محدد. وبالتالي، يتضمن Sprint منتجًا محددًا بوضوح سيتم بناؤه، وخطة مرنة لتطويره، والعمل الفعلي، والمنتج النهائي.

إذا امتد الـ Sprint لأكثر من شهر واحد، فقد يتغير تعريف المنتج، مما يزيد من المخاطر والتعقيد العام.

تعد سباقات السرعة ضرورية لضمان إمكانية التنبؤ بالعمل وإمكانية فحصه وتكييفه لتحقيق هدف Sprint. أنها تحد من المخاطر، وخاصة فيما يتعلق بالتكلفة.

يمكن إلغاء Sprint قبل انتهاء المربع الزمني الخاص به. ومع ذلك، فإن مالك المنتج فقط هو الذي يملك صلاحية القيام بذلك.

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

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

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

لا يتم تشجيع الإلغاءات لأنها تستهلك الموارد.

يجب على جميع المشاركين إعادة تجميع صفوفهم والانخراط في عملية تخطيط أخرى لـ Sprint لبدء Sprint جديد. يمكن أن تؤدي عمليات الإلغاء إلى تعطيل فريق Scrum وبالتالي يتم تجنبها.

تخطيط Sprint

أي عمل يجب أن يتم خلال الـ Sprint يتم تخطيطه في Sprint Planning. يتم إنشاء الخطة بواسطة العمل التعاوني بين جميع أعضاء فريق Scrum. يتم تحديد الوقت لـ Sprint Planning بحد أقصى ثماني ساعات لـ Sprint الذي يستمر شهرًا كاملًا؛ هنا يمكنك العثور على اقتراح حول كيفية إجراء Sprint Planning فعال.

عندما يكون الـ Sprint أقصر، يميل الحدث أيضًا إلى أن يكون أقصر. من مسؤولية الـ ScrumMaster التأكد من أن الحدث يتم وأن المشاركين يفهمون السبب وراء الحدث. ثم سيعلم الـ ScrumMaster الفريق كيف يبقى ضمن الوقت المحدد.

ما الذي يمكن تسليمه من الـ Sprint القادم؟

خلال فترة Sprint Planning، سيعمل فريق التطوير على التنبؤ بالوظائف التي سيتم تطويرها خلال الـ Sprint.

سيناقش Product Owner الهدف الذي يتطلع الـ Sprint إلى تحقيقه. علاوة على ذلك، ستساعد Product Backlog items في تحقيق Sprint Goal. سيعمل فريق الScrum كله معًا على فهم عمل الـ Sprint.

تتمثل الإدخالات الرئيسية لهذا الاجتماع في Product Backlog، والIncrement الأخير، والقدرة المتوقعة لفريق التطوير خلال الـ Sprint وأداء فريق التطوير السابق.

سيحدد فريق التطوير كم عدد العناصر التي سيأتي بها الـ Sprint من Product Backlog. فريق التطوير هو الذي سيقدم المعلومات حول ما يمكنهم إنجازه خلال توقعات الـ Sprint.

بعد التنبؤ بعناصر Product Backlog، سيطور فريق التطويرالـ Sprint بينما سيصمم فريق الـ Sprint، الهدف.

كيف سيتم تحقيق العمل؟

بمجرد إنشاء هدف الـ Sprint وتحديد عناصر Product Backlog للسبرنت، يقرر فريق التطوير كيفية بناء الوظائف في زيادة المنتج "المكتملة" أثناء الـ Sprint. تُعرف عناصر Product Backlog المحددة لـ Sprint، جنبًا إلى جنب مع خطة تسليمها، بشكل جماعي باسم Sprint Backlog.

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

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

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

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

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

هدف الـ Sprint

هذا هو هدف تم تحديده لـ Sprint والذي يمكن تحقيقه بسهولة بمجرد تنفيذ Product Backlog. يقدم بعض التوجيه لفريق التطوير بشأن السبب الذي يتم بناء الIncrement من أجله. يتم إنشاء Sprint Goal خلال اجتماع Sprint Planning.

يضمن أن يكون لدى فريق التطوير مرونة فيما يتعلق بالوظيفة التي يتم تنفيذها ضمن Sprint. يتم تقديم Sprint Goal من خلال عناصر Product Backlog ويضمن أن يتمكن فريق التطوير من العمل معًا بدلاً من التوجه إلى مبادرات منفصلة.

Daily Scrum

كل يوم، يخصص فريق التطوير 15 دقيقة لمزامنة أنشطتهم ووضع خطة للـ 24 ساعة القادمة. يُعرف هذا باسم Daily Scrum.

يتضمن Daily Scrum فحص العمل المنجز منذ الاجتماع الأخير وتحديد المهام التي يجب إنجازها قبل الاجتماع التالي.

من المهم أن يتم عقد Daily Scrum في نفس الوقت والمكان كل يوم لتقليل التعقيد. وسيتناول فريق التطوير خلال الاجتماع ما يلي:

• ما تم إنجازه بالأمس للمساعدة في تحقيق هدف Sprint
• ما الذي سيتم فعله اليوم للمساعدة في تحقيق هدف Sprint
• ما هي العوائق التي قد تمنع الفريق من تحقيق هدف Sprint

Sprint Review

يتم إجراء مراجعة Sprint بمجرد انتهاء Sprint. والغرض منه هو فحص الزيادة وتكييف Product Backlog إذا لزم الأمر. أثناء مراجعة Sprint، يقوم فريق Scrum وأصحاب المصلحة بتقييم العمل المكتمل أثناء Sprint.

قد تؤدي نتيجة مناقشتهم إلى تغييرات في Product Backlog وتحديد التحسينات المحتملة لإضافة القيمة. تهدف المراجعة إلى مشاركة المعلومات وجمع التعليقات، مما يضمن التعاون بدلاً من أن يكون بمثابة اجتماع حالة.

تتم جدولة مراجعة Sprint عادةً لمدة أربع ساعات إذا استمرت Sprint لمدة شهر واحد، مع اجتماعات أقصر لسباقات السرعة الأقصر.

تتضمن المراجعة العناصر التالية:

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

Sprint بأثر رجعي

يوفر هذا الاجتماع لفريق Scrum فرصة لتفقد عملهم ووضع خطة للتحسينات في Sprint القادم. ويحدث بعد مراجعة السبرنت وقبل تخطيط السبرنت التالي.

تم تحديد وقت الاجتماع بثلاث ساعات لسباقات السرعة القصيرة لمدة شهر واحد، مع اجتماعات أقصر لسباقات السرعة الأقصر. يضمن Scrum Master عقد الاجتماع وأن المشاركين يفهمون الغرض منه.

يشارك Scrum Master كعضو في فريق نظير، ويقدم التوجيه بشأن المساءلة ضمن عملية Scrum. الغرض من هذا الاجتماع هو:

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

يستخدم Scrum Master هذه الجلسة لتشجيع فريق Scrum على تحسين إطار عملهم، وعملية التطوير، والممارسات، مما يضمن أن يكون Sprint التالي أكثر فعالية ومتعة.

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

عند الانتهاء من Sprint Retrospective، سيكون فريق Scrum قد حدد مجالات التحسين لـ Sprint القادم. يتم بعد ذلك تكييف هذه التحسينات وفحصها بواسطة فريق Scrum. يُعد معرض Sprint Retrospective بمثابة فرصة رسمية للتفتيش والتكيف المركّزين.

لمزيد من الأفكار، يمكنك قراءة مقالتي، "The Agile Retrospectives Guide That Will Make You A Fantastic Facilitator" بالإضافة إلى ذلك، ننصح بشدة بمقالة مارك لوفلر، "The most 5 asked questions about Agile Retrospectives". للحصول على أفكار جديدة، قم بمراجعة  "Agile Retrospectives Ideas".

أدوات Scrum

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

Product Backlog

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

إن Product Backlog عبارة عن عمل قيد التقدم ولا يصل أبدًا إلى الإصدار النهائي. فهو يحدد المتطلبات ويتطور مع تطور المنتج. ويتغير لضمان بقاء المنتج ملائمًا ومفيدًا وتنافسيًا وموجودًا طوال فترة وجود المنتج.

يتضمن Product Backlog جميع الميزات والمتطلبات والوظائف والتحسينات والإصلاحات التي سيتم إجراؤها على المنتج في الإصدارات المستقبلية. يحتوي كل عنصر في Product Backlog على وصف وترتيب وتقدير وقيمة.

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

عندما تعمل فرق Scrum متعددة على منتج واحد، يتم استخدام Product Backlog واحد فقط لوصف المنتج. لتحسين قائمة المنتجات، قد يتم تعديل التفاصيل والتقديرات وترتيب العناصر.

تتضمن عملية التحسين هذه التعاون بين مالك المنتج وفريق التطوير. أثناء التحسين، تتم مراجعة وتنقيح العناصر المتبقية في Product Backlog. يقرر فريق Scrum كيفية إجراء التحسين، مع التأكد من أنه لا يتجاوز 10% من قدرة فريق التطوير.

يمكن لمالك المنتج تحديث عناصر Product Backlog في أي وقت.

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

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

مراقبة التقدم نحو هدف

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

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

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

Sprint Backlog

تُعرف عناصر Product Backlog المحددة لـ Sprint باسم Sprint Backlog. يتضمن هذا أيضًا خطة تقديم "زيادة المنتج" وتحقيق هدف Sprint.

بشكل أساسي، Sprint Backlog عبارة عن توقعات من قبل فريق التطوير والتي توضح مدى فعالية كل زيادة والعمل المطلوب لتقديم الوظيفة إلى زيادة "منجزة".

يضمن Sprint Backlog أن جميع الأعمال التي يقوم بها فريق التطوير مرئية ويمكن التعرف عليها لتحقيق هدف Sprint. إنها بمثابة خطة مفصلة، ​​مما يسمح بفهم التغييرات الجارية أثناء Daily Scrum.

يمكن لفريق التطوير تعديل Sprint Backlog خلال Sprint، والتكيف عندما يتعلمون المزيد عن العمل المطلوب لتحقيق هدف Sprint.

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

يمكن لفريق التطوير فقط تغيير Sprint Backlog أثناء Sprint. يعد Sprint Backlog مخططًا مرئيًا لفريق التطوير وهو ملك لهم فقط.

مراقبة تقدم الـ Sprint

أثناء الـ Sprint، يمكن تلخيص Sprint Backlog في أي لحظة. الأمر متروك لفريق التطوير لتتبع إجمالي العمل المتبقي لكل Daily Scrum لتوضيح إمكانية تحقيق هدف Sprint. يتيح التتبع لفريق التطوير إدارة التقدم.

Increment

يمكن تلخيص العمل الإجمالي المتبقي في Sprint Backlog في الوقت الحالي. الـ Increment هو مجموع هؤلاء بالإضافة إلى قيمة أي Increments أخرى من Sprints السابقة.

يجب أن يكون الـ Increment النهائي في نهاية الـ Sprint "Done"، مما يعني أنه في حالة قابلة للاستخدام ويفي بالتعريف الذي حدده فريق Scrum.

الحالة القابلة للاستخدام ضرورية، سواء اختار Product Owner إصدارها أم لا.

شفافية الأدوات

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

يحتاج "Scrum Master" إلى العمل مع جميع الأطراف المعنية بما في ذلك Product Owner وفريق التطوير للتأكد من أن الأدوات شفافة تمامًا. في حالة عدم وجود شفافية كاملة، هناك ممارسات للتعامل مع هذا الوضع.

يحتاج "Scrum Master" إلى مساعدة الجميع في تطبيق أفضل الممارسات حيث لا تكون الشفافية كاملة. يمكن لـ "Scrum Master" اكتشاف عدم الشفافية الكاملة عند فحص الأدوات، واستشعار الأنماط، ومراقبة جميع المعلومات بعناية.

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

تعريف "Done"

لقد ظهر مصطلح "Done" عدة مرات في هذا النص. عندما يقال أن أحد عناصر قائمة المنتجات أو الزيادة قد تم "Done"، فمن الضروري أن يفهم جميع المشاركين معناه.

تعني كلمة "Done" أن العمل قد اكتمل ويضمن الشفافية. بالنسبة لفريق Scrum، تعني كلمة "Done" أن العمل على زيادة المنتج قد اكتمل. لقد كتبت سابقًا مثالاً على "Definition of Done Checklist".

يرشد هذا التعريف فريق التطوير في تحديد عدد عناصر Product Backlog أثناء عملية تخطيط Sprint. يهدف كل Sprint إلى تقديم زيادات في الوظائف التي يمكن إصدارها والتي تتوافق مع تعريف فريق Scrum لـ "Done".

مع كل Sprint، يجب على فريق التطوير تقديم زيادة قابلة للاستخدام في وظائف المنتج. قد يقرر مالك المنتج إطلاقه على الفور. إذا كان تعريف "Done" للزيادة جزءًا من اتفاقيات أو معايير أو إرشادات منظمة التطوير، فيجب على جميع فرق Scrum الالتزام به كحد أدنى.

إذا لم يكن تعريف "Done" من اصطلاح منظمة التطوير، فيجب على فريق التطوير وضع تعريف يتوافق مع المنتج.

عندما تعمل فرق Scrum متعددة على إصدار منتج، يجب على جميع فرق التطوير تعريف "Done" بشكل متبادل.

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

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

هذا يلخص "ما هي منهجية سكروم." لا تتردد في ترك التعليقات أدناه.

هل أعجبك هذا المقال؟

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