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

گرومینگ تسک‌ها چیست؟

Backlog Grooming (refinement) — فرآیند آماده‌سازی تسک‌های Product Backlog برای اسپرینت‌های آینده. جلسه‌ای که در آن Product Owner و تیم توسعه تسک‌ها را مرور می‌کنند: نیازمندی‌ها را دقیق می‌کنند، Acceptance Criteria اضافه می‌کنند، پیچیدگی را ارزیابی می‌کنند، وابستگی‌ها و ریسک‌ها را شناسایی می‌کنند. در راهنمای Scrum رویداد اجباری «گرومینگ» وجود ندارد — این یک تمرین اضافی است که تیم‌های Scrum برای کاهش عدم قطعیت در Sprint Planning معرفی می‌کنند. تکرار توصیه‌شده — ۱ بار در اسپرینت، حداکثر ۶۰ دقیقه.

اصطلاح «شانه‌زدن» (grooming) جوهر را منعکس می‌کند: تیم بک‌لاگ را «شانه می‌زند»، تسک‌های قدیمی را حذف می‌کند، نامشخص‌ها را دقیق می‌کند و تسک‌های بیش از حد بزرگ را می‌شکند. در توسعه موبایل، گرومینگ به دلیل ویژگی‌های پلتفرم بسیار مهم است: تسک برای Android ممکن است از نظر پیچیدگی با نسخه iOS متفاوت باشد، باید targetSdk، compileSdk، سازگاری با سطوح API در نظر گرفته شود. بدون گرومینگ، Sprint Planning به هرج‌ومرج تبدیل می‌شود: تیم برای اولین بار تسک‌ها را می‌بیند و نمی‌تواند آنها را ارزیابی کند، که منجر به غیرقابل پیش‌بینی بودن و تأخیر می‌شود.

نتیجه گرومینگ — چندین تسک آماده برای Sprint Planning: آنها توضیحات، Acceptance Criteria، ارزیابی دارند و با Definition of Ready مطابقت دارند. Product Owner باید تسک‌ها را به ترتیب اولویت گرومینگ کند: نزدیک‌ترین به اسپرینت فعلی — دقیق‌ترین. تسک‌های ۳-۴ اسپرینت بعد — فقط در سطح اپیک. تکنیک Progressive Refinement: هرچه تسک به اسپرینت نزدیک‌تر باشد، توضیحات آن دقیق‌تر است. برای تسک‌های اسپرینت فعلی — full refinement (AC، طراحی، مشخصات API). برای تسک‌های ۲ اسپرینت بعد — story-level (user story بدون جزئیات پیاده‌سازی). برای تسک‌های ۳+ اسپرینت بعد — epic-level (فقط نام و ارزش تجاری).

Definition of Ready: چه زمانی تسک برای اسپرینت آماده است

Definition of Ready (DoR) — فهرست بررسی معیارهایی که تسک قبل از ورود به Sprint Backlog باید داشته باشد. DoR قراردادی بین Product Owner و تیم است: PO تضمین می‌کند که تمام اطلاعات برای توسعه وجود دارد، تیم تضمین می‌کند که می‌تواند تسک را ارزیابی و انجام دهد. DoR جهانی نیست — هر تیم مجموعه معیارهای خود را تعیین می‌کند. بدون DoR، تسک می‌تواند با نیازمندی‌های نامشخص وارد اسپرینت شود که منجر به دوباره‌کاری و تأخیر می‌شود.

DoR معمول برای توسعه موبایل: ۱) Acceptance Criteria شرح داده شده (معیارهای پذیرش در قالب Given-When-Then). ۲) طرح طراحی در Figma آماده است (برای تسک‌های UI) با تمام حالات: default، loading، error، empty state. ۳) مشخصات API تأیید شده است (OpenAPI/Swagger، نمونه‌های درخواست و پاسخ). ۴) ارزیابی در استوری پوینت وجود دارد. ۵) وابستگی به تسک‌های دیگر شناسایی شده است. ۶) تسک به مؤلفه‌های خارجی ناتمام وابسته نیست. ۷) ویژگی موبایل: نسخه‌های هدف OS، نیاز به feature flag، پشتیبانی از سطوح قدیمی API تعیین شده است.

