2018/09/24

بالعربي ادوات ال Agile لتحقيق ال Planning في ال DevOps


في هذا المقال سوف نستكمل حديثنا في سلسة مقدمة على ال DevOps التي قد بدأنها بمقدمة عامة لتوضيح الصورة الكلية لموضوع ال DevOps ثم تبعها مقال خاص بالفرق بين التخطيط لصناعة البرمجيات بين اسلوب ال Agile والاسلوب القديم وكيفية عمل عملية ال Estimation بالاعتماد على ال Story Points.
في هذا المقال سوف نوضح بعض المفاهيم والادوات المستخدمة في عملية التخطيط والمتابعة لدورة حياة صناعة البرمجيات الخاصة بال Agile او بصورة ادق ال Agile Scrum حيث انها الطريقة الاكثر شيوعا.





الفريق


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

وفي اغلب فرق تطوير البرمجيات نجد انها تحتوي على اعضاء مثل المبرمجين Developers و ال Testers و ال Business Analyst و ال System مع تدرجهم الوظيفي سواء Senior , Junio Or Team Leader ... الخ . ولكن في ال Scrum ظهر عضوان جديدان وهم كالتالي

Product Owner

هو العضو في الفريق حلقة الوصل بين العميل و فريق التطوير فهو الشخص الذي يتواصل مع العميل ويفهم احتياجاته ثم يقوم بكتابة متطلبات العميل ومناقشتها مع باقي اعضاء الفريق وعند الانتهاء من الطلبات وتنفيذها او تنفيذ جزء منها هو الذي يتواصل مع العميل ويقوم باخذ رأيه في ما تم تنفيذه وهكذا , وفي الحقيقة هذا ما كان يقوم به ال Business Analyst ولكن مع اختلاف المسميات

Scrum Master

هو العضو في الفريق الذي يحافظ على اداء الفريق ويذلل كل المعوقات طوال فترة ال Sprint فمثلا هو الشخص الذي يتأكد من اتمام انشطة ال Scrum المختلفة ومتابعتها او انه الشخص المسئول عن ايجاد حلول والتواصل مع الاخرين لحل مشكلة في حاسوب المطور مثلا او انه هو الشخص الذي يحمي الفريق من اي ضغوط خارجية فمثلا قد يحمي الفريق من ضغوط يقوم بها Product Owner قليل الخبرة مثلا.


دورة العمل داخل ال Scrum

تخيل معي ان لديك مجموعة طلبات من عميل لمشروع جديد مكتوبة في ملف Excel مثلا اول شيء سيتم عمله هو كتابة هذه المتطلبات علي شكل User Story بمعنى تقسيم هذه الطلبات بشكل مبسط لاقصى درجة ثم كتابتها على شكل انا كمستخدم اريد كذا و كذا او ممكن كتابتها باي طريقة يتفق عليها الفريق تكون واضحة للجميع

الان انت لديك مجمعة من ال User Story لم تدخل للعمل وهذه المجموعة تسمى ال Backlog او السجل الذي يحتوي كل ال User Stories ولابد من ان تقوم بترتيبه حسب الاوليات.

Release Planning

الخطوة الاولى هي التخطيط لل Releases التي سوف تصدرها من النظام الذي تقوم بتطويره وفي خلال هذه المرحلة يجتمع كامل الفريق مع ال Product Owner للنقاش في ال User Stories المختلفة داخل ال Backlog وبناء على هذه النقاشات يتم الغاء بعض ال User Stories او تعديلها او اعادة ترتيب اولوياتها او او او
ثم بعد ذلك يقوم الفريق بعمل Story Point Estimation الذي تكلمنا عنه باستفاضة في مقال سابق وينتج عنه ان اجمالي عدد نقاط ال Backlog وعن طريق عدد النقاط تستطيع تحديد عدد ال Sprints التي سيستغرقها المشروع
فمثلا اذا كان اجمالي عدد النقاط 100 نقطة والفريق يقوم بعمل 25 نقطة كل Sprint اذا هذا ال Backlog سيستغرق 4 Sprints ومثلا كان الفريق يقوم باصدار Release كل 2 Sprint اذا هذا المشروع سيتم اصدارة على 2 Release وبهذه الطريقة تستطيع معرفة متى ستنتهي كل User Story او بمعنى اخر الSprint الذي ستنتهي فيه ال User Story

