لماذا يعتقد الناس أن منهجية سكروم Scrum Methodology فكرة جيّدة ؟!!

هل تعرف طريقة تجعل تطوير البرمجيات أسرع مع المحافظة على رضا العميل؟

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

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

في هذه التدوينة سأستعرض معك بعض أهم النقاط المتعلقة بسكروم ولماذا يُعتقد أن منهجية سكروم جيّدة في تطوير بعض المشاريع.

الورطة المستمرة في منهجية الشلال Waterfall

في البدء نتحدث عن طريقة تطوير المشاريع العادية والقديمة والمعروفة، المنهجية المسماة بالشلال Waterfall Methodology فقد كانت الأكثر شيوعاً قبل ظهور المنهجيات الرشيقة (سنتحدث عن المنهجيات الرشيقة بعد قليل).

منهجية الشلال هي طريقةٌ تسلسلية لتطوير المشاريع. التسلسل يكون في خطواتها حيثُ تنتهي من خطوة ثم تنتقل إلى التي تليها وهكذا.

فلنرَ العيب الذي لا بد أن يمر به جميع من استخدم هذه المنهجية.

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

وكما ترى، بما أن خطوات منهجية الشلال متسلسلة تخيّل أن يتم اكتشاف خطأ جوهري في جمع المتطلبات أثناء اختبار النظام!

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

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

والآن، هيا لنرَ المنهجيات الرشيقة ونعرّج على منهجية سكروم قليلاً.

بين كفتين: المنهجية الرشيقة Agile و سكرم Scrum

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

المنهجية الرشيقة Agile methodology

هي منهجية لتطوير البرمجيات تعتمد التكرار والتزايد حتى الوصول إلى المنتج النهائي، في هذه المنهجية يتم البدء بتطوير المشروع مع وجود متطلبات غير واضحة ويتم إكمال جميع عمليات تطوير البرنامج بناءً على هذه المتطلبات الغير واضحة!

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

تخيّل أن خطأً حدث في وصف المتطلبات في احدى الدورات واكتُشف الخطأ في عملية الاختبار في نفس الدورة. هل ستكون تكلفة التعديل أكبر من تكلفة التعديل في منهجية الشلال؟

بالطبع لا

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

إن لم ييتضح الأمر لك بعد، كمثال مبسط جداً، إذا أوكل لك تطوير برنامج محاسبي:

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

أين موقع منهجية سكروم من إعراب المنهجية الرشيقة

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

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

طريقة عمل سكروم Scrum

منهجية سكروم تعتمد على مفاهيم بسيطة ولكنها فعالة في تطوير البرامج.

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

ولكن لمنهجية سكروم أسس خاصة بها.

الوظائف الثلاث الأساسية في منهجية سكروم

1. خبير السكروم Scrum Master.
2. مالك المنتج Product Owner.
3. فريق التطوير Development Team.

خبير السكروم Scrum Master:

كثيراً ما تترجم Scrum Master إلى مدير السكروم ولكني أفضل أن أترجمها إلى خبير السكروم لسببٍ سيتضحُ لك بعد قليل.

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

فمثلاً يتعامل مدير السكروم مع كل الأمور التي قد تشغل فريق التطوير من عمله الرئيسي “وهو التطوير” ليوفر لهم بيئةً مستقرة ومساعدة للعمل.

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

ولهذا السبب فضلتُ ترجمة Scrum Master إلى خبير سكروم وليس مدير لتلافي الخلط المتوقع من كلمة “مدير”.

مالك المنتج Product Owner:

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

فمالك المنتج يمثل أصحاب المصلحة Stakeholders بالنسبة لفريق التطوير، كما يمثل فريق التطوير بالنسبة لأصحاب المصلحة.

فهو من يحدد لفريق التطوير الخصائص المطلوبة في النظام وأولويتها. ما الذي يجب أن يطور في هذه الدورة وما الذي يجب أن يطور في الدورة القادمة وهكذا.

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

لذلك بالنسبة لي هو الرابط المهم والذي يؤدي دوراً محورياً في نجاج العمل.

فريق التطوير Development Team:

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

بمعنى يعمل فريق التطوير كوحدة واحدة مهمتها تطوير المنتج المطلوب في نفس الفترة الزمنية المتفق عليها.

ولكن وفقاً لتجربتي لم يكن فريق التطوير كذلك. بل كان فريقاً متخصصاً من محللين ومبرمجين ومختبرين، كلٌ منهم يؤدي مهمته كما يجب ثم يمررها للذي يليه حتى يتم تطوير المنتج المتفق عليها في الوقت المتفق عليه.

مصطلحات مهمة في منهجية سكروم

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

يجب أن تعرف هذه المصطلحات وتستخدمها في المكان المناسب لها:

• قائمة أعمال المنتج Product Backlog: تحتوي هذه القائمة على جميع الخصائص التي يجب تطويرها في المنتج.
• الدورة Sprint: هي الدورة التي يتم فيها تطوير جزء من المنتج.
• قائمة أعمال الدورة Spring Backlog: تحتوي هذه القائمة على جميع الخصائص التي يجب تطويرها في الدورة.
• خريطة الإنجاز Burn-down Chart: توضح بمستوىً عالٍ حجم المهام التي تم انجازها وحجم المهام المتبقية لاكتمال تطوير المنتج.

نظرة خاطفة على دورة Sprint في سكروم Scrum

بعد معرفتك لهذه المصطلحات فلنتحدث عن ما يحدث في الواقع.

في العادة تكون مدة الدورة Sprint ما بين أسبوع إلى شهر، في الفريق الذي عملتُ به كانت مدة الدورة شهراً.

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

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

بنهاية الدورة يتم إطلاق المنتج، ما يعني أن قائمة Sprint Backlog أصبح فارغة و تم انجاز بعض المهام المسجلة بقائمة Product Backlog كما تُظهر خريطة الإنجاز

الأوقات والأماكن المناسبة لاستخدام Scrum

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

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

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

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