التخطيط في ال Agile

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

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

لمراجعة السلسة (كل ما تحتاجه عن ال Agile):

• ما هي ال Agile 
• فريق التطوير في ال Agile 
• كيف تبدأ الخطوة الأولى في المشروع 
• كيف تخطط في مشروع ال Agile (المقالة الحالية)

في هذه المقالة سوف نتحدث عن  ثلاثه أمور أساسية في تطوير المشروع الا وهي:

1. أول خطوة تقوم بها مع العميل وهو كتابه  قائمة المهام والأعمال التي يريدها العميل والتي ستقوم بعملها (ويطلق عليها User Stories )
2. الحديث عن تقدير Estimation  تلك المهام الموجودة وكيف يمكن ان تقدر الوقت لها
3. سوف نتحدث عن بناء الخطة التي سوف تعمل بها وتتوقع التسليم على أساسها، وايضاً سوف نناقش بعض المشاكل التي لطالما تحدث اثناء التطوير وكيف سوف تتعامل معها .

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

النقطة الأولى: متطلبات المشروع User Stories

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

من المشاكل الأخرى التي سوف تقع بها عندما تكون لديك كل المتطلبات مكتوبة في وثائق كبيرة :

1)      لا يمكن ان تتغير بسهوله، فالوثيقة مكتوبة وانتهت عملية اخذ المتطلبات وبالتالي لا يوجد مجال في تغييرها

2)      أحيانأ تكون المتطلبات أخذت بشكل خاطئ أو اعطاها العميل بشكل غير جيد وبالتالي بنى المشروع على ذلك الأساس وليس كما يريده العميل

3)      أو أنها تكتب بشكل غامض ويقوم الفريق بالتخمين في تلك الأشياء وبالتالي النتيجة شيء خاطئ، وهكذا اضعت الوقت والجهد ايضاً

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

قد لا تظن أن هذا أمر مهم ولكن في الحقيقة الأمر كذلك، فقد حدث في السابق ان خطأ في جملة واحدة تسبب في خسارة ملايين الدولارت، بسبب جملة خاطئة حيث أدت لشيء مغاير لما يريده العميل (خطأ في كلمة واحدة أدت الى خسارة مليون دولار في أحدى الشركات الكندية The Comma That Costs 1 Million Dollars ) المصدر .

وهذا يقودنا الى القاعده المهمه في ال Agile:

أفضل طريقة لأخذ المعلومات والمتطلبات هي التي تكون وجها لوجه

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

مرحباً بال User Story

حيث هي عباره عن وصف قصير للخصائص Features التي يريدها العميل في برنامجه، وهي تكتب في بطاقات أو أوراق صغيرة Index Card (حتى لا تقوم بكتابه كل شيء) وفي نفس الوقت تحمل فكرة الخاصية التي يريدها العميل

ربما تتسأئل هل ورقة صغيرة تكفي لوصف كل الخاصية وما يحيط بها من كل الجوانب؟

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

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

كيف تكتب User Story جيدة

أول نقطه في كتابه User Story جيدة هي أن تحمل شيء مفيد للعميل Something of Value بمعنى أخر شيء سوف يدفع لك من أجله حتى تقوم بعمله، على سبيل المثال تقوم بكتابه مشروع لمطعم فيجب عليك كتابتها بلغه العميل حتى تكون مفهومه له ولك، المثال التالي يوضح الفرق بين قائمتين وانظر للفرق جيداً:

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

هذا لا يعني أننا لن نستخدم مثلاً Design Pattern في كتابة الكود، أو Connection Pooling في الاتصال مع قاعدة البيانات، ولكن ال User Story يجب ان تكون واضحه وبلهجه مبسطة، ويمكنك تحويل الكلام التقني الى فوائده التي يستطيع العميل فهمها، مثلاً:

النقطة الثانية في كتابه User Story جيدة، وهي أنها يجب أن تكون حول خاصية بكل جوانبها From End to End من شاشه المستخدم وكود ال Business وايضاً مع ال Database Layer ، يمكنك فهمها على أنها قضمه من الكيك Slices the cake