تکنیک‌های ارزیابی تسک‌ها

Planning Poker — محبوب‌ترین تکنیک ارزیابی در گرومینگ. هر توسعه‌دهنده دسته‌ای از کارت‌ها با اعداد فیبوناچی (۱، ۲، ۳، ۵، ۸، ۱۳، ۲۱) دریافت می‌کند. PO تسک را نشان می‌دهد و توضیح می‌دهد. پس از بحث، همه همزمان کارت را نشان می‌دهند. اگر ارزیابی‌ها بسیار متفاوت باشد (مثلاً ۳ و ۱۳) — توسعه‌دهندگان ارزیابی خود را توضیح می‌دهند و دوباره رأی می‌دهند. تکرارها تا رسیدن به اجماع ادامه می‌یابد. هدف Planning Poker ارزیابی دقیق نیست، بلکه کشف تفاوت‌ها در درک تسک است.

T-Shirt Sizing — تکنیک ساده‌شده برای ارزیابی سریع: XS (1 SP)، S (2)، M (3)، L (5)، XL (8)، XXL (13). برای مرتب‌سازی اولیه بک‌لاگ مناسب است، زمانی که تسک‌ها زیاد هستند و باید سریع میزان بزرگی را تخمین زد. پس از T-Shirt Sizing، ارزیابی دقیق‌تر از طریق Planning Poker برای تسک‌های اسپرینت بعدی انجام می‌شود. Affinity Estimation — مرتب‌سازی گروهی تسک‌ها بر اساس پیچیدگی نسبی بدون اعداد؛ تسک‌ها روی میز از ساده‌ترین به پیچیده‌ترین چیده می‌شوند، سپس در خوشه‌ها گروه‌بندی می‌شوند، هر خوشه یک ارزیابی دریافت می‌کند.

در توسعه موبایل، ارزیابی باید پیچیدگی پلتفرم را در نظر بگیرد. یک تسک Android ممکن است ۵ SP ارزیابی شود و همان تسک برای iOS — ۳ SP (یا برعکس). این طبیعی است: پلتفرم‌های مختلف پیچیدگی پیاده‌سازی متفاوتی دارند. نکته: اگر تیم cross-platform است، هر پلتفرم را جداگانه ارزیابی کنید. از مقیاس نسبی استفاده کنید: تسک پایه (مثلاً صفحه با متن و دکمه) = 1 SP. بقیه چیزها — نسبت به آن. طبق Scrum.org (2025)، پس از ۳-۴ اسپرینت، دقت ارزیابی تیم به ±۲۰٪ پیچیدگی واقعی می‌رسد.

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

تسک‌های بزرگتر از ۸ SP باید به تسک‌های کوچک‌تر تجزیه شوند. تسک‌های بزرگ را نمی‌توان در یک اسپرینت انجام داد، ارزیابی آنها دشوار است و حس پیشرفت نمی‌دهند. تکنیک تجزیه: تسک را به لایه‌های افقی (UI → ViewModel → Repository → Network/DB) یا برش‌های عمودی (feature: یک صفحه کامل) تقسیم کنید. تجزیه افقی برای توسعه موبایل مناسب‌تر است: Sub-task 1 — چیدمان UI (XML/Jetpack Compose/SwiftUI)، Sub-task 2 — ViewModel + State، Sub-task 3 — Repository + Network، Sub-task 4 — تست‌های واحد.

تجزیه عمودی — برش user story به داستان‌های کوچک‌تر با ارزش مستقل. مثال: Epic «سبد خرید» → Story 1 «افزودن کالا به سبد»، Story 2 «نمایش سبد»، Story 3 «حذف کالا از سبد»، Story 4 «ثبت سفارش». هر Story ارزش تجاری خود را دارد و می‌تواند مستقل منتشر شود. SPoK (Story Points on Kano): Stories را بر اساس ارزش تجاری رتبه‌بندی کنید (Must-have، Should-have، Could-have) و به ترتیب ارزش پیاده‌سازی کنید.

