Home هندسة برمجيات Agile الAgile في سطور
الAgile في سطور

الAgile في سطور

4.14K
7

حيث لا مكان للاختباء – تلخيص بتصرف من الكتاب The Agile Samurai

agile-edge-case-ninja
لتنسى أنك مطور (لدقائق معدودة) وتخيل أنك صاحب مشروع كبير ولديك المال المناسب لهذا المشروع وقد وظفت عدة مبرمجين ليقوموا بالتطوير في هذا المشروع، السؤال المهم الأن: ما هو الشيء الذي يجعلك تثق في أن الفريق يعمل ويسير في الإتجاه الصحيح؟
مجموعه من الملفات الورقية والتقارير ؟ أم عرض Power Point به صور متحركة (هذا يحدث كثيراً للأسف، هناك مبرمج بعد ثلاثه أشهر من العمل جاء بعرض Power Point! ) أم الأفضل أن تشاهد نسخه مصغرة من البرنامج تعمل أمامك، وخلال كل اسبوع أو اثنان ترى Feature جديدة في البرنامج ؟
لننسى التخيل ولنعد للواقع، وشاهد كيف اتضح لك أن الشيء الملموس ولو كان مصغراً أفضل كثيراً من التقارير والأوراق والوعود الزائفه، بهذا المنظور سوف تعمل جيداً والأشياء الجيدة سوف تحدث.
كيف تقوم بذلك، وذلك باتباع طريقة تطوير تسمى Agile، ال Agile هي ممارسات معينة في تطوير البرمجيات تكون غالباً بشكل متكرر وعلى وتيرة واحدة الى حين تطوير المشروع بالكامل Iterative Development، وكما هي طبيعة البرمجيات فلا توجد اي منهجية أو سيلة تضمن نجاح المشروع هكذا بدون أي عوامل أخرى ، وحنى لو استخدمت الAgile فقد تفشل في مشروعك اذا قمت به بشكل خاطئ،لكن باتباع الAgile بالشكل الصحيح فسوف تزيد نسبة النجاح بشكل أعلى من غيرها لأن الأمور سوف تتضح جداً منذ بدايات المشروع. 
قد تكون صادفت هذه الكلمة كثيراً في مسيرتك البرمجية، وسنتعرف في هذه السلسله من الدروس عن طريقة التطوير هذه وكيف يمكن أن تطور مشروعك بها، وحينها قد تستطيع تسليم المشروع في الوقت والميزانيه المطروحة بسهوله on time, on budget .  وبشكل عام ستغطي اهم ثلاثه مراحل في التطوير والتي عاده ما تكون فشل المشروع هو القيام بهذه المراحل بشكل خاطئ:

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

2) كيف تجمع المتطلبات Requirements وتقوم بحساب الوقت المناسب لها Estimation وتقوم بوضع الخطة plan التي ستعتمد عليها في التطوير ، هذه المرحلة من اهم المراحل فكل المشاريع تحتاج خطة واضحه المعالم، بالاضافة الى أن كثير من المبرمجين يواجهوا صعوبات في تقدير الوقت المطلوب في انجاز العمل، في هذه المرحلة ستم توضيح كيف يمكن التقدير بصورة صحيحة واعداد الخطة الصادقة والواضحة الأهداف والمعالم.

3) كيف تبدأ مرحلة التنفيذ Execution ، وهنا كيف ستقوم بتحويل الخطة الى منتج حقيقي ذو جودة في الكود Quality Code، وهنا ستمر على كافه مراحل التطوير (التحليل ، التصميم، البرمجة، الاختبار) ولكن لن تكون بشكل تقليدي لأن تطبيقها سوف يكون على حسب خطتك بالاضافة الى الاعتماد على الاساليب الصحيحة في بناء البرمجيات (مثلاً القيام بعمليات تحسين الكود بشكل متكرر Refactoring، استخدام الأدوات الصحيحة Unit Testing والخ).

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

0) التسليم المتكرر كل فترة Deliver Something of Value Every Week، لا يوجد افضل من تسليم ميزة Feature تعمل جيداً من التطبيق كل فترة (اسبوع او اثنان)، هكذا يطمئن العميل ان مشروعه يسير في المسار الصحيح وان ماله لن يذهب سدى، لذلك  تعتبر هذه من قواعد ال Agile المهمة .

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

