ڈیلی اسٹینڈاپ — یہ کیا ہے، روزانہ میٹنگ کے قواعد اور فوائد

ڈیلی اسٹینڈاپ کیا ہے؟

ڈیلی اسٹینڈاپ — Scrum ٹیم کا ایک مختصر اجلاس جو ہر کام کے دن ایک ہی وقت اور جگہ پر منعقد ہوتا ہے۔ وقت کی حد — 15 منٹ۔ یہ مختلف ناموں سے جانا جاتا ہے: Daily Scrum (Scrum Guide میں)، صبح کی ہم آہنگی، مارننگ سرکل، ڈیلی۔ مقصد ٹیم کی ہم آہنگی، رکاوٹوں کی نشاندہی اور دن کے منصوبوں کو ایڈجسٹ کرنا ہے۔ ڈیلی مینیجر کے لیے رپورٹ نہیں، بلکہ ٹیم کی خود تنظیم کا ایک آلہ ہے۔ میٹنگ کی ساخت ٹیم طے کرتی ہے، مینیجر نہیں۔

«اسٹینڈاپ» کی اصطلاح کی اصل لفظی طور پر میٹنگ کے دوران کھڑے رہنے کی مشق سے آئی ہے: شرکاء بورڈ کے گرد جمع ہوتے ہیں اور بیٹھتے نہیں ہیں۔ یہ عارضی پن کا احساس پیدا کرتا ہے — کوئی بھی 15 منٹ سے زیادہ کھڑا نہیں رہنا چاہتا۔ فزیکل اسٹینڈاپ اب بھی 60% ٹیمیں استعمال کرتی ہیں (Scrum.org 2025 کے مطابق)، باقی Zoom، Slack Huddle یا Teams کے ذریعے ریموٹ فارمیٹ میں منتقل ہو گئی ہیں۔ ریموٹ فارمیٹ میں نظم و ضبط برقرار رکھنا ضروری ہے: کیمرے آن، ملٹی ٹاسکنگ نہیں، جوابات کے بارے میں پہلے سے سوچنے کی تیاری۔

Scrum Guide 2025 Daily Scrum کو ڈیولپرز کے لیے ایک ایونٹ کے طور پر بیان کرتا ہے۔ Product Owner اور Scrum Master شرکت کر سکتے ہیں لیکن لازمی نہیں ہے۔ اگر PO یا SM شرکت کرتے ہیں، تو وہ میٹنگ نہیں چلاتے۔ ٹیم اپنی ساخت خود منتخب کرتی ہے: کلاسک تین سوال یا بورڈ واک۔ اہم نکتہ: ڈیلی Sprint Goal کی طرف پیش رفت کا معائنہ کرنے کے بارے میں ہے، نہ کہ ہر کام کی حیثیت کے بارے میں۔ اگر میٹنگ بورڈ پر کاموں کی گنتی بن جائے، تو ٹیم نے Sprint Goal پر توجہ کھو دی ہے۔

ڈیلی اسٹینڈاپ کے تین سوال

سوال 1: «میں نے کل Sprint Goal حاصل کرنے کے لیے کیا کیا؟» — مکمل شدہ کاموں کا مختصر خلاصہ۔ «APP-123 پر کام کیا» نہیں، بلکہ «لاگ ان اسکرین مکمل کی، PR جائزہ کے لیے بھیجا»۔ «Sprint Goal حاصل کرنے کے لیے» کا جملہ جان بوجھ کر ہے: یہ روزانہ کے کام کو سپرنٹ کے مجموعی مقصد سے جوڑتا ہے۔ اگر کوئی ڈیولپر اپنے کام کا Sprint Goal سے تعلق نہیں دیکھتا، تو یہ اشارہ ہے کہ موجودہ سپرنٹ میں کام کی ضرورت نہیں ہو سکتی۔ موبائل ڈیولپمنٹ میں، کل کے نتائج میں نہ صرف کوڈ بلکہ ٹیسٹ، دستاویزات اور CI/CD کنفیگریشن بھی شامل ہے۔

سوال 2: «میں آج Sprint Goal حاصل کرنے کے لیے کیا کرنے کا منصوبہ بنا رہا ہوں؟» — موجودہ دن کا منصوبہ۔ 2-3 سے زیادہ آئٹم نہیں۔ ایک ڈیولپر کہہ سکتا ہے: «آج میں پروفائل اسکرین کے لیے ViewModel مکمل کروں گا، یونٹ ٹیسٹ لکھوں گا اور اصلی ڈیوائس پر بلڈ چلاؤں گا»۔ اگر منصوبہ «کل» سے میل کھاتا ہے، تو یہ اشارہ ہے کہ کام بہت بڑا ہے اور اسے تقسیم کرنے کی ضرورت ہے۔ دو دن کا اصول: اگر کوئی کام 2 دن کے کام میں مکمل نہیں ہوتا، تو اسے ذیلی کاموں میں تقسیم کیا جانا چاہیے، ورنہ یہ ہفتوں In Progress میں پھنس جائے گا۔

