>>> User Story <<<
Template لل User Story أقدم لكم شرح القالب العام
-----------------------------
Agile Methodology
م.سالي عبد الله
مقدمة
لتنسى أنك مطور (لدقائق معدودة) وتخيل أنك صاحب مشروع كبير ولديك المال المناسب لهذا المشروع وقد وظفت عدة مبرمجين ليقوموا بالتطوير في هذا المشروع، السؤال المهم الأن: ما هو الشيء الذي يجعلك تثق في أن الفريق يعمل ويسير في الإتجاه الصحيح؟
مجموعه من الملفات الورقية والتقارير ؟ أم عرض Power Point به صور متحركة (هذا يحدث كثيراً للأسف، هناك مبرمج بعد ثلاثه أشهر من العمل جاء بعرض Power Point! ) أم الأفضل أن تشاهد نسخه مصغرة من البرنامج تعمل أمامك، وخلال كل اسبوع أو اثنان ترى Feature جديدة في البرنامج ؟
كيف تقوم بذلك
باتباع طريقة تطوير تسمى Agile، ال Agile هي ممارسات معينة في تطوير البرمجيات تكون غالباً بشكل متكرر وعلى وتيرة واحدة الى حين تطوير المشروع بالكامل Iterative Development، وكما هي طبيعة البرمجيات فلا توجد اي منهجية أو سيلة تضمن نجاح المشروع هكذا بدون أي عوامل أخرى ، وحنى لو استخدمت الAgile فقد تفشل في مشروعك اذا قمت به بشكل خاطئ،لكن باتباع الAgile بالشكل الصحيح فسوف تزيد نسبة النجاح بشكل أعلى من غيرها لأن الأمور سوف تتضح جداً منذ بدايات المشروع.
الAgile هي ممارسات عامه في التطوير
there is no one ultimate flavor of agile
مثلاً هناك ال Scrum والتي تستخدم في ادارة مشاريع ال Agile (يمكن القول بأنها قواعد معينة في سير مشروع ال Agile) ، وهناك ال XP والتي هي ايضاً ممارسات معينة تطبق على مشروع ال Agile وغيرها من المنهجيات التي جميعها تطبق تحت مفهوم ال Agile، كل هذه المنهجيات تأتي ضمن فكرة ال Agile وتستخدم ممارستها ولكنها تضيف بعض الأمور خاصه بها، بالطبع يمكنك بعد دراسه الAgile وتطبيقها ايجاد منهجيتك الخاصه في التطوير فلا يوجد مانع لذلك
هل تستطيع تقدير وقت المشروع بشكل جيد ؟
هل تريد أن تعرف حالة المشروع بشكل دائم وتعرف مدى تأثير أي حدث على المشروع مثلاً خروج أحد المطورين؟
هل تعرف ماذا تفعل عندما يكون المشروع في نهايته وقد قارب وقت التسليم وما زال هناك الكثير من المهام ؟
هل مشاريعك ما زالت متأخرة في التسليم ؟
هل العميل يطلب اضافه المزيد نم المهام ولكنك لا تستطيع التصرف أمامه أو ابلاغه بتأثير ذلك في المشروع ؟
هل لديك وثيقة متطلبات ضخمة ولكن العميل يغير ارائه واصبحت لا تعرف ماذا تفعل ؟
هل تريد أن تعرف حالة المشروع بشكل دائم وتعرف مدى تأثير أي حدث على المشروع مثلاً خروج أحد المطورين؟
هل تعرف ماذا تفعل عندما يكون المشروع في نهايته وقد قارب وقت التسليم وما زال هناك الكثير من المهام ؟
هل مشاريعك ما زالت متأخرة في التسليم ؟
هل العميل يطلب اضافه المزيد نم المهام ولكنك لا تستطيع التصرف أمامه أو ابلاغه بتأثير ذلك في المشروع ؟
هل لديك وثيقة متطلبات ضخمة ولكن العميل يغير ارائه واصبحت لا تعرف ماذا تفعل ؟
النقطة الأولى: متطلبات المشروع User Stories
أول شيء تحصل عليه من العميل أو صاحب المشروع هي المتطلبات و الخصائص Features في ذلك المشروع والأشياء التي يريد العميل تطبيقها في النظام، بالطبع عليك ان تقوم بكتابه تلك المتطلبات حتى تقوم بتطبيقها فيما بعد، عندما تعمل بأسلوب ال Agile سوف تنبذ فكرة جمع كل المتطلبات وتفاصيلها الدقيقة وكتابه الوثائق الضخمة Heavy Documentation منذ البدء وذلك لأن الوثائق الكثيرة والكبيرة والتي يتم كتابه وجمع المتطلبات بها نادراً ما تنجح في المشاريع البرمجية، وبالتالي لن يحصل العميل على ما يريد ولا الفريق البرمجي لن بيني ما يريد وسوف يكون هناك ضياع كبير في الوقت والمجهود الذي بذل لكتابه هذه الوثائق.
أول شيء تحصل عليه من العميل أو صاحب المشروع هي المتطلبات و الخصائص Features في ذلك المشروع والأشياء التي يريد العميل تطبيقها في النظام، بالطبع عليك ان تقوم بكتابه تلك المتطلبات حتى تقوم بتطبيقها فيما بعد، عندما تعمل بأسلوب ال Agile سوف تنبذ فكرة جمع كل المتطلبات وتفاصيلها الدقيقة وكتابه الوثائق الضخمة Heavy Documentation منذ البدء وذلك لأن الوثائق الكثيرة والكبيرة والتي يتم كتابه وجمع المتطلبات بها نادراً ما تنجح في المشاريع البرمجية، وبالتالي لن يحصل العميل على ما يريد ولا الفريق البرمجي لن بيني ما يريد وسوف يكون هناك ضياع كبير في الوقت والمجهود الذي بذل لكتابه هذه الوثائق.
من المشاكل الأخرى التي سوف تقع بها عندما تكون لديك كل المتطلبات مكتوبة في وثائق كبيرة :
1) لا يمكن ان تتغير بسهوله، فالوثيقة مكتوبة وانتهت عملية اخذ المتطلبات وبالتالي لا يوجد مجال في تغييرها
2) أحيانأ تكون المتطلبات أخذت بشكل خاطئ أو اعطاها العميل بشكل غير جيد وبالتالي بنى المشروع على ذلك الأساس وليس كما يريده العميل
3) أو أنها تكتب بشكل غامض ويقوم الفريق بالتخمين في تلك الأشياء وبالتالي النتيجة شيء خاطئ، وهكذا اضعت الوقت والجهد ايضاً
هذه المشاكل ( في الاعتماد الكامل على الوثائق Documentations في أخذ المتطلبات ) لم تكن بسبب الحجم فقط وانما في كيفية ايصال المطلوب بشكل جيد Communication ، حيث قد تكون هناك اجزاء تفهم بشكل اخر بناء على ما هو مكتوب، وأحياناً ما هو مكتوب قد يكون له أكثر من تفسير، مثال على ذلك الجملة التالية سوف تجد أنه يمكن ان تفهم من كل جمله شيء اخر:
أفضل طريقة لأخذ المعلومات والمتطلبات هي التي تكون وجها لوجه
ما نريده كبديل هو شيء نستطيع من خلاله حفظ المحادثة Conversation التي تجري اثناء الحديث حول المتطلبات وتكون بها جوهر أو زبدة ما يريده العميل، وفي نفس الوقت تكون صغيرة وواضحه بحيث عندما نتحدث حول هذا الموضوع بالامكان الاشارة للاسم فقط وسوف يعرف الجميع اننا نتحدث عن هذه النقطة.
ومرحبا لل User Story، حيث هي عباره عن وصف قصير للخصائص Features التي يريدها العميل في برنامجه، وهي تكتب في بطاقات أو أوراق صغيرة Index Card (حتى لا تقوم بكتابه كل شيء) وفي نفس الوقت تحمل فكرة الخاصية التي يريدها العميل
ربما تتسأئل هل ورقة صغيرة تكفي لوصف كل الخاصية وما يحيط بها من كل الجوانب؟
— في الأساس لا يجب ان تكتب كل شيء، فعملية استخراج المتطلبات Requirement Gathering لا يجب ان تقوم بها بأخذ كل التفاصيل، ولكنك ستأخذ كل الخصائص والأشياء الواضحه وتكتبها على الورق الصغير وتقوم بحفظها في ملف وسوف ترجع لها فيما بعد. على سبيل المثال قمت بجمع 10 خصائص يريدها العميل، فلا يجب الأن ان تقوم بأخذ كل صغيرة وكبيرة عن هذه الخصائص، والسبب أنه مع الوقت قد يتم الغاء الخاصية بأكملها فكل شيء يتغير مع الوقت.
—لذلك احفظ وقتك وطاقتك حيث ستقوم بالدخول في التفاصيل فيما بعد ويمكنك القول بأن ال User Story هي عباره عن المحادثه التي جرت ، وقمت بتدوينها وسوف تعود للأشياء التي قد تعمل عليها في وقت لاحق.
القالب العام Template لل User Story
اي مجموعه من الكلمات توضح مقصد العميل يمكن ان تكون في ال User Story ، ولكن ان أردت ان تستخدم نسق معين في كتابتها فيمكن ان تستخدم الطريقة التالية (تقوم بكتابه من الذي سيقوم بهذا الدور وما هو الدور الذي سيقوم به والسبب الذي يجعله يقوم بذلك):
اذا طبقنا الطريقة هذه في تفاصيل الموقع السابق يمكن ان نخرج بالوصف التالي:
1) كرياضي احب ركوب الامواج، اريد ان اتحقق من الطقس قبل الخروج من المنزل ، حتى لا اذهب الى هناك ولا اجد امواج قوية
2) كرياضي في ركوب الامواج، اريد ان ارى احدث الأدوات والتصاميم للملابس ، حتى ابدوا بمنظر جيد في الصيف
-----------------------------------------------------------------------------------------------
User Story Cards have 3 parts
• Card - A written description of the user story for planning purposes and as a reminder
• Conversation - A section for capturing further information about the user story and details of any conversations
• Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected
User Story Description
As a [user role] I want to [goal]
so I can [reason]
User Story Description
— Who (user role)
What (goal)
— Why (reason)
— gives clarity as to why a feature is useful
— can influence how a feature should function
— can give you ideas for other useful features
that support the user's goals
المصدر
م.سالي عبد الله
لتحميل الملف الرابع agile User Story
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
لكي تفهم أكثر User Story وببساطة على شكل حوار مع حمد بشير اضغط هنـــا
لكي تفهم أكثر User Story وببساطة على شكل حوار مع حمد بشير اضغط هنـــا
لاتنسى الاعجاب بصفحتنا وانضم الينا
❤||| لا تنسى الانضمام الى المدونة بالضغط هنا |||❤
اذا لديك أي سؤال، فلا تتردد في الاتصال بنا
.For any kind of question, please feel free to contact us.
HAMAD BASHIR
agile User Story, شرح agile User Story, شرح User Story, شرح User Story هندسة البرمجيات, شرح القالب العام Template لل User Story, عمل قالب User Story, كيفية عمل User Story, هندسة البرمجيات,
اطرح اي سؤال خاص بالموضوع في التعليقات