ডেইলি স্ট্যান্ডআপ — এটি কী, দৈনিক সভার নিয়ম এবং উপকারিতা

ডেইলি স্ট্যান্ডআপ কী?

ডেইলি স্ট্যান্ডআপ — 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 সই, ডেভেলপার কনসোলে আপলোড, রিলিজ নোট লেখা।