صارف کی کہانیوں کے لیے قبولیت کے معیار کو لکھنے کے لیے پروڈکٹ کے مالک کی گائیڈ

‘میں پروڈکٹ مالکان کے لیے ایک عملی رہنما بنانا چاہتا ہوں تاکہ وہ صارف کی کہانیوں کے لیے قبولیت کے معیار لکھنے میں آسانی پیدا کر سکیں تاکہ ان کی پیداوار اسکروم ٹیم کے لیے کارآمد ثابت ہو۔’

“میں سائٹ پر صارفین کی توثیق کے لیے لاگ ان صفحہ چاہتا ہوں۔”

یہی پورا تقاضا تھا۔ پروڈکٹ کے مالک کی طرف سے ایک لائن، ابتدائی دریافت میں۔ جب تک ہم بات ختم کر چکے تھے، یہ ایک مہاکاوی تھا۔.

آپ کو صفحہ کے بعد صفحہ ملے گا جس میں وضاحت کی جائے گی کہ قبولیت کے معیار کیا ہیں اور ایک اچھے سیٹ میں کیا شامل ہونا چاہیے۔ یہ پوسٹ ان میں سے کوئی اور نہیں ہے۔ یہ ایک طریقہ ہے a مصنوعات کے مالک اصل میں پیروی کر سکتے ہیں: ترتیب میں سات مراحل، پھر وہ لاگ ان صفحہ ان میں سے ہر ایک سے گزرا۔.

صارف کی کہانیوں کے لیے قبولیت کے معیار کیا ہیں؟

قبولیت کا معیار پاس یا فیل کے بیانات ہیں جو فیصلہ کرتے ہیں کہ آیا صارف کی کہانی مکمل کی گئی ہے۔ ہر ایک کہتا ہے کہ صارف کو کیا کرنے کے قابل ہونا چاہیے، سادہ الفاظ میں، اور ٹیم پر چھوڑ دیتا ہے۔ ہر بیان مل جاتا ہے، یا کہانی نہیں مانی جاتی۔ (اگر آپ صارف کی کہانیوں میں نئے ہیں،, یہاں سے شروع کریں.)

کوئی جزوی قبولیت نہیں ہے۔.

قبولیت کے معیارات کس کو لکھنے چاہئیں؟

پروڈکٹ کا مالک۔ وہ وہ شخص ہیں جو کہانی کو قبول کرے گا، یا نہیں، لہذا وہ وضاحت کرتے ہیں کہ قبولیت کیسی نظر آتی ہے۔ سکرم ٹیم سہولت فراہم کر سکتی ہے۔ ذمہ داری پروڈکٹ کے مالک کے ساتھ رہتی ہے۔.

یہ دونوں راستے کاٹتا ہے۔ معیار بھی ٹیم کے لیے قابل قبول ہونا چاہیے، اور اگر وہ نہیں ہیں، تو وہ مقصد کے لیے موزوں نہیں ہیں۔ انہیں لکھنا پروڈکٹ کے مالک کا کام ہے۔ ان سے اتفاق کرنا ایک ٹیم کی سرگرمی ہے۔.

تعاون، ہاتھ سے نہیں.

کیوں Gherkin پروڈکٹ اونرز کے لیے صحیح ٹول نہیں ہے

آپ کو پوسٹ کے بعد ایسی پوسٹ بھی ملے گی جس میں پروڈکٹ کے مالکان کو قبولیت کا معیار لکھنے کے لیے کہا گیا ہو۔ گرکن‘دیا گیا ہے، کب، پھر۔ میری رائے میں یہ دو وجوہات کی بنا پر عملی نہیں ہے۔.

سب سے پہلے، بہت سے مصنوعات کے مالکان نہیں جانتے ہیں گرکن, ، اور ٹیم اس میں سادہ بیانات کا ترجمہ کرنے کے لیے کہیں بہتر ہے۔ اس ترجمے کی حقیقی قدر ہے: ٹیم کو ٹیسٹ اسکرپٹس میں تبدیل کرنے کے لیے معیارات کا تجزیہ کرنا ہوگا۔ اور پروڈکٹ کا مالک فطری زبان میں مقصد کے لیے فٹنس کی وضاحت کے لیے بہت تیزی سے کام کرتا ہے۔.

