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

১ · অ্যাজাইল কী — একটি পরিবার, একটি একক মডেল নয়

অ্যাজাইলAgileSDLC পদ্ধতির একটি পরিবার, একক রিজিড মডেল নয় — হালকা-ওজনের, পুনরাবৃত্তিমূলক, পরিবর্তনের প্রতি সাড়া দেওয়ার উপর জোর দেয়। একটি গুরুত্বপূর্ণ কথা প্রথমেই স্পষ্ট করা দরকার — অ্যাজাইল কোনো একক, রিজিড SDLC মডেল নয়, বরং একাধিক পদ্ধতির একটি পরিবার (স্ক্রাম, কানবান, ও আরও অনেক কিছু — M2/L09-এ বিস্তারিত)। এই পরিবারটি জন্ম নিয়েছিল বিশেষভাবে ওয়াটারফলের (L05) মতো ভারী, প্রচুর ডকুমেন্টেশন ও আগাম পরিকল্পনা-নির্ভর মডেলের বিরুদ্ধে একটি হালকা-ওজনের প্রতিক্রিয়া হিসেবে। ২০০১ সালে ১৭ জন সফটওয়্যার ডেভেলপার একত্রিত হয়ে অ্যাজাইল ম্যানিফেস্টো প্রকাশ করেন — একটি বাস্তব, ঐতিহাসিকভাবে গুরুত্বপূর্ণ দলিল, যা আজও অ্যাজাইলের ভিত্তি হিসেবে বিবেচিত হয়।

২ · চারটি মূল ভ্যালু স্টেটমেন্ট

অ্যাজাইল ম্যানিফেস্টোর মূল কথাটি ঠিক এই চারটি স্টেটমেন্টে বলা আছে — এগুলো হুবহু মনে রাখার মতো গুরুত্বপূর্ণ:

৩ · কয়েকটি গুরুত্বপূর্ণ প্রিন্সিপল

ম্যানিফেস্টোর সাথে বারোটি প্রিন্সিপল প্রকাশিত হয়েছিল — সবগুলো মুখস্থ করার দরকার নেই, কিন্তু কয়েকটি বিশেষভাবে গুরুত্বপূর্ণ এবং এই কোর্সের অন্যান্য পাঠের সাথে সরাসরি যুক্ত:

• ঘন ঘন কার্যকরী সফটওয়্যার ডেলিভার করুন — সপ্তাহ থেকে মাসের মধ্যে, ছোট সময়সীমার পছন্দ সহকারে — L06-এর ইনক্রিমেন্টাল ডেলিভারি ধারণার সরাসরি পুনর্ব্যবহার, এখন এটি একটি মূল অ্যাজাইল প্রিন্সিপল।
• প্রজেক্টের শেষ দিকেও পরিবর্তিত রিকোয়ারমেন্টকে স্বাগত জানান — L05-এর ওয়াটারফল অনুমানের সরাসরি, স্পষ্ট বিপরীত।
• ব্যবসায়িক মানুষ ও ডেভেলপারদের প্রতিদিন একসাথে কাজ করতে হবে — ক্রমাগত যোগাযোগের উপর জোর।
• কার্যকরী সফটওয়্যারই অগ্রগতির প্রাথমিক পরিমাপক — ডকুমেন্টেশন বা পরিকল্পনার সাথে "সামঞ্জস্য" নয়, বাস্তবে কাজ করা সফটওয়্যারই আসল প্রমাণ।

৪ · পরিবর্তনের খরচ — ওয়াটারফল বনাম অ্যাজাইল

"Responding to change over following a plan" — এই স্টেটমেন্টটি একটি সংখ্যাগতভাবে পরিমাপযোগ্য ধারণায় পরিণত করা যায়: একটি দেরিতে আসা পরিবর্তনের খরচ কেমন বাড়ে? ওয়াটারফলে দেরিতে পরিবর্তন মানে ইতিমধ্যে সম্পন্ন হওয়া ফেজগুলো (রিকোয়ারমেন্ট, ডিজাইন) পুনরায় খুলতে হয় — যত দেরিতে পরিবর্তন আসে, তত বেশি সম্পন্ন কাজ পুনরায় করতে হয়, তাই খরচ বাড়তেই থাকে। অ্যাজাইলে কাজ ছোট, স্বয়ংসম্পূর্ণ ইটারেশনে ভাগ করা থাকে — একটি পরিবর্তন সাধারণত শুধু চলতি ইটারেশনের মধ্যেই প্রভাব ফেলে, প্রজেক্টের মোট দৈর্ঘ্যের মধ্যে ঠিক কোথায় এটি আসে তার উপর তেমন নির্ভর করে না — তাই খরচ তুলনামূলকভাবে স্থির থাকে।

# ওয়াটারফল বনাম অ্যাজাইলে একটি দেরিতে আসা পরিবর্তনের মডেলকৃত খরচ

def compare_methodology_responsiveness(model_name, change_request_day, project_length_days,
                                        iteration_length_days=10, cost_per_day_of_rework=2):
    if model_name == "waterfall":
        # আগের সম্পন্ন ফেজগুলো পুনরায় খুলতে হয় -- যত দেরিতে পরিবর্তন আসে, তত বেশি কাজ পুনরায় করতে হয়
        return change_request_day * cost_per_day_of_rework
    elif model_name == "agile":
        # প্রতিটি ইটারেশন ছোট ও স্বয়ংসম্পূর্ণ -- পরিবর্তন শুধু চলতি ইটারেশনেই সীমাবদ্ধ, day নির্বিশেষে
        return iteration_length_days * cost_per_day_of_rework
    raise ValueError(f"অজানা মডেল: {model_name}")

project_length = 100
print(f"{'দিন':>6} | {'Waterfall খরচ':>15} | {'Agile খরচ':>11}")
for day in (10, 50, 90):
    wf_cost = compare_methodology_responsiveness("waterfall", day, project_length)
    ag_cost = compare_methodology_responsiveness("agile", day, project_length)
    print(f"{day:>6} | {wf_cost:>15} | {ag_cost:>11}")