মোবাইল ডেভেলপমেন্টে স্প্রিন্ট: সারমর্ম, সময়কাল এবং পরিকল্পনা

ডেভেলপমেন্টে স্প্রিন্ট কী?

স্প্রিন্ট হল একটি নির্দিষ্ট সময়কালের টাইমবক্স যার শেষে দল ব্যবহারের জন্য প্রস্তুত পণ্য বৃদ্ধি সরবরাহ করে। স্প্রিন্টের ধারণা Scrum-এর ভিত্তি, কিন্তু এটি অন্যান্য Agile ফ্রেমওয়ার্কেও ব্যবহৃত হয়। মোবাইল ডেভেলপমেন্টে, বৃদ্ধি হল অ্যাপ্লিকেশনের একটি বিল্ড যা ডিভাইসে ইনস্টল করা, পরীক্ষা করা এবং স্টেকহোল্ডারদের দেখানো যায়। স্প্রিন্ট বাড়ানো যায় না — যদি কাজগুলি সম্পূর্ণ না হয়, সেগুলি পরবর্তী স্প্রিন্টে স্থানান্তরিত হয়।

স্প্রিন্টের মূল বৈশিষ্ট্য হল নির্দিষ্ট সময়কাল। দল অনুমোদনের পরে স্প্রিন্ট লক্ষ্য পরিবর্তন করে না। এটি পূর্বাভাসযোগ্যতা প্রদান করে: স্টেকহোল্ডাররা জানেন কখন তারা ফলাফল পাবেন। স্প্রিন্টের মধ্যে, দল সিদ্ধান্ত নেয় কীভাবে কাজ বিতরণ করতে হবে। Scrum Master দলকে বাহ্যিক হস্তক্ষেপ থেকে রক্ষা করে — বর্তমান স্প্রিন্টে নতুন কাজ যোগ করা হয় না। Scrum Guide 2025 অনুযায়ী, টেকসই উন্নয়ন গতি বজায় রাখার এটাই একমাত্র উপায়।

একটি স্প্রিন্ট চারটি বাধ্যতামূলক ইভেন্ট নিয়ে গঠিত: Sprint Planning, Daily Scrum (দৈনিক সমন্বয়), Sprint Review (ফলাফল প্রদর্শন), Sprint Retrospective (প্রক্রিয়া বিশ্লেষণ)। এগুলোর মধ্যে মূল কাজ: কাজ বাস্তবায়ন, পরীক্ষা, কোড পর্যালোচনা। সময়কাল প্রতিটি ইভেন্টের স্প্রিন্ট দৈর্ঘ্যের সাথে সরাসরি সমানুপাতিক: 2-সপ্তাহের স্প্রিন্টের জন্য, Planning 4 ঘন্টা, Review 2 ঘন্টা, Retro 1.5 ঘন্টা, Daily 15 মিনিট। মোট রিচুয়াল প্রতি স্প্রিন্টে প্রায় 8 ঘন্টা সময় নেয় — দলের কাজের সময়ের 10%।

স্প্রিন্টের Scrum রিচুয়াল

Scrum রিচুয়াল (অনুষ্ঠান/ইভেন্ট) হল স্প্রিন্টের মধ্যে কাঠামোবদ্ধ দল মিটিং। Sprint Planning শুরুতে, Daily Scrum প্রতিদিন, Sprint Review এবং Retrospective শেষে। সমস্ত ইভেন্টের একটি টাইমবক্স থাকে। Scrum Master টাইমবক্স এবং ফোকাস মেনে চলা নিশ্চিত করে। সম্পূর্ণ Scrum দল প্রতিটি রিচুয়ালে অংশগ্রহণ করে: Product Owner, Scrum Master, ডেভেলপাররা। ব্যতিক্রম হল Daily Scrum (শুধুমাত্র ডেভেলপাররা অংশগ্রহণ করে, PO এবং SM ঐচ্ছিক)।

