Kanban আর lean — WIP limit, flow, lead time আর ধারাবাহিক উন্নতি

১ · কারখানা থেকে কোডে — lean-এর জন্ম

একটি পরিচিত দৃশ্য দিয়ে শুরু করি। একটি কাল্পনিক অনলাইন বাজার অ্যাপের দলে পাঁচজন developer. Sprint-এর মাঝামাঝি দেখা গেল, board-এ “চলছে” কলামে ১৮টি কাজ! প্রত্যেকে তিন-চারটি কাজ একসাথে ধরেছেন। কোনোটাই শেষ হচ্ছে না। Product owner জিজ্ঞেস করলেন, “ঈদের আগে payment-এর নতুন অপশন কবে পাব?” কেউ নিশ্চিত করে বলতে পারলেন না।

সমস্যাটা পরিশ্রমের নয় — সবাই ব্যস্ত। সমস্যা flow-এর, অর্থাৎ কাজ শুরু থেকে শেষ পর্যন্ত কত মসৃণভাবে বয়ে যায়। এই পর্বে আমরা দেখব, এই সমস্যার সবচেয়ে কার্যকর সমাধানটি এসেছে একটি গাড়ির কারখানা থেকে।

দ্বিতীয় বিশ্বযুদ্ধের পর জাপানের Toyota কোম্পানির হাতে টাকা আর জায়গা দুটোই কম ছিল; আমেরিকার কারখানার মতো বিশাল গুদামে আগাম গাড়ির যন্ত্রাংশ জমিয়ে রাখা তাদের পক্ষে সম্ভব ছিল না। প্রকৌশলী Taiichi Ohno ও সহকর্মীরা কয়েক দশক ধরে (মোটামুটি ১৯৫০ থেকে ১৯৭০-এর দশক) গড়ে তোলেন Toyota Production System (TPS). এর দুটি স্তম্ভ:

• Just-in-time: যা দরকার, যখন দরকার, যতটুকু দরকার — তার বেশি নয়। পরের ধাপ যখন যন্ত্রাংশ চায়, তখনই আগের ধাপ বানায়। এই “চাওয়া”র সংকেত দিত একটি কাগজের কার্ড — জাপানি ভাষায় kanban (মানে মোটামুটি “সংকেত-ফলক” বা “চিহ্নের কার্ড”)।
• Jidoka: ভুল দেখা দিলেই লাইন থামানো। Toyota-র কারখানায় যেকোনো কর্মী একটি দড়ি (andon cord) টেনে লাইন থামাতে পারতেন — ভুল যেন পরের ধাপে না যায়।

আগের ধাপ নিজের ইচ্ছেমতো বানিয়ে পরের ধাপে ঠেলে দিলে সেটা push; পরের ধাপ জায়গা খালি হলে চেয়ে নিলে সেটা pull. TPS হলো একটি pull system.

পর্ব ৫-এ (Agile আর Scrum) আপনি দেখেছেন Scrum কাজকে নির্দিষ্ট দৈর্ঘ্যের sprint-এ ভাগ করে। Lean আর Kanban অন্য দিক থেকে দেখে: সময়ের বাক্স নয়, কাজের ধারাটাই মূল। দুটো পরস্পরবিরোধী নয় — অংশ ৮-এ দেখব কীভাবে মেলানো যায়।

২ · সাতটি অপচয় — software-এ কোথায় লুকিয়ে থাকে

Ohno কারখানায় সাত রকম অপচয় (জাপানি শব্দ muda) চিহ্নিত করেছিলেন: বেশি উৎপাদন, অপেক্ষা, অপ্রয়োজনীয় পরিবহন, অতিরিক্ত প্রক্রিয়া, জমা মাল (inventory), অপ্রয়োজনীয় নড়াচড়া, আর ত্রুটি। Mary ও Tom Poppendieck ২০০৩ সালে তাঁদের বই Lean Software Development: An Agile Toolkit-এ এই চিন্তা software-এ আনেন। তাঁদের ২০০৬ সালের বই Implementing Lean Software Development-এ সাতটি অপচয়ের যে তালিকা আছে, সেটিই আজ বেশি উদ্ধৃত হয় (২০০৩-এর তালিকায় কয়েকটি নাম আলাদা ছিল, যেমন “extra processes”, “waiting”, “motion”):

