পাঠ ০৯ · ৫৮-এর মধ্যে · মডিউল ২

স্ক্রাম ও কানবান ফ্রেমওয়ার্ক

Scrum & Kanban frameworks
৯ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • স্ক্রামের স্প্রিন্ট কাঠামো, তিনটি সেরিমোনি ও তিনটি রোল নির্ভুলভাবে ব্যাখ্যা করতে পারবেন
  • কানবানের কন্টিনিউয়াস-ফ্লো মডেল ও WIP লিমিটের ভূমিকা বুঝবেন
  • স্ক্রাম ও কানবানের মধ্যে গঠনগত পার্থক্য স্পষ্টভাবে বলতে পারবেন
  • Python দিয়ে একটি WIP-লিমিট-সচেতন কানবান বোর্ড বাস্তবায়ন করবেন

১ · স্ক্রাম — টাইম-বক্সড স্প্রিন্ট

স্ক্রামScrumএকটি অ্যাজাইল ফ্রেমওয়ার্ক যেখানে কাজ নির্দিষ্ট-দৈর্ঘ্যের স্প্রিন্টে সংগঠিত থাকে, নির্দিষ্ট সেরিমোনি ও রোল সহকারে। L08-এর অ্যাজাইল মূল্যবোধের একটি কংক্রিট, বাস্তব বাস্তবায়ন। স্ক্রামে কাজ ফিক্সড-দৈর্ঘ্যের সময়সীমায় ভাগ করা হয়, যাকে বলা হয় স্প্রিন্টSprintএকটি ফিক্সড-দৈর্ঘ্যের সময়সীমা (সাধারণত ১-৪ সপ্তাহ) যার মধ্যে টিম একটি নির্দিষ্ট, প্রতিশ্রুতিবদ্ধ কাজের সেট সম্পন্ন করে। (সাধারণত ১-৪ সপ্তাহ)। প্রতিটি স্প্রিন্টের শুরুতে টিম একটি অগ্রাধিকারভিত্তিক ব্যাকলগ থেকে কিছু কাজ করার প্রতিশ্রুতি দেয় (স্প্রিন্ট প্ল্যানিং)। প্রতিদিন টিম একটি সংক্ষিপ্ত ডেইলি স্ট্যান্ডআপ করে, যেখানে প্রতিটি সদস্য বলে তারা কী করেছে, কী করবে, এবং কোনো বাধা আছে কি না। স্প্রিন্টের শেষে একটি স্প্রিন্ট রিভিউ সম্পন্ন কাজ প্রদর্শন করে, এবং একটি স্প্রিন্ট রেট্রোস্পেক্টিভ টিমের নিজস্ব প্রসেস নিয়ে প্রতিফলন করে, যাতে সেটি উন্নত করা যায়।

Product Owner
ব্যাকলগের মালিক ও অগ্রাধিকার নির্ধারণকারী।
Scrum Master
প্রসেস সহজতর করে, বাধা দূর করে।
Development Team
যারা প্রকৃতপক্ষে কাজ সম্পন্ন করে।

২ · কানবান — কন্টিনিউয়াস ফ্লো

কানবানKanbanএকটি অ্যাজাইল পদ্ধতি যেখানে কাজ ফিক্সড স্প্রিন্টের বদলে অবিরাম প্রবাহিত হয়, ভিজ্যুয়াল কলাম ও WIP লিমিট দিয়ে নিয়ন্ত্রিত। স্ক্রামের ঠিক বিপরীত গঠনগত ধারণা নিয়ে চলে — কোনো ফিক্সড স্প্রিন্ট নেই, কোনো ফিক্সড রোল নেই। কাজের আইটেম ভিজ্যুয়ালাইজড কলামের (যেমন "To Do", "In Progress", "Done") মধ্য দিয়ে একটি কানবান বোর্ডে অবিরাম প্রবাহিত হয়, ক্ষমতা অনুযায়ী। প্রতিটি কলামের একটি স্পষ্ট WIP লিমিটWork-In-Progress Limitএকটি কলামে একসাথে সর্বোচ্চ কতগুলো আইটেম থাকতে পারে তার সীমা — কানবানের সংজ্ঞায়ক, স্বতন্ত্র মেকানিজম। থাকে — যেমন, "In Progress" কলামে একসাথে সর্বোচ্চ ৩টি আইটেম থাকতে পারবে। এই WIP লিমিটই কানবানের সংজ্ঞায়ক, স্বতন্ত্র মেকানিজম — ইচ্ছাকৃতভাবে একটি টিমকে একসাথে অনেক বেশি কাজ শুরু করা থেকে বিরত রাখে, একটি বাস্তব, প্রায়োগিক অ্যান্টি-মাল্টিটাস্কিং শৃঙ্খলা।

৩ · স্ক্রাম বনাম কানবান — মূল পার্থক্য