রিচুয়ালগুলির স্প্রিন্ট ধাপের সাথে সংযোগ: Planning দিক নির্ধারণ করে (কী এবং কীভাবে করি), Daily সমন্বয় করে (কে কী করছে, কী কী বাধা আছে), Review ফলাফল দেখায় (কী করা হয়েছে, কী করা হয়নি), Retrospective প্রক্রিয়া উন্নত করে (কীভাবে পরবর্তী স্প্রিন্ট আরও ভাল করা যায়)। পূর্ববর্তী বাদ দেওয়া সবচেয়ে সাধারণ দলগত ভুল: যখন সময়সীমা টাইট থাকে, প্রথমে Retro-কে বলি দেওয়া হয়। এটি প্রক্রিয়াগুলির স্থবিরতা এবং একই ভুলের পুনরাবৃত্তির দিকে নিয়ে যায়। Scrum.org (2025) এর গবেষণা দেখায়: প্রতি 2 সপ্তাহে Retro করা দলগুলি ভেলোসিটি 35% দ্রুত উন্নত করে।

Sprint Planning: পুনরাবৃত্তি পরিকল্পনা

Sprint Planning হল স্প্রিন্টের শুরুতে দলের মিটিং যেখানে নির্ধারণ করা হয় কী করা হবে এবং কীভাবে। Product Owner Product Backlog থেকে অগ্রাধিকার কাজ উপস্থাপন করে। দল ক্ষমতা (ছুটি, মিটিং, টেকনিক্যাল ডেট বিবেচনা করে উপলব্ধ সময়) মূল্যায়ন করে এবং সেই কাজগুলি নির্বাচন করে যা স্প্রিন্টের সময় সম্পূর্ণ করতে পারে। Planning-এর ফলাফল হল Sprint Goal (স্প্রিন্ট লক্ষ্য) এবং Sprint Backlog (কাজের তালিকা)। Sprint Goal একটি সংক্ষিপ্ত বাক্য হিসাবে প্রণয়ন করা হয়: “অর্ডার স্ক্রিন এবং SBP-এর মাধ্যমে পেমেন্ট ইন্টিগ্রেশন বাস্তবায়ন করুন।”

ভেলোসিটি হল প্রতি স্প্রিন্টে স্টোরি পয়েন্টে মাপা দলের গতি। শেষ 3-5 স্প্রিন্টের গড়। Scrum.org (2025) অনুযায়ী, 5 মোবাইল ডেভেলপারের (3 Android + 2 iOS) একটি দলের ভেলোসিটি 2-সপ্তাহের স্প্রিন্টে 25-40 SP। Planning ভেলোসিটিকে উপরের সীমা হিসাবে ব্যবহার করে — অপ্রত্যাশিত কাজের (কোড পর্যালোচনা, ঘটনা, অন্যান্য দলকে সাহায্য) জন্য 10-15% কম নেয়। ক্ষমতা বনাম ভেলোসিটি: ক্ষমতা হল “ব্যক্তি-ঘন্টা”, ভেলোসিটি হল “স্টোরি পয়েন্ট”। ক্ষমতা ছুটি, অসুস্থ ছুটি, মিটিং বিবেচনা করে। সাধারণ ক্ষতির হার কাজের সময়ের 25-30% নন-কোড কার্যকলাপে ব্যয় হয়।

Planning দুটি ভাগে বিভক্ত: “কী” (PO কাজগুলি বর্ণনা করে, দল স্পষ্ট করে) — 2 ঘন্টা, এবং “কীভাবে” (দল বিভক্ত এবং মূল্যায়ন করে) — 2 ঘন্টা। মোবাইল প্রকল্পের জন্য, “কীভাবে”-এ আলোচনা হয়: Android/iOS সংস্করণের সাথে সামঞ্জস্য, ফিচার ফ্ল্যাগের প্রয়োজনীয়তা, APK/IPA আকারের উপর প্রভাব, নতুন অনুমতি। Planning Poker কৌশল মূল্যায়নের জন্য ব্যবহৃত হয়: প্রতিটি ডেভেলপার স্টোরি পয়েন্টে (1, 2, 3, 5, 8, 13) তাদের মূল্যায়ন দেয়। 2 ইউনিটের বেশি পার্থক্য কারণ আলোচনা শুরু করে। এটি পরিকল্পনা পর্যায়ে লুকানো ঝুঁকি প্রকাশ করে, স্প্রিন্টের মাঝখানে নয়।

