Agile আর Scrum — Agile Manifesto, role, event, artifact আর sprint

১ · কেন Agile এলো — বড় নকশা থেকে ছোট ছোট ধাপে

আগের পর্ব পর্ব ০৪ · SDLC আর process model-এ দেখেছেন waterfall কীভাবে কাজকে ধারাবাহিক ধাপে সাজায়: আগে সব requirement, তারপর নকশা, তারপর কোড, শেষে test. যেখানে requirement সত্যিই স্থির, সেখানে এই ক্রম কাজ করে। কিন্তু বেশিরভাগ software-এ ব্যবহারকারী নিজেও শুরুতে জানেন না তিনি ঠিক কী চান। হাতে কিছু একটা পেয়ে তবেই বলেন, “না, এটা না — ওইটা।”

১৯৯০-এর দশকে অনেক দল আলাদা আলাদাভাবে এই পথে হাঁটছিল। Ken Schwaber আর Jeff Sutherland-এর Scrum, Kent Beck-এর Extreme Programming (XP), Alistair Cockburn-এর Crystal, Jim Highsmith-এর Adaptive Software Development, DSDM, Feature-Driven Development — নাম আলাদা, কিন্তু সবার মিল ছিল এক জায়গায়: ভারী দলিল আর দীর্ঘ পরিকল্পনার বদলে ছোট iteration, ঘন ঘন delivery আর গ্রাহকের সাথে নিয়মিত কথা। এদের তখন বলা হতো “lightweight method”.

খেয়াল করুন, Agile কোনো এক ব্যক্তির আবিষ্কার নয়। Iterative আর incremental উন্নয়নের ধারণা বহু পুরোনো (পর্ব ০৪-এর spiral model মনে করুন); Manifesto সেই অভিজ্ঞতাগুলোকে মূল্যবোধের ভাষায় বেঁধে দিয়েছে। Software engineering-এর বৃহত্তর ইতিহাসে এর জায়গা কোথায়, তা পর্ব ০২-এ আছে।

২ · Agile Manifesto — চারটি মূল্যবোধ আর বারোটি নীতি

Manifesto-র মূল অংশ মাত্র কয়েক লাইনের। পরীক্ষা আর ইন্টারভিউতে প্রায়ই হুবহু জিজ্ঞেস করা হয়, তাই মূল ইংরেজিটিই আগে দেখুন:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

মূল্যবোধের পাশে আছে বারোটি নীতি (Principles behind the Agile Manifesto). নিচে প্রতিটির সারকথা, মূলের ক্রম মেনে:

1. গ্রাহকের সন্তুষ্টি সবার আগে — শুরু থেকেই আর ধারাবাহিকভাবে মূল্যবান software দিয়ে।
2. বদলে যাওয়া requirement-কে স্বাগত, উন্নয়নের শেষ দিকে হলেও — কারণ পরিবর্তন গ্রাহককে প্রতিযোগিতায় এগিয়ে রাখতে পারে।
3. ঘন ঘন কাজ করা software দেওয়া — কয়েক সপ্তাহ থেকে কয়েক মাস পরপর, যত ছোট সময় তত ভালো।
4. ব্যবসার মানুষ আর developer প্রতিদিন একসাথে কাজ করবেন, পুরো project জুড়ে।
5. উদ্যমী মানুষদের ঘিরে project — তাঁদের দরকারি পরিবেশ ও সহায়তা দিন, আর বিশ্বাস করুন যে তাঁরা কাজটি করবেন।
6. মুখোমুখি কথা দলের ভেতরে ও দলের কাছে তথ্য পৌঁছানোর সবচেয়ে কার্যকর উপায়।
7. কাজ করা software-ই অগ্রগতির প্রধান মাপ।
8. টেকসই গতি — sponsor, developer আর ব্যবহারকারী যেন অনির্দিষ্টকাল একই গতিতে চলতে পারেন; রাত জেগে “crunch” নয়।
9. প্রযুক্তিগত উৎকর্ষ আর ভালো নকশায় নিয়মিত মনোযোগ agility বাড়ায়।
10. সরলতা — যে কাজ করতে হবে না, তা যতটা সম্ভব বেশি চিহ্নিত করার শিল্প — অপরিহার্য।
11. সেরা architecture, requirement আর নকশা আসে self-organizing দল থেকে।
12. নিয়মিত বিরতিতে দল ভেবে দেখে কীভাবে আরও কার্যকর হওয়া যায়, তারপর সেই অনুযায়ী নিজের আচরণ বদলায়।