سوال 3: «میری ترقی میں کون سی رکاوٹیں حائل ہیں؟» — سب سے اہم سوال۔ رکاوٹ وہ ہے جسے ڈیولپر خود حل نہیں کر سکتا: جائزے کا انتظار (اگر جائزے کا SLA ختم ہو گیا ہو)، ایمولیٹر کام نہ کر رہا ہو، API تیار نہ ہو، ریپوزٹری تک رسائی درکار ہو۔ اہم: رکاوٹوں کا نام لیا جانا چاہیے لیکن ڈیلی کے دوران حل نہیں کیا جانا چاہیے۔ میٹنگ کے بعد، ڈیولپر اور Scrum Master / مینیجر رکاوٹ کے حل کا بندوبست کرتے ہیں۔ Scrum.org (2025) کے مطابق، موبائل ٹیم کی 70% رکاوٹیں متعلق ہیں: جائزے کا انتظار (30%)، ٹیسٹ ڈیوائسز کی عدم دستیابی (20%) اور بیک اینڈ پر انحصار (20%)۔

اسٹینڈاپ کو صحیح طریقے سے کیسے منعقد کریں

وقت اور جگہ۔ ڈیلی ہر روز ایک ہی وقت میں منعقد ہوتا ہے — عام طور پر کام کے دن کے آغاز میں (9:00-10:00)۔ تقسیم شدہ ٹیموں کے لیے، تمام ٹائم زونز کے لیے آرام دہ وقت منتخب کیا جاتا ہے۔ مدت — سختی سے 15 منٹ۔ ٹائمر لازمی ہے۔ اگر ٹیم وقت پر ختم نہیں کر پاتی، تو مسئلہ ڈیلی میں نہیں بلکہ عمل میں ہے: یا تو بہت زیادہ شرکاء ہیں، یا کاموں پر صرف نام لینے کے بجائے بحث کی جا رہی ہے۔ پنگ پونگ اصول: ہر شریک 60 سیکنڈ سے زیادہ نہیں بولتا۔ جواب دینے کے بعد، اگلے شخص کو بات دیتا ہے۔

بورڈ واک فارمیٹ۔ تین سوالوں کا ایک متبادل: ٹیم باری باری Scrum بورڈ پر کاموں کو منتقل کرتی ہے اور تبدیلیوں پر تبصرہ کرتی ہے۔ ڈیولپر اپنا کام To Do سے لیتا ہے، اسے In Progress میں منتقل کرتا ہے اور کہتا ہے: «APP-123 لے رہا ہوں — آرڈر اسکرین، پرومو کوڈ فیلڈ شامل کر رہا ہوں»۔ بورڈ واک پیش رفت کی بصری سمجھ فراہم کرتا ہے اور «بھولے ہوئے» کاموں کو ظاہر کرتا ہے — جو 3+ دنوں سے حرکت نہیں کر رہے ہیں۔ بورڈ واک ترجیح ہے Jira/Linear استعمال کرنے والی تقسیم شدہ ٹیموں کے لیے — ہر کوئی ایکولوگ سننے کے بجائے بورڈ دیکھتا ہے۔

ریموٹ ٹیموں کے لیے: کیمرے آن ہونے چاہئیں — Microsoft Research (2025) کے مطابق، کیمرہ آن رکھنے سے مشغولیت 40% بڑھ جاتی ہے۔ ٹاسک بورڈ (Jira, Linear, Miro) کے ساتھ مشترکہ اسکرین استعمال کریں۔ رکاوٹیں چیٹ میں لکھیں — اس سے تحریری ریکارڈ بنتا ہے۔ ری ایکشن ایموجیز کی حوصلہ افزائی کریں (صارف کی ہدایت کے علاوہ — ایموجیز استعمال نہیں کی جاتی ہیں) — ساتھی کے پیغام پر انگوٹھا اوپر۔ ڈیلی کے بعد، پارکنگ لاٹ کے لیے 2-3 منٹ لیں: علیحدہ بحث کی ضرورت والے موضوعات فالو اپ میٹنگز کی فہرست میں لکھے جاتے ہیں۔ Scrum Master کی کلیدی مہارت: ڈیلی کے دوران بحث روکنا اور اسے پارکنگ لاٹ میں منتقل کرنا۔

میٹنگز میں عام غلطیاں