دوسرا، کسی بھی اسکرپٹڈ فارمیٹ پر اصرار کرنا نسخہ ہے، اور یہ عملییت اور عقل پر مبنی فرتیلی نقطہ نظر کے خلاف ہے۔ یہ نہ سمجھیں کہ آپ کے پروڈکٹ کا مالک اسکرپٹ کر سکتا ہے۔.

فارمیٹ مسئلہ نہیں ہے۔ جس کے پاس قلم ہے۔.

پروڈکٹ کے مالک کو قبولیت کے معیار کا کون سا فارمیٹ استعمال کرنا چاہیے؟

سادہ پاس یا فیل اسٹیٹمنٹس، فی لائن ایک۔ اگر آپ کی ٹیم Gherkin میں منظرنامے لکھتی ہے، تو انہیں ترجمہ کرنے دیں۔ آپ کا کام کیا ہے. ان کا طریقہ ہے۔.

قبولیت کے معیار کب طے ہونے چاہئیں؟

اس سے پہلے کہ کہانی تیار ہو جائے۔ قبولیت کے معیارات آپ کی ڈیفینیشن آف ریڈی (DoR) کا حصہ ہیں: ان کے بغیر کہانی تکنیکی خرابی یا تخمینہ کے لیے تیار نہیں ہے۔.

قبولیت کا کوئی معیار نہیں، کوئی "تیار" نہیں۔.

صارف کی کہانیوں کے لیے قبولیت کا معیار کیسے لکھا جائے: سات مراحل

ترتیب میں ان کے ذریعے کام کریں. ہر ایک اگلے کو کھلاتا ہے۔.

1. پروڈکٹ کے مالک کے اپنے الفاظ میں مطلوبہ کو لکھیں۔. ایک جملہ، غیر پولش۔ اسے حل میں تبدیل کرنے کی مزاحمت کریں۔ ٹیم آپ میں سے کسی کی تلاش نہیں کر رہی ہے۔.
2. اس کا خاکہ بنائیں۔. ایک وائر فریم، اسکرین گریب، رومال پر ایک ڈرائنگ۔ ایک تصویر اس گنجائش کو ظاہر کرتی ہے کہ ایک جملہ چھپاتا ہے۔ اگر کہانی ڈیٹا دکھاتی ہے، تو کالموں کا خاکہ بنائیں اور آپ انہیں کیسے ترتیب دیں گے۔ اگر یہ ڈیٹا حاصل کرتا ہے تو، کھیتوں کا خاکہ بنائیں۔.
3. بیانات کا مسودہ تیار کریں۔. ایک فی سطر، آخری صارف کے نقطہ نظر سے: "میں کر سکتا ہوں"، "میں دیکھ رہا ہوں"۔ فنکشن، مستثنیات (جب یہ غلط ہو جاتا ہے تو کیا ہوتا ہے) اور غیر فعال ضروریات کا احاطہ کریں۔ کیا ڈیٹا حساس ہے؟ کیا اسے ریئل ٹائم ہونے کی ضرورت ہے؟ اسے کتنی جلدی جواب دینا چاہیے؟ فارم کے لیے، بتائیں کہ ہر فیلڈ کیا قبول کرتا ہے، کیا رد کرتا ہے اور توثیق کے اصول۔.
4. ہر بیان کی جانچ کریں۔. کیا ٹیسٹر اسے پڑھ کر ہاں یا نہیں میں جواب دے سکتا ہے؟ "ایک مناسب غلطی کا پیغام" اس ٹیسٹ میں ناکام ہوجاتا ہے۔ "میں ایک پیغام دیکھ رہا ہوں جس میں بتایا گیا ہے کہ میری تفصیلات غلط ہیں" پاس۔ کسی بھی چیز کو دوبارہ لکھیں جو پاس یا ناکام نہیں ہوسکتا ہے۔.
5. طریقہ نکال دیں۔. ہر بیان کے لیے، پوچھیں: کیا یہ کوئی نتیجہ ہے یا حل؟ "سائٹ بوٹس سے محفوظ ہے" ایک نتیجہ ہے۔ "میں ایک کیپچا دیکھ رہا ہوں" ایک حل ہے، اور ٹیم کے پاس اس سے بہتر ہوسکتا ہے۔.
6. کہانی سے بڑی کسی بھی چیز کو تقسیم کریں۔. اگر کسی بیان کو اپنی اسکرین، سفر یا کاروباری قواعد کی ضرورت ہے، تو یہ صارف کی ایک اور کہانی ہے۔ اسے لکھیں اور اسے بیک لاگ میں منتقل کریں۔ دروازہ اس کہانی کا ہے۔ اس کے پیچھے والا کمرہ ایسا نہیں کرتا۔.
7. ٹیم کے ساتھ اس سے اتفاق کریں، پھر اسے تیار نشان زد کریں۔. ٹیم اور صارف کے اختتامی نمائندے کو معیار کے مطابق چلائیں۔ بات چیت ایک اہم جزو ہے۔ ایک بار جب ہر کوئی اس کی جانچ کر سکتا ہے، تو یہ آپ کی تیار کی تعریف پر پورا اترتا ہے۔.

