agile شرح رشيقة-تعريفات قصة المستخدم




user story شرح (5)

محاولة، لتحقيق [قيمة الأعمال] كما [المستخدم] أحتاج [ميزة].

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

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

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

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

ك [نوع المستخدم] أريد [ميزة] بحيث [بعض الفائدة]

أنا دائما يميل إلى تفويت بداية ونهاية، ومجرد ترك ميزة - ولكن هذا ثم يصبح مجرد متطلبات جمع الطريق القديم!

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

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

ك [مدير مخزن] أريد [لرؤية قائمة من بنود الأسهم] بحيث ...؟

هل من الممارسة العادية أن تترك شرط [بحيث]؟


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

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

خلاصة القول بالنسبة لي: إذا كانت القصص العمل بالنسبة لك دون المستخدم والأساس المنطقي - طالما كنت أفهم من المستخدم و لماذا يريدون شيئا - تفعل ذلك ولكن تريد. فقط لا تتطلب مواصفات كاملة قبل البدء في تنفيذ.


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

باختصار لا تشعر وكأنك يجب أن تكون في سترة مستقيمة. الشيء المهم هو أن تتبع روح المنهجية.

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


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

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


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