2) فقط اهتم بالأشياء المهمة وانسى البقية: فالCustomer أو المدير لن يهتم بالتوثيقات Documentation والأوراق اذا لم يكن هناك شيئاً يعمل، فالأوراق والخطط والتوثيقات هي لدعم البرنامج (اقصد الذي يعمل Working Software) هي مهمه ولكن اذا لم يكن لديك برنامج يعمل فما فائدتها؟. عندما تركز على هذا النقطة (ميزة Feature تعمل كل أسبوع) سوف تكون أفضل في أداء هذه الميزة Feature حيث التركيز لها وتنسى البقية الأن، فأنت تبنى بالتدريج.

3) الاختبار ثم الاختبار الدائم: بما أنك تطور بالتدريج ميزة تلو الأخرى فالاختبار سوف يكون تدريجي ايضاً منذ أول اسبوع، مثله مثل التطوير.

4) استمع جيداً وخذ الأراء Feedback: كل اسبوع أو انثان عليك بمعرفة الاراء من العميل، هكذا تعلم أنك في المسار الصحيح، وتتحرك بقلب مطمئن الى الأمام (من مشاكل الطرق التقليدية في التطوير وبالأخص Waterfall هي انك بعد عناء التطوير والمدة الكبيرة مثلاً 8 أشهر ومن ثم تأتي لمرحلة التسليم وتبدأ عملية مرحلة التذمر من العميل وأنه لا يريد هذا ولا يريد هذا وان هذا يريده بشكل اخر، الAgile سوف يقلص هذا لأقل درجة ممكنة حيث العميل -الذي يريد البرنامج- يعرف شكل البرنامج ويعرف الخصائص حيث كان يشاهده طيلة فترة التطوير وكل التغييرات سوف تحدث اثناء التطوير).

5) لذلك اقبل التغيير متى ما كان: المتطلبات تتغير دائماً (هذه احدى القواعد في تطوير البرمجيات، يجب عليك ان تدركها جيداً)، , وأيضاً طبيعة العمل تتغير فقد يغادر ذو الخبرة من الفريق Senior Programmer أو أن يذهب في اجازه والخ، اذا كنت تتبع الخطط بشكل أعمى فسوف تصل في نهايه المشروع الى شيء لا يريده أحد (ولن تستطيع تحمل الركلات واللكمات) ، فعندما يتعارض الواقع مع الخطة، فغير الخطة وليس الواقع when reality messes with your plan, you change your plan not reality.

6) كن مسوؤلاً become accountable: التسليم الأسبوعي يعطيك الأحساس بالمسؤولية أكثر فأنت ترى العميل كل اسبوع وتريه التقدم وفي أين دفعت النقود، لذلك هناك من يرفض طريقة العمل هذه، ربما لأنها تتسم بالوضوح ومشاهدة العمل الحقيقي فلا مكان للاختباء أو الهرب فكل شيء مكشوف في اخر الاسبوع (هل انت عملت أم لم تعمل).. لكن في الحقيقة اذا كنت شخص متحمس وتحب العمل ف Agile توفر لك بيئة ممتعة حقاً .

ولا تنزعج من فكرة كل اسبوع تسليم، فهذا يختلف من فريق لأخر ، هناك من يسلم كل اسبوعين وهناك من يسلم كل ثلاثه اسابيع، الفكرة هنا ان تتعود على تسليم شيء يعمل كل فترة لأخذ الأراء والملاحظات وان تكون مستعد للتغيرات اذا حدثت. (من حسب تجربتي في ال Agile فهي تجدي نفعاً مع المشاريع الموجهه للعميل أو يمكن أن نقول Enterprise Application أو Web Application حيث لا وجود للبحث العملي في فترة التطوير، لكن بالنسبة للعمل البحثي الذي يتطلب الابحاث والتجارب فبعض ممارسات ال Agile سوف يجدي ولكن البعض الاخر لن يفيد كثيراً ).

7)  من أعلى أولويات ال Agile هو ارضاء العميل من خلال التسليم المبكر والمستمر  early and continuous delivery لأشياء تعمل في النظام، لذلك اذا كنت تستطيع اطلاق الصفحة الرئيسية من الموقع بعد اسبوع فافعل ذلك وارى العميل انك تعمل وهذه النتيجة .

8) طريقة التطوير Agile ليست عشوائية بل هناك مرحلة تخطيط لأي مرحلة Plan ، والتخطيط في مشروع Agile لا يختلف عن التخطيط لرحلة طويلة، وبدلاً من استخدام لفظ قائمة المهام To Do List هنا يستخدموا لفظ Master Story List و User Stories (عذراً لن نترجم المصطلحات ولكن سنشرحهم جيداً فيما بعد).