স্ক্রাম: টাইম-বক্সড
ফিক্সড-দৈর্ঘ্যের স্প্রিন্ট, নির্দিষ্ট রোল, পর্যায়ক্রমিক সেরিমোনি।
কানবান: কন্টিনিউয়াস
কোনো ফিক্সড স্প্রিন্ট নেই, কোনো ফিক্সড রোল নেই, কাজ WIP লিমিটের মধ্যে অবিরাম প্রবাহিত হয়।

উভয়ই L08-এর অ্যাজাইল মূল্যবোধ মেনে চলে — ঘন ঘন কার্যকরী ফলাফল, পরিবর্তনের প্রতি সাড়া দেওয়ার ক্ষমতা, এবং টিমের ধারাবাহিক আত্ম-উন্নতি — কিন্তু ভিন্ন কাঠামোগত মেকানিজমের মাধ্যমে সেই মূল্যবোধ বাস্তবায়ন করে।

৪ · একটি WIP-সচেতন কানবান বোর্ড

নিচের কোড সেলে একটি বাস্তব KanbanBoard ক্লাস বাস্তবায়ন করা হয়েছে যেখানে move_item() মেথডটি WIP লিমিট মেনে চলতে বাধ্য — গন্তব্য কলাম ইতিমধ্যে তার লিমিটে পৌঁছে গেলে স্থানান্তর সরাসরি প্রত্যাখ্যাত হয়।

Python
# একটি WIP-লিমিট-সচেতন কানবান বোর্ড

class KanbanBoard:
    def __init__(self, column_names, wip_limits):
        self.columns = {name: [] for name in column_names}
        self.wip_limits = wip_limits

    def move_item(self, item, from_column, to_column):
        limit = self.wip_limits.get(to_column)
        if limit is not None and len(self.columns[to_column]) >= limit:
            print(f"  X ব্লকড: '{to_column}' কলাম WIP লিমিটে ({limit}) পৌঁছে গেছে -- '{item}' সরানো যাবে না")
            return False
        if from_column is not None:
            self.columns[from_column].remove(item)
        self.columns[to_column].append(item)
        print(f"  OK '{item}' সরানো হলো: {from_column} -> {to_column}")
        return True

    def show(self):
        for name, items in self.columns.items():
            limit = self.wip_limits.get(name, "সীমাহীন")
            print(f"  {name} (WIP limit: {limit}): {items}")

board = KanbanBoard(["To Do", "In Progress", "Done"], {"In Progress": 3})

for feature in ["লগইন ফিচার", "প্রোডাক্ট লিস্টিং", "পেমেন্ট গেটওয়ে", "সার্চ ফিচার"]:
    board.move_item(feature, None, "To Do")

print("\nতিনটি ফিচার In Progress-এ সরানো হচ্ছে:")
board.move_item("লগইন ফিচার", "To Do", "In Progress")
board.move_item("প্রোডাক্ট লিস্টিং", "To Do", "In Progress")
board.move_item("পেমেন্ট গেটওয়ে", "To Do", "In Progress")

print("\nচতুর্থ ফিচার সরানোর চেষ্টা (WIP লিমিট ইতিমধ্যে পূর্ণ):")
board.move_item("সার্চ ফিচার", "To Do", "In Progress")

print("\nবোর্ডের বর্তমান অবস্থা:")
board.show()

    
লক্ষ্য করুন প্রথম তিনটি "In Progress"-এ সরানোর চেষ্টা সফল হয় (কলামে ০, ১, ২টি আইটেম ছিল, লিমিট ৩) — কিন্তু চতুর্থটি ব্লকড হয়, কারণ সরানোর আগেই কলামে ৩টি আইটেম আছে, যা লিমিটের সমান। এই সাধারণ শর্তটিই (len(...) >= limit) কানবানের সবচেয়ে গুরুত্বপূর্ণ, প্রায়োগিক শৃঙ্খলা প্রয়োগ করে — একবারে অনেক বেশি কাজ শুরু করা থেকে টিমকে সরাসরি বিরত রাখে।
মূল কথা · Key takeaway

স্ক্রাম ও কানবান দুটোই L08-এর অ্যাজাইল মূল্যবোধকে বাস্তব, প্রায়োগিক ফ্রেমওয়ার্কে রূপ দেয় — স্ক্রাম টাইম-বক্সড স্প্রিন্ট ও নির্দিষ্ট রোলের মাধ্যমে, কানবান কন্টিনিউয়াস ফ্লো ও WIP লিমিটের মাধ্যমে। কোনটি "ভালো" তা নির্ভর করে টিমের কাজের প্রকৃতির উপর — ফিক্সড রিলিজ চক্র থাকলে স্ক্রাম, অবিরাম আগত সাপোর্ট/মেইনটেন্যান্স কাজের ধরনে কানবান প্রায়ই বেশি স্বাভাবিক পছন্দ।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি টিম যাদের কাজ প্রধানত অবিরাম আগত প্রোডাকশন বাগ ফিক্স করা (কোনো পূর্ব-নির্ধারিত রিলিজ চক্র নেই) — তাদের জন্য স্ক্রাম নাকি কানবান বেশি স্বাভাবিক?