فهرست بررسی تجزیه در گرومینگ: ۱) تسک بزرگتر از ۸ SP است؟ → تجزیه کنید. ۲) Acceptance Criteria وجود دارد؟ → اگر نه — اضافه کنید. ۳) به تسک‌های دیگر وابسته است؟ → وابستگی‌ها را شناسایی و ثبت کنید. ۴) عدم قطعیت دارد؟ → قبل از تسک اصلی، Spike (تحقیق) اضافه کنید. ۵) طراحی لازم است؟ → آمادگی ماکت‌ها را بررسی کنید. قاعده INVEST: Independent (مستقل از دیگران)، Negotiable (قابل مذاکره)، Valuable (باارزش برای کسب‌وکار)، Estimable (قابل ارزیابی)، Small (کوچک)، Testable (قابل تست). اگر تسک INVEST را برآورده نمی‌کند — برای اسپرینت آماده نیست.

فرآیند گرومینگ: گام به گام

گام ۱: گرم‌کردن (۵ دقیقه). Scrum Master هدف گرومینگ و DoR را یادآوری می‌کند. تیم به تابلو نگاه می‌کند، PO نشان می‌دهد کدام تسک‌ها بحث خواهند شد. گام ۲: مرور تسک‌ها (۳۰ دقیقه). PO به ترتیب تسک‌های انتهای اسپرینت فعلی و ابتدای اسپرینت بعدی را ارائه می‌دهد. برای هر تسک: نام، توضیحات، Acceptance Criteria (در صورت وجود)، لینک طراحی، مشخصات API. تیم سوالات شفاف‌ساز می‌پرسد: «آیا ماکت برای حالت خالی وجود دارد؟»، «چه متد HTTP؟»، «iOS minimum deployment target چیست؟».

گام ۳: ارزیابی (۱۵ دقیقه). تیم تسک را از طریق Planning Poker یا T-Shirt Sizing ارزیابی می‌کند. اگر اختلاف > ۲ SP باشد — علل را بحث می‌کنند و دوباره رأی می‌دهند. قاعده: اگر تسک قابل ارزیابی نیست (نیازمندی‌ها نامشخص، طراحی وجود ندارد) — برای بازبینی به PO بازگردانده می‌شود و با شفاف‌سازی به گرومینگ بعدی می‌آید. تسک‌های با ناشناخته‌ها را ارزیابی نکنید — این قطعاً به خطا در اسپرینت منجر می‌شود. گام ۴: ثبت نتایج (۱۰ دقیقه). PO ارزیابی‌ها را در Jira/Linear ثبت می‌کند، توضیحات تسک را به‌روز می‌کند و اولویت‌ها را تعیین می‌کند.

نتایج گرومینگ: ۳-۷ تسک کاملاً آماده برای Sprint Planning (با DoR، ارزیابی، طراحی، API). PO بک‌لاگ را به‌روز می‌کند: تسک‌های قدیمی را حذف می‌کند، موارد تکراری را ادغام می‌کند، اولویت‌ها را دقیق می‌کند. مهم: گرومینگ کار PO را تمام نمی‌کند — بین گرومینگ‌ها باید تسک‌های بعدی را آماده کند. سرعت توصیه‌شده: PO ۳-۴ تسک برای گرومینگ آماده می‌کند، تیم آنها را پردازش می‌کند. اگر بیش از ۵۰ تسک در بک‌لاگ وجود دارد — PO باید قبل از گرومینگ اولویت‌بندی (MoSCoW یا Weighted Shortest Job First) انجام دهد.

تفاوت گرومینگ با Sprint Planning

گرومینگ — آماده‌سازی است. در آن تعهدی وجود ندارد — تسک صرفاً دقیق و ارزیابی می‌شود. Sprint Planning — تعهد است. تیم تسک‌هایی را از میان آماده‌شده در گرومینگ انتخاب می‌کند و متعهد به انجام آنها در اسپرینت می‌شود. تفاوت‌های اصلی: گرومینگ به اسپرینت خاصی وابسته نیست (refinement کلی بک‌لاگ)، در گرومینگ Sprint Goal وجود ندارد، گرومینگ می‌تواند در هر زمان اسپرینت انجام شود. Sprint Planning — دقیقاً در ابتدای اسپرینت و همیشه به Sprint Goal منتهی می‌شود.

