ما هي منهجية أجايل وكيف تصبح راوي قصص محترف في إدارة المشاريع؟

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

ما هي منهجية أجايل (Agile)؟

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

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

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

مفاهيم أساسية يجب أن تعرفها في أجايل

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

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

القصص (Stories)

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

صياغة القصص

عند العمل في مشروع، ستصادف على الأرجح مجموعة متنوعة من الطرق التي يعبر بها الأشخاص عن القصص. ولكن المبدأ التوجيهي الجيد هو العمل من خلال مفهوم كلمة “قصة” نفسها وشرح العمل الذي يجب إنجازه بهذه الطريقة. على سبيل المثال، إذا كنت ترغب في توفير القدرة لمستخدمي موقعك على مشاركة منشور مدونة على Twitter، فقد ترغب في كتابة القصة على النحو التالي:

As a reader, I want to share the post I just read to Twitter.

يساعد استخدام نمط "as a [person], I want to [action]" في توفير السياق حول الحالة التي قد يكون عليها شخص ما عند زيارة الموقع وما يحاول تحقيقه. يمكن أن يكون هذا مفيدًا بشكل خاص إذا كنت تقوم بتطوير ميزات للمستخدمين المسجلين تختلف عن الضيوف.

التفاصيل والمتطلبات

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

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

طريقة جيدة لصياغة هذه المتطلبات هي: verify [requirement]. بالعودة إلى مثالي حول مشاركة منشور على Twitter، قد تكون بعض متطلبات تلك القصة هي:

• التحقق من أنه عند النقر على زر المشاركة يتم إنشاء تغريدة جديدة.
• التحقق من أن التغريدة تتضمن رابطًا لمنشور المدونة الحالي.

كمية العمل أو مستوى الصعوبة

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

إحدى الطرق التي تمثل بها الفرق ذلك هي باستخدام متتالية فيبوناتشي، حيث يمكن أن يكون عدد النقاط 1، 2، 3، 5، 8، إلخ. حيث قد يكون تحديث نصي بسيط نقطة واحدة، بينما إضافة نموذج جديد إلى صفحة يمكن أن يكون 3 نقاط.

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

الملاحم (Epics)

بينما تهدف القصص إلى تحديد قطعة عمل صغيرة الحجم، فإن الملاحم هي طريقة لتجميع قطع العمل هذه معًا لتمثيل ميزة كاملة.

تعريف القصص كميزة

طريقة جيدة لشرح ذلك هي بمثال آخر. إذا كنت تعمل على تطبيق يتطلب دمج المصادقة (Authentication)، فقد ترغب في إنشاء ملحمة جديدة تسمى ببساطة “Authentication“. داخل تلك الملحمة، يمكنك العثور على قصص مثل:

• As a guest, I want to sign into the application with my email address
• As an authenticated user, I want to change my password
• As the security team, I want to prevent spam and abuse of user authentication

مع تحديد ملحمتك، فإنك تمنح فريقك مسارًا لإعلان اكتمال ميزة معينة مع فهم النطاق الكامل لذلك العمل. هذا مهم عندما يتعلق الأمر بتخطيط العمل الذي يتعين القيام به. يمنحك تحديد قصصك في ملحمتك إحساسًا بمقدار العمل الذي يستغرقه شيء ما، ولكنه لا يساعدك في تحديد المدة التي سيستغرقها، وهذا هو المكان الذي تأتي فيه “السباقات” (Sprints).

السباقات (Sprints)

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

المدة الزمنية لكل سباق

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

النقاط لكل سباق

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

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

كيف تتناسب منهجية أجايل مع فريقك؟

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

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

ما هي عملية فريقك؟ شاركني على Twitter!

الخلاصة التقنية

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