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

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

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

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

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

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

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

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

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

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

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

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

فهم Scrum: نظرية Scrum

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

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

الشفافية

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

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

الفحص

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

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

التكيف

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

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

Scrum Team

ثلاثة أعضاء يشكلون فريق "Scrum" الأساسي، وهم: المالك المنتج (Product Owner)، وفريق التطوير (Development Team)، و"ScrumMaster". يُتوقع من هذه الفرق أن تكون ذات تنظيم ذاتي ووظيفي متعدد.

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

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

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

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

Product Owner

عندما يتعلق الأمر بتحقيق القيمة القصوى للمنتج وعمل فريق التطوير، المالك المنتج (Product Owner) هو المسؤول. يختلف ذلك باعتماده على فرق "Scrum" والأفراد داخل الفريق.

للمالك المنتج (Product Owner) المسؤولية الوحيدة لإدارة سجل المنتج (Product Backlog). تشمل هذه الإدارة:

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

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

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

لضمان نجاح Product Owner، يحتاج الجميع في المنظمة إلى احترام قراراته التي تظهر في محتوى وترتيب Product Backlog.

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

The Development Team

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

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

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

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

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

علاوة على ذلك، قد يكون لدى فرق التطوير الصغيرة قيود في مهاراتهم خلال Sprint، مما يعني أنهم قد لا يكونون قادرين على تقديم "Increment" القابل للإصدار.

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

عند عد فريق التطوير، Product Owner و"ScrumMaster" لا يتم احتسابهما إلا إذا كانوا أيضًا ينفذون عمل Sprint Backlog.

Scrum Master

لـ "ScrumMaster" مسؤولية التأكد من فهم Scrum وتنفيذه. يعملون مع فريق Scrum حتى يتمكنوا من الالتزام بنظرية Scrum والممارسات والقواعد.

"ScrumMaster" هو في الأساس القائد-الخادم لفريق Scrum. إذا كنت في الموقف الذي تكون فيه "ScrumMaster" لفريقين، فانظر في: "أسئلتك الملحة حول قيادة فريقين كـ ScrumMaster".

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

فهم خدمة Scrum Master

هناك ثلاث مجموعات تخدمها خدمة ScrumMaster وتشمل:

خدمة Scrum Master لـ Product Owner

يتم ذلك بعدة طرق منها:

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

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

هنا، سيساعد "ScrumMaster" فريق التطوير بالطرق التالية:

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

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

يمكن لـ "ScrumMasters" خدمة المنظمة بعدة طرق مثل:

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

Scrum Values

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

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

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

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

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

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

كل حدث يوفر فرصة للتفتيش أو التكيف بشيء ما وتم تصميمه لتمكين الشفافية الحاسمة. هناك أربعة أحداث رسمية يوصي بها Scrum. وهي:

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

فهم الـ Sprint

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

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

تحتوي الـ Sprints وتتألف من Sprint Planning، Daily Scrums، Sprint Review، Sprint Retrospective، وأعمال التطوير.

بينما يجري الـ Sprint، لا يجب إجراء أي تعديلات قد تؤثر على Sprint Goal، أهداف الجودة لا تقل، ويمكن توضيح النطاق وإعادة التفاوض بين الـ Product Owner وفريق التطوير حيث يتم التعلم أكثر.

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

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

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

من الممكن إلغاء Sprint قبل أن ينتهي وقت Sprint. ومع ذلك، الشخص الوحيد الذي لديه السلطة للقيام بذلك هو الـ Product Owner.

قد يتأثر هذا القرار بالآخرين بما في ذلك المعنيين، فريق التطوير، أو الـ ScrumMaster. قد يأتي الإلغاء مع Sprint Goal يصبح عفا عليه الزمن.

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

هناك خطوات تحتاج إلى أن تتخذ بمجرد إلغاء الـ Sprint. يتم مراجعة العناصر المكتملة و "Done" من Product Backlog أولاً. إذا كان بعض العمل من Sprint قابلًا للإصدار، سيتم قبوله بواسطة Agile Product Owner.

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

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

Sprint Planning

أي عمل يجب أن يتم خلال الـ 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 بينما سيصمم فريق الScrum Sprint Goal.

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

بمجرد تحديد Sprint Goal واختيار عناصر Product Backlog للSprint، سيقرر فريق التطوير كيف سيتم بناء الوظيفة في Increment منتج "Done" خلال الSprint. العناصر Product Backlog التي تم اختيارها لهذا الSprint، جنبًا إلى جنب مع الخطة لتقديمها تعرف باسم Sprint Backlog.

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

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

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

يتم ذلك مع Agile Product Owner، كما يكون فريق التطوير أيضًا حرًا في دعوة الآخرين للحضور من أجل الحصول على نصائح فنية أو مجالية.

Sprint Goal

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

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