في ال Agile يمكن أن نشبه ال Master story list بال to-do list كما ذكرنا، حيث هي تحتوي على كل الFeatures بشكل مبسط جداً High Level (يطلق على اي Feature بال user story) والتي طلبها العميل في المشروع، ويقوم العميل بترتيبها حسب الأهمية التي يراها Prioritized، وتقوم انت المبرمج وفريقك بتخميين Estimate الوقت المناسب لهذه الuser stories وهكذا تعتبر هذه أول نواه للخطة Plan في مشروعك.

لو لاحظت في الصورة السابقة أن هناك مراحل تسمى Iterations وهي الفترة الزمنية (اسبوع أو اثنين) والتي تقوم فيها بتطوير اي من ال user story التي يريدها العميل (سوف تأخذ الأكثر أهمية بناء على تقييم العميل) وتقوم بتحويل هذا الطلب الى شيء يعمل في المشروع..

اثناء بدء المشروع سوف تعلم انت وفريقك سرعتكم في التطوير (تسمى Team Velocity بمعنى مقدار العمل الذي انجز خلال الIteration الواحد)، وهكذا بتتبع ال Velocity واستخدامه كمؤشر يمكنك ان تتوقع كم ستنجز في الفترة المقبلة والتالي تستطيع اعطاء العميل اكثر خطة واقعية وصادقه honest plan وهكذا تبتعد عن مشاكل القول بلا فعل over-committing. احياناً قد يطلب منك عمل اكثر من ما تستطيع، وفي هذه الحالة عليك بفعل ما تستطيع وهو فعل الأقل، وكلما كنت مرناً في مزايا المشروع Flexible on Scope كلما تكون مماشياً مع الخطة ومع الوعيد التي اعطيتها Commitments.

وكما ذكرنا عندما يختلف الواقع Reality مع الخطة Plan ، فقط عليك بتغيير الخطة (وهذه من أهم ما يميز ال Agile وهو الخطط المتغيرة Adaptive Planning). فأنت تعمل مع العميل منذ أول يوم وهو يعرف كل خطوة تقوم بها والمشاكل الحالية وسوف يقوم بأخذ القرارات المتعلقة بسير المشروع، والتواريخ والميزات الموجودة فيه. هكذا في الAgile لا يوجد شيء يسمى العمل على خطة مهما كان سواء كانت مناسبة أم غير مناسبه ومن ثم انتظار المعجزة كي تحدث ويخرج المشروع,,

9) الصدق في الحديث وان الميزة عندما تنتهي يعني انها انتهت من كل شيءDone Means Done، فأكثر ما يزعج العميل أو المدير ان تقول له انتهيت ثم تأتي بعد فترة وتقول هناك شيء لم ينتهي بعد (لا نريد اي مفاجئات خصوصاً في الوقت الأخير) ، لذلك هذه القاعدة من اساسيات ال Agile فعندما يقال ان الميزة انتهت فهذا يعني انها انتهت فعلياً (التحليل، التصميم، البرمجة، الاختبار، اي اختبارات اخرى),

10) لا تنسى القواعد الأساسية الثلاثه في تطوير البرمجيات Three Simple Truths (لا يمكنك كامل جمع المتطلبات منذ البدء، المتطلبات سوف تتغير دائماً، الوقت دائماً ضيق مقارنه بالمطلبات الأساسية والموراد ايضاً قليلة)

النظرية الأولى (لا يمكنك جمع كامل المتطلبات منذ البدء) تعني انك لن تخف في البدء في المشروع بدون معرفة تفاصيل كل شيء بشكل دقيق، فقط سوف المتطلبات الأساسية والبقية سوف يتم اكتشافها وقت التطوير,,

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

النظرية الثالثه (الوقت والمبلغ لا يكفيان لكل العمل) فهذا يعني انك لن تتوقف من العمل بمجرد ان قائمة المهام كثيرة اكثر من الوقت والمبلغ المدفوع، هذا الأمر يحصل دائماً في كل المشاريع وحينها عليك بترتيب المهام بحسب الأعلى أهمية ومن ثم تقوم بالعمل عليها واترك البقية بعدما تنهي المهم.

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

11) أخيراً الAgile هي ممارسات عامه في التطوير  there is no one ultimate flavor of agile وهناك الكثير من المنهجيات تندرج تحتها مثلاً Scrum أو XP

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

