کارت خوب چه شکلی است: تسکی بنویسید که کسی نپرسد یعنی چه

عنوان کارت این است: «درست کردن صفحهٔ ورود». برنامه‌نویس فکر می‌کند منظور باگ دکمهٔ ورود است، طراح فکر می‌کند قرار است صفحه از نو طراحی شود و مدیر محصول منظورش اضافه کردن ورود با کد پیامکی بود. سه روز بعد، هر سه نفر روی سه چیز متفاوت کار کرده‌اند و تازه در جلسه معلوم می‌شود.

کارت مبهم وقت کسی را نمی‌گیرد که آن را می‌نویسد؛ وقت همهٔ کسانی را می‌گیرد که بعداً می‌خوانندش. پنج دقیقه نوشتن بیشتر، معمولاً چند ساعت سؤال و پیام و دوباره‌کاری را حذف می‌کند. این مقاله یک قالب عملی برای نوشتن کارت‌هایی می‌دهد که خودشان حرف بزنند.

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

کارت برای چه کسی نوشته می‌شود

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

• انجام‌دهنده: باید بداند دقیقاً چه چیزی خواسته شده و کی کارش تمام است.
• بازبین و تستر: باید بداند کار را با چه معیاری بسنجد.
• کسی که از کنار تابلو رد می‌شود: مدیر یا هم‌تیمی‌ای که فقط عنوان را می‌بیند و باید در یک نگاه بفهمد این کارت دربارهٔ چیست.
• خوانندهٔ آینده: کسی که شش ماه بعد، شاید خود شما، می‌خواهد بداند چرا این تغییر داده شد.

کارت خوب برای هر چهار نفر کار می‌کند. یک آزمون ساده: اگر نویسندهٔ کارت فردا به مرخصی برود، آیا کسی می‌تواند بدون پرسیدن از او کار را شروع کند؟

عنوان: یک جمله که بدون باز کردن کارت فهمیده شود

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

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

توضیح: سه بخش کافی است

لازم نیست توضیح کارت یک سند چندصفحه‌ای باشد. سه بخش کوتاه تقریباً همیشه کافی است:

1. چرا: این کار چه مشکلی را حل می‌کند یا چه ارزشی می‌سازد؟ یکی دو جمله. این بخش به انجام‌دهنده اجازه می‌دهد وقتی به تصمیم کوچکی رسید که در کارت نیامده، درست انتخاب کند.
2. چه: دقیقاً چه چیزی باید ساخته یا تغییر داده شود؟ و اگر لازم است، چه چیزی جزو این کارت نیست.
3. معیار پذیرش: از کجا بفهمیم کار تمام است؟ فهرستی از جمله‌های قابل بررسی.

یک قالب که می‌توانید کپی کنید:

چرا:
...

چه:
...
خارج از این کارت: ...

معیار پذیرش:
- ...
- ...

پیوست‌ها / لینک‌ها:
...

معیار پذیرش: مهم‌ترین بخش

اگر فقط یک بخش را جدی بگیرید، این را بگیرید. معیار پذیرش باید جمله‌هایی باشد که بشود با «بله» یا «نه» جوابشان داد. «صفحه سریع باشد» معیار نیست؛ «فهرست سفارش‌ها برای مشتری با هزار سفارش در کمتر از ۲ ثانیه باز شود» معیار است.

یک قالب رایج و مفید برای نوشتن معیار پذیرش، الگوی «با فرضِ … وقتی … آن‌گاه …» (Given / When / Then) است:

با فرض اینکه کاربر شمارهٔ موبایلش را تأیید کرده، وقتی در صفحهٔ ورود «ورود با کد» را می‌زند، آن‌گاه یک کد شش‌رقمی به شماره‌اش پیامک می‌شود و فرم ورود کد نمایش داده می‌شود.

همین معیارها بعداً در آزمون پذیرش کاربر هم به کار می‌آیند؛ کاربر دقیقاً می‌داند چه چیزی را باید بسنجد. در مقالهٔ UAT چیست توضیح داده‌ام چرا بدون معیار پذیرش، آن مرحله به بحث سلیقه‌ای تبدیل می‌شود.

یک کارت کامل، به‌عنوان نمونه

عنوان: افزودن ورود با کد یک‌بارمصرف پیامکی به صفحهٔ ورود

چرا: بخشی از کاربران رمز عبورشان را فراموش می‌کنند و برای بازنشانی با پشتیبانی تماس می‌گیرند. ورود با کد پیامکی این تماس‌ها را کم می‌کند.

چه: در صفحهٔ ورود، کنار ورود با رمز، گزینهٔ «ورود با کد» اضافه شود. فقط برای کاربرانی که موبایلشان تأیید شده. خارج از این کارت: تغییر ظاهر صفحهٔ ورود و ورود با ایمیل بدون رمز.

معیار پذیرش:

• کاربر با موبایل تأییدشده، کد شش‌رقمی دریافت می‌کند و با آن وارد می‌شود.
• کد پس از ۲ دقیقه منقضی می‌شود.
• بعد از ۵ تلاش ناموفق، تا ۱۵ دقیقه کد تازه ارسال نمی‌شود.
• کاربر بدون موبایل تأییدشده، این گزینه را نمی‌بیند.

این کارت در پنج دقیقه نوشته می‌شود و تقریباً هیچ سؤالی باقی نمی‌گذارد.

کارت باگ: قالب خودش را دارد

برای باگ، بخش «چه» را با این چهار مورد جایگزین کنید:

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

«کار نمی‌کند» گزارش باگ نیست. «در کروم، با کاربر نقش مدیر، روی دکمهٔ خروجی گزارش زدم و فایل خالی دانلود شد» گزارش باگ است.