নীতি ৯ আর ১০ বিশেষভাবে মনে রাখুন। অনেকে Agile বলতে শুধু মিটিং আর board বোঝেন, অথচ Manifesto নিজেই বলছে ভালো নকশা আর প্রযুক্তিগত উৎকর্ষ ছাড়া দ্রুত বদলানো যায় না। নীতি ১২-ই পরে Scrum-এর Sprint Retrospective হয়ে উঠেছে। আর নীতি ৭ মনে করিয়ে দেয়, “৮০% কাজ শেষ” কোনো অগ্রগতি নয় যদি কিছুই ব্যবহার করা না যায় — software quality নিয়ে পর্ব ০৩-এর আলোচনার সাথে এর সরাসরি যোগ।

৩ · Agile কী নয়, আর XP-এর প্রকৌশল অনুশীলন

“আমরা Agile, তাই documentation লাগে না” — এ কথা প্রায়ই শোনা যায়। এটি Manifesto-র ভুল ব্যাখ্যা। কয়েকটি প্রচলিত ভুল ধারণা আর আসল কথা:

Extreme Programming (XP) — কোড লেখার দিকের Agile

Scrum বলে কীভাবে কাজ সাজাবেন, কিন্তু কীভাবে কোড লিখবেন তা বলে না। এই ফাঁক পূরণ করে XP. Kent Beck ১৯৯৯ সালে Extreme Programming Explained: Embrace Change বইয়ে একে বিস্তারিত লেখেন (দ্বিতীয় সংস্করণ ২০০৪, Cynthia Andres-এর সাথে)। নামের পেছনের চিন্তা: যে অনুশীলন ভালো, তাকে “চরমে” নিয়ে যাওয়া — code review ভালো হলে সবসময় review, test ভালো হলে কোডের আগেই test. প্রথম সংস্করণে বারোটির মতো অনুশীলন ছিল; তার মধ্যে সবচেয়ে প্রভাবশালী চারটি:

বাকি অনুশীলনের মধ্যে ছিল planning game, simple design, refactoring, collective code ownership, coding standard, টেকসই গতি (প্রথম সংস্করণে “40-hour week”) আর on-site customer. বাস্তবে বহু দল কাজ সাজায় Scrum দিয়ে আর কোড লেখে XP-র অনুশীলনে।

৪ · Scrum-এর ভিত্তি — empiricism আর Scrum Team

Scrum-এর আনুষ্ঠানিক সংজ্ঞা আছে একটি ছোট দলিলে — The Scrum Guide, লিখেছেন Ken Schwaber ও Jeff Sutherland. প্রথম প্রকাশ ২০১০ সালে, তারপর কয়েকবার সংশোধন; সর্বশেষ সংস্করণ ২০২০ সালের নভেম্বরের। এই পর্বে সব নিয়ম ২০২০ সংস্করণ অনুযায়ী। Guide নিজেই নিজেকে বলে একটি “lightweight framework” — ইচ্ছা করে অসম্পূর্ণ, যাতে প্রতিটি দল নিজের অনুশীলন যোগ করতে পারে।

Empiricism — অভিজ্ঞতা থেকে সিদ্ধান্ত

Scrum দাঁড়িয়ে আছে empiricism-এর ওপর: জ্ঞান আসে অভিজ্ঞতা থেকে, আর সিদ্ধান্ত হয় যা দেখা গেছে তার ভিত্তিতে। Guide এর সাথে lean চিন্তাও যোগ করে — অপচয় কমিয়ে মূল জিনিসে মন দেওয়া। Empiricism-এর তিনটি স্তম্ভ:

Guide পাঁচটি মূল্যবোধও বলে: Commitment, Focus, Openness, Respect, Courage. যে দলে খারাপ খবর দিলে শাস্তি হয়, সেখানে কেউ সমস্যা দৃশ্যমান করেন না — স্বচ্ছতা টেকে না।

Scrum Team — তিনটি দায়িত্ব

Scrum-এর মৌলিক একক একটি ছোট দল, সাধারণত ১০ জন বা তার কম। দলের ভেতরে কোনো উপ-দল বা স্তরবিন্যাস নেই, আর দলটি cross-functional — কাজ শেষ করতে যত দক্ষতা দরকার, সব দলের ভেতরেই। ২০২০ সংস্করণ “role”-এর বদলে accountability (জবাবদিহির দায়িত্ব) শব্দটি ব্যবহার করে। Guide একই মানুষের দুটি দায়িত্ব নেওয়া স্পষ্ট করে নিষেধ করে না (যেমন Product Owner বা Scrum Master Sprint Backlog-এর কাজ করলে Developer হিসেবেও অংশ নেন), তবে সাধারণত তা না করাই ভালো।

৫ · Sprint আর চারটি event — নির্দিষ্ট সময়ের চক্র

Scrum-এর হৃদয় হলো Sprint — এক মাস বা তার কম সময়ের নির্দিষ্ট দৈর্ঘ্যের একটি চক্র, যার ভেতরে বাকি সব event ঘটে। এক Sprint শেষ হওয়ার পরপরই পরের Sprint শুরু। বাস্তবে অনেক দল দুই সপ্তাহ বেছে নেয়, তবে Guide কোনো নির্দিষ্ট দৈর্ঘ্য বলে না — শুধু ঊর্ধ্বসীমা। প্রতিটি event একটি timebox: সময়ের সর্বোচ্চ সীমা, যার আগে শেষ হতে পারে কিন্তু পরে নয়।

খেয়াল করুন, ছোট Sprint-এর জন্য Guide কোনো আনুপাতিক সূত্র দেয় না, শুধু বলে “usually shorter”. দুই সপ্তাহের Sprint-এ অনেক দল Planning-এর জন্য ৪ ঘণ্টা ধরে নেয় — এটি প্রচলিত অনুশীলন, Guide-এর নিয়ম নয়। আরও কয়েকটি নিয়ম Sprint চলাকালীন: Sprint Goal ঝুঁকিতে ফেলে এমন বদল করা যায় না; গুণমান কমানো যায় না; Product Backlog দরকার মতো refine হয়; আর কাজ যত বোঝা যায়, Product Owner-এর সাথে আলোচনা করে Sprint-এর scope স্পষ্ট বা পুনর্নির্ধারণ করা যায়। Sprint Goal পুরোপুরি অর্থহীন হয়ে গেলে শুধু Product Owner Sprint বাতিল করতে পারেন।

এবার একটি পূর্ণ Sprint ধাপে ধাপে দেখুন। উদাহরণটি একটি কাল্পনিক অনলাইন বাজার অ্যাপের, দুই সপ্তাহের (১০ কর্মদিবস) Sprint, আর দলের সাম্প্রতিক velocity প্রায় ২১ point (অংশ ৭-এ velocity বিস্তারিত)।

Product Goal: ক্রেতা ফোনে বাজার অর্ডার করে বাসায় পাবেন
PB-1  মোবাইল নম্বর ও OTP দিয়ে লগইন        3
PB-2  নাম লিখে পণ্য খোঁজা                  5
PB-3  কার্টে পণ্য যোগ ও বাদ                 5
PB-4  ক্যাশ অন ডেলিভারিতে অর্ডার           8
PB-5  অর্ডারের অবস্থা দেখা                 3
PB-6  ডিসকাউন্ট কুপন                     5

Sprint Goal: লগইন করা ক্রেতা কার্ট থেকে
             ক্যাশ অন ডেলিভারিতে অর্ডার দিতে পারবেন
PB-1 (3) · PB-2 (5) · PB-3 (5) · PB-4 (8)  = 21
PB-4-এর কাজ: অর্ডার টেবিল, API, ঠিকানার ফর্ম,
             নিশ্চিতকরণ SMS, test