কানবান সাধারণত বেশি স্বাভাবিক পছন্দ। স্ক্রামের স্প্রিন্ট প্ল্যানিং ধরে নেয় টিম আগে থেকে একটি নির্দিষ্ট কাজের সেটে প্রতিশ্রুতিবদ্ধ হতে পারবে — কিন্তু অবিরাম আগত, অগ্রাধিকারযোগ্য বাগ ফিক্সের ক্ষেত্রে এই আগাম প্রতিশ্রুতি বাস্তবসম্মত নয়। কানবানের কন্টিনিউয়াস ফ্লো মডেল, যেখানে কাজ যখনই ক্ষমতা থাকে তখনই শুরু হয়, এই ধরনের অনির্দেশ্য কাজের ধরনের সাথে বেশি মানানসই।

প্র ০২ কানবানে WIP লিমিট না থাকলে কী সমস্যা হতে পারে?

WIP লিমিট ছাড়া একটি টিম একসাথে অনেক বেশি কাজ শুরু করতে পারে — প্রতিটি কাজের আইটেমে মনোযোগ ভাগ হয়ে যায় (কনটেক্সট-সুইচিং খরচ বেড়ে যায়), কোনো কাজই দ্রুত সম্পন্ন হয় না, এবং প্রকৃত অগ্রগতি (কতগুলো আইটেম সত্যিই "Done" হলো) মাপা কঠিন হয়ে পড়ে। WIP লিমিট জোর করে টিমকে চলতি কাজ শেষ করার পর নতুন কাজ শুরু করতে উৎসাহিত করে — একটি সরাসরি, ইচ্ছাকৃত অ্যান্টি-মাল্টিটাস্কিং নিয়ম।

প্র ০৩ কোড সেলে চতুর্থ ফিচার (সার্চ ফিচার) কেন "In Progress"-এ সরানো যায়নি, যদিও "To Do" কলামে সেটি বিদ্যমান ছিল?

কারণ move_item() মেথডটি গন্তব্য কলামের (এখানে "In Progress") আইটেম সংখ্যা লিমিটের সাথে তুলনা করে — এবং সেই মুহূর্তে "In Progress"-এ ইতিমধ্যে ৩টি আইটেম ছিল, যা তার WIP লিমিট ৩-এর সমান। সোর্স কলামে ("To Do") জায়গা আছে কি না তা এখানে অপ্রাসঙ্গিক — শর্তটি শুধু গন্তব্য কলামের ক্ষমতা পরীক্ষা করে, যা কানবানের প্রকৃত নিয়মের সাথে সামঞ্জস্যপূর্ণ।

অনুশীলন

  1. চিন্তা করুন: স্ক্রামের "ডেইলি স্ট্যান্ডআপ" ও "স্প্রিন্ট রেট্রোস্পেক্টিভ" — এই দুটো সেরিমোনির উদ্দেশ্য কীভাবে ভিন্ন? প্রতিটি কী ধরনের সমস্যা সমাধান করার জন্য ডিজাইন করা হয়েছে?

    ডেইলি স্ট্যান্ডআপ স্বল্পমেয়াদী, দৈনিক সমন্বয়ের জন্য — টিম সদস্যরা একে অপরকে জানায় তারা কী করছে এবং কোনো তাৎক্ষণিক বাধা আছে কি না, যাতে দ্রুত সমাধান করা যায়। স্প্রিন্ট রেট্রোস্পেক্টিভ দীর্ঘমেয়াদী, প্রসেস-স্তরের উন্নতির জন্য — পুরো স্প্রিন্ট জুড়ে টিমের নিজস্ব কর্মপদ্ধতি কতটা ভালো কাজ করেছে তা প্রতিফলিত করা হয়, যাতে পরবর্তী স্প্রিন্টে প্রসেসটি নিজেই উন্নত করা যায়।

  2. পরীক্ষা করুন: কোড সেলে wip_limits-এ "Done"-এর জন্যও একটি লিমিট (যেমন ২) যোগ করুন, তারপর "In Progress"-এ থাকা আইটেমগুলো একে একে "Done"-এ সরানোর চেষ্টা করে দেখুন কী ঘটে।

    প্রথম দুটি আইটেম "Done"-এ সফলভাবে সরানো যাবে, কিন্তু তৃতীয়টি ব্লকড হবে, কারণ "Done" কলামও এখন তার নিজস্ব WIP লিমিটের অধীন। এটি একটি বাস্তব প্রশ্ন তোলে — বাস্তব কানবান বোর্ডে "Done" কলামে সাধারণত সীমা রাখা হয় না (সম্পন্ন কাজ জমা হতেই পারে), কিন্তু মাঝের প্রসেসিং কলামগুলোতে (যেমন "রিভিউ", "টেস্টিং") WIP লিমিট রাখা বেশি সাধারণ ও কার্যকর।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
অ্যাজাইল প্রিন্সিপল ও অ্যাজাইল ম্যানিফেস্টো