معیارهای پذیرش کارکرد را می‌سنجند، اما تعریف «انجام‌شده» انتشارپذیری عمومی را تضمین می‌کند
تیم‌های چابک برای مدیریت اتمام وظایف از دو چک‌لیست مجزا استفاده می‌کنند، اما اشتباه گرفتن آن‌ها گلوگاه‌های فوری در جریان کار می‌سازد. معیارهای پذیرش تأیید می‌کنند که یک ویژگی، ارزش تجاری مدنظر را تأمین کرده است؛ در حالی که تعریف «انجام‌شده» یک استاندارد مهندسی همگانی را برای هر انتشار به اجرا درمی‌آورد.
به قلم شیرین کریمی
این خبر را به اشتراک بگذارید
به‌طور خلاصه
- معیارهای پذیرش اطمینان می‌دهند که ویژگی خاص، ارزش تجاری مورد نظر را ارائه می‌دهد و با هر داستان کاربر تغییر می‌کنند.
- تعریف انجام‌شده یک تراز کیفی همگانی بنا می‌نهد و همان استانداردهای مهندسی را روی تمام خروجی‌ها اعمال می‌کند.
- اشتباه گرفتن این دو ابزار با پرحجم کردن چک‌لیست‌های سراسری یا ثبت مستندات تکراری، موجب کندی و قفل‌شدن جریان کار می‌شود.
برای اینکه یک تیم نرم‌افزاری کدی عملیاتی تحویل دهد، برنامه‌نویسان و ذی‌نفعان باید درکی یکسان و دقیق از معنای کلمه «تمام‌شده» داشته باشند. در بیشتر محیط‌های چابک، چنین توافقی به‌خودی‌خود شکل نمی‌گیرد. تیم‌ها مرتباً کدهایی را ادغام می‌کنند که کارکرد بی‌نقصی دارند اما مستندسازی نشده‌اند، یا برای ویژگی‌ای تست‌های بی‌عیب‌ونقص می‌نویسند که کاربر هرگز درخواست نکرده بود.[3]
برای رفع این ناهماهنگی، مدیران محصول از دو چک‌لیست مجزا برای بررسی وضعیت اتمام کار بهره می‌گیرند. معیارهای پذیرش، نیازمندی‌های تجاریِ خاص یک داستان کاربر منفرد را تعریف می‌کنند. در مقابل، تعریف «انجام‌شده» یک معیار پایه و همگانی از کیفیت تعیین می‌کند که هر خروجی، صرف‌نظر از نوع عملکردش، باید واجد آن باشد.[3]
خلط این دو مفهوم، بلادرنگ به ایجاد گلوگاه در جریان کاری منجر می‌شود. ممکن است برنامه‌نویس با راه‌اندازی ویژگی، داستان را پایان‌یافته اعلام کند، اما سرپرست تضمین کیفیت به دلیل تکمیل‌نشدن آزمون‌های خودکار آن را رد نماید. شفاف‌سازی مرز میان این دو مفهوم، به بحث‌های سلیقه‌ای بر سر میزان آمادگی تسک پایان می‌دهد.
معیارهای پذیرش در سطح خُرد عمل می‌کنند و تضمین می‌دهند که ویژگی خاص، ارزش مورد نظر را به همراه دارد. این معیارها مختص هر قلم از بک‌لاگ محصول تعریف می‌شوند. اگر تیم در حال ساخت بخش بازیابی گذرواژه باشد، معیارها دقیقاً رفتاری را مشخص می‌کنند که کاربر انتظار دیدنش را دارد.[2]
تنظیم شروط ویژه برای هر ویژگی
این شروط پیش از آغاز توسعه و در قالب گزاره‌هایی ساده و قابل آزمون نوشته می‌شوند. یک نیاز متعارف می‌تواند این باشد که ایمیل بازیابی ظرف نهایتاً یک دقیقه ارسال شود. نیازمندی دیگر می‌تواند منقضی شدن لینک بازیابی دقیقاً پس از ۳۰ دقیقه باشد تا الزامات امنیتی حفظ گردد.[2]
مالکان محصول معمولاً این شروط را در جلسات پالایش بک‌لاگ پیش‌نویس می‌کنند. سپس در برنامه‌ریزی اسپرینت، تیم توسعه آن‌ها را بررسی و اصلاح می‌نماید تا از واقع‌بینانه و قابل سنجش بودنشان مطمئن شود. این موارد ماهیتی صفر و یکی دارند؛ یک داستان را نمی‌توان به‌طور ناقص پذیرفت.[2]
مستندات اطلسیان در زمینه متدولوژی چابک توضیح می‌دهد: «معیارهای پذیرش، شروطی هستند که یک محصول، داستان کاربر یا بخش خروجی کار باید برآورده سازد تا پایان‌یافته تلقی شود. معیارهای پذیرش به جای تمرکز بر شیوه رسیدن به راه‌حل، روی خروجی نهایی و مطلوب تسک متمرکز هستند.»[2]
اگرچه معیارهای پذیرش با هر تیکت دستخوش تغییر می‌شوند، تعریف «انجام‌شده» در سرتاسر پروژه بدون تغییر باقی می‌ماند. این چارچوب نقش یک تراز کیفی همگانی را ایفا می‌کند که کل سازمان بر سر آن توافق کرده است. هر تحویل‌دادنی منفرد باید پیش از رسیدن به محیط عملیاتی، این مانع را پشت سر بگذارد.[1]
استاندارد فراگیر پایان کار
راهنمای اسکرام سال ۲۰۲۰، تعریف «انجام‌شده» را رسماً به عنوان تعهدِ مربوط به بخش خروجی محصول به رسمیت شناخت. این سند تضمین می‌کند فارغ از آنکه تیم در حال رفع یک باگ جزئی باشد یا پیاده‌سازی درگاه پرداختی بزرگ، دقت و استانداردهای مهندسی زیربنایی یکسان اعمال شود.[1]
یک تعریف قوی از «انجام‌شده» تمرکز ویژه‌ای بر نیازمندی‌های غیرکارکردی و انطباق با فرایندها دارد. مواردی چون ضرورت بازبینی کد توسط همکار، قبولی در اسکن‌های امنیتی خودکار و به‌روزرسانی گزارش تغییرات انتشار، نمونه‌های رایج آن هستند. این سازوکار، سلامت ساختاری نرم‌افزار را تضمین می‌کند.[1]
پایگاه Scrum.org خاطرنشان می‌کند: «تعریف انجام‌شده با ایجاد درکی مشترک از اینکه چه کارهایی انجام شده و چه استانداردهایی به عنوان بخشی از خروجی رعایت گشته‌اند، شفافیت می‌آفریند. اگر موردی در بک‌لاگ با تعریف انجام‌شده مطابقت نداشته باشد، انتشار آن مجاز نخواهد بود.»[1]
سازمان‌ها تعریف «انجام‌شده» خود را با استفاده از آستانه‌های عددی مشخص، کمی‌سازی می‌کنند. ممکن است تیمی مقرر کند تمامی کدهای تازه دست‌کم به ۷۰ تا ۸۰ درصد پوشش آزمون واحد دست یابند. هر درخواستی که این رقم را تأمین نکند، به‌طور خودکار در خط لوله یکپارچه‌سازی مداوم متوقف می‌شود.[3]
کمی‌سازی سطح پایه کیفیت
پارامترهای سنجش هم در این چک‌لیست سراسری جای می‌گیرند. یک برنامه کاربردی عمومی ممکن است نیازمند سازگاری با پنج مرورگر دسکتاپ برتر روز باشد. در حوزه موبایل نیز بررسی سازگاری با سه مدل گوشی برتر طبق آمارهای تحلیلی کسب‌وکار ضرورت پیدا می‌کند.
این سنجه‌ها مانع از انباشت بدهی فنی در طول دوره‌های سریع توسعه می‌شوند. هرگاه برنامه‌نویسی برای رساندن کار به ددلاین اسپرینت عجله کند، تعریف «انجام‌شده» در نقش آخرین سد دفاعی ظاهر می‌شود و مانع از استقرار فیزیکی کدهای غیراستاندارد خواهد شد.
یکی از خطاهای رایج در تیم‌های چابک، گنجاندن الزامات فنی در دل معیارهای پذیرش است. وقتی مالک محصول شرطی مانند «کد باید بازبینی شود» را به داستان کاربر اضافه می‌کند، مرز بین کارکرد ویژگی و استانداردهای کلی مخدوش می‌گردد و مستندسازی تکراری پدید می‌آید.
در نقطه مقابل، قراردادن منطق مختص یک ویژگی درون تعریف «انجام‌شده»، چک‌لیست همگانی را سنگین و بیهوده می‌کند. اگر در استاندارد عمومی نوشتن اسکریپت مایگریشن دیتابیس اجباری شود، تیم‌های فرانت‌اند که تنها رابط کاربری را تغییر می‌دهند همیشه در تأیید نهایی مردود خواهند شد. این دو ابزار باید کاملاً جدا بمانند.[3]
توسعه استاندارد در میان چندین تیم
مرجع AgileSherpas تبیین می‌کند: «تعریف انجام‌شده به شکلی فراگیر در تمام کارهای تیم اعمال شده و استانداردهای کیفیِ پیش از نهایی‌شدن کار را تشریح می‌کند. در مقابل، معیارهای پذیرش مختص یک بخش کاری معین هستند و مشخص می‌کنند آن دستاورد خاص باید دقیقاً شامل چه مواردی باشد.»
در سازمان‌های بزرگ، چندین تیم اسکرام به‌طور هم‌زمان بر روی یک محصول نرم‌افزاری واحد کار می‌کنند. در این فضاها، تیم‌ها باید دارای تعریف «انجام‌شده» یکتا و یکپارچه‌ای باشند. چنین رویکردی از ورود کدهای ضعیف و فاقد آزمون به مخزن اشتراکی جلوگیری می‌کند.[1][3]
تیم‌ها می‌توانند تعریف «انجام‌شده» سخت‌گیرانه‌تری برای خود وضع کنند، اما کاهش سطح پایه استاندارد برای آن‌ها مجاز نیست. اگر سازمان ۷۵ درصد پوشش آزمون را الزامی کرده باشد، یک تیم می‌تواند آن را به ۹۰ درصد برساند، اما حق ندارد کف نیاز خود را تا ۶۰ درصد پایین بیاورد.[3]
بااین‌حال، معیارهای پذیرش کاملاً غیرمتمرکز باقی می‌مانند. مالک محصول بخش تسویه‌حساب معیارهای پرداخت را تنظیم می‌کند و تیم جست‌وجو معیارهای سرعت پاسخ‌دهی به پرسمان‌ها را می‌نویسد. این کنترل منطقه‌ای سرعت تیم‌ها را بدون نیاز به تاییدیه‌های خارجی بالا می‌برد.[2][3]
تکامل استانداردهای چابک در طول زمان
یک تعریف کاربردی از «انجام‌شده»، به مرور زمان و همگام با پختگی تیم رشد می‌کند. یک استارتاپ نوپا ممکن است کارش را با چک‌لیستی سه‌موردی آغاز کند تا سرعت خود را حفظ کند؛ اما به موازات رشد محصول و جذب کاربران بیشتر، سنجه‌های امنیتی و انطباقی سخت‌گیرانه‌تری اضافه می‌شوند.
تیم‌ها معمولاً در جلسات بازنگری اسپرینت استانداردهای همگانی‌شان را مرور و تصحیح می‌کنند. اگر باگی حیاتی به محیط عملیاتی راه یابد، تیم با بررسی چرایی شکست، بررسی پیشگیرانه جدیدی به تعریف «انجام‌شده» اضافه می‌کند. این شیوه چرخه‌ای دائمی برای بهبود می‌آفریند.[1]
تیم‌ها معمولاً در جلسات بازنگری اسپرینت استانداردهای همگانی‌شان را مرور و تصحیح می‌کنند.
مجموعه رایک اشاره می‌کند: «تعریف انجام‌شده (DoD) مجموعه‌ای مشترک از معیارهایی است که باید برآورده شوند تا کار، تکمیل‌شده و قابل عرضه تلقی گردد. در تیم‌های چابک، انجام‌شدن فقط به معنای تیک زدن تسک‌ها نیست؛ یعنی برآورده ساختن استانداردهای توافق‌شده.»
این دو چارچوب پاسخ‌گوی دو پرسش بنیادین کاملاً متفاوت هستند: معیارهای پذیرش مشخص می‌کنند که آیا تیم چیز درستی را برای کاربر ساخته است یا خیر. تعریف «انجام‌شده» بررسی می‌کند که آیا تیم همان چیز را مطابق با استانداردهای مهندسی تعیین‌شده ساخته است یا خیر.[3]
این تحلیل چگونه انجام شد
- روش
- ترکیبی تطبیقی از مستندات چارچوب‌های چابک و استانداردهای صنعتی برای تفکیک مرز میان نیازمندی‌های خاص هر ویژگی و معیارهای پایه کیفیت سراسری.
- یافته
- در حالی که تیم‌ها اغلب این دو را به جای یکدیگر به عنوان چک‌لیست استفاده می‌کنند، آن‌ها بر دو محور کاملاً متفاوت عمل می‌کنند: معیارهای پذیرش تأیید می‌کنند که آیا تیم چیز درستی را ساخته است، در حالی که تعریف انجام‌شده تأیید می‌کند کار طبق استانداردهای کیفی الزامی ساخته شده است.
- داده‌هایی که بر پایهٔ آن‌ها کار کردیم
- دامنه کاربرد (معیار پذیرش در برابر تعریف انجام‌شده): AC applies to one item; DoD applies to all items
- زمان ایجاد: DoD is established upfront; AC is created per sprint
- محدودیت‌های این تحلیل
- این تحلیل فرض را بر این می‌گذارد که تیم‌ها از چارچوب‌های رسمی چابک یا اسکرام استفاده می‌کنند؛ محیط‌های توسعه موردی و بی‌نظم ممکن است هیچ‌یک از این دو چک‌لیست را به کار نگیرند.
بررسی عمیق دیدگاه‌ها
معیارهای پذیرش
شروط ویژه هر ویژگی که بررسی می‌کنند آیا داستان کاربر ارزش تجاری مدنظر را تأمین کرده است یا خیر.
معیارهای پذیرش مانند قراردادی در سطح خُرد بین مالک محصول و تیم توسعه عمل می‌کنند. این معیارها برای هر داستان کاربر به شکلی اختصاصی نوشته می‌شوند و به جای شیوه پیاده‌سازی فنی، کاملاً بر خروجی‌های عملکردی تمرکز دارند. این معیارها با بیان دقیق اینکه کاربر باید چه اقداماتی انجام دهد — مانند دریافت ایمیل بازیابی گذرواژه ظرف مدت یک دقیقه — اطمینان می‌دهند که تیم در حال خلق راه‌حل مناسب است. همچنین بررسی این معیارها مبنایی کاملاً دوحالته (قبول یا رد) دارد و تا پیش از احراز کامل آن‌ها، ویژگی مربوطه پایان‌یافته اعلام نمی‌شود.
تعریف «انجام‌شده»
معیار پایه و همگانی از کیفیت که تمام خروجی‌های محصول باید پیش از انتشار نهایی از آن عبور کنند.
تعریف «انجام‌شده» به عنوان دروازه کیفی کلان عمل می‌کند که به صورت یکپارچه بر تمام بخش‌های کاری یک پروژه اعمال می‌شود. این چارچوب به جای بررسی رفتار ویژگی، دقت مهندسی، استانداردهای امنیتی و انطباق با فرایندها را به اجرا درمی‌آورد. چه تیم در حال اصلاح یک باگ کوچک باشد و چه بازطراحی بنیادین معماری سامانه، کار باید همان آزمون‌های خودکار، بازبینی‌های همکار و مستندسازی‌ها را پشت سر بگذارد. این چک‌لیست کلی مانع از افزایش بدهی فنی شده و تضمین می‌کند کدهای تجمیع‌شده کاملاً مهیای استقرار عملیاتی هستند.
- مدیریت محصول
- تمرکز بر بیشینه‌سازی ارزش کاربر و اطمینان از برآورده‌شدن نیازمندی‌های تجاری مشخص از طریق معیارهای پذیرش.
- رهبری مهندسی
- تمرکز بر صیانت از سلامت ساختار نرم‌افزار، به حداقل رساندن بدهی فنی و اجرای استانداردهای کیفی سراسری از طریق تعریف انجام‌شده.
دیدگاه‌هایی که این گزارش پوشش نداده
- آزمون‌گران مستقل تضمین کیفیت (QA)
منابع
پوشش منابع
3 منبع
2 دیدگاه شناسایی‌شده
- [1]Scrum.orgرهبری مهندسی
Done and the Definition of Done
مطالعه در Scrum.org → - [2]Atlassianمدیریت محصول
User stories with examples and a template
مطالعه در Atlassian → - [3]تیم سردبیری کوهستان
تحلیل تیم سردبیری کوهستان
مطالعه در تیم سردبیری کوهستان →
بیشتر در جامعه
مشاهده همه →برنامه‌ریزی چابک
چگونه برش افقی انتشار مانع از عرضه قابلیت‌های جزیره‌ای در بک‌لاگ‌های خطی می‌شود
7 منبع
مهندسی نرم‌افزار
قانون وبر و خطای تخمین زمان؛ چرا اسکرام از اعداد فیبوناچی به جای ساعت استفاده می‌کند؟
5 منبع
ساختارهای حاکمیتی
واگذاری قدرت به پایین‌ترین سطح کارآمد حاکمیت
4 منبع
پویایی اجتماعی
قانون ۲۵ درصد: چگونه یک اقلیت متعهد می‌تواند هنجارهای یک گروه را تغییر دهد
7 منبع
نظرات
هر زاویه. هر روز.
اخبار جامعه با پوشش کامل منابع و تحلیل دیدگاه‌ها، هر روز و رایگان.