Sprint Planning

قبل بداية ال Sprint تقوم بالتخطيط له عن طريق تقسيم كل User Story الى Tasks على كل عضو من اعضاء الفريق فمثلا قد تكون هناك Task لعمل الواجهة UI من قبل ال Frontend و Task اخر لبرمجة ال Backend وتاسك اخر لعمل Unit Test و Task اخر لعمل Test Plan او Test Execution من ال Testers وهكذا.
وعملية التوزيع هذه تقوم فيها بتحديد عدد ساعات متوقع لكل Task ويقوم بها العضو صاحب ال Task نفسه (ولا يقوم بها مديره مثلا نيابة عنه) وذلك لضمان التزامه بمال قال وايضا لشعورة بمدى اهمية رأيه.

الان كل عضو في الفريق يعلم ماذا عليه ان يفعل تحديدا فقد شاركوا جميعا في مناقشة ال Business الخاص بكل User Story خلال ال Release Planning وايضا يعلم كل عضو الوقت المتوقع لتنفيذ كل مهمة وكل الفريق يعمل حسب الاولوية التي حددها ال Product Owner مع العميل وكذلك العميل يعلم متى سيتسلم كل طلب من طلباته المختلفة (الكل سعيد و فرحان :) ).

هل تتذكر الان الطريقة القديمة وكيف كا يحدث فيها من ضغوط وتخطيط باسلوب قديم لا يشارك فيه الا بعض من الفريق وقد يفشل المشروع بالنهاية؟ هل احسست بالفرق النفسي للفريق و للعميل و بمستوى الاداء الذي يتحسن من تعديل اسلوب التخطيط فقط حتى الان.

Standup Meeting

خلال فترة عمل ال Sprint يقوم الفريق بعمل اجتماع يومي غالبا في بداية اليوم لمدة حوالي ربع ساعة (اجتماع سريع) . والهدف منه هو متابعة العمل بشكل سريع ففي هذا الاجتماع يتم الاجابة على الاسئلة التالية؟
ماذا فعلت بالامس؟
ماذا ستفعل اليوم؟
هل يوجد معوقات تعوق عملك؟


Retrospective Meeting

في نهاية كل Sprint يعقد هذا الاجتماع لمناقشة ما تم خلال ال Sprint ككل وقد يقوم الفريق بتقييم ادائه او مناقشة التعديلات التي قد يقومون بها لتحسين العمل في ال Sprint القادم وهكذا.

Sprint Review Meeting

في هذا الاجتماع يجتمع الفريق مع ال Product Owner لتسليمه الذي تم بالSprint وقد يتم مناقشة اي اعدادات خاصة بالطلبات التي نفذت او توضيح اسلوب عملها على النظام وما الى ذلك.

Customer Feedback

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



الان انت خططت للمشروع وقمت بمتابعة الSprints من خلال اجتماع يومي واجتماع اخر كل Sprint وايضا سلمت الطلبات للProduct Owner واخذت رأي العميل بعد كل Sprint . هل تشعر بالتحسن الذي حدث؟



الان بقي لك شيء واحد وهو ان تعمل Like لصفحتنا على Facebook وان تكتب تعليق اذا اعجبك المقال او اذا تريد المناقشة واعلم انك اذا لم تعمل Like فان ال Scrum Master هو الذي منعك 😁😁😁




مراجع

https://www.mountaingoatsoftware.com
http://agilemanifesto.org/iso/ar/principles.html

تمت بحمد الله

هناك تعليق واحد:

Unknown يقول...

شكرا جزيلا علي المقالات الرائعة دي.. انا عجبتني فكرة الagile وكنت مهتمة اعرف ازاي أطبق نفس الفكر مع المشروعات الكبيرة يعني لو شركة بيدخلها اكتر من ٥٠ أو ٦٠ نقطة يوميا من عملاء مختلفين ازاي اخلي العمل منظم بنفس الفكر ؟؟

مقدمة عن الDevOps

في هذا المقال سوف اتحدث عن مقدمة بسيطة عن ال DevOps ولماذا لابد ان تهتم فرق تطوير البرمجيات به وما هي النتائج المترتبة عن استخدام اساليبه ...