ویرگول
ورودثبت نام
سید محمدرضا امامیان
سید محمدرضا امامیان
خواندن ۵ دقیقه·۱ سال پیش

تعریف DoD (Definition of Done) در اسکرام چیست؟

یکی از موضوعاتی که در اسکرام ممکنه سوالات زیادی رو به وجود آورده باشه مفهوم DoD یا همون Definition of Done هست که قصد دارم توی این مقاله این موضوع رو باز کنم و آخر این مقاله نگاه جامعی به این مفهوم داشته باشیم.

در Scrum Guide تعریف DoD اینطوری گفته شده:

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

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

همچنین میتونیم برای هر کاری در جهان که قابل تحویل گرفتنه، یک DoD داشته باشیم. بیاید با چندتا سوال ساده در مورد موضوعاتی که میتونیم توی جهان واقعی پیداشون کنیم، این موضوع رو اثبات کنیم:

  1. کی میتونیم یک موشک رو به فضا بفرستیم؟
  2. چه زمانی نمایندگی یک شرکت خودروسازی می‌تونه به مشتری خودش زنگ بزنه و بگه ماشین شما آماده‌ست؟
  3. چه چیزی لازمه برای این‌که یک دکتر بعد از عمل جراحی بگه «عمل موفقیت آمیز بوده»؟
  4. چه زمانی میتونیم به تیم فنی بگیم که محصول رو منتشر کنه و به دست مشتری برسونه؟

این چهارتا سوال بخش کوچکی از سوالاته که میتونیم بهشون یک DoD اختصاص بدیم و بگیم که چه زمانی این کارها به حالت «انجام شده» تغییر وضعیت دادن.

به طور خاص وقتی در مورد توسعه یک محصول صحبت می‌کنیم لازمه که DoD رو به سه قسمت تقسیم کنیم:

  • نیازهای تجاری یا عملکردی
  • کیفیت
  • نیازهای غیر عملکردی

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

بریم باهم این سه قسمت رو بررسی کنیم و نگاه کامل‌تری نسبت بهشون داشته باشیم:

  • نیازهای تجاری یا عملکردی

توی این بخش، توسعه یک محصول از لحاظ عملکردی بررسی میشه. چطور؟ اینطوری که باید ببینیم آیا توسعه‌ای که انجام گرفته، ارزشی رو خلق کرده یا نه؟ که این مورد رو میتونیم با نوشتن یوزر استوری User Story بررسی کنیم. (یک تعریف خلاصه از یوزر استوری بدم برای افرادی که ممکنه با این تعریف آشنا نباشن: یوزر استوری یا همون داستان کاربر، نیازهای کاربر رو در قالب پرسش سوال‌هائی که معمولا با «چه کسی»، «چه چیزی» و «چرا» شروع میشن بیان میکنه - در ادامه این مقاله چندتا یوزر استوری رو باهم بررسی می‌کنیم و بیشتر آشنا میشی باهاش)

قالب یک یوزر استوری
قالب یک یوزر استوری

همونطور که توی عکس بالا مشخصه، هر یوزر استوری شامل سه بخشه که قراره سه تا موضوع رو مشخص کنه.

مثالمون توی این قسمت به این صورته که یک سرویس فروش بلیط هواپیما داریم و قراره که به مشتری بلیط‌های خریداری شده‌ش رو نمایش بدیم:

  1. توی بخش اول قراره مشخص کنیم که مخاطب هدفمون توی این یوزر استوری کیه. پس توی قسمت اول مینویسیم: به عنوان مسافر.
  2. توی بخش دوم لازمه مشخص کنیم که این شخص می‌خواد چه کاری انجام بده. توی قالب مثالمون میگیم: میخوام که بلیط‌های خریداری شده‌م رو ببینم (باید از فعل اول شخص استفاده کنیم. چرا؟ چون داریم داستان کاربر رو مینویسیم و نیازهاش رو از زبان خودش بیان می‌کنیم)
  3. و تو قسمت آخر علت کاری که میخوایم انجام بدیم رو باید بیان کنیم. چرا یک مسافر می‌خواد بلیط‌هائی که خرید کرده رو ببینه؟ که بتونه تاریخ پروازهاش رو مشاهده کنه (ممکنه یک کاری که کاربر می‌خواد انجام بده، علت‌های زیادی داشته باشه. مثلا اینجا میشه این رو هم نوشت که: کاربر بتونه جمع مبلغ پرداختی‌ش رو ببینه).
  • کیفیت

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

  • نیازهای غیر عملکردی

این مولفه، ویژگی‌ها یا ویژگی‌های یک محصول هستند که ممکنه ارزش مستقیم تجاری‌ای به محصول اضافه نکنن، اما بدون اونها محصول نمی‌تونه حرکت کنه و مسیرش رو ادامه بده. این ویژگی‌های تضمین کیفیت محصول رو می‌تونیم تحت مؤلفه کیفیت هم در نظر بگیریم. از مثال‌های این مولفه هم می‌تونیم به موارد زیر اشاره بکنیم:

  1. قابلیت نگهداری
  2. کارائی (Performance)
  3. امنیت
  4. مقیاس پذیری (Scalability)
  5. قانونی بودن

و...

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




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

خوشحال میشم اگر نکته‌ای داری که فکر میکنی این متن رو بهتر میکنه، نقدی داری و احساس میکنی جائی رو اشتباه گفتم و یا نظری نسبت به این نوشته داری، توی کامنت‌ها بخونمش.

برای ارتباط گرفتن با من میتونی از این لینک استفاده کنی.

توی کانال تلگرامم محتوای مربوط به حوزه تکنولوژی میزارم، اگر فکر میکنی به دردت میخوره خوشحال میشم اونجا ببینمت :)

توسعه محصولscrumagiledoddefinition of done
Android Developer - In Search of Technology
شاید از این پست‌ها خوشتان بیاید