স্প্রিন্ট নির্বাহ: Daily Standup এবং ট্র্যাকিং

Daily Scrum (Standup) হল দল সমন্বয়ের জন্য দৈনিক 15 মিনিটের মিটিং। প্রতিটি অংশগ্রহণকারী তিনটি প্রশ্নের উত্তর দেয়: “গতকাল কী করা হয়েছে?”, “আজ কী করার পরিকল্পনা?”, “কী বাধা আছে?” Daily ম্যানেজারের জন্য স্ট্যাটাস রিপোর্ট নয়, বরং দল স্ব-সংগঠনের একটি হাতিয়ার। যদি Daily-তে দেখা যায় যে দুজন ডেভেলপার একই কাজে কাজ করছে — এটি পুনর্বিন্যাসের সংকেত। গুরুত্বপূর্ণ: Daily সমস্যা সমাধান করে না বরং চিহ্নিত করে — সমাধানের জন্য Daily-এর পরে আলাদা মিটিং ডাকা হয়।

Scrum Board (স্প্রিন্ট বোর্ড) হল Sprint Backlog-এর ভিজুয়ালাইজেশন। কলাম: To Do / In Progress / In Review / Done। প্রতিটি কাজ বোর্ড জুড়ে চলে। Burndown Chart হল স্প্রিন্টের দিন অনুযায়ী অবশিষ্ট কাজের গ্রাফ। আদর্শ বার্নডাউন হল মোট SP থেকে 0 পর্যন্ত একটি সরল রেখা। প্রকৃত বার্নডাউন হল কাজ সমাপ্তির বিবরণ সহ একটি ধাপযুক্ত গ্রাফ। নিচের দিকে পড়া বার্নডাউন (আদর্শ রেখার নীচে) মানে আমরা পিছিয়ে আছি। সমস্যা সংকেত: যদি স্প্রিন্টের মাঝামাঝি 30% এর কম কাজ সম্পন্ন হয় — সমন্বয় প্রয়োজন। সম্ভবত ঝুঁকি বিবেচনা করা হয়নি বা কাজগুলি অতিমূল্যায়িত হয়েছে।

মোবাইল ডেভেলপমেন্টের জন্য, স্প্রিন্ট ট্র্যাকিং নির্দিষ্ট কারণগুলির দ্বারা প্রভাবিত হয়: বিল্ড সময় (CI-তে Android প্রকল্প বিল্ড 30+ মিনিট সময় নিতে পারে), App Store / Google Play মডারেশনের জন্য অপেক্ষা (যদি TestFlight-এর মাধ্যমে টেস্টারদের কাছে বিল্ড প্রকাশ করার প্রয়োজন হয়), বিভিন্ন ডিভাইসের সাথে সামঞ্জস্য (10+ মডেলে পরীক্ষা করতে সময় লাগে)। টিপ: চূড়ান্ত পরীক্ষা এবং রিলিজ বিল্ড অ্যাসেম্বলির জন্য স্প্রিন্টের শেষে 1 দিনের বাফার বরাদ্দ করুন। এটি Mind the Product (2025) অনুযায়ী অসম্পূর্ণ স্প্রিন্টের ঝুঁকি 40% কমায়।

Sprint Review এবং Retrospective