খেয়াল করুন, প্রথমটিই সবচেয়ে গুরুত্বপূর্ণ। কারখানায় জমা মাল চোখে দেখা যায় — গুদাম ভরে যায়। Software-এ অর্ধেক শেষ কাজ অদৃশ্য: একটি branch-এ বসে থাকা কোড কারও চোখে পড়ে না, অথচ সেটি পুরোনো হচ্ছে, অন্য কোডের সাথে conflict বাড়াচ্ছে, আর কোনো মূল্য দিচ্ছে না। পর্ব ১৭-এ trunk-based development আর পর্ব ৫৮-এ continuous integration — দুটোরই একটি বড় লক্ষ্য এই অদৃশ্য জমা কমানো।

Value stream mapping — একটি কাজের পুরো যাত্রা আঁকা

Value stream mapping (VSM) হলো একটি অনুরোধ আসা থেকে গ্রাহকের হাতে পৌঁছানো পর্যন্ত প্রতিটি ধাপ আর প্রতিটি অপেক্ষা কাগজে আঁকা। Toyota-র ভেতরে এর চর্চা পুরোনো; Mike Rother ও John Shook-এর বই Learning to See (১৯৯৮) একে কারখানার বাইরে জনপ্রিয় করে। Software-এ এর সহজ রূপ: একটি ticket-এর ইতিহাস ধরে প্রতিটি ধাপে কাজ কতক্ষণ সত্যিই হয়েছে, আর কতক্ষণ শুধু অপেক্ষা করেছে, তা লেখা।

ছবিটি একটি অস্বস্তিকর সত্য দেখায়: developer-কে দ্রুত কোড লেখাতে চাপ দিয়ে ৬ ঘণ্টাকে ৫ ঘণ্টা করলে লাভ ১ ঘণ্টা। কিন্তু test-এর জন্য ৩০ ঘণ্টার অপেক্ষা অর্ধেক করলে লাভ ১৫ ঘণ্টা। Lean-এর চোখে উন্নতি মানে আগে অপেক্ষা খোঁজা, মানুষের গতি নয়। এই হিসাবের নাম flow efficiency; অংশ ৭-এ কোড দিয়ে হিসাব করব।

৩ · Kanban method — ছয়টি মূল চর্চা আর board

Toyota-র kanban ছিল যন্ত্রাংশের কার্ড। Software-এর Kanban method (বড় হাতের K দিয়ে লেখা হয়) মূলত David J. Anderson-এর কাজ থেকে এসেছে; ২০০০-এর দশকের মাঝামাঝি কয়েকটি software দলে তাঁর পরীক্ষা-নিরীক্ষার পর ২০১০ সালের দিকে প্রকাশিত বই Kanban: Successful Evolutionary Change for Your Technology Business একে পরিচিত করে। Anderson-এর ভাষায় এটি একটি “বিবর্তনমূলক পরিবর্তনের পদ্ধতি” — আপনার বর্তমান কাজের ধারা থেকেই শুরু, রাতারাতি সব বদলানো নয়।

সাধারণভাবে এর ছয়টি মূল চর্চা বলা হয় (বিভিন্ন সংস্করণে শব্দ একটু আলাদা):

Board-এর অংশগুলো একে একে:

