اسپرینت در توسعه موبایل: مفهوم، مدت‌زمان و برنامه‌ریزی

اسپرینت در توسعه چیست؟

اسپرینت — یک بازه زمانی (timebox) با مدت ثابت است که در پایان آن تیم یک افزایش آماده برای استفاده از محصول ارائه می‌دهد. مفهوم اسپرینت اساس Scrum است، اما در سایر چارچوب‌های چابک نیز استفاده می‌شود. در توسعه موبایل، افزایش یک بیلد از برنامه است که می‌توان روی دستگاه نصب کرد، آزمایش کرد و به ذی‌نفعان نشان داد. اسپرینت قابل تمدید نیست — اگر وظایف انجام نشوند، به اسپرینت بعدی منتقل می‌شوند.

ویژگی کلیدی اسپرینت مدت ثابت آن است. تیم پس از تأیید، هدف اسپرینت را تغییر نمی‌دهد. این امر قابلیت پیش‌بینی را فراهم می‌کند: ذی‌نفعان می‌دانند چه زمانی نتیجه را دریافت خواهند کرد. در داخل اسپرینت، تیم خود تصمیم می‌گیرد چگونه کار را توزیع کند. Scrum Master از تیم در برابر دخالت‌های خارجی محافظت می‌کند — وظایف جدید به اسپرینت جاری اضافه نمی‌شوند. طبق Scrum Guide 2025، این تنها راه برای حفظ سرعت پایدار توسعه (sustainable pace) است.

اسپرینت از چهار رویداد اجباری تشکیل شده است: Sprint Planning (برنامه‌ریزی)، Daily Scrum (هماهنگی روزانه)، Sprint Review (نمایش نتایج)، Sprint Retrospective (تحلیل فرآیند). بین آنها کار اصلی انجام می‌شود: پیاده‌سازی وظایف، تست، بازبینی کد. مدت هر رویداد متناسب با طول اسپرینت است: برای اسپرینت ۲ هفته‌ای Planning — ۴ ساعت، Review — ۲ ساعت، Retro — ۱.۵ ساعت، Daily — ۱۵ دقیقه. مجموعاً مراسم حدود ۸ ساعت در هر اسپرینت — ۱۰٪ از زمان کاری تیم — را اشغال می‌کنند.

مراسم Scrum اسپرینت

مراسم Scrum (Ceremonies/Events) — جلسات ساختاریافته تیم در چارچوب اسپرینت. Sprint Planning — در ابتدا، Daily Scrum — هر روز، Sprint Review و Retrospective — در پایان. همه رویدادها timebox (محدودیت زمانی) دارند. Scrum Master بر رعایت timebox و تمرکز نظارت می‌کند. در هر مراسم، کل تیم Scrum شرکت می‌کند: Product Owner، Scrum Master، توسعه‌دهندگان. استثنا — Daily Scrum (فقط توسعه‌دهندگان شرکت می‌کنند، PO و SM — اختیاری).

ارتباط مراسم با مراحل اسپرینت: Planning جهت را تعیین می‌کند (چه کاری و چگونه انجام دهیم)، Daily هماهنگ می‌کند (چه کسی چه کاری انجام می‌دهد، چه موانعی وجود دارد)، Review نتیجه را نشان می‌دهد (چه انجام شده، چه نشده)، Retrospective فرآیند را بهبود می‌بخشد (چگونه اسپرینت بعدی را بهتر کنیم). حذف Retrospective — رایج‌ترین اشتباه تیم‌ها: وقتی مهلت‌ها فشرده هستند، ابتدا Retro قربانی می‌شود. این امر به رکود فرآیندها و تکرار همان اشتباهات منجر می‌شود. تحقیقات Scrum.org (2025) نشان می‌دهد: تیم‌هایی که هر ۲ هفته Retro برگزار می‌کنند، ۳۵٪ سریع‌تر velocity را بهبود می‌بخشند.

