تعریف اتمام کار (DoD) و کاهش دوباره‌کاری

تیم آرادتیم مهندسی

سؤالی که در جلسهٔ روزانه پرسیده می‌شود: «کارت تمام شد؟» و جوابی که می‌آید: «آره، فقط تستش مانده.»

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

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

چرا این بیشتر از یک بحث لفظی است

سه پیامد مشخص دارد:

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

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

دوباره‌کاری زیاد می‌شود. برگشتن به کدی که سه هفته پیش نوشته‌اید، از تمام کردنش در همان زمان گران‌تر است — چون باید دوباره در ذهنتان بارگذاری‌اش کنید.

تعریف اتمام چیست

یک فهرست کوتاه از شرط‌هایی که هر کاری باید داشته باشد تا تمام حساب شود. یکسان برای همهٔ کارها، توافق‌شده توسط کل تیم، و جایی نوشته شده که همه ببینند.

نکتهٔ اصلی همان «هر کاری» است. این با معیار پذیرش فرق دارد:

  • معیار پذیرش مخصوص یک کار است: «کاربر بتواند سفارش را لغو کند.»
  • تعریف اتمام برای همهٔ کارهاست: «کد بازبینی شده، تست دارد، روی محیط آزمایش مستقر شده.»

هر دو لازم‌اند و جای هم را نمی‌گیرند.

یک تعریف عملی برای شروع

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

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

نه بند بلندی نیست و بیشترش خودکار قابل بررسی است.

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

چه چیزی نباید در تعریف باشد

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

«استقرار روی محیط اصلی» — مگر اینکه واقعاً تحویل مستمر داشته باشید. در بیشتر سازمان‌های ایرانی انتشار به محیط اصلی تابع تقویم و تأیید کارفرماست و گذاشتنش در تعریف یعنی هیچ کاری هرگز تمام نمی‌شود.

بندهای مبهم. «کد تمیز باشد» قابل بررسی نیست. «تحلیل ایستا بدون خطا بگذرد» هست.

تعریف آماده‌بودن، طرف دیگر همان سکه

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

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

چطور اجرایش کنیم بدون اینکه به تشریفات تبدیل شود

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

کوتاه شروع کنید. پنج بند که همیشه رعایت می‌شوند، از پانزده بند که گاهی رعایت می‌شوند بهتر است. بند اضافه کردن آسان است.

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

در بازبینی دوره‌ای مرورش کنید. اگر بندی مدام رد می‌شود، یا بند غلط است یا مانعی هست که باید برداشته شود. هر دو حالت اطلاعات مفیدی است.

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

اثری که در عمل می‌بینید

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

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

پروژه یا ایده‌ای دارید؟

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

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

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

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.