مستندسازی از یک بریف
از lore:brief-to-doc زمانی استفاده کنید که ورودی‌تان الزامات نوشته‌شده است: یک بریف محصول، PRD، اپیک، یوزر استوری، یا توضیح فیچر، به‌شکل متن یا فایل.
lore:brief-to-doc <brief-text-or-file>
چه می‌کند
- بریف را سرتاسر می‌خواند و هر یوزر استوری و معیار پذیرش را استخراج می‌کند، و شکاف‌ها و ابهام‌ها را از همان ابتدا شناسایی می‌کند. منابع مورد اعتماد پیکربندی‌شده را هم واقعاً واکشی می‌کند و برای مطالب مربوط به فیچرهای در محدوده جست‌وجو می‌کند، و یافته‌های هر منبع را در یک سرشماری منبع قابل حسابرسی ثبت می‌کند: هر سطر با رسیدی پشتش، تا منبعی که هرگز باز نشده نتواند به‌عنوان «چیز مرتبطی نداشت» ثبت شود. هر چیزی که در گفت‌وگو خواسته‌اید پیش از شروع خواندن به‌صورت یک سطر شماره‌دار نوشته می‌شود، و تا وقتی یکی از آن‌ها باز باشد اجرا تحویل نمی‌شود.
- سؤال‌های شفاف‌ساز می‌پرسد هرجا که رفتار، قواعد، حالت‌های مرزی یا پیام‌های دقیق مشخص نشده‌اند. این پرسش‌ها محدود به چند موردِ پراثرند، و مابقی به‌جای دیوار بی‌پاسخ سؤال، به نشانگرهای صریح تبدیل می‌شوند.
- سناریوها را از یوزر استوری‌ها استنتاج می‌کند و «به‌عنوان [نقش]، می‌خواهم [اقدام]، تا [فایده]» را به یک سناریوی کامل با هدف، پیش‌شرط‌ها، جریان و پس‌شرط‌ها تبدیل می‌کند. معیارهای Gherkin به‌شکل ساختاری نگاشت می‌شوند: Given ← پیش‌شرط‌ها، When/Then ← یک گام جریان و واکنش سیستم، و نتایج شکست ← extensionها.
- تاکسونومی حالت‌های مرزی را می‌پیماید. هر سناریو در برابر دسته‌های حالت‌مرزی قالب مستندسازی (حالت‌های خالی، مرزها، بارگذاری، همروندی، دسترسی‌ها، …) بررسی می‌شود؛ دسته‌ای که بریف به آن نپرداخته، به یک پرسش هدفمند یا یک نشانگر صریح تبدیل می‌شود، نه یک فلوی اختراعی. هرکدام در فهرست حالت‌هایی که باید طراحی شود (پایین‌تر) هم می‌نشیند.
- معیارهای پذیرش را به قواعد کسب‌وکار صریح تبدیل می‌کند و زبان مبهم را شفاف می‌سازد. یک معیار ذهنی مثل «سریع» یا «تجربه‌ی خوب» هرگز بی‌سروصدا به‌عنوان قاعده پذیرفته نمی‌شود؛ با یک صورت‌بندی قابل‌سنجش پیشنهادی علامت‌گذاری می‌شود.
- اعتبارسنجی و گزارش، شامل یک لاگ از هر ابهامی که مطرح شده.
فهرست حالت‌هایی که دیزاینر باید طراحی کند
بریف مسیر خوشبینانه را شرح می‌دهد و بقیه را ضمنی می‌گذارد، یعنی همان حالت‌هایی که کسی به آن‌ها فکر نکرده، دیر و یکی‌یکی از راه گزارش باگ به دیزاینر می‌رسند. برای همین سند با جدول حالت‌هایی که باید طراحی شود تمام می‌شود: همه‌ی حالت‌هایی که این فیچر لازم دارد، در یک فهرست تخت، با وضعیتی که می‌گوید هرکدام چه جنس کاری است.
| وضعیت | یعنی چه |
|---|---|
| مشخص‌شده، نیازمند طراحی | بریف گفته چه اتفاقی می‌افتد. کسی طراحی‌اش نکرده. یک کار طراحی، همین. |
| نامشخص، نیازمند تصمیم و طراحی | بریف ساکت است. اول باید کسی رفتار را تصمیم بگیرد؛ پرسش متناظر در فلو، همین شکاف است از سمت دیگر. |
| طراحی‌شده | این حالت در طراحی وجود دارد. فهرست شده تا جدول کل تصویر را نشان دهد، نه فقط سوراخ‌ها را. |
یک شکاف عمداً دو بار می‌آید، چون دو نفر به آن نیاز دارند: یک‌بار داخل سناریو سر همان گامی که به آن مربوط است، برای کسی که فلو را می‌خواند؛ و یک‌بار به‌صورت ردیف در این جدول، برای دیزاینری که چک‌لیست می‌خواهد بی‌آنکه همه‌ی سناریوها را دوباره بخواند. دسته‌ای که واقعاً مصداق ندارد ردیف نمی‌گیرد، چون پر کردن فهرست با «نامرتبط» همان کاری است که باعث می‌شود آدم‌ها دیگر نخوانندش.
این حدس‌زدن محصول شما نیست. نام‌بردن حالتی که باید طراحی شود، با اختراع اینکه محصول در آن حالت چه می‌کند یکی نیست: جدول موقعیت را نام می‌برد، نه واکنش را. آنجا که واکنش نامعلوم است، دقیقاً همان چیزی است که وضعیت نامشخص ثبت می‌کند.
به شما می‌گوید کی یک بریف آماده نیست
اگر بریف فاقد ملزومات اساسی‌اش باشد (معیارهای پذیرش، پرسوناها و نقش‌ها، یا اظهارات خارج از محدوده)، اسکیل پیش از نوشتن این را می‌گوید، هشدار می‌دهد که خروجی در آن نواحی پر از نشانگر جای‌خالی خواهد بود، و فقط با تأیید صریح شما ادامه می‌دهد. هرگز بی‌سروصدا از یک بریف ناآماده سند تولید نمی‌کند.
آنچه گفته شده را مستند کن، آنچه نگفته را علامت بزن
یک بریف جزئیات بصری ندارد، پس انتظار داشته باشید نشانگرهای [CLARIFICATION NEEDED: …] بیشتری نسبت به یک اجرای مبتنی بر طراحی ببینید. این اسکیل الزامات گفته‌شده را مستند می‌کند و هرگز فیچری اختراع یا رفتاری فرض نمی‌کند. هرجا چیزی غایب باشد:
- به یک الگوی موجود و قبلاً مستندشده ارجاع می‌دهد،
- رفتار را توصیف می‌کند نه ظاهر را، یا
- وقتی جزئیات حیاتی است، یک ماک‌آپ درخواست می‌کند.
سؤال‌های بی‌پاسخ زیر پرسش‌های معلق در گزارش نهایی جمع می‌شوند، تا چیزی بی‌سروصدا از قلم نیفتد.