بالعربي ال Planning في ال DevOps ببساطة

في هذا المقال سوف استكمل سلسلة ال مقدمة عن الDevOps وسوف اتكلم عن ال Planning وعن طريقة تقييم متطلبات العملاء وتوقع الوقت الذي قد يستغرقه تنفيذ المشروع وذلك بصورة مبسطة

وهذا المقال مرتبط بالمقال السابق مقدمة عن ال DevOps

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

ولل Agile اكثر من طريقة اشهرهم تسمى Scrum فهيا بنا نمشي في جوانبها 😀

Scrum

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

جميل انت الان تعاقدت على مشروع جديد , مبروك 💪💪

 ولكن انتظر هل اخبرت العميل المدة الزمنية التي سيتسلم فيها العميل المشروع 🕓 ؟

في ال Agile المفترض ان طريقة تقييم المجهود والمدة الزمنية للمشروع لا يقوم بها شخص واحد ذو خبرة كما هو المعتاد ولكن يقوم بها الفريق ككل وهذا عمليا ادق و افضل ولكن كيف , خذ نفس عميق وهيا نفقهم ما هو الSprint اولا

ال Sprint

عادة في ال Scrum يتم تقسيم المشروع الى مراحل كل مرحلة تسمى Sprint وكل Sprint يفضل ان يكون وقته من اسبوعان الى اربعة اسابيع وقد تقوم بتقسيم اعلى يسمى Release

مثلا انت من الممكن ان تقول لعميلك هذا المشروع ساسلمه لك على ثلاث Releases (وانت تعلم ان كل Release تحتوي على اثنان Sprint وانت تعلم ايضا ان كل Sprint اسبوعان مثلا) اذا المشروع سيأخذ 12 اسبوع

ولكن كيف يستطيع فريقك تحديد عدد ال Releases او عدد ال Sprints التي ستأخذها متطلبات برنامج الصيدلية التي تعاقدت عليه ؟

في الحقيقة لتحقيق ذلك لابد من تحويل كل متطلب من متطلبات عميلك الى رقم ولكن كيف ذلك 🤔.؟

تخيل معي ان متطلبات بناء نظام الصيدلية هي كالتالي

1. الصيدلي يريد تعريف اسماء الادوية على النظام
2. الصيدلي يريد تعريف اسماء العملاء على النظام
3. الصيدلي يريد بيع الادوية

الطريقة التي سنتحدث عنها الان تسمى Fibonacci وهي من اشهر الطرق المستخدمة في ال Scrum وتعتمد هذه الطريقة على اعطاء كل متطلب رقم اما 1 او 2 او 3 او 5 او 8 او 13 وهكذا (لاحظ انه لا يوجد رقم 4 مثلا او 6 او ...)

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

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

وعند تقيييم الطلب الثاني وجد فريقك انه مساوي للطلب الاول وبالتالي اعطى له 1 وهكذا

الان انت لديك وزن نسبي لكل طلب فالنفترض مثلا ان مجموع طلبات الصيدلية بالكامل كانت 120 نقطة.

بقي لك ان تعرف عدد النقاط التي تستطيع تنفيذها داخل ال Sprint الواحد وفي الحقيقة اذا كنت في بداية عملك بال Scrum لن تكون على يقين من الرقم ولكن اذا كنت بدأت العمل قبل ذلك ففي نهاية الSprint ستعرف عدد النقاط التي استطاع فريقك تنفيذها وبعد اكثر من Sprint ستستطيع تحديد الرقم المناسب الذي يستطيع فريقك تنفيذه 

نفترض مثلا ان فريقك يستطيع تنفيذ 10 نقاط في ال Sprint الواحد اذا بمعادلة بسيطة 120 نقطة اجمالي الطلبات نقوم بقسمتها على عدد النقاط التي يستطيع فريقك تنفيذها 10 يكون الناتج 12 Sprint

ولكن لحظة ما قام به فريقك الان هو عمل ما يسمى بال Release Planning اي انه خطط حجم المجهود الذي ستأخذه Relase او اكثر ولكن لم يتم التخطيط لمهام ال Development و ال Testing و ال System Design ..... الخ فاين ومتى يتم ذلك

هذا ما سنراه في المقال القادم 😃😃😃

ملاحظات 

عدد النقاط التي يستطيع الفريق تنفيذها خلال ال Sprint تسمى Team Velocity

طريقة التقييم كل متطلب بمقارنتة بالمتطلب الاصغر تسمى Relative Estimation

اختيار الارقام من هذه المجموعة 1, 2, 3, 5, 8, 13, 21, 34 وعدم اختيارها بالتسلسل الطبيعي تسمى Fibonacci
النقاط التي تاخذها متطلبات العميل تسمى Story Points
كل متطلب من متطلبات العميل يسمى User Story

اذا كنت تريد متابعة المقالات القادمة يمكنك ان تعمل Like لصفحتي على ال Facebook واعلم انك اذا لم تعمل Like فان ال Waterfall هو الذي منعك 😂😂😂

مراجع

https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops