تحديد قصص المستخدم والتطوير السريع
يتمثل أحد المبادئ الأساسية لعمليات التطوير الحديثة في التطوير السريع . تؤكد منهجية التطوير هذه على استخدام قصص مستخدم صغيرة الحجم لتحديد ما يفعله النظام من منظور المستخدم ، وليس من منظور تقني. يهتم المستخدم إذا كان المنتج سريعًا وسهل الاستخدام ويحل مشكلته. إنهم لا يهتمون بما إذا كانت تتبع بنية من 3 طبقات ، أو بها Mongo DB ، أو إذا كانت تستخدم Rails أو Asp.net.
قصص المستخدم:
- سهلة الفهم ويمكن لأي شخص المشاركة
- العمل بشكل تكراري يمكن وينبغي تغييرها أو تعديلها بشكل متكرر
- قم بمواءمة المطورين والمستخدمين والمتخصصين في الأعمال حول الأهداف والتوقعات المشتركة
- أسهل كثيرًا في القراءة من مستندات المتطلبات المكونة من 400 صفحة
يوفر Storyboard That نظامًا أساسيًا مثاليًا لإنشاء قصص مستخدم رشيقة وإثارة محادثة بتنسيق أقل ضرائب بكثير من جدار النص.
مَلحمي
في سياق قصص المستخدمين ، فإن "الملحمة" هي ببساطة قصة واسعة جدًا سيتم تقسيمها لاحقًا إلى العديد من قصص المستخدمين المحددة. البدء بالملحمة يجعل الجميع يرتبكون برؤية واحدة عالية المستوى. ترتكز القصة الملحمية على مشروع من الأعلى إلى الأسفل ، وإذا لم يكن من المنطقي إنشاء ملحمة ، فإن العمل الداعم سيكون أيضًا مضيعة للجهد.
في هذه القصة ، من الواضح جدًا ما هي الرؤية طويلة المدى وكيف يجب أن يبدو النجاح. يجب أن تتضمن القصة الملحمية الجيدة ما يلي:
- الإعداد أو السياق
- الفاعلون أو المستخدمون
- أهداف و غايات
- الأنشطة والفعاليات
تحديد المستخدمين
خاصة عند تصميم البرامج ، من المهم أن يكون لديك رؤية جيدة لما سيكون عليه المستخدمون. لن يتطابق كل مستخدم مع هذه الرؤية بدقة ، وقد تكون هناك فئات متعددة من المستخدمين ، لكن هذه الرؤى المنفصلة تحتاج إلى توضيح. يحمي التفكير في المستخدمين أولاً من الإفراط في الهندسة والمضاعفات ، ويمنع المنتج الجديد من الحصول على شيء للجميع وعدم كونه مفيدًا لأحد.
خلق قصة
بمجرد إنشاء ملحمة وتحديد المستخدمين ، يمكن إنشاء قصص أصغر وأكثر تحديدًا حول تجارب مستخدم معينة. تقسم القصص أدناه ما هو موضح أعلاه إلى روايتين: البحث عن طلب وإعادة طلب منتج.
لا تحتوي هذه الروايات على معلومات فنية ؛ لا يهتم المستخدمون بكيفية تحقيق النتائج ، طالما أنها تؤدي المهام المطلوبة. وبالمثل ، يتم تصوير تجربة المستخدم بشكل عام ، لتجنب خنق الابتكار أو فرض مسار. بشكل عام ، يجب أن تكون القصص:
- صغير - أقل من 10 أيام عمل
- ذات قيمة - بمجرد اكتمالها ، يجب أن تقدم شيئًا صالحًا للاستخدام
- قابل للتقدير - قادر على إنشاء تقدير تقريبي لمقدار الجهد المبذول
البحث عن طلب
إجراء إعادة ترتيب
المحادثة والتخطيط للاختبار
يجب أن تدعو هذه القصص إلى محادثة وأسئلة ، مثل:
- هل هذه هي القصص الصحيحة لتتناسب مع ملحمتنا؟
- ما هي القصص الأخرى التي يجب إنشاؤها؟
- هل تتوافق هذه القصص مع ما نعرفه عن مستخدمينا؟
من المعقول تمامًا إنشاء العديد من القصص ؛ في الواقع ، ينبغي تشجيعه. لن يتم استخدام بعض هذه القصص مطلقًا ، ولكن من المهم أن ترى المسار الذي حددته. ستؤدي هذه المجموعة من القصص إلى التخلص من المتطلبات الإضافية والتأثير على الاختبار.
يجب أن تثير القصص وتعلم المناقشة حول كيفية اختبار البرنامج وما هي قواعد العمل التي يجب تحديدها بشكل صريح. على سبيل المثال:
- ما هي السرعة التي يحتاجها البحث؟
- هل هناك حد زمني لإعادة الطلبات؟
- ماذا يجب أن يفعل النظام إذا كانت هذه هي إعادة الطلب الثانية؟ الخامس؟
- ما الاختبارات وأسئلة المتابعة لديك؟
© 2024 - Clever Prototypes, LLC - كل الحقوق محفوظة.
StoryboardThat هي علامة تجارية لشركة Clever Prototypes , LLC في مكتب براءات الاختراع والعلامات التجارية بالولايات المتحدة