غلطی 1: مینیجر کے لیے صورتحال رپورٹ۔ ڈیولپر باری باری Jira میں لکھا پڑھتے ہیں، مینیجر وضاحتی سوالات پوچھتا ہے، میٹنگ 45 منٹ چلتی ہے۔ حل: یاد دلائیں کہ ڈیلی ٹیم کے لیے ہے، مینیجر کے لیے نہیں۔ مینیجر بورڈ پر صورتحال دیکھ سکتا ہے۔ اگر مینیجر سوالات پوچھتا ہے، تو انہیں 1:1 میٹنگز میں منتقل کریں۔ جو ٹیم ڈیلی کو صورتحال رپورٹ میں بدل دیتی ہے، وہ تمام شرکاء کے درمیان ہفتہ وار 2-3 گھنٹے کھو دیتی ہے۔ 8 ڈیولپرز کے ساتھ، یہ ماہانہ 16-24 گھنٹے کام ہے — ایک سال میں ایک پورے سپرنٹ کا نقصان۔

غلطی 2: موقع پر مسائل کا حل۔ ایک ڈیولپر کہتا ہے «gRPC میں ایک مسئلہ ہے — پروجیکٹ بلڈ نہیں ہو رہا» اور پوری ٹیم حل پر بحث کرنے میں 20 منٹ گزارتی ہے۔ حل: رکاوٹ کو پارکنگ لاٹ میں ریکارڈ کریں اور ڈیلی جاری رکھیں۔ میٹنگ کے بعد، متعلقہ افراد (ڈیولپر + جو مدد کر سکتا ہے) کو 10 منٹ کی بحث کے لیے جمع کریں۔ Basecamp (Shape Up) کے مطابق، ڈیلی میں دریافت ہونے والے صرف 20% مسائل پر پوری ٹیم کی بحث کی ضرورت ہوتی ہے۔ باقی دو ڈیولپر 10 منٹ میں حل کر سکتے ہیں۔

غلطی 3: تاخیر اور غیر حاضری۔ کوئی شروع ہونے کے 5 منٹ بعد آتا ہے اور دہرانا پڑتا ہے۔ حل: اصول طے کریں کہ «ڈیلی وقت پر شروع ہوتا ہے، دیر سے آنے والے شامل نہیں ہوتے» یا «دیر سے آنے والا جرمانہ ادا کرتا ہے» (ٹیم کے لیے کافی)۔ اس سے بھی سخت: ڈیلی مقررہ وقت پر ہوتا ہے؛ اگر کوئی منظم طریقے سے دیر سے آتا ہے، تو یہ نظم و ضبط کا مسئلہ ہے جو 1:1 میں حل ہوتا ہے۔ ڈیلی دن کی ہم آہنگی ہے۔ اگر کوئی ڈیولپر اسے چھوڑ دیتا ہے، تو وہ ہم آہنگ نہیں ہے اور ٹیم کے لیے غلط کام کرنے کا خطرہ اٹھاتا ہے۔

غلطی 4: بہت زیادہ شرکاء۔ 15+ افراد کی ٹیم، ہر ایک ایک منٹ بولتا ہے — کل 20+ منٹ۔ حل: ٹیم کو فیچر/ماڈیول کے مطابق ذیلی گروپوں میں تقسیم کریں۔ ہر ذیلی گروپ اپنا ڈیلی منعقد کرتا ہے (5-7 افراد)۔ ہر ذیلی گروپ سے ایک نمائندہ کراس ٹیم اسٹینڈاپ میں شرکت کر سکتا ہے (اگر ٹیموں کے درمیان ہم آہنگی درکار ہو)۔ متبادل: Slack/GeekBot کے ذریعے غیر متزامن اسٹینڈاپ جہاں ہر کوئی لکھتا ہے کہ اس نے کیا کیا / منصوبہ بنایا / رکاوٹیں۔

غیر متزامن اسٹینڈاپ: متبادل

غیر متزامن اسٹینڈاپ — ایک فارمیٹ جہاں شرکاء زبانی میٹنگ کے بجائے چیٹ (Slack، Telegram، Teams) یا خصوصی بوٹ (GeekBot، Standuply، Status Hero) میں اپنے جوابات لکھتے ہیں۔ 3+ گھنٹے کے ٹائم زون فرق والی تقسیم شدہ ٹیموں کے لیے موزوں۔ ہر شریک ایک مقررہ وقت (مثلاً، 11:00 بجے تک) تک اسی تین سوالوں کے جواب دیتا ہے۔ بوٹ جوابات جمع کرتا ہے اور مشترکہ چینل میں ایک خلاصہ شائع کرتا ہے۔ فوائد: لچک، تحریری ریکارڈ، تاخیر کا کوئی مسئلہ نہیں۔