• কলাম: আপনার দলের আসল কাজের ধাপ — বইয়ের আদর্শ ধাপ নয়। অনেক দল একটি কলামকে দুই ভাগ করে: “চলছে” আর “শেষ, পরের ধাপের অপেক্ষায়”। দুটো মিলিয়ে একটি WIP limit.
• Swimlane: আড়াআড়ি সারি — কাজের ধরন বা অগ্রাধিকার আলাদা করতে। যেমন ওপরে জরুরি কাজের সরু সারি, নিচে সাধারণ কাজ।
• Done-এর শর্ত: প্রতিটি কলামের বেরোনোর নিয়ম লেখা থাকে। Scrum-এর Definition of Done-এর মতোই, কিন্তু এখানে প্রতিটি ধাপের জন্য আলাদা।
• Blocked card: বাইরের কারণে আটকে থাকা কাজ (অন্য দলের API, গ্রাহকের উত্তর)। লাল চিহ্ন দিয়ে আলাদা করা হয়, কারণ এটাই প্রায়ই সবচেয়ে বড় অপেক্ষার উৎস।
• Class of service: কোন ধরনের কাজ কোন নিয়মে চলবে। Anderson-এর বইয়ে প্রচলিত চারটি: expedite (এখনই — যেমন production-এ payment বন্ধ), fixed date (নির্দিষ্ট তারিখের আগে — যেমন সরকারি নিয়মের সময়সীমা), standard (সাধারণ ক্রম), intangible (এখন জরুরি নয়, কিন্তু না করলে পরে বিপদ — যেমন পুরোনো library হালনাগাদ)।

৪ · Board-এ একটি card-এর যাত্রা — pull আর WIP limit

WIP limit-এর আসল কাজ বোঝা যায় যখন সেটি কাউকে থামায়। নিচের ছোট board-এ Dev কলামের সীমা ২, Review-এর সীমা ১। “পরে” চেপে দেখুন কখন একটি টান আটকে যায় আর তখন দলের মানুষ কী করেন।

সীমা কত হবে? কোনো জাদুর সংখ্যা নেই। একটি প্রচলিত শুরু হলো কলামে যতজন কাজ করেন, তার কাছাকাছি একটি সংখ্যা; তারপর তথ্য দেখে কমানো-বাড়ানো। সীমা এত কম যে মানুষ প্রায়ই অপেক্ষায় থাকেন, বা এত বেশি যে কখনো ছোঁয়াই হয় না — দুটোই ভুল সংকেত। অংশ ৬-এর সিমুলেটরে দুই প্রান্তই দেখবেন।

৫ · Flow-এর মাপ — lead time, cycle time, throughput আর CFD

Kanban মাপ দিয়ে কথা বলে। কিন্তু শব্দগুলো নিয়ে বাস্তবে অনেক বিভ্রান্তি আছে, তাই আগে নিখুঁত সংজ্ঞা:

Work item age সবচেয়ে কম আলোচিত, কিন্তু প্রতিদিনের কাজে সবচেয়ে কাজের। Cycle time জানা যায় কাজ শেষ হওয়ার পরে; age জানা যায় এখনই। কোনো card-এর age যদি অতীতের ৮৫% card-এর cycle time ছাড়িয়ে যায়, তাহলে সেটি নিয়ে আজই কথা বলা দরকার।

Cumulative flow diagram — এক ছবিতে পুরো ধারা

Cumulative flow diagram (CFD) প্রতিদিন হিসাব রাখে: এ পর্যন্ত মোট কতগুলো card এসেছে, কতগুলো শুরু হয়েছে, কতগুলো শেষ হয়েছে। নিচে ছয় দিনের তথ্য দিয়ে সারি ধরে ধরে CFD বানাই:

CFD পড়ার তিনটি চেনা লক্ষণ: (১) মাঝের band ক্রমশ মোটা হচ্ছে — WIP জমছে, cycle time বাড়বে; (২) সবুজ রেখা কয়েকদিন সমান — কিছুই শেষ হচ্ছে না, কোথাও আটকে আছে; (৩) ওপরের রেখা অনেক খাড়া — চাহিদা আপনার ক্ষমতার চেয়ে বেশি, backlog অনন্তকাল বাড়বে।