Sprint Planning: برنامه‌ریزی تکرار

Sprint Planning — جلسه تیم در ابتدای اسپرینت که در آن مشخص می‌شود چه کاری انجام خواهد شد و چگونه. Product Owner وظایف اولویت‌دار را از Product Backlog ارائه می‌دهد. تیم ظرفیت (capacity) را با در نظر گرفتن مرخصی‌ها، جلسات، بدهی فنی ارزیابی کرده و وظایفی را که می‌تواند در اسپرینت انجام دهد انتخاب می‌کند. نتیجه Planning — Sprint Goal (هدف اسپرینت) و Sprint Backlog (فهرست وظایف). Sprint Goal به صورت یک جمله کوتاه تدوین می‌شود: «پیاده‌سازی صفحه سفارش و یکپارچه‌سازی پرداخت از طریق SBP».

Velocity — سرعت تیم که در استوری‌پوینت در هر اسپرینت اندازه‌گیری می‌شود. میانگین ۳-۵ اسپرینت اخیر. طبق Scrum.org (2025)، یک تیم ۵ نفره از توسعه‌دهندگان موبایل (۳ Android + ۲ iOS) velocity ۲۵-۴۰ SP در یک اسپرینت ۲ هفته‌ای دارد. Planning از velocity به عنوان حد بالایی استفاده می‌کند — ۱۰-۱۵٪ کمتر می‌گیرند برای وظایف پیش‌بینی‌نشده (code review، حوادث، کمک به تیم‌های دیگر). Capacity vs Velocity: capacity — «ساعت-نفر» است، velocity — «استوری‌پوینت». Capacity مرخصی‌ها، مرخصی استعلاجی، جلسات را در نظر می‌گیرد. نرخ تلفات معمول — ۲۵-۳۰٪ از زمان کاری صرف فعالیت‌های غیر کدنویسی می‌شود.

برنامه‌ریزی به دو بخش تقسیم می‌شود: «چه چیزی» (PO وظایف را توضیح می‌دهد، تیم شفاف‌سازی می‌کند) — ۲ ساعت، و «چگونه» (تیم تجزیه و ارزیابی می‌کند) — ۲ ساعت. برای پروژه‌های موبایل در بخش «چگونه» موارد زیر بحث می‌شود: سازگاری با نسخه‌های Android/iOS، نیاز به feature flag، تأثیر بر اندازه APK/IPA، مجوزهای جدید. تکنیک Planning Poker برای ارزیابی استفاده می‌شود: هر توسعه‌دهنده ارزیابی خود را به استوری‌پوینت (۱، ۲، ۳، ۵، ۸، ۱۳) ارائه می‌دهد. اختلاف بیش از ۲ واحد — علت را بحث می‌کنند. این کار ریسک‌های پنهان را در مرحله برنامه‌ریزی آشکار می‌کند، نه در وسط اسپرینت.

اجرای اسپرینت: Daily Standup و ردیابی

Daily Scrum (Standup) — جلسه روزانه ۱۵ دقیقه‌ای برای هماهنگی تیم. هر شرکت‌کننده به سه سؤال پاسخ می‌دهد: «دیروز چه انجام شد؟»، «امروز چه برنامه‌ای دارم؟»، «چه موانعی وجود دارد؟». Daily — گزارش وضعیت برای مدیر نیست، بلکه ابزاری برای خودسازماندهی تیم است. اگر در Daily مشخص شود که دو توسعه‌دهنده روی یک وظیفه کار می‌کنند — این سیگنالی برای reorganize کردن است. مهم: Daily مشکلات را حل نمی‌کند، بلکه آنها را شناسایی می‌کند — برای حل آنها جلسه جداگانه‌ای بعد از Daily تشکیل می‌شود.