كما انك لا تستطيع اكل الكيك بشكل افقى  فالعميل لا يريد انصاف الحلول او حل غير مكتمل، وهكذا ال User Story يجب أن تكون مثل الSlice (من أعلى الى اسفل) في كل ال Layer في النظام حتى تقدم شيء مفيد Something of Value.

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

النقطة الرابعه وهي أنها ليس ثابته Negotiable وقابلة للتغيير لأي سبب سواء كان من صاحب المشروع أو بسبب تقنى ، وقد يكون هناك اكثر من طريقة للتطويرها وسيتم الاختيار بناء الميزانية ومتغيرات المشروع

النقطة الخامسة وهي ان تكون قابلة للاختبار Testable ، فكل من هذه الUser Story يجب أن يتم اختبارها والتأكد من أنها تعمل جيداً، ولذلك سنقوم بكتابه الاختبارات والتي تعطي الضوء الأخضر بأن هذه الخاصية تعمل وفقاً للاختبارات التي اجريت عليها.

النقطة السادسة وهي أن تكون صغيرة وقابلة للتقدير Estimable، حيث يمكن جعل اغلب ال User Story تكون في حدود يوم الى 5 ايام عمل، وهكذا ستقوم بادخالها في مرحلة Iteration من مراحل التطوير (سيتم الحديث عن مراحل التطوير في الدرس القادم).

النقاط الستة السابقة تسمى INVEST وكل حرف منها اختصار ل Independent, Negotiable, Valuable, Estimable, Small and Testable، والجدول التالية بين الفرق بين ال User Story ووثائق المتطلبات Requirement Documents:

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

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

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

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

الآن حاول ان تستخرج 6 مهام من التفاصيل السابقة 6 User Stories ، لا تقلق اذا لم تستطيع كتابتها بشكل جيد فهذا تمرين لكي تستطيع تحويل ما تسمعه من العميل الى User Story كما يريديها العميل.

بعد محاولتك في استخراج ال User Stories قم باختبارها هل حققت مفهوم ال INVEST ؟ أي هل هي Independent, Negotiable, Valuable, Estimable, Small and Testable ولا تقلق اذا لم تستطيع جعلها جيدة منذ البدء وركز على جعلها مفيدة للعميل وانها تمثل شيء يريده العميل.

هذه أول محاولة لكتابة ال User Stories للتفاصيل الموجودة:

السؤال الآن هل أخر وظيفتين (الموقع يجب ان يكون سريع، و التصميم يجب ان يكون جيد) هم User Stories جيدة أم لأ ؟

قد تفكر بأن المهمه الموقع يجب أن يكون سريعاً (The website must be super-fast) غامضة قليلاً وهذا صحيح، حيث كلمة سريع جداً Super-fast لا توضح السرعة المرغوبة، وبنفس المنطلق  التصميم يكون جيداً (The design should look really good) فكيف يمكن ان تعرف ان الموقع يظهر بشكل جيد أم لأ.

هذه ال Stories تسمى قيود Constraints فهي ليست User Stories يجب أن نطورها في كل دورة تطوير، وهي مهمه ايضاً لأنه تحدد مالذي يريده العميل في برنامجه، ويمكن ان نضعها على Card ولكن تكون ورقة قيد Constraint Card بعد تحويلها لشيء مفهوم –اذا استطعت- بشكل أفضل حتى يتم اختباره

هكذا أصبحت اوضح وعرفت ماذا تعني كلمة Super-Fast وهكذا تستطيع كتابه الاختبارات لها. ويفضل ان تضع ال Constraints على Card مختلفة اللون من ال User Stories حتى تفرق بينهم، واجعل فريق التطوير يعرفوا القيود جيداً وقم باختبارها بشكل متكرر اثناء تطوير المشروع.

القالب العام Template لل User Story

اي مجموعه من الكلمات توضح مقصد العميل يمكن ان تكون في ال User Story ، ولكن ان أردت ان تستخدم نسق معين في كتابتها فيمكن ان تستخدم الطريقة التالية (تقوم بكتابه من الذي سيقوم  بهذا الدور وما هو الدور الذي سيقوم به والسبب الذي يجعله يقوم بذلك):

