درس الكثير منا وقرأ واطلع على تطوير أنظمة المعلومات وكيف تسير العمليات في إطار دائرة تطوير البرمجيات المشهورة , وعند تكوينه للفريق الأول الذي يتألف من عدد بسيط من المطورين , ومحاولته تطبيق القواعد تكون الأمور معقدة , ولا تؤدي بالنهاية إلى منتجات عالية الجودة وترضي العميل
ولحل المشكلة في الآونة الأخيرة ظهرت الكثير من أطر البرمجة السريعة (Agile Development) والتي توائم سوق العمل خصوصا للشركات التي تملك فرق تطوير متوسطة الحجم أو صغيرة , وتطورت هذه الأطر بشكل متفاوت , ولكنها تشترك في كثير من الميزات ومن أهم ما يميزها
- التطوير السريع والتوفير في الوقت والجهد
- إرضاء العملاء المختلفين من خلال إدخالهم بشكل مباشر في عملية التطوير
- يمكن البدء المباشر في عملية التطوير دون فهم المتطلبات بشكل كامل
- جودة البرمجيات المنتجه لما فيها من عمليات فحص متكرره وإستعمال الأدوات الاوتوماتيكية
عن ال Scrum
نشأ هذا الإطار كإطار عمل سريع وقد جاءت تسميته كإختصار لكلمة ال scrummage والتي تستعمل في لعبة ال rugby عند إعادة اللعبة ليقوم الفريق بدفع الفريق المعارض .. وجاءت هذه التسميه لان كل الفريق التطويري له دور كبير جدا للتغلب على مشاكل المشروع (الفريق المعارض)
إذا ماهو ال Scrum
السكروم هو إطار برمجي سريع ينتمي لفئة ال Agile Methodologies يتم فيه تقسيم المنتج إلى الخصائص المراد تطويرها وتسمى ال(Backlogs) ويتم تجزئة كل خاصية (Backlog) إلى مجموعة من الركضات (sprints) بحيث يتم تطوير كل ركضة على حده ولا تتجاوز مدة الركضة أكثر من شهر فهيه تتراوح مابين الأسبوع إلى الشهر
يتم فيها عمل إجتماع دوري بشكل يومي(كل 24 ساعة) لمعرفة حالة المهام المنفذة وآلية سيرها في الركضة , وبالتالي فالهدف الرئيسي لمجموعة الركضات ال(Sprints) هو تحقيق الخاصية (Backlog) أما عن هدف مجموعة الخصائص (Backlogs) فهو تحقيق المنتج النهائي والشكل المشهور لآلية عمل السكروم أدناه
فريق Scrum
ينقسم فريق سكروم إلى
- مالك المنتج (Product Owner)
وهو يقوم بتحديد خصائص المنتج المطلوبه و كذلك أولوية كل خاصية في المنتج بالتعاون مع قائد الفريق , لذلك قد يكون مالك المنتج هو الزبون أو من ينوب عنه. - قائد فرقة سكروم (Scrum Master)
يلعب قائد الفرقة دور كبير في اجتماعاته مع مدير المنتج لتحديد أولويات الخصائص وكذلك مع الفريق في تحديد الركضات لكل خاصية وأولويات المهام كما و يقوم بتقسيم وتوزيع المهام لفريق التطوير , ويتابع عمل المجموعة وحالة سير المهام, فضلا عن مساعدة الفريق وإبقاء التركيز على المهام. - فريق التطوير (Development team)
وتكون مسؤوليته إنهاء تطوير كل ركضة على حسب الأولوية , كما ويتعاون مع قائد الفرقة على تحديد أولويات المهام والتخطيط للركضات , وتوصيل حالة المهام التي يعمل عليها.
أهم إجتماعات سكروم
إجتماع التخطيط للركضة يقوم فريق سكروم بالتخطيط للركضة من خلال جميع الأعضاء ويتم النقاش بما ستحويه من مهام ويكون لكل واحد المهام التي يراها ملائمه لشخصه دون الحاجة للتكليف بشكل مباشر مما يجعل الفريق أكثر حماسا ومسؤولية.
- اجتماعات سكروم اليومية
وهي عبارة عن إجتماع دوري يقوم به قائد فرقة السكروم لمعرفة حالة الركضة حيث يتم سؤال كل عضو من الفريق
– ما قمت بعمله بالأمس
– ماذا ستقوم بعمله اليوم
– هل هناك معوقات أثرت على العمل
- إجتماع إستعراض الركضة
ويتم فيها عرض ما تم لكل ركضة لل Product Owner حتى ولم يكن هناك شيء فعلي فيتم عرض ما تم إنجازه فعليا.
- إجتماع مراجعة الركضة
اجتماع لمعرفة النواحي الإيجابية والسلبية في كل ركضة وكيف يمكن الإستفادة من ذلك لتطوير كل ركضة.
متابعة سير منتج السكروم
يعد متابعة سير المنتج أمر هام جدا في تحديد المدة والمواعيد النهائية ويمكن من خلالها تقدير معدل ولحسابها
يتم تحديد درجة التعقيد او الإنجاز في كل ركضة من خلال رقم معين يسمى Velocity Points
على سبيل المثال احتاجت خاصية إلى 5 ركضات وتم تحديد سرعة كل ركضة كالتالي
V1=10 pt ,V2=5pt , V3 =15pt , V4=10pt , V5= 4pt
فبإستناء الركضة الأولى والاخيرة نظرا لأنهم يكونوا بسرعة مختلفة قليلا عن بقية الركضات لغرض البدء او الإنتهاء
فإن معدل سرعة الركضات = 5+15+5\3=8 pt
ولو حسبنا مجموع سرعة الركضات = 44 pt
إذا فالخاصية (BackLog) تكلف ما يقارب 44 pt
ولو قسمناها على معدل السرعة فنحن بحاجة لمدة ما يقارب ال 6 ركضات لتحقيق الخاصية مع إضافة ركضتين للأمور المتعلقه بالخطر والفحص فإن الوقت الفعلي يقارب ال 8 ركضات
معدل الإحتراق (BurnDown) وهو رسم تخطيطي يوضح الوقت الفعلي التي يتم فيه إنجاز كل ركضة والوقت المقدر بناء على المعلومات السابقة وقد قمت برسم رسمة توضيحية على المثال السابق توضح هذا الرسم والذي يسهل على معرفة حالة المشروع وهل سيكون هناك تاخير في تسليم الركضات أم لا
أهم ما يميز ال Scrum
الجميع في السكروم مسؤول عن إنجاح المنتج وما يميز هذا الإطار هو الشفافية الحقيقية في أن الفريق مطلع على المهام والمنتج كما أن التواصلية العالية لأعضاء الفريق وكذلك الزبون يساعد كثيرا في تحقيق المطلوب بأسرع وقت , ومن المثير حقا أن هذا الإطار يحفز الفريق على إعتبار نفسه مسؤولا وتحديد الكثير من المهام بنفسه.
وهذا الإطار هو من أكثر الإطارات التي توافق بناء أنظمة ال SAAS
عوامل جودة مهمة في ال Scrum
- إستعمال طريقة التطوير TDD وهيه بعمل حالة إختبار قبل البدء بالتطوير
- التطوير بمراجعة الفريق لما قام به peer review
- عمل أنواع الفحص المختلفه على مستويات system test , integration test , unit test
- التواصل الدائم مع الفريق والزبون
فعلا كما قالت اختي سمير علي .. التقرير جميل ومفيد ولكن يحتاج تعزيز للغة العربية اكثر بحيث يسهل على القارئ استيعاب اكبر كم من المعلومات في هذا المقال واستخلاص الفائده منه فضلاً عن البحث في مقالات اخرى .. شكراً لكم
شكرا لكم على هذا المقال الرائع
واظن انكم من اوائل من كتبت عنه في المدونات
واتفق مع الاخت سمر