معرفی Example Mapping

قبل از اینکه یک یوزر استوری وارد چرخه تولید و توسعه شود لازمه که گفتگویی صورت بگیره حول شناخت و شفاف سازی مساله و ملاک های پذیرش آن.

برخی تیم های Scrum محور این فرایند و پردازش در جلسات backlog refinement یا planning poker انجام می دهند و برخی در ورک شاپ های شناخت و کشف (specification workshop یا discovery workshop)

برخی این جلسات را ناکارآمد ، سخت ، بدون ساختار و کسل کننده و درنهایت بدون هیچ خروجی مطلوب متناسب با هدف می دانند.

اما Example Mapping چگونه کار میکنه؟

در واقع مثال های عینی راه های فوق العاده برای کشف و شناخت دامنه و مساله مورد بحث و یک پایه خوبی از مساله واقعی عرضه می کند و هر چه بیشتر در مورد آن بحث شود شناخت بیشتر و مسائل بیشتری کشف می شوند. در واقع Example Mapping تشکیل شده است از :

قواعد یا Rule ها که خلاصه ی دسته ای از مثال ها یا examples هستند و یا محدودیت هایی را در مورد محدوده داستان یا Scope بیان می کنند.
سوالات در مورد سناریو ها که هیچ کسی در مورد آن چیزی نمی داند یا فرضیات که ما در نظر میگیریم.
یوزر استوری های جدید که ما خارج از محدوده یا Scope مورد نظر کشف می کنیم.

در Example Mapping از بسته 4 تایی کارت های رنگی و نوشته های روی آن ها که اطلاعات مورد نظر را در مورد کارت انتقال می دهند. و در حین صحبت ها این کارت ها در یک نقشه یا Map مرتب می شوند.

ما با نوشتن داستان مورد بحث روی یک کارت زرد رنگ در بالای کارت ها شروع می کنیم.

در مرحله بعد، هر یک از معیارهای پذیرش، یا قوانینی Ruleها را که قبلاً می‌دانیم، روی یک کارت آبی می‌نویسیم و آن‌ها را روی جدول زیر کارت داستان زرد قرار می‌دهیم.

برای هر قانون، ممکن به یک یا چند مثال برای توضیح آن نیاز داشته باشیم. آن ها را روی کارت sfc می نویسیم و تحت قانون مربوطه قرار می دیم.

همانطور که در مورد این مثال ها بحث می کنیم، ممکن سوالاتی را کشف کنیم که هیچ کس در اتاق نمی تواند به آنها پاسخ دهد. اون ها رو روی کارت قرمز مینویسیم و به گفتگو ادامه می دهیم.

ادامه می دهیم تا زمانی که گروه به این نتیجه برسند که دامنه داستان مشخص است یا وقت جلسه تمام شده.

بازخورد فوری

همانطور که مکالمه جریان دارد، ما به سرعت یک نمایش بصری روی میز جلوی خود ایجاد می کنیم که درک فعلی ما از داستان را منعکس می کند:

جدولی که با کارت های قرمز رنگ (سوالی) پوشانده شده است به ما می گوید که هنوز چیزهای زیادی برای یادگیری درباره این داستان داریم.
جدولی که با کارت های آبی (قاعده) پوشانده شده است به ما می گوید که این داستان بزرگ و پیچیده است. شاید بتوانیم آن را برش دهیم؟ یک کارت زرد (داستانی) دیگر بردارید و داستان برش خورده را در قسمت عقب مانده قرار دهید.
یک قانون با مثال های زیاد ممکن است بیش از حد پیچیده باشد. آیا قوانین متعددی در بازی وجود دارد که باید از هم جدا شوند؟

متوجه خواهید شد که برخی از قوانین آنقدر واضح هستند که اصلاً نیازی به مثال ندارید. از گفتگو مشخص است که همه این قانون را درک می کنند. عالی! همه شما می توانید بدون اینکه خود را مجبور کنید نمونه هایی مانند خودکارهای شستشوی مغزی BDD را به کار بگیرید، به زندگی خود ادامه دهید.