Scrum Board (تخته اسپرینت) — بصری‌سازی Sprint Backlog. ستون‌ها: To Do / In Progress / In Review / Done. هر وظیفه روی تخته حرکت می‌کند. Burndown Chart — نمودار کار باقیمانده بر اساس روزهای اسپرینت. burndown ایده‌آل — یک خط مستقیم از total SP تا ۰. burndown واقعی — نمودار پله‌ای با در نظر گرفتن تکمیل وظایف. burndown نزولی (زیر خط ایده‌آل) — عقب هستیم. سیگنال مشکل: اگر تا اواسط اسپرینت کمتر از ۳۰٪ وظایف انجام شده باشد — نیاز به تنظیم مجدد است. احتمالاً ریسک‌ها در نظر گرفته نشده یا وظایف بیش از حد ارزیابی شده‌اند.

برای توسعه موبایل، ردیابی اسپرینت تحت تأثیر عوامل خاصی قرار می‌گیرد: زمان بیلد (بیلد پروژه Android در CI ممکن است ۳۰+ دقیقه طول بکشد)، انتظار برای تأیید App Store / Google Play (اگر نیاز به انتشار بیلد برای تسترها از طریق TestFlight باشد)، سازگاری با دستگاه‌های مختلف (تست روی ۱۰+ مدل زمان می‌برد). توصیه: ۱ روز بافر در پایان اسپرینت برای تست نهایی و بیلد release در نظر بگیرید. این کار ریسک اسپرینت ناقص را طبق Mind the Product (2025) تا ۴۰٪ کاهش می‌دهد.

Sprint Review و Retrospective

Sprint Review — نمایش افزایش به ذی‌نفعان. تیم بیلد کارآمد برنامه را نشان می‌دهد، نه اسلایدها. مدت — ۲ ساعت برای اسپرینت ۲ هفته‌ای. Product Owner مطابقت با Acceptance Criteria را بررسی می‌کند. ذی‌نفعان بازخورد می‌دهند که می‌تواند بر Product Backlog تأثیر بگذارد. Review — گزارش نیست، بلکه یک گفتوگو است: ذی‌نفعان می‌توانند سؤالاتی بپرسند و تغییراتی پیشنهاد دهند. قاعده کلیدی: Sprint Review درباره محصول است، نه فرآیند. آنچه به دست آمده را نشان می‌دهیم، نه اینکه چگونه انجام شده است.

Sprint Retrospective — جلسه داخلی تیم برای تحلیل اسپرینت گذشته. قالب: Start Doing (چه چیزی را شروع کنیم)، Stop Doing (چه چیزی را متوقف کنیم)، Continue Doing (چه چیزی را ادامه دهیم). مدت — ۱.۵ ساعت برای اسپرینت ۲ هفته‌ای. Retrospective — فضای امن برای بحث درباره مشکلات. قاعده: در Retro جزئیات فنی بحث نمی‌شود (برای آن جلسات فنی وجود دارد). فقط فرآیند، ارتباطات، ابزارها، فرهنگ. Scrum Master جلسه را تسهیل می‌کند و مطمئن می‌شود هر شرکت‌کننده نظر خود را بیان کند.

نتیجه Retrospective — ۱-۳ بهبود برای اسپرینت بعدی. اگر تیم مشکل «بازبینی کد بیش از حد طولانی» را شناسایی کرد — action item: «تعیین SLA برای بازبینی — ۴ ساعت. اگر بازبینی به موقع انجام نشد — توسعه‌دهنده در Slack یادآوری می‌کند». Action Items باید مشخص، قابل اندازه‌گیری و به شخص خاصی واگذار شده باشند. طبق Atlassian (2025)، تیم‌هایی که action items Retro خود را اجرا می‌کنند، velocity را ۱۵-۲۵٪ در ۳-۴ اسپرینت بهبود می‌بخشند. آنهایی که اجرا نمی‌کنند — درجا می‌زنند.

چگونه مدت اسپرینت را انتخاب کنیم