Daily Scrum

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

يتضمن فحص العمل الذي تم منذ الـ Daily Scrum الأخير ومن ثم النظر في العمل الذي يجب القيام به قبل الـ Daily Scrum التالي.

من الأساسي أن يظل وقت ومكان الـ Daily Scrum نفسه كل يوم، حيث سيقلل ذلك من أي تعقيد. في الاجتماع، سيستكشف فريق التطوير:

• ما الذي تم القيام به أمس والذي ساعد الفريق في تحقيق Sprint Goal.
• ما الذي سيتم القيام به اليوم للمساعدة في تحقيق Sprint Goal.
• ما العوائق التي قد تمنع قدرة الفريق على تحقيق Sprint Goal.

وهذا يعني أن الـ Daily Scrum هو مثل متعقب لفحص تقدم Sprint Goal. يضمن أن العمل قائم على الـ Sprint Backlog ويجعل من السهل جدًا تحقيق الهدف.

يتم تحدي فريق التطوير خلال الـ Daily Scrum للعمل معًا كفريق ذاتي التنظيم من خلال مناقشات مفصلة حيث قد يكون عليهم التكيف أو إعادة تشغيل باقي عمل Sprint.

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

Sprint Review

الاستعراض الـ Sprint Review يتم إجراؤه بمجرد الانتهاء من الـ Sprint. وهو مخصص لفحص الـ Increment وتكييف الـ Product Backlog إذا كان ذلك ضروريًا. عندما يتم الـ Sprint Review، يقوم فريق Scrum وأصحاب المصلحة بتقييم ما تم القيام به خلال الـ Sprint.

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

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

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

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

بعد الـ Sprint Review، غالبًا ما يتم مراجعة الـ Product Backlog، ويتم تحديد عناصر Product Backlog المحتملة للـ Sprint التالي. قد يتم ضبطه بشكل عام لمواجهة فرص جديدة.

Sprint Retrospective

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

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

سيشارك ScrumMaster كعضو فريق متساوي لتقديم المعلومات حول المسؤولية عن عملية Scrum. الغرض من هذا الاجتماع هو:

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

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

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

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

أدوات Scrum

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

Product Backlog

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

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

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

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

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

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

لدى Product Owner الحق في تحديث عناصر Product Backlog في أي وقت.

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

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

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

من الممكن حساب كمية العمل المطلوبة لتحقيق هدف في أي وقت. خلال Sprint Review، سيتتبع Product Owner كم من العمل لا يزال يتعين القيام به.

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

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

Sprint Backlog

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

في الأساس، Sprint Backlog هو توقع من فريق التطوير ينظر فيه إلى مدى فعالية كل Increment، وكذلك العمل المطلوب لتحويل الوظيفة إلى Increment "Done".

يضمن Sprint Backlog أن كل العمل الذي يقوم به فريق التطوير مرئي ويمكن تحديده لتحقيق Sprint Goal. Sprint Backlog في الأساس هو خطة تحتوي على التفصيل المطلوب لفهم التغييرات في التقدم في Daily Scrum.

يمكن لفريق التطوير تعديل Sprint Backlog طوال الـ Sprint ومن ثم الظهور خلال الـ Sprint حيث يعمل فريق التطوير من خلال الخطة. وذلك لأنه تم التعرف أكثر على العمل اللازم لتحقيق Sprint Goal.

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

فقط فريق التطوير هو الذي يمكنه تغيير Sprint Backlog خلال Sprint. Sprint Backlog هو مثل الرسم البياني المرئي لفريق التطوير وينتمي فقط إلى فريق التطوير.

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

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

Increment

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

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

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

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

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

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

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

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

Definition of “Done”

المصطلح "Done" ظهر عدة مرات في هذا النص. عندما يقال أن عنصر Product Backlog أو "Increment" هو "Done"، فمن الأساسي أن يفهم جميع المعنيين المعنى.

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

هو هذا التعريف الذي سيقدم إرشادًا لفريق التطوير في عدد عناصر Product Backlog التي يجب اختيارها خلال عملية Sprint Planning. السبب في وجود كل "Sprint" هو تقديم "Increments" من الوظائف المحتملة القابلة للإصدار التي تتناسب مع تعريف "Done" من فريق Scrum.

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

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

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

كل "Increment" هو إضافي إلى جميع الـ "Increments" السابقة وتم اختباره بشكل مكثف. هذا يضمن أنهم جميعًا يعملون معًا.

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

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

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

إذا كنت مهتمًا في معرفة ما إذا كانت شركتك مركزة على المشروع أو شركة موجهة للمنتج ببساطة خذ اختبارنا للمنتج إلى منتج.

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

إذا كنت مهتمًا في إجراء تحول في شركتك، يرجى مراجعة: الاستشارات من المشروع إلى المنتج.