خندق سے ایک کہانی: لاگ ان صفحہ، قدم بہ قدم

مرحلہ 1: خواہش۔. ہمارے پروڈکٹ کے مالک کی ضرورت، دریافت کے اوائل میں، یہ تھی: "میں سائٹ پر صارفین کی تصدیق کے لیے ایک لاگ ان صفحہ چاہتا ہوں۔" لہذا ہماری صارف کی کہانی ایک سادہ سی تھی: "بطور صارف میں لاگ ان صفحہ سے سائٹ میں سائن ان کرنا چاہتا ہوں تاکہ صارفین کی تصدیق کی جا سکے۔"“

مرحلہ 3: پہلا مسودہ۔. پھر ہم نے گہرے ڈوبکی گفتگو کا آغاز کیا: تو آپ کی قبولیت کے معیار کیا ہیں؟ یہ وہی ہے جو ہمیں ملا ہے:

• کسی بھی صفحے سے، سائن ان لنک کے ذریعے لاگ ان صفحہ تک رسائی حاصل کرنے کے قابل ہوں۔.
• جب میں ‘سائن ان’ لنک پر کلک کرتا ہوں، تو مجھے لاگ ان صفحے پر بھیج دیا جاتا ہے جہاں میں تصدیق کے لیے اپنا ای میل اور پاس ورڈ درج کر سکتا ہوں۔.
• ناکام لاگ ان پر، مجھے ہوم پیج پر ری ڈائریکٹ کیا جاتا ہے۔.
• ہوم پیج پر، میرا پہلا نام اوپر دائیں کونے میں، میرے آخری لاگ ان کی تاریخ اور وقت کے ساتھ دکھایا گیا ہے۔.
• میرے اکاؤنٹ سے لاگ ان کرنے کی تین بار ناکام کوشش کے بعد مجھے لاک کر دیا جانا چاہیے اور پھر مجھے اپنا اکاؤنٹ کھولنے کے لیے پاس ورڈ دوبارہ سیٹ کرنا ہوگا۔.
• میرے پاس ورڈ کو محفوظ پاس ورڈ کے لیے کمپنی کی پاس ورڈ پالیسی پر عمل کرنے کی ضرورت ہے۔.
• مجھے پاس ورڈ ری سیٹ کرنے کی سہولت دینے والا ایک لنک بھی دیکھنا ہوگا۔.
• مجھے رجسٹریشن کے لیے ایک لنک بھی دکھانا ہوگا اگر میں نیا صارف ہوں۔.

نوٹ کریں کہ ہم سیدھے مرحلہ 1 سے مرحلہ 3 تک گئے ہیں۔ خاکہ کو چھوڑنا سب سے عام شارٹ کٹ ہے، اور آپ پہلے ہی دیکھ سکتے ہیں کہ اس کی قیمت کیا ہے: ایک پوری سائٹ کا لنک، ایک ذاتی ہوم پیج، پاس ورڈ ری سیٹ اور رجسٹریشن سبھی سائن ان کہانی میں شامل ہو گئے تھے۔.

مرحلہ 2: خاکہ، دیر سے۔. اسکوپ بیلون کو دیکھنے کے بعد، ہم نے اپنے پروڈکٹ کے مالک سے وائر فریم کا خاکہ بنانے کو کہا۔ ہمیں یقین تھا کہ مزید ابھریں گے۔ یہ کیا.

وائر فریم جس نے پوشیدہ گنجائش ظاہر کی

ہمارے پروڈکٹ اونر کی طرف سے خاکہ بنایا گیا تار کا فریم۔.

