دليل شامل لمناهج الرشاقة، سكروم، والبرمجة المتطرفة
يجب إحضار منتجات البرمجيات إلى السوق بسرعة، مما يجعل التطوير والتسليم السريع للبرمجيات ضروريًا. تقريبًا جميع منتجات البرمجيات تُطور الآن باستخدام نهج رشيق يركز على تسليم الوظائف بسرعة، والاستجابة لمواصفات المنتج المتغيرة، وتقليل النفقات العامة للتطوير.
التركيز على تسليم البرمجيات الوظيفية بشكل تدريجي ومتكرر لتقديم قيمة تجارية فورية.
احتضان المتطلبات والمواصفات المتغيرة طوال عملية التطوير.
تقليل البيروقراطية والوثائق التي لا تساهم مباشرة في تطوير البرمجيات.
التركيز على التعاون الجماعي، مشاركة العملاء، والتواصل المستمر.
العمل الأكثر تأثيرًا الذي غير ثقافة تطوير البرمجيات كان تطوير البرمجة المتطرفة (XP). بيان الرشاقة، الذي تم إنشاؤه عام 2001، أرسى هذه المبادئ وأنشأ منهجيات الرشاقة كنهج رئيسي لتطوير البرمجيات.
البرمجة المتطرفة (XP) هي منهجية تطوير برمجيات رشيقة صاغها كينت بيك عام 1998. الاسم يأتي من نهج دفع الممارسات الجيدة المعترف بها، مثل التطوير التكراري، إلى مستويات "متطرفة". قدمت XP تقنيات تطوير ثورية موجهة نحو التطوير السريع، التغير، والتسليم التدريجي للبرمجيات.
قصص المستخدم توجيه التطوير بدون خطة شاملة مسبقة
تسليم متكرر للحد الأدنى من الوظائف المفيدة
كتابة الاختبارات قبل كتابة الكود
تكامل واختبار الكود بشكل متكرر
تحسين هيكل الكود باستمرار
يمكن لأي شخص تغيير أي كود في أي مكان
مبرمجان يعملان معًا على محطة عمل واحدة
العمل بوتيرة يمكن الحفاظ عليها إلى أجل غير مسمى
ممثل العميل هو جزء من الفريق
التصميم للمتطلبات الحالية فقط
لا توجد "خطة شاملة" للنظام. يتم تحديد المتطلبات من خلال مناقشات مع ممثل العميل الذي هو جزء من فريق XP. يتم التعبير عن متطلبات المستخدم كقصص مستخدم أو سيناريوهات تصف ما يجب تنفيذه في كل زيادة.
الأكثر أهميةيتم تطوير الحد الأدنى من الوظائف المفيدة التي تقدم قيمة تجارية أولاً. الإصدارات متكررة وتضيف الوظائف تدريجيًا للإصدارات السابقة، مما يضمن التسليم المستمر للقيمة.
تأثير عاليبدلاً من كتابة الكود ثم الاختبارات، يكتب المطورون الاختبارات أولاً. يساعد هذا النهج في توضيح ما يجب أن يفعله الكود فعلاً ويضمن تغطية اختبار شاملة من البداية.
تركيز على الجودةبمجرد اكتمال العمل في مهمة، يتم دمجها في النظام بأكمله ويتم إنشاء نسخة جديدة. تعمل جميع اختبارات الوحدات من جميع المطورين تلقائيًا ويجب أن تنجح قبل قبول النسخة الجديدة.
الأتمتةإعادة الهيكلة تعني تحسين الهيكل، إمكانية القراءة، الكفاءة، وأمان البرنامج دون تغيير وظائفه. من المتوقع من جميع المطورين إعادة هيكلة الكود بمجرد العثور على تحسينات محتملة، مما يحافظ على الكود بسيطًا وقابل للصيانة.
التطوير المستمرالسياق: يجب أن يكون سجل المريض مفتوحًا للإدخال. انقر على حقل الدواء واختر إما "الدواء الحالي"، "دواء جديد"، أو "النموذج الطبي".
السيناريو 1 - الدواء الحالي: إذا اخترت "الدواء الحالي"، سيُطلب منك التحقق من الجرعة. إذا أردت تغيير الجرعة، أدخل الجرعة الجديدة ثم أكد الوصفة.
السيناريو 2 - دواء جديد: إذا اخترت "دواء جديد"، يفترض النظام أنك تعرف الدواء الذي تريد وصفه. اكتب الحروف الأولى من اسم الدواء. سترى قائمة بالأدوية المحتملة التي تبدأ بهذه الحروف. اختر الدواء المطلوب، تحقق من أن اختيارك صحيح، أدخل الجرعة، ثم أكد الوصفة.
السيناريو 3 - النموذج الطبي: إذا اخترت "النموذج الطبي"، سيتم تقديم صندوق بحث للنموذج الطبي المعتمد. ابحث عن الدواء المطلوب ثم اختره. تحقق من أن الدواء الذي اخترته صحيح، أدخل الجرعة، ثم أكد الوصفة.
فحص السلامة: في جميع الحالات، سيتحقق النظام من أن الجرعة ضمن النطاق المعتمد وسيطلب منك تغييرها إذا كانت خارج نطاق الجرعات الموصى بها.
التأكيد النهائي: بعد تأكيد الوصفة، ستظهر للفحص. انقر إما على "موافق" أو "تغيير". إذا نقرت على "موافق"، سيتم تسجيل وصفتك في قاعدة بيانات التدقيق. إذا نقرت على "تغيير"، فستدخل مرة أخرى في عملية "وصف الدواء".
تنفيذ وظيفة تعديل جرعة الدواء الموصوف مسبقًا
تطوير الواجهة والمنطق للبحث والاختيار من النموذج الطبي المعتمد
فحص الجرعة هو احتياط سلامة للتحقق من أن الطبيب لم يصف جرعة خطيرة صغيرة جدًا أو كبيرة جدًا. باستخدام معرف النموذج الطبي لاسم الدواء العام، ابحث في النموذج الطبي واسترجع الحد الأقصى والحد الأدنى الموصى بهما للجرعة. تحقق من الجرعة الموصوفة مقابل الحد الأدنى والحد الأقصى. إذا كانت خارج النطاق، أصدر رسالة خطأ تقول أن الجرعة مرتفعة جدًا أو منخفضة جدًا. إذا كانت ضمن النطاق، فعّل زر "تأكيد".
مثال لاختبار وحدة مكتوب قبل كود التنفيذ
المدخلات:
الاختبارات:
المخرجات:
موافق أو رسالة خطأ تشير إلى أن الجرعة خارج النطاق الآمن
على عكس الحكمة التقليدية في هندسة البرمجيات التي تنادي بالتصميم للتغيير، تؤكد XP أن توقع التغييرات لا يستحق العناء لأن التغييرات لا يمكن توقعها بموثوقية. بدلاً من ذلك، تؤكد XP على الحفاظ على الكود بسيطًا من خلال إعادة الهيكلة المستمرة، مما يجعل من السهل التكيف عندما تحدث تغييرات فعلية.
سكروم هو منهج رشيق يركز على إدارة التطوير التكراري بدلاً من الممارسات الرشيقة المحددة. يوفر إطارًا لتنظيم وإدارة العمل، مما يسمح للفرق باختيار ممارساتهم التقنية الخاصة. سكروم فعال بشكل خاص للمشاريع التي تتغير خططها دائمًا والخطط طويلة المدى غير موثوقة.
مرحلة التخطيط العامة حيث يتم إنشاء الأهداف العامة وتصميم بنية البرمجيات
سلسلة من سباقات التطوير حيث تطور كل دورة زيادة في النظام
اختتام المشروع، إكمال الوثائق، وتقييم الدروس المستفادة
يحدد ميزات المنتج والمتطلبات، يرتب قائمة المنتج حسب الأولوية، ويضمن أن المشروع يلبي احتياجات الأعمال الحرجة. يمكن أن يكون عميلًا، مدير منتج، أو ممثلًا لأصحاب المصلحة.
يضمن اتباع عملية سكروم ويوجه الفريق في الاستخدام الفعال لسكروم. مسؤول عن التواصل مع الشركة وضمان عدم تشتيت انتباه الفريق من خلال التدخل الخارجي.
مجموعة ذاتية التنظيم من مطوري البرمجيات (عادة 5-9 أشخاص) مسؤولة عن تطوير البرمجيات والوثائق الأساسية للمشروع. يدير الفريق نفسه وينشئ زيادات "مكتملة".
| المصطلح | التعريف |
|---|---|
| السبرنت | تكرار تطوير، عادة ما يكون من 2-4 أسابيع، يتم خلاله إنشاء زيادة منتج قابلة للشحن |
| قائمة المنتج | قائمة مرتبة حسب الأولوية من عناصر "المهام" بما في ذلك الميزات، المتطلبات، قصص المستخدم، والمهام الأخرى التي تحتاج إلى معالجة |
| قائمة السبرنت | مجموعة عناصر قائمة المنتج المختارة للسبرنت، بالإضافة إلى خطة لتسليم زيادة المنتج |
| سكروم اليومي | اجتماع يومي مدته 15 دقيقة يراجع فيه الفريق التقدم ويخطط العمل للـ 24 ساعة القادمة |
| زيادة المنتج القابلة للشحن | البرمجيات المسلمة من سبرنت تكون في حالة مكتملة لا تتطلب مزيدًا من العمل لدمجها في المنتج النهائي |
| السرعة | تقدير لمقدار جهد قائمة المنتج الذي يمكن للفريق تغطيته في سبرنت واحد، يستخدم للتخطيط وقياس التحسين |
قائمة المنتج هي وثيقة حية تسرد كل ما هو مطلوب لإكمال المنتج. تشمل العناصر ميزات المنتج، طلبات المستخدم، أنشطة التطوير، وتحسينات الهندسة. يجب أن تكون القائمة دائمًا مرتبة حسب الأولوية مع العناصر ذات الأولوية القصوى في الأعلى.
أفكار عالية المستوى وأوصاف الميزات التي هي مؤقتة وقد تتغير جذريًا أو قد لا تُدرج في المنتج النهائي.
العناصر التي وافق الفريق على أنها مهمة ويجب تنفيذها. هناك تعريف واضح إلى حد معقول، لكن هناك حاجة إلى مزيد من العمل لفهم وتحسين العنصر.
عنصر قائمة المنتج به تفاصيل كافية للفريق لتقدير الجهد وتنفيذه. تم تحديد التبعيات على العناصر الأخرى.
يتم إضافة عناصر جديدة بناءً على احتياجات أصحاب المصلحة واكتشافات الفريق
يتم تقسيم العناصر إلى عناصر أصغر وأكثر تفصيلاً
يقدر الفريق الجهد المطلوب لكل عنصر
مالك المنتج يرتب العناصر حسب القيمة التجارية والتبعيات
يختار الفريق العناصر ذات الأولوية القصوى من قائمة المنتج وينشئ قائمة السبرنت
ينفذ الفريق عناصر قائمة السبرنت مع اجتماعات سكروم يومية كل 24 ساعة
عرض الوظائف الجديدة لأصحاب المصلحة
يتأمل الفريق في العملية ويحدد التحسينات
اجتماع وقوف يومي مدته 15 دقيقة حيث يجيب أعضاء الفريق على ثلاث أسئلة أساسية:
يساعد هذا الاجتماع في الحفاظ على محاذاة الفريق، تحديد المعوقات بسرعة، وتعزيز المساءلة.
يجب أن ينتج كل سبرنت زيادة منتج قابلة للشحن. هذا يعني أن البرمجيات المطورة يجب أن تكون مكتملة، مختبرة، وجاهزة للنشر دون الحاجة إلى عمل إضافي. بينما هذا المثالي ليس دائمًا قابل للتحقيق في الممارسة، يبقى المعيار المستهدف.
المسؤولية: مالك المنتج
المسؤولية: سكروم ماستر
بينما تصور مطورو سكروم سكروم ماستر كمدرب بدلاً من مدير مشروع تقليدي، في الممارسة العملية، تحتاج العديد من المنظمات إلى شخص ما للتعامل مع مسؤوليات إدارة المشروع. غالبًا ما يتولى سكروم ماستر هذه المهام حيث لديه أفضل معرفة بتقدم العمل وديناميكيات الفريق.
الفريق ذاتي التنظيم هو فريق تطوير ينظم العمل المطلوب إنجازه من خلال المناقشة والاتفاق بين أعضاء الفريق بدلاً من توجيهه بواسطة مدير. تتخذ الفرق قراراتها الخاصة حول كيفية تحقيق أهداف السبرنت، توزيع العمل، والمناهج التقنية.
تحديد الوقت هو ممارسة تعيين فترات زمنية ثابتة للأنشطة. في سكروم، عادةً ما تكون سباقات التطوير طويلة من 2-4 أسابيع ولا يتم تمديدها أبدًا. هذا يخلق إلحاحًا، ويجبر على تحديد الأولويات، ويضمن التسليم المنتظم للبرمجيات العاملة.
يتم دمج الكود في قاعدة الكود الرئيسية عدة مرات في اليوم. يتم تشغيل البناءات والاختبارات الآلية مع كل تكامل لاكتشاف المشكلات مبكرًا.
أولوية عاليةتعمل الاختبارات الآلية باستمرار طوال التطوير. لا يتم قبول الكود الجديد ما لم تجتاز جميع الاختبارات، مما يحافظ على معايير الجودة.
بوابة الجودةالبرمجيات دائمًا في حالة قابلة للنشر. يمكن للفرق الإطلاق إلى الإنتاج في أي وقت بثقة.
ممارسة متقدمةتقدر الفرق العمل باستخدام الحجم النسبي (نقاط القصة) بدلاً من الساعات. تقيس السرعة عدد نقاط القصة التي يكملها الفريق لكل سبرنت، مما يساعد في التنبؤ بالسعة المستقبلية وتحسين دقة التخطيط مع مرور الوقت.
| نقاط القصة | مستوى التعقيد | المدة النموذجية |
|---|---|---|
| 1-2 | بسيط، مفهوم جيدًا | بضع ساعات إلى يوم واحد |
| 3-5 | تعقيد متوسط | 1-3 أيام |
| 8-13 | معقد، بعض المجهولات | 3-5 أيام |
| 21+ | معقد جدًا، يحتاج إلى تقسيم | كبير جدًا - يجب تقسيمه |
توجد منهجيات تطوير البرمجيات على سلسلة متصلة من التنبؤية العالية (الشلال التقليدي) إلى التكيفية العالية (الرشيقة). يساعد فهم مكان سقوط المناهج المختلفة في هذا الطيف الفرق على اختيار المنهجية الصحيحة لسياقها.
| الجانب | التنبؤية (الشلال) | التكرارية | التزايدية | الرشيقة |
|---|---|---|---|---|
| التخطيط | مسبق موسع | مسبق معتدل | موجة متداولة | في الوقت المناسب |
| المتطلبات | كلها محددة مسبقًا | متحسنة في كل تكرار | شرائح ذات أولوية | متطورة باستمرار |
| تردد التسليم | إصدار واحد في النهاية | معالم دورية | زيادات منتظمة | تسليم مستمر |
| نهج التغيير | مسيطر عليه، موثق | مدار لكل تكرار | زيادات مخططة | محتضن باستمرار |
| هيكل الفريق | أدوار هرمية | أدوار محددة | أدوار مختلطة | ذاتية التنظيم |
| مشاركة العميل | البداية والنهاية | مراجعات دورية | مراجعات الزيادات | تعاون مستمر |
| التوثيق | شامل | معتدل | أخف | الحد الأدنى، كافٍ فقط |
| الأفضل لـ | المتطلبات المستقرة، البيئات المنظمة | التحسين مطلوب لكن النطاق معروف | التسليم الجزئي ذو قيمة | متطلبات غير مؤكدة، تغيير سريع |
منخفضة →→→ عالية
تعمل الأساليب التنبؤية بشكل أفضل مع التغيير المنخفض، بينما تزدهر الأساليب الرشيقة مع معدلات التغيير العالية.
منخفض →→→ عالي
تسلم الأساليب الرشيقة القيمة بشكل متكرر، بينما تسلم الأساليب التنبؤية مرة واحدة عند اكتمال المشروع.
تستند الأساليب الرشيقة حول التطوير التكراري وتقليل النفقات العامة أثناء عملية التطوير. تعطي الأولوية للبرمجيات العاملة، تعاون العميل، والاستجابة للتغيير بدلاً من اتباع الخطط الصارمة.
البرمجة المتطرفة (XP) هي طريقة رشيقة مؤثرة قدمت ممارسات ثورية تعتبر الآن سائدة:
أصبحت هذه الممارسات معيارية في تطوير البرمجيات الحديث بغض النظر عما إذا كانت الفرق تتبع XP صراحةً.
سكروم هو منهج رشيق يركز على التخطيط والإدارة الرشيقة بدلاً من وصف ممارسات هندسية محددة:
يمكن استخدامها في أي عملية رشيقة لإدارة عناصر العمل وترتيبها حسب الأولوية، بغض النظر عما إذا تم اعتماد سكروم بالكامل.
سباقات التطوير ذات المدة الثابتة تخلق قابلية للتنبؤ وتجبر على التسليم المنتظم، قابلة للتطبيق على أي نهج تكراري.
تمكين الفرق من اتخاذ القرارات يحسّن المشاركة والنتائج في أي سياق تطوير.
تسليم البرمجيات العاملة بشكل متكرر يوفر قيمة مبكرة ويمكن من التغذية الراجعة المستمرة.
يتطلب النجاح مع الأساليب الرشيقة التزامًا من المؤسسة بأكملها، وليس فقط فريق التطوير. يتطلب تغييرات ثقافية، دعم الإدارة، واستعدادًا للتعلم المستمر والتكيف. ابدأ صغيرًا، تعلم من الخبرة، وقم بتوسيع الممارسات الرشيقة تدريجيًا مع زيادة راحة المؤسسة مع النهج.