المقالة القادمة ان شاء الله سوف تتحدث عن الفريق Agile Team وكيف يكون هذا الفريق وأدوارهم وبعض الأمور التي يجب ان يعلمها كل افراد الفريق قبل البدء في المشروع,
الى لقاء قريب,,

(4139)

وجدي عصام مهندس برمجيات مهتم بعلوم الحاسب وبالأخص مجال الخوارزميات وهندسة البرمجيات وحماية التطبيقات،

Comment(7)

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

    – ال agil هي طريقة لملازمة المشروع مند البدء الى التسليم ..تعتمد على أسس عامة كما تم ذكره..و تندرج تحتها طرق أخرى تعتمد على نفس المبادىء مع اضافات للوصول الى التطبيق الامثل لل agil ….و منها xp و scrum

    -ال iteration هو عدد معين من user stories..تقوم بانتقاءهم حسب الترابط أولا ..و حسب الأهمية و الاولوية داخل المشروع…و هو محدد بمدة زمنية للتنفيد هي مجموع المدة الزمنية لتنفيد كل user storie
    اذن ممكن ان نقول ان وقت delevering… كل مدة زمنية هو ال iteration

    ———————
    تتبادر الى ذهني بعض الاستفسارات

    -هل يمكن تشبيه user storie ..ب use case in uml؟
    -لماذا تم تسمية وقت تسليم جزء معين يعمل من المشروع ..iteration …لانه لا تتم اعادة برمجة اشياء بعينها …بل تتم برمجة اشياء اخرى ….عندي لبس في الترجمة الحرفية للكلمة

    -ال user stories ..لن يتم عملها بشكل سلس ..اذا لم يكن هناك مرحلة أولية هي كيف يتم تقسيم المشروع او طريقة جعله modular…عن طريق احدى اطر العمل مثلا..أو طريقة عمل موحدة …حيث اذا تغيرت هذه الطريقة …تغير كل شيء حتى user stories…لذلك اظنها اهم مرحلة و هي الاساس الذي تبني عليها مشاريعك…لكن اذا هناك لغط فيها او محاولة تطوير فيها ستؤثر على مشروع العميل …أظن ان الشركة عندما تطور طريقة عمل موحدة عندها …حيث تصبح هي مشروعها الاول الذي يجب الانتهاء منه ..آنذاك ممكن ان تبني مشاريع عليها

    شكرا و جزاك الله خيرا على هذا المقال ..في انتظار مقال Agile Team

  2. حياك الله، وفهمك صحيح بالنسبة للنقاط الاولى، اما بالنسبة للاستفسارات فسوف نجيب عليها :

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

    والعكس كتابه ال user story سهل لأنها وصف لما يريده العميل بلغته، بينما ال use case تكون اكثر شموليه وتحتاج دراسه اكثر ومعرفة ال pre-condition وال post-condition وغيرها ،

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

  3. أستاذ وجدي هناك قاعدة في هندسة البرمجيات تقول أنك لن تتعلم صناعة البرامج القوية والمحترفة بقرأة الكتب والمدونات الخاصة بهذا المجال بل بالممارسة الفعلية فمهما قرأة من كتب فهذا سوف يبقى نظري لذالك أنصح أي شخص لديه بعض الأساسيات في أي لغة برمجة بالمحاولة لصنع البرامج حتى وأن كانت ضعيفة فبالمواصلة والأجتهاد سيتمكن من صناعة البرامج التي تطمح أليها وأخير هناك برنامج ممتاز جدا أسمه Sweet 3D لصانعة منزل وتأثيثه بتقنية D3 يمكن تحميله مجانا من http://www.SourceForge.com وهو مفتوح المصدر ومطور هذا البرنامج قام بتأليف كتاب رائع يشرح فيه مراحل تطوير البرنامج من الألف الى الياء من أراد أن أقوم بأرسال الكتاب له مع الكود سورس كاملا فهذا حساب الريد الألكتروني [email protected] ومعذرة على الأطالة

    1. اهلاً أخي، بالتأكيد يجب التطبيق وبناء البرامج ولا يوجد من يقول اكتفى بالقرائه فقط، فالاثنان ضروريان.

      شكراً لك ولاشارتك للبرنامج

      بالتوفيق

  4. ششكرا على الموضوع الرائع والمفيييد اسستفدت جداا ..

    لكن هل من الممكن التوسسع في Agile XP لان مشروع تخرجي بستخدامة ..

LEAVE YOUR COMMENT

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

مشاركة