۲ هفته — استاندارد برای توسعه موبایل. تعادل بهینه بین قابلیت پیش‌بینی و انعطاف‌پذیری. فرصت می‌دهد: برنامه‌ریزی، پیاده‌سازی ۳-۵ ویژگی متوسط، تست، نمایش نتیجه. ۱ هفته — برای تیم‌هایی با بلوغ فرآیندی بالا و CI/CD. نیاز به تصمیم‌گیری سریع، حداقل بوروکراسی. مناسب برای استارتاپ‌ها در مرحله اولیه که نیاز به آزمایش سریع دارند. نقطه ضعف: سربار بالا برای مراسم (هر هفته Planning + Review + Retro = ۷.۵ ساعت).

۳-۴ هفته — برای پروژه‌های پیچیده که نیاز به یکپارچه‌سازی با سخت‌افزار (wearables, IoT, BLE)، تأیید طولانی فروشگاه‌ها یا مهاجرت‌های بزرگ (مثلاً انتقال از RxJava به Coroutines) دارند. اسپرینت‌های طولانی زمان بیشتری برای تست فراهم می‌کنند، اما ریسک «اثر آبشاری» را افزایش می‌دهند — تیم انعطاف‌پذیری چابک را از دست می‌دهد. توصیه Scrum Guide: از ۱ ماه تجاوز نکنید. اگر اسپرینت طولانی‌تر باشد — در Review زمینه زیادی وجود خواهد داشت، ذی‌نفعان نمی‌توانند بازخورد کیفی ارائه دهند.

مشکلات رایج اسپرینت‌ها

مشکل ۱: افزایش محدوده (Scope Creep). در وسط اسپرینت، Product Owner یک وظیفه جدید «فوری و مهم» اضافه می‌کند. تیم موافقت می‌کند — و اسپرینت شکست می‌خورد. راه‌حل: Sprint Goal — یک قرارداد است. هر تغییری نیاز به بازنگری Sprint Goal دارد و این فقط در موارد اضطراری ممکن است. وظیفه جدید به Product Backlog و اسپرینت بعدی می‌رود. اگر وظیفه واقعاً حیاتی است — Sprint Goal قدیمی لغو می‌شود، اسپرینت دوباره برنامه‌ریزی می‌شود، اما این استثناست نه رویه. فراوانی scope creep بیش از ۱ بار در ۳ اسپرینت — نشانه ضعف Product Owner است.

مشکل ۲: وظایف ناتمام. در پایان اسپرینت ۵۰٪ وظایف در In Progress، ۲۰٪ در Review، فقط ۳۰٪ Done. دلایل: بیش‌برآوردی ظرفیت، کم‌برآوردی پیچیدگی، باگ‌های پیش‌بینی‌نشده. راه‌حل: علت را در Retro تحلیل کنید. اگر به طور سیستماتیک نمی‌رسید — تعداد وظایف را در Planning افزایش ندهید، بلکه کاهش دهید. تیم‌هایی که ۲۰٪ وظایف کمتری می‌گیرند، درصد تکمیل بالاتری دارند (۸۰٪+ در مقابل ۵۰-۶۰٪). چک‌لیست برای Planning: برای هر وظیفه Acceptance Criteria، Definition of Ready و وابستگی به وظایف دیگر را بررسی کنید.

مشکل ۳: Retro صوری. تیم Retro را برای فرمالیته انجام می‌دهد — ۱۵ دقیقه، کلی‌گویی، بدون action item. راه‌حل: هر بار قالب Retro را تغییر دهید. روش‌ها: Sailboat (چه چیزی کند می‌کند، چه چیزی سرعت می‌بخشد)، Start / Stop / Continue، Happy / Sad / Mad، 4Ls (Liked, Learned, Lacked, Longed For). Action items را با مهلت و مسئول تعیین کنید. در ابتدای Retro بعدی، اجرای action items قبلی را بررسی کنید. طبق Atlassian (2025)، تیم‌هایی که از قالب‌های مختلف Retro استفاده می‌کنند، ۵۰٪ بینش مفید بیشتری تولید می‌کنند.