Sprint Review হল স্টেকহোল্ডারদের কাছে বৃদ্ধির প্রদর্শন। দল একটি কার্যকরী অ্যাপ্লিকেশন বিল্ড দেখায়, স্লাইড নয়। 2-সপ্তাহের স্প্রিন্টের জন্য সময়কাল 2 ঘন্টা। Product Owner Acceptance Criteria মেনে চলা পরীক্ষা করে। স্টেকহোল্ডাররা প্রতিক্রিয়া প্রদান করে যা Product Backlog-কে প্রভাবিত করতে পারে। Review রিপোর্ট নয় বরং সংলাপ: স্টেকহোল্ডাররা প্রশ্ন জিজ্ঞাসা করতে এবং পরিবর্তনের পরামর্শ দিতে পারেন। মূল নিয়ম: Sprint Review পণ্য সম্পর্কে, প্রক্রিয়া সম্পর্কে নয়। কী অর্জন করা হয়েছে তা দেখান, কীভাবে করা হয়েছে তা নয়।

Sprint Retrospective হল বিগত স্প্রিন্ট বিশ্লেষণের জন্য অভ্যন্তরীণ দল মিটিং। ফরম্যাট: Start Doing (কী শুরু করবেন), Stop Doing (কী বন্ধ করবেন), Continue Doing (কী চালিয়ে যাবেন)। 2-সপ্তাহের স্প্রিন্টের জন্য সময়কাল 1.5 ঘন্টা। Retrospective সমস্যা আলোচনার জন্য একটি নিরাপদ স্থান। নিয়ম: Retro-তে প্রযুক্তিগত বিবরণ আলোচিত হয় না (এর জন্য প্রযুক্তিগত মিটিং আছে)। শুধুমাত্র প্রক্রিয়া, যোগাযোগ, সরঞ্জাম, সংস্কৃতি। Scrum Master মিটিং সহজতর করে এবং নিশ্চিত করে প্রতিটি অংশগ্রহণকারী কথা বলে।

Retrospective-এর ফলাফল হল পরবর্তী স্প্রিন্টের জন্য 1-3 উন্নতি। যদি দল “কোড পর্যালোচনা খুব বেশি সময় নেয়” সমস্যা চিহ্নিত করে — অ্যাকশন আইটেম: “পর্যালোচনার জন্য SLA নির্ধারণ করুন — 4 ঘন্টা। যদি সময়মতো পর্যালোচনা না করা হয় — ডেভেলপার Slack-এ মনে করিয়ে দেয়।” অ্যাকশন আইটেম নির্দিষ্ট, পরিমাপযোগ্য এবং নির্দিষ্ট ব্যক্তিকে অর্পিত হতে হবে। Atlassian (2025) অনুযায়ী, যে দলগুলি তাদের Retro অ্যাকশন আইটেমগুলি সম্পন্ন করে, তারা 3-4 স্প্রিন্টে ভেলোসিটি 15-25% উন্নত করে। যারা সম্পন্ন করে না — তারা স্থবির থাকে।

কীভাবে স্প্রিন্ট সময়কাল নির্বাচন করবেন

2 সপ্তাহ মোবাইল ডেভেলপমেন্টের জন্য মানক। পূর্বাভাসযোগ্যতা এবং নমনীয়তার মধ্যে সর্বোত্তম ভারসাম্য। পর্যাপ্ত সময়: পরিকল্পনা, 3-5 মাঝারি বৈশিষ্ট্য বাস্তবায়ন, পরীক্ষা, ফলাফল দেখানোর জন্য। 1 সপ্তাহ উচ্চ প্রক্রিয়া পরিপক্কতা এবং CI/CD সহ দলগুলির জন্য। দ্রুত সিদ্ধান্ত, ন্যূনতম আমলাতন্ত্র প্রয়োজন। প্রাথমিক পর্যায়ের স্টার্টআপগুলির জন্য উপযুক্ত যাদের দ্রুত পরীক্ষা করার প্রয়োজন। অসুবিধা: রিচুয়ালগুলিতে উচ্চ ওভারহেড (প্রতি সপ্তাহে Planning + Review + Retro = 7.5 ঘন্টা)।