৬ · Little-এর সূত্র — WIP কমালে cycle time কেন কমে

১৯৬১ সালে MIT-এর John D. C. Little queue-তত্ত্বের একটি সাধারণ সূত্র প্রমাণ করেন: একটি স্থিতিশীল ব্যবস্থায় গড়ে ভেতরে থাকা জিনিসের সংখ্যা = গড় আগমনের হার × গড়ে ভেতরে কাটানো সময় (L = λW). System design কোর্সে সূত্রটির প্রমাণ আর server-এর হিসাব আছে: Latency, throughput আর percentile-এর অংশ ৬। এখানে শুধু Kanban-এর ভাষায় সাজিয়ে লিখি:

একটি হিসাব। একটি দলের board-এ গড়ে ১৫টি card চলমান থাকে, আর দল সপ্তাহে গড়ে ৫টি card শেষ করে। তাহলে গড় cycle time = ১৫ ÷ ৫ = ৩ সপ্তাহ। দল যদি WIP limit বসিয়ে চলমান কাজ ৭–৮টিতে নামায় আর throughput একই থাকে, গড় cycle time হবে প্রায় ১.৫ সপ্তাহ। কেউ দ্রুত কাজ করেননি — শুধু একসাথে কম কাজ ধরেছেন।

Little-এর সূত্র কাজ করে কয়েকটি শর্তে:

• স্থিতিশীল ব্যবস্থা: দীর্ঘ সময়ে যত card ঢোকে, মোটামুটি তত card বেরোয়; WIP অবিরাম বাড়ছে না। Backlog প্রতি সপ্তাহে বাড়তে থাকলে পুরো ব্যবস্থার জন্য সূত্রটি খাটে না।
• একই সীমানা: WIP, throughput আর cycle time — তিনটিই একই “শুরু” আর “শেষ” বিন্দু দিয়ে মাপতে হবে। WIP গুনলেন শুধু Dev কলামে, আর cycle time মাপলেন backlog থেকে — তাহলে মিলবে না।
• যথেষ্ট লম্বা সময়ের গড়: দুই দিনের তথ্যে নয়; আর যে card কখনো শেষ হয় না (বাতিল, হারিয়ে যাওয়া), সেগুলো আলাদা করে সামলাতে হয়।
• এটি গড়ের সূত্র: কোনো একটি card কতদিনে শেষ হবে, তা এটি বলে না। সেজন্য অংশ ৭-এর percentile লাগে।

তাহলে WIP কমালে throughput কি কমে যাবে না? দুটি কারণে প্রায়ই কমে না, বরং বাড়ে। এক, কাজ বদলের খরচ (context switching) কমে। দুই, কম কাজ মানে ছোট queue, তাই bug আর প্রশ্ন দ্রুত ধরা পড়ে। কিন্তু সীমা খুব কম হলে মানুষ সত্যিই বসে থাকেন। নিচের সিমুলেটরে একটি কাল্পনিক দল: ৩ জন developer, প্রতিদিন ৮০% সম্ভাবনায় একটি নতুন card আসে, প্রতিটির কাজ ১ থেকে ৫ developer-দিন (গড় ৩)। অর্থাৎ চাহিদা দিনে গড়ে ০.৮ × ৩ = ২.৪ developer-দিন, ক্ষমতা ৩ — ৮০% ব্যস্ততা। একটি card-এ একসাথে একজনের বেশি কাজ করেন না। আর একটি ধরে নেওয়া মান: developer-সংখ্যার চেয়ে প্রতিটি বাড়তি চলমান card দলের ২% সময় কাজ বদলে খায়। একই seed-এ, শুধু WIP limit বদলে, ৪০০ দিন চালানো হয় (প্রথম ১০০ দিন বাদ দিয়ে মাপা):