فکر کردن در درون جعبه زمان

گروه کوچکی از همکاران باید بتوانند یک داستان کاملاً درک شده و با اندازه خوب را در حدود 25 دقیقه ترسیم کنند.

اگر نمی توانید، یا هنوز در حال انجام این کار هستید (که خوب است)، داستان خیلی بزرگ است (قطعا خوب نیست)، یا هنوز عدم اطمینان زیادی در آن وجود دارد. به آن گوش دهید، و یا سعی کنید داستان را برش دهید، یا اجازه دهید مدیر محصول برود و روی آن کار کند ، قبل از اینکه داستان در جلسه مطرح شود در تاریخ جلسه بعدی آن را بازگردانید.

فواید

فرایند Example Mapping به شما کمک می کند کلی نگری کنید و روی کوچکترین رفتارهای درون داستان خود تمرکز کنید. با ترسیم آن می توانید قوانین را از هم جدا کنید، هسته رفتاری را که می خواهید پیدا کنید و بقیه را به بعد موکول کنید. با این سطح از بررسی دقیق، نقشه‌برداری نمونه مانند یک فیلتر عمل می‌کند و از ورود داستان‌های بزرگ به سرعت شما و انفجار با شگفتی‌های لحظه آخری سه روز قبل از روز نمایشی جلوگیری می‌کند.

همچنین باعث صرفه جویی در زمان می شود و به حفظ علاقه افراد پرمشغله به این فرآیند کمک می کند.

بسیاری از تیم‌ها فرض می‌کنند که سه همکار باید در طول این جلسه تست‌های پذیرش (مثلاً سناریوها) را بنویسند، دور یک پروژکتور بنشینند در حالی که شخصی سناریوهای رسمی Gherkin را در یک IDE تایپ می‌کند. طرز فکری وجود دارد که این با ارزش است، اما به طور کلی فکر می کنم ایده بدی. در واقع می تواند تمرکز را از هدف واقعی گفتگو منحرف کند.

به راحتی می توان فهمید که چرا مردم مرتکب این اشتباه می شوند: هدف ظاهری این است که یک داستان کاربر را که قبلاً دارای معیارهای پذیرش از پیش تعریف شده است، در نظر بگیرید و مثال هایی ارائه کنید که می توانند به آزمون های پذیرش تبدیل شوند.

با این حال، من فکر می‌کنم هدف واقعی دستیابی به یک درک مشترک از آنچه برای انجام داستان لازم است، است. شما می توانید با حفظ فناوری پایین، خیلی سریعتر به سمت این هدف حرکت کنید.

قسمت های همکاران

بنابراین به جای اینکه به سراغ سناریوهای رسمی و کامل Gherkin بروید، فقط سعی کنید فهرستی از نمونه های تقریبی را با استفاده از قرارداد نامگذاری قسمت همکار تهیه کنید.

مثلا :

جایی که مشتری رسیدش را فراموش کرده بود.
جایی که محصول آسیب دیده است.
محصولی که 15 روز پیش از آن خریداری شده است.

گاهی اوقات، وقتی عدم اطمینان در کمین است، به طور غریزی می خواهید واضح تر از این باشید. هنوز لازم نیست به ساختار سفت و سخت Given When Then متوسل شوید:

وقتی نتیجه (سپس) نامشخص است، شما یک مثال ندارید، یک سوال دارید.

مجهولات شناخته شده

هر زمان که مکالمه ای مانند این در دایره می چرخد، به این دلیل است که شما اطلاعات کافی ندارید. احتمالاً شخصی در مکالمه گم شده است، یا شاید شما نیاز به تحقیق در مورد کاربر داشته باشید، یا یک مکالمه انجام دهید.