اذا طبقنا الطريقة هذه في تفاصيل الموقع السابق يمكن ان نخرج بالوصف التالي:

1)      كرياضي احب ركوب الامواج، اريد ان اتحقق من الطقس قبل الخروج من المنزل ، حتى لا اذهب الى هناك ولا اجد امواج قوية

2)      كرياضي في ركوب الامواج، اريد ان ارى احدث الأدوات والتصاميم للملابس ، حتى ابدوا بمنظر جيد في الصيف

الشيء الجيد في القالب هو انه يجب على 3 أسئلة مهمه في ال User Story وهي من Who   وماذا What ولماذا Why. فيكتب بها جمل وتوضيحات اكثر وتركز على ما يريده العميل وهذا المطلوب. على كل هناك من لا يفضل الاطالة بهذه الاسئلة الثلاث وهناك من يفضل ذلك، لذلك يمكنك تجربة كل منهم واختيار ما تراه مناسباً لك. ويمكنك أن تعمل بهم الاثنين، فتكتب في الورقة من الأمام الوصف القصير ومن الخلف تقوم باتباع القالب اذا كان سيفيدك ذلك فيما بعد.

كيف تأخذ ال User Story من العميل ؟

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

هذه بعض من النقاط المفيدة:

1)      ايجاد غرفة كبيرة بها طاولة: لأنك ستتحرك وتأخذ الأوراق وتضعها على اللوحة، وتكتب في اوراق والخ

2)      رسم المخطاطات والصور التوضيحية:  فالصور هي وسيلة جيدة لعصر الدماغ واستخراج الأفكار وال Stories ، الصورة التالية توضح ال Personas (الأشخاص الذين سيعملوا على النظام) وهي جيدة لمعرفة المستخدمين، وتوضح ال Flowcharts وال Scenarios  وال Process Flows فهي جيدة لتوضيح الأدوار في النظام وكيف يعمل النظام، وتوضح ال System map لتقسيم اجزاء النظام، وتوضح ال Concept Design وال Paper Prototypes وهي لتوضيح ما يمكن ان يقوم النظام به.

بعد أن تقوم برسم مجموعه من الصور التوضيحية ومعرفة كيف يعمل النظام يمكن بعدها استخراج ال Stories من الصور التوضيحية.

3)      كتابه الكثير من ال Stories: يمكنك الان ان تستخرج ال Stories مع العميل من تلك الرسوم التوضيحية

اذا كان كل البرنامج موجود فقط في صورة واحدة أو اثنين، فيمكنك اخذها وتقسيمها لأجزاء أصغر، وفي العادة من Flow Chart واحد ممكن اخذ معظم الCore Stories في المشروع.

قد تجد بعد ان تنتهي من استخراج ال User Stories أن هناك Stories كبيرة وهي تسمى Epics (الUser Stories التي تأخذ عده اسابيع من العمل). وال Epics سوف يتم تقسيمها لعدة Stories وقت التطوير عندما تبدأ العمل عليها. وفي الأخير 10 الى 40 User Stories تعتبر كافية للعمل من 3 أشهر الى 6 أشهر، اذا كانت لديك مئات ال Stories فهذا يدل انك قمت بالدخول في ادق التفاصيل وهذا خطأ فنحن نريد النظرة العامة Breadth وليست التفاصيل الدقيقة Depth.

4)      فكر بأي شيء أخر: الصور التوضيحية مفيدة ولكنك قد لا تستطيع اخذ كل شيء بها، مثلاً الاختبارات Load Testing/User Acceptance Testing ، دليل البرنامج Manuals and Documentations ، أدوات التدريب Training Materials ، وغيرها ، فيجب كتابتها سواء ك  Constrains أو Stories عادية مع غيرها.

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

الآن لديك جميع المهام وأنت جاهز لمرحلة التقدير.

النقطة الثانية : التقدير Estimation

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