در گرومینگ تسک‌ها فقط ارزیابی می‌شوند، اما به اسپرینت برده نمی‌شوند. در Planning تسک‌ها از استخر آماده انتخاب می‌شوند. بدون گرومینگ، Sprint Planning ۶-۸ ساعت (به جای ۴) طول می‌کشد، زیرا تیم برای اولین بار تسک‌ها را می‌بیند و نمی‌تواند سریع آنها را ارزیابی کند. قاعده ۸۰/۲۰: ۸۰٪ تسک‌های Sprint Planning باید کاملاً آماده باشند (گرومینگ شده)، ۲۰٪ — می‌توانند جدید باشند (باگ‌های فوری، hotfix). اگر در Planning بیش از ۲۰٪ تسک‌های ارزیابی‌نشده وجود داشته باشد — گرومینگ کافی نبوده است.

اشتباهات رایج گرومینگ

اشتباه ۱: گرومینگ ماهی یک بار. تیم ۳-۴ اسپرینت تسک جمع می‌کند، سعی می‌کند همه را در ۲ ساعت دقیق کند. نتیجه: نیمی از تسک‌ها ارزیابی‌نشده می‌مانند، Planning تمام روز طول می‌کشد. راه‌حل: گرومینگ باید منظم باشد — ۱ بار در اسپرینت، ۶۰ دقیقه. اگر تسک‌ها زیاد است — یک گرومینگ دوم در وسط اسپرینت اضافه کنید. بهتر است تسک‌های کمتری را با کیفیت گرومینگ کرد تا زیاد — اما سطحی. سرعت: ۳-۵ تسک در یک گرومینگ، هر کدام بحث و ارزیابی کامل دریافت می‌کند.

اشتباه ۲: ارزیابی بدون زمینه. PO تسک «پیاده‌سازی صفحه سبد خرید» را بدون طراحی، بدون API، بدون AC نشان می‌دهد. تیم «چشمی» ارزیابی می‌کند — ۱۳ SP. در Planning مشخص می‌شود که در واقع ۵ SP است (چون صفحه ساده است). راه‌حل: اگر طراحی یا API وجود ندارد، تسک ارزیابی نمی‌شود. PO موظف است قبل از گرومینگ مواد را آماده کند. قاعده: «ماکت نیست — ارزیابی نیست». استثنا: Spike-تسک‌ها — تحقیق عدم قطعیت، آنها جداگانه بدون طراحی ارزیابی می‌شوند (۲-۵ SP بسته به پیچیدگی تحقیق).

اشتباه ۳: گرومینگ به Planning تبدیل می‌شود. تیم شروع به توزیع تسک‌ها بین مجریان و بحث درباره اینکه چه کسی چه کاری انجام می‌دهد می‌کند. راه‌حل: یادآوری کنید که گرومینگ برای دقیق‌سازی است، نه توزیع. توزیع — در Daily پس از شروع اسپرینت. گرومینگ به سوال «چه کاری انجام دهیم؟» پاسخ می‌دهد، Planning — به «کی انجام دهیم؟»، Daily — به «چه کسی انجام می‌دهد؟». مخلوط کردن این سوالات در یک جلسه اثربخشی هر یک را کاهش می‌دهد. Scrum Master باید بحث Planning را متوقف کرده و توجه را به دقیق‌سازی تسک معطوف کند.

اشتباه ۴: نادیده گرفتن Tech Debt. در گرومینگ فقط ویژگی‌های جدید بحث می‌شود، تسک‌های فنی نادیده گرفته می‌شوند. پس از ۳-۴ اسپرینت، بدهی فنی به سطح بحرانی می‌رسد. راه‌حل: در هر گرومینگ حداقل ۱ تسک Tech باید ارزیابی شود. نسبت: به ازای ۳ feature → ۱ تسک فنی. از معیار Tech Debt Ratio استفاده کنید: نسبت تسک‌های Tech به Feature در اسپرینت. مقدار هدف: ۰.۲۵-۰.۳ (۲۵-۳۰٪ زمان روی بدهی فنی). اگر ratio زیر ۰.۲ باشد — سرعت توسعه در اسپرینت‌های بعدی کاهش می‌یابد.