اندازه: کارتی که در چند روز تمام شود

کارتی که سه هفته کار دارد، سه هفته در ستون «در حال انجام» می‌ماند، هیچ‌کس نمی‌داند واقعاً کجای کار است و یک ستون را قفل می‌کند. قاعدهٔ سرانگشتی من: اگر کارتی بیش از چند روز کاری طول می‌کشد، احتمالاً باید شکسته شود. چرا این برای جریان کار این‌قدر مهم است را در مقالهٔ محدودیت کار در جریان گفته‌ام.

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

چک‌لیست معروف INVEST هم برای سنجیدن یک کارت مفید است: مستقل باشد، قابل مذاکره باشد، ارزش داشته باشد، قابل تخمین باشد، کوچک باشد و قابل آزمون باشد. لازم نیست هر کارتی همهٔ این‌ها را کامل داشته باشد، ولی اگر کارتی هیچ‌کدام را ندارد، هنوز آمادهٔ شروع نیست.

بقیهٔ فیلدها: مسئول، برچسب، تاریخ، پیوست

• مسئول: یک نفر. کارتی که سه مسئول دارد، در عمل هیچ مسئولی ندارد. بقیه می‌توانند عضو کارت باشند، ولی یک نفر باید جواب «این کارت کجاست؟» را بدهد.
• برچسب‌ها: کم و با معنای توافق‌شده. اگر هر کس برچسب خودش را بسازد، بعد از یک ماه چهل برچسب دارید که هیچ‌کس معنایشان را نمی‌داند.
• سررسید: فقط اگر واقعی است. سررسیدی که «همین‌طوری» گذاشته شده، سررسیدهای واقعی را هم بی‌اعتبار می‌کند.
• پیوست‌ها: تصویر صفحه، فایل طراحی، نمونهٔ خروجی مورد انتظار. یک تصویر اغلب از سه پاراگراف توضیح روشن‌تر است.

یک مجموعهٔ برچسب نمونه که برای بیشتر تیم‌های نرم‌افزاری کافی است:

در بردماگ کارت همین فیلدها را دارد: توضیح، سررسید، اعضا، برچسب‌های رنگی، پیوست و کامنت. رنگ برچسب‌ها به این کمک می‌کند که «مسدود» و «فوری» از دور هم روی تابلو دیده شوند.

گفت‌وگو روی کارت، نه بیرون از آن

کارت خوب هم سؤال‌برانگیز است، و این خوب است. مشکل وقتی است که سؤال و جواب در پیام‌رسان شخصی یا تماس تلفنی انجام شود. تصمیمی که آنجا گرفته شده، برای بقیهٔ تیم و برای خوانندهٔ آینده وجود ندارد. دو قاعده:

1. سؤال‌ها و جواب‌های مربوط به کارت، به‌صورت کامنت روی همان کارت.
2. اگر جوابی چیزی را در کار عوض کرد، توضیح کارت را هم به‌روز کنید. کسی نباید برای فهمیدن خواستهٔ فعلی، بیست کامنت را بخواند.

این موضوع را در مقالهٔ گفت‌وگو کنار کار مفصل‌تر باز کرده‌ام.

نشانه‌های کارت بد

• عنوانش یک یا دو کلمه است.
• توضیح ندارد، یا توضیحش فقط تکرار عنوان است.
• معیار پذیرش ندارد و «تمام شد» یعنی هر چه انجام‌دهنده فکر کند.
• چند هفته است در یک ستون مانده.
• چند مسئول دارد یا هیچ مسئولی ندارد.
• برای فهمیدنش باید از نویسنده‌اش پرسید.
• در واقع چند کار است که در یک کارت جمع شده («و همچنین…»).

تمرین این هفته

1. پنج کارت از ستون «آمادهٔ شروع» بردارید.
2. عنوان هر کدام را با قالب فعل + موضوع + زمینه بازنویسی کنید.
3. برای هر کدام دست‌کم سه معیار پذیرش بنویسید.
4. هر کارتی را که بیش از چند روز کار دارد، عمودی بشکنید.
5. در جلسهٔ روزانه از تیم بپرسید: «کدام کارت را بدون سؤال می‌توانید شروع کنید؟» کارت‌هایی که جواب منفی گرفتند، هنوز آماده نیستند.
6. قالب توضیح را به‌عنوان یک کارت نمونه در بالای بک‌لاگ بگذارید تا همه از آن کپی کنند.

جمع‌بندی

کارت خوب یک پیام است به آدم‌هایی که شاید هیچ‌وقت با نویسنده‌اش حرف نزنند. عنوانی که بدون باز کردن کارت فهمیده شود، توضیحی که بگوید چرا و چه، معیار پذیرشی که «تمام شد» را قابل بررسی کند، اندازه‌ای که در چند روز تمام شود و گفت‌وگویی که روی خود کارت بماند؛ این پنج چیز بیشترِ سؤال‌ها و دوباره‌کاری‌ها را حذف می‌کنند. هیچ‌کدامشان ابزار خاصی لازم ندارد؛ فقط پنج دقیقه حوصلهٔ بیشتر هنگام نوشتن.

منابع و مطالعهٔ بیشتر

• User Story — Martin Fowler — کارت به‌عنوان یادآور یک گفت‌وگو و نه یک سند کامل
• INVEST — Agile Alliance Glossary — شش ویژگی یک کارت یا داستان کاربر خوب
• Given When Then — Martin Fowler — الگوی نوشتن معیار پذیرش به شکل سناریو
• User story — Wikipedia — مروری بر قالب‌ها، معیار پذیرش و روش‌های شکستن داستان‌های بزرگ