ستيف ماكونيل (صاحب كتاب Code Complete الشهير) سمى عملية التقدير بعدم اليقين  cone of uncertainty  ووضح أن التقدير الأولي قد يختلف بنسبة تصل الى 400% عن الوقت الحقيقي للمشروع، ولذلك يجب أن تدرك أن التقديرات الدقيقة منذ البدء امر لا يمكن أن يتم بشكل كامل ، ويجب ان تتوقف من التفكير بهذه الناحية.

الشيء الوحيد الذي سوف تجيب عليه التقديرات الأولية هو الاجابه على السؤال: هل يمكن القيام بهذا المشروع  في هذا الوقت وبهذه المصادر  Resources المتوفرة؟

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

ولكي تقيس بشكل صحيح، فأنت تحتاج الى :

1)      قائمة المهام التي يريدها العميل User Stories مرتبه في مجموعات على حسب حجمها Relative to each other

2)      طريقة تسمح لنا بمعرفة التقدم في التطوير point based system

لكي نرتب المهام على حسب حجمها Relative Sizing نأخذ المثال التالي لكي تفهم الفكرة ، لنفترض انك تستطيع اكل قطعه من الكعك في 10 ثواني، وطلبنا منك تقدير الوقت اللازم لأكل 7 كعكات و 14 كعكة ؟ فما هو جوابك ؟

الآن لنفرض أننا طلبنا منك تقدير شيء آخر، شيء بسيط ولكنك لم تقم بذلك من قبل، فكم الوقت المطلوب في كل من هذه المهام ؟

بالتأكيد ستجد أن عملية التقدير الأولى (تقدير عملية  الأكل بناء على تقدير موجود مسبقاً Relative Sizing)  اسهل بكثير من الثانية (تقدير شيء جديد بدون عمله مسبقاً Absolute). والفرق بين التمرينين، هو أن الأول كان التقدير عملية نسبية Relatively بينما التمرين الثاني كان عملية تقدير مطلقة Absolute.

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

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

هناك ملاحظة مهمه بطريقة التقدير النسبية Relative Estimation الا وهي أن اليوم الواحد في التقدير لا يعني يوم واحد في العمل، وقد يعمل الفريق بشكل أسرع أو ابطئ من ما هو في التقدير.

على سبيل المثال نفرض اننا قدرنا أن ال Story تأخذ 3 ايام من العمل ولكن في الحقيقة تم الانتهاء منها بعد 4 ايام.

هكذا سوف نحتاج لتعديل كل التقديرات لكل ال Stories بهذه النسبة الجديدة (مقدار 33%)

لدينا مشكلة وهي ان الارقام 1.33 يوم ماذا تعني ، والمشكلة الثاني هي اعادة التقدير للجميع في حالة اكتشفنا ان الوقت الفعلي اكثر. لحل هذه المشكلة، وتقادي عملية اعادة تقدير كل ال User Stories مجدداً فسوف نقوم بعملية التقدير باستخدام النقاط Point System

نظام النقاط لتقدير المهام Point Based System

سوف يسهل لنا هذا النظام معرفة مدى التقدم Track Progress وايضاً التقدير النسبي بدون القلق حول التقدم الفعلي مقارنه بالتقدير.

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

للتسهيل اكثر يمكنك التفكير بأن التقدير هي كعملية معرفة حجم التيشرت (مقاس صغير Small Size، مقاس وسط Medium Size، مقاس كبير Large Size).

هذه الطريقة Point Based System سهله وبسيطة وتذكرنا بأن التقديرات هو مجرد تخمين وتصور المهمه بحجمها الطبيعي، هناك بعض الفرق Teams تستخدم مفهوم اليوم المثالي Ideal Days بدلاً من النقاط وهو اليوم الذي تعمل فيه بدون توقف أو اي مقاطعات وفي الحقيقة هذا صعب في بيئات العمل فهناك دائماً توقفات وانقطاعات ولا يمكن العمل 8 ساعات بدون اي توقف الا نادراً. لذلك سوف نستخدم مفهوم النقاط Points.

الآن لكي تقدر المهام الموجود لديك ، توجد طريقتين يمكن ان تستخدمها لعمل التقديرات لكل ال Stories لديك:

1)      طريقة ال Triangulation
2)  الاجتماع مع الفريق وتقدير المهام مع بعض (تسمى Planning Poker)

طريقة ال Triangulation

وهي ببساطة اخذ اي Stories سهله وتقديرها ومن ثم تقدير بقية ال Stories بناء على ذلك

لنفرض أن لديك هذه ال User Stories وأنك بحاجه لعمل Estimation   لها

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

بعد أن تقسم أول مهام سوف تستطيع تقدير المهام الأخرى بالإعتماد على المهام التي قسمتها في أول خطوة

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

الاجتماع مع الفريق للتقدير Planning Poker

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

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

ال Planning Poker مفيدة لأن الأشخاص الذين يقوموا بعمل التقدير هم من سيقوم بتلك المهام (المبرمجين)، وايضاً قد يكون ال DBA أو المصممين موجودين في الاجتماع في حال كانت لديهم مهمه في العمل ايضاً. من الملاحظات المعروفة وهي أن ال Planning Poker ليست نظام تصويت Voting System لكنها طريقة لجعل الجميع يدلوا بأرائهم ومن ثم يتم اخذ التقدير الصحيح بناء على المناقشة التي ستدار بين اعضاء الفريق.

هناك أدوات تجارية تساعدك في ال Planning Poker ووتحتوي على بطاقات بأرقام 8,13,20,40 و 100  ولكنك في الغالب لا تحتاج لذلك، فقط الارقام 1 و 3 و 5 تكفي للقيام بذلك.

الآن قمنا بعمل التقديرات باستخدام طريقة Point-Based System والآن أنت جاهز في بناء أول خطة لك Agile Plan.

النقطة الثالثة: التخطيط في ال Agile:

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

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

من المشاكل الأخرى وهي تغيير المتطلبات فقد يكتشف العمل انه حقاً يريد عمل تلك الخاصية

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

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

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

1)      انتاج شيء مفيد للعميل

2)      طريقة واضحه للجميع وصادقة في نفس الوقت

3)      تجعلك تستطيع الوعد بالتسليم من خلال الاعتماد عليها

4)      تتكيف مع التغيرات في المشروع بحيث تتغير الخطة بما يلزم الأمر

مرحباً في ال Agile Plan ، وهي في شكلها البسيط عباره عن طريقة لقياس سرعه الفريق من حيث قدرتهم على تحويل ال User Stories الى برنامج يعمل بشكل جيد ، ومن ثم باستخدام هذا المقياس يمكن تخمين متى سوف تنتهي من العمل.

قائمة المهام في مشروع الAgile تسمى ب Master Story List وهي تحتوي على جميع ال Features التي يريدها العميل في المشروع، والسرعه التي تستطيع انجاز ال User Story وتحويلها لشيء يعمل تسمى Team Velocity وهو ما ستستخدمه لقياس سرعه الانتاجية للفريق ووضع التوقعات Expectation حول مواعيد التسليم في المستقبل.

هذه العمليات تتم خلال دورة التطوير (تسمى Iteration) وهي اسبوع أو اثنان من العمل في ال User Stories الموجودة وتحويلها لشكل قابل للعمل Production Ready Software.

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

#Iterations = Efforts / Team Velocity

على سبيل المثال:

#Iterations = 100 pts / 10 pts per iteration

#iterations = 10

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

لذلك كثير من المشاريع تفشل في بداياتها أو ربما قبل البدء بسبب معاملة الخطة الأولوية Initial Plan كوعد للتسليم Hard Commitment. حيث عندما تبدأ بالعمل قد تجد أنك تعمل بشكل أسرع مما كنت متوقع أو أنك تعمل بشكل أبطئ مما كنت متوقع (وهو الغالب).

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

يجب أن تكون مرناً من ناحية ال Scope

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

في حال لم يريد العميل أن يزيل ال Story عندما يضيف واحدة جديدة وهو مستعد على دفع اي تكاليف جديدة عليها فعليك في هذه اللحظة هو تأخير موعد التسليم Push our delivery date.  لذلك لكي تتعامل في هذه الحالات لا يوجد لديك الا أن تأخر موعد التسليم أو تقلل ال Scope