// Kanban board: 3 developers, ~0.8 new items/day, size 1-5 dev-days.
// Same seed for every run, so only the WIP limit changes.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const DEVS = 3, DAYS = 400, WARM = 100, SWITCH = 0.02; // assumption: 2% capacity lost per item beyond DEVS
function run(limit) {
  const rnd = mulberry32(42), backlog = [], wip = [];
  let wipSum = 0, done = 0, ctSum = 0, ltSum = 0;
  for (let day = 0; day < DAYS; day++) {
    if (rnd() < 0.8) backlog.push({ arrive: day, left: 1 + Math.floor(rnd() * 5) }); // new card?
    while (backlog.length && wip.length < limit) { const it = backlog.shift(); it.start = day; wip.push(it); }
    const eff = Math.max(0.3, 1 - SWITCH * Math.max(0, wip.length - DEVS));
    const each = Math.min(1, DEVS * eff / wip.length);    // one person per item at most
    if (day >= WARM) wipSum += wip.length;
    for (const it of wip) it.left -= each;
    for (let i = wip.length - 1; i >= 0; i--) if (wip[i].left <= 1e-9) {
      const it = wip.splice(i, 1)[0];
      if (day >= WARM) { done++; ctSum += day + 1 - it.start; ltSum += day + 1 - it.arrive; }
    }
  }
  const n = DAYS - WARM, W = wipSum / n, TH = done / n, CT = ctSum / done;
  return { W, TH, CT, LT: ltSum / done, little: W / TH, queue: backlog.length };
}
console.log("limit  avgWIP  thru/day  cycle  lead   WIP/thru  backlog@end");
for (const lim of [2, 4, 8, Infinity]) {
  const r = run(lim), f = (x, w) => x.toFixed(2).padStart(w);
  console.log(String(lim === Infinity ? "none" : lim).padEnd(5) + f(r.W, 8) + f(r.TH, 10) +
    f(r.CT, 7) + f(r.LT, 7) + f(r.little, 10) + String(r.queue).padStart(9));
}

limit  avgWIP  thru/day  cycle  lead   WIP/thru  backlog@end
2        2.00      0.66   3.03  43.60      3.05       56
4        3.44      0.79   4.34   6.03      4.37        1
8        4.93      0.78   6.13   6.55      6.32        0
none     6.31      0.76   7.77   7.77      8.26        0

কাজ বদলের খরচ — একজনের হিসাব

মনোযোগ ফিরে পেতে সময় লাগে: আগের কাজটি কোথায় ছিল, কোন file খোলা ছিল, কোন test কেন ব্যর্থ হচ্ছিল। Gerald Weinberg-এর Quality Software Management (১৯৯২) বইয়ের একটি বহুল-উদ্ধৃত আনুমানিক সারণিতে প্রতিটি বাড়তি project-এ প্রায় ২০% সময় হারানোর কথা আছে — এটি অভিজ্ঞতাভিত্তিক অনুমান, নিয়ন্ত্রিত গবেষণার মাপ নয়। নিচের মডেলে আমরা আরও নরম একটি অনুমান নিই: প্রথমটির পর প্রতিটি বাড়তি চলমান কাজে দিনের ১৫%. একজন developer-এর হাতে N টি কাজ, প্রতিটি ১০ ঘণ্টার, দিনে ৮ ঘণ্টা:

// Context switching: one developer, N tasks of 10 hours each, 8-hour days.
// ASSUMPTION (a model, not a measurement): every task beyond the first that is
// "in progress" at the same time costs 15% of the day in switching overhead.
const HOURS = 10, DAY = 8, COST = 0.15;
console.log("n  useful h/day | juggle: avg = all done | WIP 1: avg finish  all done");
for (let n = 1; n <= 5; n++) {
  // (a) juggle all n together: equal share each day, so all finish together
  const useful = DAY * Math.max(0, 1 - COST * (n - 1));
  const jugDone = (n * HOURS) / useful;
  // (b) one at a time (WIP 1): no overhead, task k finishes at k*HOURS/DAY days
  let sum = 0;
  for (let k = 1; k <= n; k++) sum += (k * HOURS) / DAY;
  const seqDone = (n * HOURS) / DAY;
  const f = (x, w) => x.toFixed(2).padStart(w);
  console.log(n + useful.toFixed(1).padStart(14) + " |" + f(jugDone, 22) + " |" +
    f(sum / n, 18) + f(seqDone, 10));
}