3-4 সপ্তাহ জটিল প্রকল্পগুলির জন্য যাতে হার্ডওয়্যার ইন্টিগ্রেশন (wearables, IoT, BLE ডিভাইস), দীর্ঘ স্টোর মডারেশন বা বড় মাইগ্রেশন (যেমন, RxJava থেকে Coroutines-এ স্থানান্তর) অন্তর্ভুক্ত। দীর্ঘ স্প্রিন্ট পরীক্ষার জন্য বেশি সময় দেয় কিন্তু “ওয়াটারফল প্রভাব”-এর ঝুঁকি বাড়ায় — দল Agile নমনীয়তা হারায়। Scrum Guide সুপারিশ: 1 মাসের বেশি নয়। যদি স্প্রিন্ট দীর্ঘ হয়, Review-এ খুব বেশি প্রসঙ্গ থাকবে এবং স্টেকহোল্ডাররা গুণগত প্রতিক্রিয়া দিতে পারবেন না।

স্প্রিন্টের সাধারণ সমস্যা

সমস্যা 1: স্কোপ ক্রিপ (Scope Creep)। স্প্রিন্টের মাঝখানে, Product Owner একটি নতুন “জরুরি এবং গুরুত্বপূর্ণ” কাজ যোগ করে। দল সম্মত হয় — এবং স্প্রিন্ট ব্যর্থ হয়। সমাধান: Sprint Goal একটি চুক্তি। যেকোনো পরিবর্তনের জন্য Sprint Goal পুনর্বিবেচনা প্রয়োজন, যা শুধুমাত্র জরুরি ক্ষেত্রে সম্ভব। নতুন কাজ Product Backlog এবং পরবর্তী স্প্রিন্টে যায়। যদি কাজটি সত্যিই গুরুত্বপূর্ণ হয় — পুরানো Sprint Goal বাতিল করা হয়, স্প্রিন্ট পুনরায় পরিকল্পনা করা হয়, তবে এটি ব্যতিক্রম, অভ্যাস নয়। 3 স্প্রিন্টে একবারের বেশি স্কোপ ক্রিপ দুর্বল Product Owner-এর লক্ষণ।

সমস্যা 2: অসম্পূর্ণ কাজ। স্প্রিন্টের শেষে, 50% কাজ In Progress, 20% In Review, মাত্র 30% Done। কারণ: অতিমূল্যায়িত ক্ষমতা, অবমূল্যায়িত জটিলতা, অপরিকল্পিত বাগ। সমাধান: Retro-তে কারণ বিশ্লেষণ করুন। যদি আপনি নিয়মিতভাবে না পারেন — Planning-এ কাজের সংখ্যা বাড়াবেন না, বরং কমিয়ে দিন। যে দলগুলি 20% কম কাজ নেয়, তারা উচ্চতর সমাপ্তির হার দেখায় (80%+ বনাম 50-60%)। Planning-এর জন্য চেকলিস্ট: প্রতিটি কাজের জন্য Acceptance Criteria, Definition of Ready এবং অন্যান্য কাজের সাথে নির্ভরতা পরীক্ষা করুন।

সমস্যা 3: আনুষ্ঠানিক Retro. দল শুধু দেখানোর জন্য Retro করে — 15 মিনিট, সাধারণ বাক্যাংশ, কোনো অ্যাকশন আইটেম নেই। সমাধান: প্রতিটি Retro-এর ফরম্যাট পরিবর্তন করুন। পদ্ধতি: Sailboat (কী ধীর করে, কী গতি বাড়ায়), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For)। সময়সীমা এবং দায়িত্বশীল ব্যক্তিদের সাথে অ্যাকশন আইটেম নির্ধারণ করুন। পরবর্তী Retro-এর শুরুতে, পূর্ববর্তী অ্যাকশন আইটেমগুলির সম্পাদন পরীক্ষা করুন। Atlassian (2025) অনুযায়ী, বিভিন্ন Retro ফরম্যাট ব্যবহার করে দলগুলি 50% বেশি কার্যকর অন্তর্দৃষ্টি উৎপন্ন করে।