Done: PB-1 (3)
বাধা: SMS gateway-র test account এখনো পাওয়া যায়নি
     → OTP আর নিশ্চিতকরণ SMS দুটোই এতে নির্ভর করে
সিদ্ধান্ত: Scrum Master আজই সরবরাহকারীর সাথে কথা বলবেন;
     বিস্তারিত আলোচনা মিটিংয়ের পরে, যাঁদের দরকার তাঁরা

Done: PB-1, PB-3  → 8 point
অনুরোধ: “ঈদ অফারের জন্য কুপন (PB-6) এই Sprint-এই চাই”
Product Owner: Sprint Goal-এর অংশ নয় → PB-6 যাবে
     Product Backlog-এর একদম ওপরে, পরের Sprint-এ
PB-2 স্পষ্ট করা হলো: আপাতত ইংরেজি নামে খোঁজা

Done:     PB-1 (3) · PB-3 (5) · PB-4 (8) = 16
Done নয়:  PB-2 — বড় তালিকায় খোঁজা ধীর, test বাকি
          → Increment-এ নেই, Product Backlog-এ ফিরল
Sprint Goal: অর্জিত — ক্রেতা category তালিকা
             থেকে বেছে অর্ডার দিতে পারেন
মতামত: “বাংলায় নাম লিখে খোঁজা চাই” → নতুন item PB-7

ভালো হয়েছে: PB-6 নিয়ে চাপের মধ্যেও Goal ঠিক ছিল
উন্নতি দরকার: বাইরের নির্ভরতা (SMS) দেরিতে ধরা পড়ল
পরের Sprint-এ একটি পদক্ষেপ:
     Planning-এর আগে প্রতিটি item-এর বাইরের নির্ভরতা যাচাই
velocity লেখা হলো 16 — কারও দোষ খোঁজা নয়, শুধু তথ্য

৬ · তিনটি artifact, তিনটি commitment আর backlog refinement

Scrum-এর artifact হলো কাজ বা মূল্যের দৃশ্যমান রূপ — স্বচ্ছতার জন্যই এদের থাকা। ২০২০ সংস্করণে প্রতিটি artifact-এর সাথে একটি commitment যোগ হয়েছে: এমন একটি লক্ষ্য বা মানদণ্ড, যা দিয়ে অগ্রগতি মাপা যায়।

Definition of Done দেখতে কেমন? একটি কাল্পনিক দলের জন্য উদাহরণ: কোড review হয়েছে; unit test লেখা ও সব test পাস; CI pipeline সবুজ; গ্রহণযোগ্যতার শর্ত (acceptance criteria) মিলেছে; staging-এ deploy হয়েছে; দরকারি documentation হালনাগাদ। প্রতিষ্ঠানের কোনো মানদণ্ড থাকলে সব দলকে অন্তত সেটি মানতে হয়। Guide-এর একটি কঠিন নিয়ম: যে item Definition of Done মেলায় না, তা release করা যায় না, Sprint Review-তে দেখানোও যায় না — Product Backlog-এ ফিরে যায়। “প্রায় শেষ” বলে কোনো অবস্থা নেই।

Backlog refinement — বড় কাজকে ছোট করা

Product Backlog refinement হলো item-গুলোকে ভেঙে ছোট আর স্পষ্ট করা, বিবরণ, ক্রম আর আকার যোগ করা। এটি আলাদা কোনো event নয়, একটি চলমান কাজ — Developers সাধারণত আকার অনুমান করেন, Product Owner বুঝতে ও সিদ্ধান্ত নিতে সাহায্য করেন। লক্ষ্য: ওপরের item-গুলো যেন এত ছোট আর স্পষ্ট হয় যে একটি Sprint-এর ভেতরে Done করা যায়। (২০১৭-এর Guide-এ বলা ছিল refinement সাধারণত দলের সময়ের ১০%-এর বেশি নেয় না; ২০২০ সংস্করণে এমন কোনো সংখ্যা নেই।)

PB-20  ক্রেতা অনলাইনে টাকা দিয়ে অর্ডার করবেন     40 ?
       (velocity ~21 → এক Sprint-এ হবে না)