n  useful h/day | juggle: avg = all done | WIP 1: avg finish  all done
1           8.0 |                  1.25 |              1.25      1.25
2           6.8 |                  2.94 |              1.88      2.50
3           5.6 |                  5.36 |              2.50      3.75
4           4.4 |                  9.09 |              3.13      5.00
5           3.2 |                 15.63 |              3.75      6.25

Operating Systems কোর্সে CPU-র ক্ষেত্রেও একই ব্যাপার দেখবেন: process বদলাতে CPU-কেও register আর cache নতুন করে সাজাতে হয় (Context switch). মানুষের মাথার context switching আরও ব্যয়বহুল।

৭ · “কবে শেষ হবে?” — percentile, পূর্বাভাস আর flow efficiency

Cycle time-এর বণ্টন প্রায় কখনো সুষম হয় না। বেশিরভাগ card দ্রুত শেষ হয়, আর কয়েকটি অনেক দিন ঝুলে থাকে — ডান দিকে লম্বা লেজ। তাই গড় দিয়ে কথা দিলে প্রায় অর্ধেক সময় কথা রাখা যায় না। ভালো উপায় percentile: “অতীতের ৮৫% card এত দিনের মধ্যে শেষ হয়েছে।” হিসাবের সহজ পদ্ধতি nearest-rank: n টি মান ছোট থেকে বড় সাজান, p-তম percentile হলো ⌈p/100 × n⌉-তম মান।

নিচের প্রোগ্রাম নির্দিষ্ট seed থেকে ৪০টি শেষ হওয়া card-এর cycle time বানায়, percentile বের করে, তারপর দুটি প্রশ্নের উত্তর দেয়: (ক) আজ শুরু হওয়া একটি card কবে শেষ হবে? (খ) ২০টি card-এর একটি release কবে তৈরি হবে? দ্বিতীয়টির জন্য Monte Carlo পদ্ধতি: অতীতের ৩০ দিনের দৈনিক throughput থেকে এলোমেলোভাবে দিন বেছে ১০,০০০ বার “ভবিষ্যৎ” চালানো।

// Cycle-time percentiles (nearest-rank) and two "by when" forecasts.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rnd = mulberry32(2026);
// 40 finished cards: cycle time in days (1 + a long right tail, like real teams)
const ct = Array.from({ length: 40 }, () => 1 + Math.floor(-Math.log(1 - rnd()) * 3.5));
const sorted = [...ct].sort((a, b) => a - b);
const pct = (p) => sorted[Math.ceil(p / 100 * sorted.length) - 1];   // nearest-rank
const mean = ct.reduce((s, x) => s + x, 0) / ct.length;
console.log("sorted:", sorted.join(" "));
console.log("mean", mean.toFixed(2), " p50", pct(50), " p85", pct(85), " p95", pct(95));
console.log("One card started today: 85% of past cards finished within", pct(85), "days");
// Batch forecast: 20 cards, resample past daily throughput (Monte Carlo, 10000 runs)
const daily = Array.from({ length: 30 }, () => Math.floor(rnd() * 4));   // 0..3 done per day
const need = [];
for (let r = 0; r < 10000; r++) {
  let left = 20, days = 0;
  while (left > 0) { left -= daily[Math.floor(rnd() * daily.length)]; days++; }
  need.push(days);
}
need.sort((a, b) => a - b);
const q = (p) => need[Math.ceil(p / 100 * need.length) - 1];
const avgTh = daily.reduce((s, x) => s + x, 0) / daily.length;
console.log("avg throughput", avgTh.toFixed(2), "/day -> naive 20/avg =", (20 / avgTh).toFixed(1), "days");
console.log("20 cards: 50% by day", q(50), " 85% by day", q(85), " 95% by day", q(95));

