القصص والسيناريوهات التي تعني واجهة المستخدم

Question

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

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

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

ضع في اعتبارك ، لقد قرأت فقط مقالات حول BDD وأعتقد أنها ستساعد فريقنا كثيرًا ولكن لا يزال جديدًا جدًا في هذا! شكرًا!

Answer 1

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

أحب أن أرى سيناريوهات تقول أشياء مثل:

• عندما أبحث عن الإدخال
• عندما أذهب إلى اليوميات لشهر يناير
• عندما أنظر إلى أحدث الإدخالات
• عندما أنظر إلى نفس القميص باللون الأسود

يمكن أن تتضمن كل هذا النقر على رأس العمود ، لكن تفاصيل التنفيذ لا تهم. إنها قدرة النظام.

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

لقد كتبت هذا في DSL بدلاً من اللغة الإنجليزية ، لكنه يعمل مع نفس الفكرة - لا يمكنك معرفة ما إذا كانت واجهة المستخدم الرسومية أو صفحة ويب ، وبعض الخطوات تتضمن إجراءات واجهة المستخدم المتعددة:

http://code.google.com/p/wipflash/source/browse/example.petshop.scenarios/petregistrationandpurchase.cs

آمل أن تجدها مثيرة للاهتمام وربما تساعد. حظا طيبا وفقك الله!

Answer 2

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

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

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

Answer 3

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

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

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

أما بالنسبة لهذه العملية ، فإن RUP/UP تستمد واجهة المستخدم من حالات الاستخدام ، لكنني أعتقد أن Agile في طبيعتها تدريجيًا (لن أقول تكرارًا ، فهذا سيستبعد أساليب رشيقة مثل FDD و Kanban). هذا يعني ، أثناء تنفيذ قصة جديدة ، تضيف إلى واجهة المستخدم الخاصة بك ما هو ضروري. هذا يجعل فقط إضافة تفاصيل واجهة المستخدم في القصص أكثر منطقية. المشكلة هي أن هذه ليست طريقة جيدة جدًا لإنشاء واجهة مستخدم أو بشكل عام UX (تجربة المستخدم). هذا هو بالضبط ما قد يسميه المرء نقطة ضعف. يركز البيان Agile على البرامج الوظيفية ، ولكن هذا هو. لا يوجد أي تقنيات رشيقة لتصميم واجهة المستخدم أو UX.

Answer 4

أعتقد أنك تحتاج فقط إلى التراجع قليلاً.

سيئ: عندما أقوم بالنقر فوق رأس العمود ، يتم فرز الصفوف حسب العمود الذي نقرت عليه.

جيد: ثم أقوم بفرز الصفوف بالاسم ، أو في بعض الأحيان عن طريق الرمز البريدي إذا كان الاسم شائعًا جدًا ، مثل "Smith".

قصة / سير عمل المستخدم هي سلسلة من ما يريد المستخدم تحقيقه, ، ليس سلسلة من الإجراءات كيف انه يحقق ذلك. أنت تجمع ما هى حتى تتمكن من تحديد الأفضل كيف لجميع المستخدمين وحالات الاستخدام.

---

بالنظر إلى جانب فردي في رسالتك:

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

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