কোন পথে টাকা? ক্যাশ অন ডেলিভারি, মোবাইল ওয়ালেট, কার্ড
ঠিকানা আর ডেলিভারির সময় কি এর অংশ?      হ্যাঁ
রসিদ লাগবে?                           হ্যাঁ, SMS-এ
টাকা ফেরত (refund)?                    লাগবে, তবে পরে

PB-20a  ঠিকানা আর ডেলিভারির সময় বাছাই
PB-20b  টাকা পরিশোধ (সব পথ)
PB-20c  SMS-এ রসিদ
PB-20d  টাকা ফেরত

PB-20a  ঠিকানা আর ডেলিভারির সময় বাছাই
PB-20b1 ক্যাশ অন ডেলিভারি
PB-20b2 মোবাইল ওয়ালেটে পরিশোধ
PB-20b3 কার্ডে পরিশোধ
PB-20c  SMS-এ রসিদ
PB-20d  টাকা ফেরত

1  PB-20a  ঠিকানা আর সময়               5
2  PB-20b1 ক্যাশ অন ডেলিভারি          5
3  PB-20c  SMS-এ রসিদ                3   ← মোট 13
4  PB-20b2 মোবাইল ওয়ালেট             8
5  PB-20b3 কার্ড                      8
6  PB-20d  টাকা ফেরত                 13
                              সব মিলিয়ে 42

৭ · Velocity, burndown আর সৎ forecast

প্রথমেই একটি কথা স্পষ্ট করা দরকার: velocity আর story point Scrum Guide 2020-এ নেই, আর burndown-এর নাম আছে শুধু একটি উদাহরণ হিসেবে — কোনো নিয়ম হিসেবে নয়। এগুলো বহু দলের প্রচলিত অনুশীলন, মূলত XP থেকে আসা। Guide শুধু বলে অগ্রগতি মাপার বিভিন্ন পদ্ধতি (burn-down, burn-up, cumulative flow) কাজে লাগতে পারে, কিন্তু empiricism-এর জায়গা নিতে পারে না — ভবিষ্যৎ নয়, শুধু যা ঘটে গেছে তা-ই সিদ্ধান্তের ভিত্তি।

Story point হলো কাজের আপেক্ষিক আকার (জটিলতা, অনিশ্চয়তা, পরিমাণ মিলিয়ে) — ঘণ্টা নয়। আর velocity হলো একটি Sprint-এ Done হওয়া item-গুলোর মোট point. শুধু Done — আধা-শেষ item-এর point গোনা হয় না। আগের stepper-এ তাই velocity ২১ নয়, ১৬.

Velocity থেকে একটি পরিসর

ধরুন একটি দলের শেষ ছয়টি Sprint-এর velocity আছে, আর বাকি কাজ ১৫০ থেকে ২০০ point-এর মধ্যে (বাকি কাজের আকারও অনিশ্চিত)। আর কত Sprint লাগবে? একটি সংখ্যা নয়, একটি পরিসর বের করুন। নিচের প্রোগ্রাম seed দেওয়া ছোট একটি PRNG (mulberry32) দিয়ে ছয়টি velocity তৈরি করে, যাতে প্রতিবার একই সংখ্যা আসে:

// Velocity of 6 past sprints -> average, range, and sprints left for a backlog.
let seed = 2001;                         // mulberry32: small seeded PRNG
function rand() {
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const velocity = [];
for (let s = 1; s <= 6; s++) velocity.push(16 + Math.floor(rand() * 15)); // 16..30 points
console.log("velocity per sprint:", velocity.join(", "));

const sum = velocity.reduce((a, b) => a + b, 0);
const avg = sum / velocity.length;
const lo = Math.min(...velocity), hi = Math.max(...velocity);
console.log("average " + avg.toFixed(1) + "   min " + lo + "   max " + hi + "   range " + (hi - lo));

const last3 = velocity.slice(-3), avg3 = last3.reduce((a, b) => a + b, 0) / 3;
console.log("last 3 sprints average " + avg3.toFixed(1));

const backlog = { min: 150, max: 200 };  // remaining work is itself uncertain
const best = Math.ceil(backlog.min / hi);
const mid = Math.ceil(((backlog.min + backlog.max) / 2) / avg);
const worst = Math.ceil(backlog.max / lo);
console.log("backlog " + backlog.min + "-" + backlog.max + " points");
console.log("optimistic  " + backlog.min + "/" + hi + " -> " + best + " sprints");
console.log("using avg   " + (backlog.min + backlog.max) / 2 + "/" + avg.toFixed(1) + " -> " + mid + " sprints");
console.log("pessimistic " + backlog.max + "/" + lo + " -> " + worst + " sprints");
console.log("forecast: " + best + " to " + worst + " sprints (a range, not a promise)");

velocity per sprint: 17, 23, 23, 25, 17, 20
average 20.8   min 17   max 25   range 8
last 3 sprints average 20.7
backlog 150-200 points
optimistic  150/25 -> 6 sprints
using avg   175/20.8 -> 9 sprints
pessimistic 200/17 -> 12 sprints
forecast: 6 to 12 sprints (a range, not a promise)

Burndown আর burnup

Burndown chart দেখায় Sprint-এর প্রতিদিন কত কাজ বাকি; পাশে একটি “ideal” সরল রেখা — প্রতিদিন সমান হারে কমলে যেমন হতো। Burnup chart দেখায় দুটি রেখা: কত কাজ Done হয়েছে, আর মোট scope কত। নিচের প্রোগ্রাম ১০ দিনের একটি Sprint-এ ৪০ point দিয়ে শুরু করে, প্রতিদিন seed দেওয়া এলোমেলো ০–৭ point শেষ করে, আর ৪র্থ দিনে ৮ point নতুন কাজ ঢুকিয়ে দেয়:

// Text burndown for a 10-day sprint: 40 points committed, 8 points added on day 4.
let seed = 2020;                         // mulberry32: small seeded PRNG
function rand() {
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const DAYS = 10, START = 40;
const added = { 4: 8 };                  // scope change: new work pushed in on day 4
let remaining = START, scope = START, doneTotal = 0;
console.log("day  done  added  left  ideal  chart (# = 2 points left)");
console.log("  0     -      -  " + String(remaining).padStart(4) + "   40.0  " + "#".repeat(remaining / 2));
for (let d = 1; d <= DAYS; d++) {
  const done = Math.min(remaining, Math.floor(rand() * 8));   // 0..7 points finished today
  const add = added[d] || 0;
  remaining = remaining - done + add;
  scope += add; doneTotal += done;
  const ideal = START - (START / DAYS) * d;
  console.log(String(d).padStart(3) + String(done).padStart(6) + String(add || "-").padStart(7) +
    String(remaining).padStart(6) + ideal.toFixed(1).padStart(7) + "  " + "#".repeat(Math.round(remaining / 2)));
}
console.log("burnup view: done " + doneTotal + " of scope " + scope + " (scope grew by " + (scope - START) + ")");
console.log("left at sprint end: " + remaining + " points -> back to the Product Backlog");

day  done  added  left  ideal  chart (# = 2 points left)
  0     -      -    40   40.0  ####################
  1     6      -    34   36.0  #################
  2     5      -    29   32.0  ###############
  3     7      -    22   28.0  ###########
  4     3      8    27   24.0  ##############
  5     3      -    24   20.0  ############
  6     3      -    21   16.0  ###########
  7     2      -    19   12.0  ##########
  8     1      -    18    8.0  #########
  9     5      -    13    4.0  #######
 10     0      -    13    0.0  #######
burnup view: done 35 of scope 48 (scope grew by 8)
left at sprint end: 13 points -> back to the Product Backlog

এবার এই chart-টিকে একজন অভিজ্ঞ Scrum Master-এর চোখে পড়ুন:

day  left  ideal
  0    40   40.0  ####################
  1    34   36.0  #################
  2    29   32.0  ###############
  3    22   28.0  ###########

day  done  added  left  ideal
  3     7      -    22   28.0  ###########
  4     3      8    27   24.0  ##############   ↑ +5

day  done  left  ideal
  5     3    24   20.0  ############
  6     3    21   16.0  ###########
  7     2    19   12.0  ##########
  8     1    18    8.0  #########

day  done  left  ideal
  9     5    13    4.0  #######
 10     0    13    0.0  #######
→ 13 point Done হয়নি, Product Backlog-এ ফিরবে

day    1  2  3  4  5  6  7  8  9 10
done   6 11 18 21 24 27 29 30 35 35
scope 40 40 40 48 48 48 48 48 48 48

Monte Carlo — অতীতকে বারবার নতুন করে চালানো

অংশের শুরুর ৬–১২ পরিসর অনেক চওড়া। আরও কাজের উত্তর হলো সম্ভাবনা: “৮৫% নিশ্চয়তায় কত Sprint?” Monte Carlo simulation সেটাই করে: অতীতের ছয়টি velocity থেকে এলোমেলোভাবে একটি করে বেছে নিয়ে (একটি বারবার আসতে পারে) ভবিষ্যতের Sprint সাজায়, যতক্ষণ না backlog শেষ হয়। এভাবে ১০,০০০ বার “ভবিষ্যৎ” চালিয়ে দেখে কতবার কত Sprint লাগল। প্রতিবার backlog-এর আকারও ১৫০–২০০-এর মধ্যে এলোমেলো:

// Monte Carlo forecast: resample past velocities to see how many sprints a 150-200 point backlog needs.
let seed = 1995;                         // mulberry32: small seeded PRNG
function rand() {
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const past = [17, 23, 23, 25, 17, 20];   // velocities of the last 6 sprints
const TRIALS = 10000;
const result = [];
for (let t = 0; t < TRIALS; t++) {
  let left = 150 + Math.floor(rand() * 51), sprints = 0; // backlog 150..200
  while (left > 0) {                     // pick one past sprint at random (with replacement)
    left -= past[Math.floor(rand() * past.length)];
    sprints++;
  }
  result.push(sprints);
}
result.sort((a, b) => a - b);
const count = {};
for (const s of result) count[s] = (count[s] || 0) + 1;
let cum = 0;
console.log("sprints  trials  cumulative");
for (const s of Object.keys(count).map(Number)) {
  cum += count[s];
  console.log(String(s).padStart(7) + String(count[s]).padStart(8) + (100 * cum / TRIALS).toFixed(1).padStart(11) + "%");
}
const pct = (p) => result[Math.ceil(p * TRIALS) - 1];  // smallest value covering p of trials
console.log("50% confidence: done within " + pct(0.50) + " sprints");
console.log("85% confidence: done within " + pct(0.85) + " sprints");
console.log("95% confidence: done within " + pct(0.95) + " sprints");

sprints  trials  cumulative
      7     373        3.7%
      8    3046       34.2%
      9    3999       74.2%
     10    2378       98.0%
     11     203      100.0%
     12       1      100.0%
50% confidence: done within 9 sprints
85% confidence: done within 10 sprints
95% confidence: done within 10 sprints

৮ · Anti-pattern, বড় প্রতিষ্ঠানে Scrum আর চুক্তি

Scrum-এর নিয়ম অল্প, তাই নাম রেখে ভেতরটা বদলে ফেলা সহজ। Ken Schwaber এমন অবস্থার নাম দিয়েছিলেন “ScrumBut” — “আমরা Scrum করি, কিন্তু Retrospective বাদ দিই, কারণ সময় নেই।” প্রতিটি “কিন্তু” কোনো একটি সমস্যাকে দৃশ্যমান হতে দেয় না। সাধারণ কয়েকটি anti-pattern:

বড় প্রতিষ্ঠানে — একাধিক দল

Scrum একটি ছোট দলের জন্য। একই product-এ দশটি দল কাজ করলে কী হবে? এর জন্য কয়েকটি “scaling” কাঠামো আছে। SAFe (Scaled Agile Framework, Dean Leffingwell-এর নেতৃত্বে, ২০১০-এর দশকের শুরু থেকে) অনেক স্তর, নির্দিষ্ট role আর বড় পরিকল্পনা-অনুষ্ঠান যোগ করে; বড় প্রতিষ্ঠানে জনপ্রিয়, আবার অনেক Agile অনুশীলনকারীর সমালোচনাও পায় যে এটি বেশি ভারী। LeSS (Large-Scale Scrum, Craig Larman ও Bas Vodde) উল্টো পথে হাঁটে — যতটা সম্ভব কম নতুন জিনিস: একটি Product Backlog, একজন Product Owner, একাধিক দল একই Sprint-এ। Scrum.org-এর Nexus-ও আছে। কোনটি “সেরা” — এ নিয়ে কোনো সর্বসম্মত প্রমাণ নেই; প্রতিটির পক্ষে-বিপক্ষে অভিজ্ঞতা আছে।

চুক্তি আর outsourcing

Manifesto-র তৃতীয় মূল্যবোধ চুক্তির কথা বলে, কারণ বাস্তবে software প্রায়ই একটি প্রতিষ্ঠান আরেকটির জন্য বানায়। প্রচলিত fixed-price, fixed-scope চুক্তিতে শুরুতেই সব feature, দাম আর সময় বাঁধা থাকে — Agile-এর “বদলকে স্বাগত” নীতির সাথে সরাসরি টান। প্রচলিত বিকল্পগুলোর মধ্যে আছে: সময় ও খরচ নির্দিষ্ট রেখে scope নমনীয় রাখা (Product Backlog-এর ওপরের অংশ আগে); time-and-materials (কাজের সময় অনুযায়ী বিল); অথবা ছোট ছোট পর্যায়ে চুক্তি, প্রতিটি শেষে চালিয়ে যাওয়া বা থামার সুযোগ। কোনটি উপযুক্ত, তা দুই পক্ষের আস্থা, ঝুঁকি আর আইনি পরিবেশের ওপর নির্ভর করে।

বিদেশি গ্রাহকের জন্য কাজ করা দলের (বাংলাদেশসহ অনেক দেশে এমন কাজ প্রচলিত) কিছু সাধারণ চ্যালেঞ্জ আছে: সময়-অঞ্চলের পার্থক্যে Daily Scrum বা Review-র সময় মেলানো; গ্রাহকের পক্ষের প্রকৃত Product Owner দূরে থাকায় স্থানীয় একজন “proxy” রাখার প্রবণতা; আর চুক্তিতে Agile লেখা থাকলেও কার্যত waterfall-এর মতো শেষে একবার হস্তান্তর। এগুলো সাধারণ অভিজ্ঞতার কথা, কোনো পরিসংখ্যান নয়; প্রশ্ন ০৪-এ আরও আলোচনা আছে।

৯ · AI-এর যুগে Agile আর Scrum

AI এখন user story লেখে, backlog সাজায়, এমনকি story point-ও অনুমান করে। কিন্তু Scrum দাঁড়িয়ে আছে empiricism-এর ওপর — যা আপনার দলে সত্যিই ঘটেছে তার ওপর, আর AI আপনার দল, গ্রাহক বা codebase দেখেনি। তাই AI-এর দেওয়া Scrum “নিয়ম” বা সংখ্যা যাচাই করে নিন।

Software engineering-এ AI ব্যবহারের চেকলিস্ট

• AI-এর বলা Scrum বা Agile-এর নিয়ম মূল Scrum Guide 2020 বা agilemanifesto.org-এ মিলিয়েছি
• Forecast-এ AI-এর সংখ্যা নয়, নিজের দলের velocity দিয়ে পরিসর বা Monte Carlo চালিয়েছি
• AI-এর লেখা test বা acceptance criteria সত্যিই ভুল ধরতে পারে কি না, ইচ্ছা করে ভুল কোডে চালিয়ে দেখেছি
• AI যে Git command দিয়েছে (বিশেষ করে reset --hard বা push --force), তা আগে একটি আলাদা clone-এ চালিয়েছি আর git help পড়েছি
• AI-এর দেওয়া কোডের উৎস আর license যাচাই করেছি, আর prompt-এ কোনো password, key বা গ্রাহকের গোপন তথ্য দিইনি