به جای اینکه به همه اجازه دهید نظر خود را در مورد اینکه فکر می کنند نتیجه باید چه باشد به اشتراک بگذارند، به سادگی سؤال را در نظر بگیرید و ادامه دهید. تبریک می گویم! شما به تازگی یک ناشناخته را به یک ناشناخته شناخته شده تبدیل کرده اید. این پیشرفت بزرگی است.

بسیاری از مردم می‌گویند که فقط همین یک جنبه از نقشه‌برداری نمونه کارگاه‌های اکتشاف آنها را از مسابقات کسل‌کننده رامبل آتون‌ها به ترکیب‌های ذهنی مولد سریع تبدیل کرده است.

کی باید بیاد؟

حداقل سه همکار: یک توسعه دهنده، یک آزمایش کننده و یک مدیر محصول. این فقط یک حداقل است. به هر حال از عملیات خود، افراد تجربه کاربری یا هر کس دیگری که با داستان مورد بحث مرتبط است دعوت کنید. هر کسی که احتمالاً به شما کمک می کند تا سؤالات جدیدی را کشف کنید، یا سؤالات را به تصمیم گیری در طول مکالمه تبدیل کنید، مفید خواهد بود.

در حالی که شما در حال یادگیری این تکنیک هستید، داشتن یک نفر در نقش رسمی تسهیل کننده، که وظیفه او این است که مطمئن شود همه چیزهایی که گفته می شود در یک کارت ثبت شده است، می تواند کمک کند. مثال‌ها و سؤال‌ها به سرعت در اتاق پرواز می‌کنند، و ثبت آنها روی میز نظم و انضباط لازم دارد تا بتوانید ببینید در مورد چه چیزی صحبت می‌کنید.

هر چند وقت یک بار باید این کار را انجام دهیم؟

مدیران محصول اغلب مشغول هستند. با برنامه ریزی این جلسات به گونه ای به وقت آنها احترام بگذارید تا بتوانند تمام توجه خود را به شما معطوف کنند.

توصیه من، بر اساس آنچه که در عمل برای چندین تیم کار کرده ام، این است که آنها را به طور مکرر اجرا کنید: یک روز در میان اغلب ریتم خوبی است. فقط یک داستان را انتخاب کنید و 25 دقیقه به آن توجه کنید، سپس به کار خود بازگردید. تلاش برای انجام کارهای بیشتر در یک دسته بزرگ فقط انرژی شما را تخلیه می کند.

اما تیم من توزیع شده است!

من قبلاً هک‌های نوآورانه‌ای را در این مورد دیده‌ام: برخی از افراد از لیست‌های گلوله در یک سند مشترک Google استفاده می‌کنند، من افرادی را دیده‌ام که از صفحه‌گسترده با سلول‌های رنگی برای نشان دادن کارت‌ها استفاده می‌کنند. همچنین می توانید از نقشه ذهنی استفاده کنید. نکته کلیدی این است که کار با آن سریع و آسان باشد تا بتوانید روی مکالمه تمرکز کنید.

چند نکته نهایی

قبل از اینکه بتوانید از Example Mapping استفاده کنید، مهم است که به وضوح تمایز بین قوانین و مثال ها را درک کنید. من یک تمرین سرگرم کننده برای آموزش این دارم که در پست بعدی به اشتراک خواهم گذاشت.

به یاد داشته باشید که تمام هدف این گفتگو کشف چیزهایی است که قبلاً نمی دانید. بنابراین هیچ سوال احمقانه ای وجود ندارد. کمی لذت ببرید و واقعا مشکل را بررسی کنید.

متوجه خواهید شد که قوانین خطوط گسل طبیعی را برای برش داستان شما ایجاد می کنند. سعی کنید تا حد امکان به تعویق انداختن آن احساس راحتی کنید تا بتوانید روی حل اصلی مشکل تمرکز کنید. بعداً می توانید پیچیدگی (و پیچیدگی) بیشتری اضافه کنید.