الذي لا يمكن أن يحدث أن يضيف العميل في القائمة ولا يتوقع حدوث مقابل لذلك سواء كان في الوقت أو ال Scope، فهذا لا يمكن أن يحدث في ال Agile، وعندما تكون بين الأمرين (تأخير الوقت أو تقليل ال Scope ) فال Agile يختاروا الثانية وهي تقليل المهام و تقليصها.

قد تتسائل ماذا اذا رفض العميل أن يكون مرنا من ناحية الScope وفي نفس الوقت يريد المزيد من العمل والمهام ؟ في هذه الحالة لديك بعض الخيارات:

1)      تتجاهله وتعمل كما الخطة الأصلية، أو أن تعطيه تقدير جديد للوقت بدون أن تنظر لسرعه الفريق وتأمل أن تنتهي الأمور في الأخير وأنت لا تعرف كيف سيحصل ذلك (الانتظار لحدوث المعجزة Management by Miracle).

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

كيف تبنى أول خطة Agile في مشروعك؟

لديك 5 خطوات بسيطة:

1)   انشئ قائمة المهام Master Story List

قائمة المهام هي قائمة تحتوي على ال User Story (ال Features المطلوبة) التي يريدها العميل وتكون مرتبة بحسب الأهمية التي يريدها العميل (الFeatures الأكثر أهمية أولاً ثم التي تليها وهكذا) وتقوم وفريقك بتقدير Estimate الوقت لها وتكون هذه هي أساس خطتك لتطوير المشروع.

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

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

ال Release هي مجموعه من ال Stories متعلقة ببعضها البعض وتقوم بتطويرها لتخرج شيء له قيمة في المشروع وتسمى أحياناً ب Minimal Marketable Features واختصاراً MMF والحرف الأول M يعني أننا نريد تطوير شيء له قيمة بسرعه (في الغالب 80% من قيمة المشروع تكون في 20% من الFeatures) لذلك عليك أن تختار أقل عدد من ال Features التي تحتوى على صلب المشروع والتي تجعل أول Release لها أكبر قيمة.

ال M الثانية تذكرك بأن ال Release يجب أن تكون مفيدة للعميل (والا فلن يستخدمه) لذلك فال Minimal  وال Marketable من الأمور المهمه في اختيار ال Stories لأول Release في مشروعك.

بعد أن تقوم بعمل ال Releases وتحديد قائمة المهام سوف تبدأ بعملية التقدير Estimations.

2) تقدير المهام Estimations

وقد سبق أن تحدثنا عن الطرق المستخدمه في هذا الموضوع، وهنا نريد معرفة كم تأخذ فترة التطوير وهل هي شهر أم اثنان أم ثلاثه أم 9 أشهر

فبعد أن تقوم بتقدير المشروع باحدى الطريقتين ( ال Triangulation أو ال Planning Poker)  عليك بترتيب المهام على حسب أولويتها أو أهميتها بالنسبة للعميل.

3) ترتيب المهام Prioritizing

العمل يجب أن يكون على الأمور الأكثر أهمية في المشروع أولاً، فاجعل العميل يحدد المهام الموجودة واعطائها الأهمية التي يريد من جهه منظورة (منظور العمل Business Point of View)

كما يحق للعميل بتحديد ماالذي سيتم بنائه ومتى فيمكن لك تقديم الاقتراحات حول ال Stories التي يجب أن تبنى من الأول والتي تراها ضرورية في العمل أو لكي تقلل اي خسائر يمكن أن تحدث Reduce Architecture Risk لذلك لا تخف من تقديم تلك المهام والتحدث عنها فخبرتك مهمه هنا.

بعد أن تنتهي من الترتيب ولديك قائمة مرتبه ومقدرة فعليك أن تعرف كيف يمكن ان تقيس سرعه الفريق أو المطورين في العمل.

4)  قياس سرعه الفريق في العمل Team Velocity

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

اذا كانت كل ال Stories لديها نفس الحجم ، مقياس السرعه يكون عن طريق المعادلة:

Team Velocity = Stories Completed / Iteration