sorted: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 4 4 4 4 5 5 6 6 6 6 7 9 9 10 11
mean 3.45  p50 2  p85 6  p95 9
One card started today: 85% of past cards finished within 6 days
avg throughput 1.83 /day -> naive 20/avg = 10.9 days
20 cards: 50% by day 11  85% by day 13  95% by day 15

পর্ব ৬০-এ story point আর অন্যান্য estimation পদ্ধতি আসবে। Kanban-এর পূর্বাভাস তার বিকল্প হিসেবে বা পাশাপাশি ব্যবহার করা যায়; কোনটা কখন ভালো, তা নিয়ে practitioner-দের মধ্যে বিতর্ক আছে।

Flow efficiency — কাজ বনাম অপেক্ষার অনুপাত

অংশ ২-এর ছবির card-টিসহ চারটি কাল্পনিক card-এর ইতিহাস নিচে। প্রতিটি ধাপ চিহ্নিত: "a" মানে সক্রিয় কাজ, "w" মানে অপেক্ষা।

// Flow efficiency = active (touch) time / lead time, per card and for the whole set.
// Times in working hours, read from each card's history on the board.
const cards = [
  { id: "BAZ-101", steps: [["dev", 6, "a"], ["wait review", 20, "w"], ["review", 2, "a"], ["wait test", 30, "w"], ["test", 4, "a"], ["wait deploy", 16, "w"]] },
  { id: "BAZ-102", steps: [["dev", 3, "a"], ["review", 1, "a"], ["test", 2, "a"], ["wait deploy", 2, "w"]] },
  { id: "BAZ-103", steps: [["wait spec", 40, "w"], ["dev", 10, "a"], ["blocked: API", 24, "w"], ["dev", 4, "a"], ["wait review", 8, "w"], ["review", 2, "a"]] },
  { id: "BAZ-104", steps: [["dev", 8, "a"], ["wait review", 4, "w"], ["review", 2, "a"], ["wait test", 6, "w"], ["test", 3, "a"]] },
];
let A = 0, L = 0;
for (const c of cards) {
  const active = c.steps.filter(s => s[2] === "a").reduce((t, s) => t + s[1], 0);
  const lead = c.steps.reduce((t, s) => t + s[1], 0);
  const worst = c.steps.filter(s => s[2] === "w").sort((x, y) => y[1] - x[1])[0];
  A += active; L += lead;
  console.log(c.id, " active", String(active).padStart(2), "h  lead", String(lead).padStart(3), "h  efficiency",
    (100 * active / lead).toFixed(1).padStart(5) + "%  longest wait:", worst ? worst[0] + " " + worst[1] + "h" : "-");
}
console.log("ALL      active", A, "h  lead", L, "h  efficiency", (100 * A / L).toFixed(1) + "%");
const avgEff = cards.reduce((t, c) => {
  const a = c.steps.filter(s => s[2] === "a").reduce((x, s) => x + s[1], 0);
  return t + a / c.steps.reduce((x, s) => x + s[1], 0);
}, 0) / cards.length;
console.log("mean of per-card efficiencies", (100 * avgEff).toFixed(1) + "%  (not the same thing)");

BAZ-101  active 12 h  lead  78 h  efficiency  15.4%  longest wait: wait test 30h
BAZ-102  active  6 h  lead   8 h  efficiency  75.0%  longest wait: wait deploy 2h
BAZ-103  active 16 h  lead  88 h  efficiency  18.2%  longest wait: wait spec 40h
BAZ-104  active 13 h  lead  23 h  efficiency  56.5%  longest wait: wait test 6h
ALL      active 47 h  lead 197 h  efficiency 23.9%
mean of per-card efficiencies 41.3%  (not the same thing)