غیر متزامن فارمیٹ کے نقصانات: کوئی لائیو تعامل نہیں — غیر زبانی اشارے کھو جاتے ہیں، رکاوٹوں کی نشاندہی مشکل ہے (ڈیولپر کسی مسئلے کے بارے میں نہیں لکھ سکتا)۔ چیٹ میں لکھی گئی رکاوٹ دن کے آخر تک کسی کا دھیان نہیں جا سکتی۔ GitLab (2025) کے مطابق، غیر متزامن اسٹینڈاپ پر منتقل ہونے والی 40% ٹیمیں 3 ماہ کے اندر زبانی پر واپس آ گئیں۔ سفارش: ہائبرڈ استعمال کریں — ہفتے میں 3 دن زبانی اسٹینڈاپ (پیر، بدھ، جمعہ)، 2 دن غیر متزامن (منگل، جمعرات)۔ یا: ہفتے میں 1-2 بار زبانی اسٹینڈاپ، باقی دنوں میں غیر متزامن۔

غیر متزامن اسٹینڈاپ کے اوزار: GeekBot (Slack) — تین سوال پوچھتا ہے اور خلاصہ شائع کرتا ہے؛ Standuply — Jira کے ساتھ انضمام اور خودکار ٹریکنگ فراہم کرتا ہے؛ Status Hero — حالات جمع کرتا ہے اور انتظامیہ کے لیے ہفتہ وار رپورٹیں تیار کرتا ہے۔ آلے کا انتخاب ٹیم کی ثقافت پر منحصر ہے: اسٹارٹ اپ میں Slack بوٹ کافی ہے؛ کارپوریٹ ماحول میں، Standuply کارپوریٹ عمل کے انضمام کے ساتھ درکار ہو سکتا ہے۔ اہم اصول: فارمیٹ سے قطع نظر، جوابات پوری ٹیم کو دکھائی دینے چاہئیں، نہ کہ صرف مینیجر کو۔ شفافیت Agile کی بنیادی قدر ہے۔

موبائل ٹیم کے لیے ڈیلی کی خصوصیات

موبائل ٹیم کو ڈیلی کے دوران مخصوص رکاوٹوں کا سامنا کرنا پڑتا ہے۔ اہم: CI میں پروجیکٹ بلڈ (Gradle بلڈ 20+ منٹ لے سکتا ہے — اگر ٹوٹ جائے، تو ڈیولپر ڈیبگنگ میں ایک گھنٹہ کھو دیتا ہے)، TestFlight / Firebase App Distribution کا انتظار (ٹیسٹرز کو بلڈ شائع کرنے میں 30-60 منٹ لگتے ہیں)، ایمولیٹر اور سمیلیٹر کے مسائل (Android Emulator کو KVM/HAXM درکار ہے، iOS Simulator صرف Mac پر)۔ موبائل ٹیم کا ڈیلی میں بلڈ کی حیثیت کا فوری چیک شامل ہونا چاہیے: «کیا بلڈ پاس ہو رہا ہے؟ کیا تمام ٹیسٹ سبز ہیں؟»۔

کراس پلیٹ فارم پروجیکٹس (Flutter, React Native) کے لیے، ڈیلی میں مشترکہ کوڈ کی حالت کے بارے میں سوال شامل ہو سکتا ہے۔ اگر دو ڈیولپر بیک وقت ایک ہی Dart فائل میں ترمیم کر رہے ہیں اور ایک تبدیلیوں کو ضم کرتا ہے، تو دوسرے کو تنازعات کا سامنا کرنا پڑے گا۔ مشورہ: پلیٹ فارم (Android / iOS / Shared) کے لحاظ سے تقسیم شدہ بورڈ کے ساتھ بورڈ واک استعمال کریں۔ اس سے یہ دیکھنے میں مدد ملتی ہے کہ کون کہاں کام کر رہا ہے اور کیا تبدیلیاں اوورلیپ ہو رہی ہیں۔ Flutter پروجیکٹس کے لیے، Platform Channel، BLoC/Cubit، UI اور Tests کالم والا بورڈ استعمال کریں۔

ریلیز کی تیاری — ڈیلی میں موبائل ڈیولپمنٹ کا ایک اور مخصوص نکتہ۔ ریلیز سے 3-5 دن پہلے، سوال شامل کریں: «کیا بلڈ ریلیز کے لیے تیار ہے؟ کیا تمام میٹا ڈیٹا (آئیکن، اسکرین شاٹس، وضاحتیں) اپ ڈیٹ ہو چکے ہیں؟» اس سے ان حالات کو روکتا ہے جہاں ڈیولپر ریلیز کے دن کوڈ ختم کرتے ہیں جبکہ بلڈ اور اشاعت میں مزید 3-4 گھنٹے لگتے ہیں۔ ریلیز ٹریکر — چیک لسٹ والا ایک علیحدہ بورڈ: versionCode/versionName اپ ڈیٹ، ProGuard چیک، AAB دستخط، ڈیولپر کنسول میں اپ لوڈ، ریلیز نوٹس لکھنا۔