لكن الغالب لن يكون بهذا الشكل لأن ال Stories سوف تختلف حجمها وتقاس بالمعادلة:

Team Velocity = Story Points Completed / Iteration

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

بعد ثلاثه أو اربعه دورات Iterations سوف تثبت ال Velocity ويمكنك معرفة سرعه الفريق بشكل جيد حينها، ولا توجد قاعدة جيدة لذلك، فعليك بسؤال الفريق كم يمكن أن ينجزوا خلال ال Iteration وضع في اعتبارك تواجد العميل (اذا احتاجه الفريق اثناء العمل) وايضاً تواجد الفريق مع بعضهم في مكان واحد Co-Located Team.

من المهم أن تذكر الفريق أن كلمة انتهت Done تعني أنك بالفعل أنتهيت (تحدثنا عنها في أول موضوع عن ال Agile) من كل شيء بخصوص هذه ال Story وهذا يشمل التحليل Analysis والاختبار Testing والتصميم Designing والتطوير Coding كل شيء متعلق بها. أيضاً  لا يحبذ أن تكون متشدد في تقديرك الأولى ، اذا كنت تنظر بشكل عالي جداً Shoot too high فقد تجد صعوبة في اقناع العميل والتحدث معه أكثر بكثير من اذا كنت تنظر بشكل بشكل متواضع جداً Shoot too low لذلك كن متوسطاً وذكر كل العاملين Stakeholders بأنك تقدر فقط وابدء بالقياس من اليوم الأول.

ايضاً عليك باستخدام ال Velocity للفريق وليس للفرد، فقولك باسم الفريق “نحن نستطيع انجاز هذا كل هذه الفترة” سوف يختلف عن “محمد يستطيع اكمال 10 واحمد يستطيع اكمال 2” فاذا كنت تود تدمير مشروعك وحصول المشاكل بين الفريق وسوء التواصل بينهم  Miscommunication وعدم مشاركة المعلومات فقم بتحديد الأفراد بدلاً من العمل كفريق. وتذكر هذا يقتل روح الفريق وتشارك المعلومات وقد تحصل على منتج سيء في الأخير.

الآن قدرت السرعه وأنت جاهز لوضع التوقعات حول مواعيد التسليم.

5)  اختيار التواريخ Dates

لديك منهجيتين في التسلييم ، وهي تسليم المشروع بزمن معين Deliver by date أو تسليم المشروع بالمميزات Deliver by features set.

التسليم بالوقت Deliver by date

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

اذا كنت مرناً من ناحية الوقت والمهم هو أن تكمل ال Features فيمكنك ان تستخدم الأسلوب الثاني وهو ال Deliver by Features

التسليم بالمهام Deliver by Features

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

الآن أنت انشئت خطة ال Agile وهي ببساطة قائمة المهام Master Story List تكون مرتبة بالأهمية Prioritize ومقدرة الحجم Estimated وقدرت سرعه الفريق في التطوير Velocity واخترت تواريخ التسليم Dates.

هناك مخطط يوضح لك حالة المشروع ولا يمكن ان تكون خطة ال  Agile بدون استخدامه : الا وهو ال Burn Down Chart.

مخطط Burn Down 

هذا المخطط يوضح لك حالة المشروع وكيف يعمل الفريق على ال Stories المطلوبة وتوضح لك متى تتوقع التسليم النهائي.

في محور ال Y يكون هناك العمل المطلوب انجازه (سواء بالأيام أو النقاط) وفي محور ال X يكون هناك ال Iterations ، وعن طريق معرفة العمل المتبقى points وترسمه على المخطط ، وميل المستقيم هو سرعه الفريق (كم انجز كل Iteration).

من هذا المخطط يمكنك معرفة :

–          كم العمل المنتهي

–          كم العمل المتبقى

–          سرعه الفريق

–          الوقت المتوقع للتسليم

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

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

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

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

من المخططات الأخرى المشابه هو Burn up وهو نفس المخطط السابق ولكنه معكوس