৮ · Scrum, Kanban আর Scrumban — কোনটি কখন

পর্ব ৫-এর (Agile আর Scrum) সাথে মিলিয়ে দেখুন। দুটোই Agile-এর মূল্যবোধে বিশ্বাসী, কিন্তু কাজ সাজানোর কৌশল আলাদা:

Scrumban শব্দটি সাধারণত Corey Ladas-এর সাথে যুক্ত (২০০৮ সালের দিকের প্রবন্ধ, ২০০৯ সালের বই Scrumban). শুরুতে এর ধারণা ছিল Scrum থেকে Kanban-এ যাওয়ার একটি পথ; এখন অনেকে দুটোর যেকোনো মিশ্রণকেই Scrumban বলেন — তাই কেউ “আমরা Scrumban করি” বললে জিজ্ঞেস করুন ঠিক কোন নিয়মগুলো মানা হয়। Scrum.org ২০১৮ সালের দিকে Scrum দলের জন্য আলাদা একটি Kanban নির্দেশিকাও প্রকাশ করেছে।

৯ · ধারাবাহিক উন্নতি — kaizen, retrospective আর 5 whys

Kaizen জাপানি শব্দ, মোটামুটি অর্থ “ভালোর দিকে বদল”। Lean-এ এর মানে: বড় বিপ্লব নয়, প্রতিদিনের ছোট উন্নতি — আর সেটা করবেন কাজের সবচেয়ে কাছের মানুষেরা। Scrum-এর retrospective (পর্ব ৫) এই চিন্তারই একটি নিয়মিত রূপ। Kanban-এ উন্নতির ভিত্তি তথ্য: CFD-তে band মোটা হচ্ছে কোথায়, কোন কলামে card-এর age বেশি, কোন class of service কত ঘন ঘন আসে।

সমস্যা ঘটলে মূল কারণ খোঁজার একটি সহজ কৌশল 5 whys — “কেন?” প্রশ্নটি বারবার করা, যতক্ষণ না একটি বদলানো যায় এমন প্রক্রিয়ায় পৌঁছান। কৌশলটি Toyota-য় Sakichi Toyoda-র সময় থেকে প্রচলিত বলে বলা হয়, আর Ohno একে জনপ্রিয় করেন। একটি কাল্পনিক ঘটনা দিয়ে দেখি:

১০ · AI-এর যুগে — flow-এর হিসাবে AI-কে যাচাই

AI এখন board-এর তথ্য থেকে report বানায়, sprint-এর সারাংশ লেখে, এমনকি Jira বা অন্য tool-এর data দেখে পূর্বাভাস দেয়। কাজটি দ্রুত হয়, কিন্তু এই বিষয়ে AI-এর কিছু পরিচিত ভুল আছে:

AI-এর দেওয়া flow-বিশ্লেষণ হাতে পেলে — চেকলিস্ট

• শুরু আর শেষের বিন্দু (ঘড়ি কোথায় চালু, কোথায় থামে) স্পষ্ট লেখা আছে
• অন্তত একটি percentile আর Little-এর একটি হিসাব আমি নিজে হাতে বা ছোট script-এ মিলিয়েছি
• ব্যবস্থা স্থিতিশীল কি না দেখেছি — backlog কি প্রতি সপ্তাহে বাড়ছে?
• প্রতিটি বই, guide বা বছরের উল্লেখ নিজে যাচাই করেছি; উৎসহীন সংখ্যা বাদ দিয়েছি
• AI-কে দেওয়া data থেকে নাম, গ্রাহকের তথ্য আর গোপন token মুছে দিয়েছি
• সুপারিশ হিসেবে এসেছে এমন tool-এর script বা Git command আগে একটি পরীক্ষার কপিতে চালিয়ে দেখেছি