خاکے نے اس بات کی تصدیق کی کہ پہلا مسودہ پہلے ہی کیا پھسل چکا تھا (ایک سائن ان بٹن جس پر "ہر صفحے پر" نشان لگا ہوا ہے، پاس ورڈ کو دوبارہ ترتیب دینے اور رجسٹر کرنے کے لیے لنکس) اور دو مزید شامل کیے گئے۔ ایک "میں روبوٹ نہیں ہوں" کا چیک باکس۔ اور، ای میل فیلڈ کے ساتھ سرخ قلم میں، "TFA اگر سیٹ اپ ہے": دو عنصر کی تصدیق، ہر اس شخص کے لیے جس نے اسے آن کیا ہے۔.

آرڈر کے معاملات۔.

مرحلہ 4 سے 6: ٹیسٹ، پٹی، تقسیم۔. اگلے تین مراحل کے ذریعے پہلا مسودہ چلائیں، ایک وقت میں ایک لائن، اور یہ وہی ہے جو آتا ہے:

• پوری سائٹ پر سائن ان کا لنک ہر صفحے پر نیویگیشن تبدیلی ہے۔ تقسیم.
• ہوم پیج پر پہلا نام اور آخری لاگ ان ہوم پیج کی خصوصیت ہے۔ تقسیم.
• پاس ورڈ کی پالیسی اس وقت چیک کی جاتی ہے جب پاس ورڈ سیٹ کیا جاتا ہے، نہ کہ جب کوئی سائن ان کرتا ہے۔ اس کا تعلق رجسٹریشن اور پاس ورڈ ری سیٹ سے ہے۔ تقسیم.
• پاس ورڈ کو دوبارہ ترتیب دینے اور قیام کو رجسٹر کرنے کے لنکس۔ دروازہ اس کہانی کا ہے۔ ری سیٹ اور رجسٹریشن کا سفر نہیں ہوتا ہے۔.
• کچھ نہیں کہتا کہ کیا ہوتا ہے جب کسی کو ان کی تفصیلات غلط ہو جاتی ہیں۔ اسے شامل کریں، اور اسے لکھیں تاکہ ٹیسٹر اسے پاس یا ناکام کر سکے۔.

مرحلہ 7: اس سے اتفاق کریں۔. ہمارے پروڈکٹ کے مالک اور ٹیم کے ساتھ بات چیت نے صارف کی اضافی کہانیوں کی نشاندہی کی جن کی ہمیں ضرورت تھی، اور اصل کہانی کے معیار کو صرف اس کہانی سے منسلک رکھا۔.

نظرثانی شدہ صارف کی کہانی اور اس کے قبولیت کے معیار

صارف کی کہانی: “"ایک رجسٹرڈ صارف کے طور پر، میں اپنے ای میل ایڈریس اور پاس ورڈ کے ساتھ سائن ان کرنا چاہتا ہوں تاکہ میں صرف اراکین کے لیے پریمیم مضامین پڑھ سکوں۔"”

دیکھیں کہانی بھی بدل گئی ہے۔ اصل کا "تاکہ" سائٹ کا مقصد تھا، صارف کا نہیں، اور اس نے حل کا نام دیا: ایک لاگ ان صفحہ۔ خواہش وہی ہے۔ کس کا فائدہ منتقل ہو گیا ہے۔.

اس کے قبولیت کے معیار:

• سائن ان پیج پر میں اپنا ای میل ایڈریس اور پاس ورڈ درج کر کے جمع کر سکتا ہوں۔.
• ایک درست ای میل ایڈریس اور پاس ورڈ کے ساتھ، میں سائن ان ہوں اور ہوم پیج پر لے جایا گیا ہوں۔.
• غلط ای میل ایڈریس یا پاس ورڈ کے ساتھ، میں سائن ان صفحہ پر رہتا ہوں اور ایک پیغام دیکھتا ہوں جس میں مجھے بتایا گیا کہ میری تفصیلات غلط ہیں۔.
• تین ناکام کوششوں کے بعد، میرا اکاؤنٹ مقفل ہو گیا ہے اور میں اسے صرف اپنا پاس ورڈ دوبارہ ترتیب دے کر ان لاک کر سکتا ہوں۔.
• میں اپنا پاس ورڈ دوبارہ ترتیب دینے کے لیے ایک لنک دیکھ سکتا ہوں۔.
• میں ایک نئے صارف کے طور پر رجسٹر کرنے کے لیے ایک لنک دیکھ سکتا ہوں۔.

چھ بیانات۔ ہر ایک پاس ہوتا ہے یا فیل ہوتا ہے۔.

اس میں تقسیم ہونے والی کہانیاں:

نئی صارف کی کہانی	جہاں سے آیا تھا۔
ہر صفحے پر سائن ان لنک	پہلا مسودہ، معیار 1
پہلا نام اور آخری لاگ ان کے ساتھ ہوم پیج سلام	پہلا مسودہ، معیار 4
پاس ورڈ ری سیٹ، بشمول پاس ورڈ پالیسی	پہلا مسودہ، معیار 6 اور 7
نیا صارف رجسٹریشن، بشمول پاس ورڈ پالیسی	پہلا مسودہ، معیار 6 اور 8
بوٹس سے سائن ان کی حفاظت کرنا	وائر فریم ("میں روبوٹ نہیں ہوں")
دو عنصر کی توثیق، جہاں صارف نے اسے ترتیب دیا ہے۔	وائر فریم ("TFA اگر سیٹ اپ ہو")

کہانی اب ایک ہی سپرنٹ کے اندر آزاد، قابل گفت و شنید، قابل قدر، اندازے کے مطابق، چھوٹی اور قابل آزمائش ہے۔ یہ ایک صارف کی کہانی ہے، ہمارے پروڈکٹ کے مالک کے اصل وائر فریم کی نمائندگی کرنے والی مہاکاوی نہیں۔.

منظور شدہ معیارات کو یوزر اسٹوری کے دائرے میں رکھیں

“"قبولیت کے معیار کو صارف کی کہانی کے دائرہ کار سے باہر نہیں جانا چاہئے۔ اگر وہ ایسا کرتے ہیں، تو اضافی صارف کی کہانیوں کو پکڑنے کی ضرورت ہے جو خصوصیت 'چاہتے ہیں' کی وضاحت کرتی ہے۔"‘

اچھی طرح سے سوچا ہوا قبولیت کا معیار آپ کو اصل دائرہ کار اور ابھرتی ہوئی گنجائش دکھاتا ہے۔ وہ پروڈکٹ کے مالک کے ساتھ ایک معاہدہ بھی بناتے ہیں جس کا مطلب مکمل اور قابل قبول ہے۔.

لاگ ان صفحہ کو مزید معیار کی ضرورت نہیں تھی۔ اسے کم، اور مٹھی بھر نئی کہانیوں کی ضرورت تھی۔.

اسکرپٹ نہیں۔ تقریب نہیں۔ ایک نظم و ضبط والی گفتگو جو ایک مبہم خواہش کو کسی ایسی چیز میں بدل دیتی ہے جو اسکرم ٹیم بنا، جانچ اور قبول کر سکتی ہے۔.

تو میرا سوال یہ ہے، اور میں حقیقی طور پر اس کا جواب چاہوں گا: جب آپ کی ٹیم میں کوئی کہانی غبارے بنتی ہے، تو سب سے پہلے کون نوٹس کرتا ہے؟ سپرنٹ کے اختتام پر پروڈکٹ کا مالک، ٹیم، یا ٹیسٹر؟

خوشحالی کے ذریعے امن کی حمایت

اگر آپ کو میرے اشتراک کردہ مواد سے کوئی فائدہ ہوا ہے تو براہ کرم تعاون کرنے پر غور کریں۔ خوشحالی کے ذریعے امن — آپ کر سکتے ہیں پیروی کرو کام، مدد براڈکاسٹ یہ، یا عطیہ.

امن خوشحالی کے ذریعہ (PTP) تنازعات سے متاثرہ جغرافیوں میں خوشحالی کو فروغ دے کر امن کے لیے مقامی اور اندرونی ماحول کو بہتر بناتا ہے۔ ہم غربت کے خاتمے اور انتہا پسندی کی روک تھام کے لیے کام کرتے ہیں، مائیکرو کاروباریوں کو علم، ہنر اور اپنی آمدنی اور مواقع تک رسائی بڑھانے کی صلاحیت سے بااختیار بناتے ہیں۔ ہم معاشرے میں کمزور اور پسماندہ افراد اور گروہوں کی ملکیت اور ان کے زیر انتظام چھوٹے کاروباروں کی حمایت کرتے ہیں۔ PTP ‘خطرے میں’ کمیونٹیز میں کم لاگت، فوری اور دیرپا اثر والے سماجی ترقیاتی پروگرام بنانے اور پہنچانے کے لیے Agile اصولوں اور طریقوں کا استعمال کرتے ہوئے سماجی تبدیلی کے ڈیزائن اور فراہمی میں جدت لا رہا ہے۔.