تسک خوب چطور نوشته می‌شود؟ فرمول، نمونه و اشتباه‌های رایج

تسک خوب کاری را توضیح می‌دهد که کسی بتواند بدون پرسیدن شروعش کند و بداند کی تمام شده است. این راهنما یک فرمول ساده برای نوشتن تسک می‌دهد و با یک مثال نشان می‌دهد نسخهٔ مبهم و نسخهٔ آماده چه فرقی دارند.

آخرین بازبینی: ۱۶ مهر ۱۴۰۵

تسک خوب چه ویژگی‌هایی دارد؟

  • یک مسئول مشخص دارد، حتی اگر چند نفر کمک کنند.
  • یک نتیجه دارد، نه یک فهرست بلند از کارهای نامربوط.
  • آن‌قدر کوچک است که معمولاً در یکی دو روز تمام شود؛ بزرگ‌تر را بشکنید.
  • پایانش روشن است: همه می‌دانند «انجام‌شده» یعنی چه.
  • بدون پرسیدن از نویسنده فهمیده می‌شود.

عنوان: با یک فعل شروع کنید

عنوان باید در فهرست تسک‌ها به‌تنهایی معنا بدهد. «دعوت» یعنی چه؟ ولی «افزودن دکمهٔ دعوت به صفحهٔ تیم» روشن است. فعل (افزودن، حذف، اصلاح، بررسی) به خواننده می‌گوید چه نوع کاری در انتظار است و اگر عنوان بدون فعل است، معمولاً کار هنوز در ذهن نویسنده کامل نشده.

توضیح: زمینه، نتیجه، شرایط پذیرش

برای بیشتر تسک‌ها همین چهار بخش کافی است:

  • زمینه: چرا این کار لازم شد؟ مشکل از کجا آمد؟
  • نتیجهٔ مورد انتظار: بعد از انجام کار چه چیزی برای چه کسی فرق می‌کند؟
  • شرایط پذیرش: با چه آزمونی می‌فهمیم تمام شد؟
  • خارج از دامنه: چه چیزی را در این تسک انجام نمی‌دهیم؟

یک نمونه: مبهم در برابر آماده

فرض کنید در یک اپ پرداخت، کاربران از ورود ناموفق شکایت دارند. دو شکل تسک را کنار هم ببینید.

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

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

شرایط پذیرش را قابل‌آزمایش بنویسید

هر شرط پذیرش باید جمله‌ای باشد که با «بله» یا «نه» جواب بگیرد. قالب «وقتی… آنگاه…» کمک می‌کند:

  • وقتی کاربر کد اشتباه وارد کند، آنگاه پیام «کد درست نیست» نمایش داده می‌شود.
  • وقتی فهرست تیم‌ها خالی است، آنگاه به‌جای صفحهٔ سفید راهنمای ساخت تیم نمایش داده می‌شود.
  • وقتی کاربر دسترسی ندارد، آنگاه دکمه دیده نمی‌شود، نه اینکه خطا بدهد.

تسک بزرگ را چطور بشکنیم؟

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

چک‌لیست پیش از ساختن تسک

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

اشتباه‌های رایج

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

پرسش‌های رایج

تسک چقدر باید بزرگ باشد؟

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

تسک با داستان کاربر (User Story) چه فرقی دارد؟

داستان کاربر یک قالب برای بیان نیاز است («به‌عنوان … می‌خواهم … تا …») و معمولاً بزرگ‌تر از یک تسک است. داستان به چند تسک شکسته می‌شود که هرکدام کار مشخصی برای یک نفر است.

چه کسی باید تسک را بنویسد؟

هر کس که کار را می‌شناسد می‌تواند بنویسد، ولی مدیر محصول و تیم با هم باید روشن‌شدن آن را تأیید کنند. تسک مبهم را نباید فقط به‌خاطر اینکه نوشته شده وارد اسپرینت کرد.

بیشتر بخوانید

صفحه‌های مرتبط

مسیر را یک هفته رایگان امتحان کنید

ثبت‌نام کمتر از یک دقیقه طول می‌کشد و به کارت بانکی نیازی نیست.

شروع رایگان