البعض يفضل استخدام هذا المخطط لأنه يوضح ال Scope ومتى يحصل زيادة فيه عن طريق اضافة Stories جديدة (خط افقى مستقيم وأي زيادة سوف توضح في الخط المستقيم)، فاذا كنت تحب وضوحية ال Scope في  Burnup وسهوله ال Burndown فيمكنك دمجهم مع بعض

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

الإنتقال في منتصف المشروع الى Agile

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

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

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

الان أن تعلم الكثير في التخطيط  بال Agile ولكن هناك  اربعه تحديات سوف تواجهها اثناء العمل وكيف يمكنك التعامل معها بخطتك في ال Agile

السيناريو الأول: العميل لديه متطلبات جديدة

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

لكن لا تأخذك العاطفة عندما تبدأ هذه المحادثه، فهذا ليس وقتك لاثبات شيء ما It’s not your call to make، فأنت ما الا وسيلة للتوصيل فكن محايداً تجاه النتيجة فمسؤليتك هي جعله يدرك مدى تأثير قراراته واعطه كافه المعلومات اللازمه التي يحتاجها لاتخاذ القرار.

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

السيناريو الثاني: لم تعمل بشكل سريع كما تتوقع:

اذا تفاجئت بعد 3 أو 4 Iterations بأن السرعه ليست كما كنت متوقعها فلا تقلق فهذا متوقع لذلك وضعنا التوقعات حول السرعه من الأول وأخبرنا العميل بأن الخطة الأولية هي تقدير وليس موثوقه بشكل كامل، لكن الأمر الجيد أنك تعلم الآن السرعه فيمكن التعديل على أساسها.

المرونه من ناحية ال Scope هي الطريقة المفضلة للمحافظة على التوازن ، يمكنك اضافه المزيد من ال Resources (والتي سوف تبطئ في البدايه) أو تأخر موعد التسليم الى وقت آخر. المهم هو المحادثه مع العميل واعطائه الخيارات وهذا قد يجعلك في موقف صعب مع العميل ولكنك لا تستطيع اخفاء هذا الأمر، انشر الأخبار السيئة مبكراً هي من العادات في الأجايل Bad News Early.

أحياناً قد تسأل هل يكفى هذا الوقت للقيام بذلك الأمر؟ وهنا سوف ستقوم بالطريقة الصادقة الشفافه وهي بناء أقل شيء يمكن واذا لم تستطيع القيام به فالخطة بالتأكيد خاطئة وتحتاج لأعادة بنائها. وهي تعمل عن طريق اخذ أهم Features للمشروع (شيء من Core Features) وقيس كم من الوقت سوف يأخذ لعمل اقل من هذه المهام، واستخدم ذلك لبقية ال Stories لكي ترى هل النسخه المبسطة Minimalists من المشروع يمكن القيام بها في ذلك الوقت والمصادر ، فاذا كان الوقت يبدوا جيداً فاكمل العمل والا فعلى الأقل انت تعلم ذلك.

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

السيناريو الثالث: خروج احد المطورين الرئيسين

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

السيناريو الرابع:  أنت تعديت الوقت المسموح Run out of time

الاجابه المحتملة بأن تكون مرناً من ال Scope واذا وصلت لنهايه المشروع فقم بعمل نصف المهام التي تريد اطلاقها، الاجابه لهذه الواقعه هو أن تجلس مع العميل وابحث عن حلول ابداعية لمساعدته (مثلاً هناك Story يمكنك عمله بشكل بسيط Spartan أو مثلاً كان العميل يريد 10 تقارير ثابته يمكنك عمل تقرير واحد Dynamic). عليك أن تساعده وتكون ناصح موثوق وذلك عن طريق اعطائه الخيارات وهذا طريق لبناء علاقه جيدة مع العميل Relationship ، لا يجب أن تكون صارماً وتخوف العميل بأنك لا تستيطع التسليم فهذا لا ينفع اي أحد فقط كن صادقاً معه لحل المشكلة.

المرة القادمة ان شاء الله سوف نتحدث عن تنفيذ هذه الخطة وكيف يمكن تحوليها لشيء حقيقي يعمل وجاهز للعمل Production Ready Software.