SAFe-এ Agile দলের কাজের বিশেষত্ব অনুশীলনে Scrum-এর তুলনায়

বন্ধুদের মধ্যে প্রকাশের পর Burn Down Chart নিয়ে প্রথম নিবন্ধটি, মন্তব্যে প্রথম প্রশ্নটি ছিল: "আপনার SAFe অভিজ্ঞতা সম্পর্কে আরও বিস্তারিত জানতে আগ্রহী হব।" তাই, এই নিবন্ধে আমি আমাদের অনুশীলনে Scrum-এর তুলনায় SAFe-এ কাজের বিশেষত্ব তুলে ধরার চেষ্টা করব। আমি প্রথমেই সত্যের দাবিদার নই এবং সহকর্মীদের যেকোনো সংশোধন ও স্পষ্টীকরণে সন্তুষ্ট হব।

প্রথমে আমি সংক্ষেপে সবচেয়ে মূল বিষয়গুলো তালিকাভুক্ত করব যা আমার মতে SAFe-এ কাজকে SCRUM থেকে আলাদা করে।

• Scrum-এ Increment এবং SAFe-এ Program Increment
• ART - Agile Release Train
• পরস্পরক্রিয়াশীল দলের সংখ্যা
• PIPE
• SOS
• PO - ব্যবসার মালিক নন
• RTE
• প্রশিক্ষণের জন্য পঞ্চম স্প্রিন্ট
• System Demo

Scrum-এ Increment এবং SAFe-এ Program Increment। আসলে ভিন্ন পরিভাষা, কিন্তু এগুলোতে সহজেই বিভ্রান্তি ঘটে কারণ আমাদের মধ্যে কেউ Program Increment শব্দটি ব্যবহার করে না, সবাই শুধু Increment বলে - যা ইতিমধ্যে একটি ভিন্ন পরিভাষা যা SCRUM-এ ব্যবহৃত হয়। তবে আমার মতে অর্থের দিক থেকে এগুলো বেশ মিল। SCRUM-এ Increment মূলত বর্তমান পণ্য + সম্পন্ন অবস্থায় স্প্রিন্টের জন্য পরিকল্পিত স্টোরিগুলো (দলের DOD পাস করা)। Program Increment - এটি একটি সময়কাল যার মধ্যে ট্রেন (Agile Release Train) উৎপাদনে ক্রমবর্ধমান মূল্য পৌঁছে দেয়। সময়কালের দিক থেকে আমাদের ক্ষেত্রে এটি ২ সপ্তাহের ৪টি স্প্রিন্ট ডেভেলপমেন্টের জন্য এবং একটি স্প্রিন্ট প্রশিক্ষণের জন্য।

Agile Release Train - এটি একটি মূল্য সৃষ্টির একক প্রবাহে কাজ করা দলগুলোর দল। আমরা এটিকে শুধু ট্রেন বলি, কিন্তু ফ্রেমওয়ার্ক অনুযায়ী এটিকে সঠিকভাবে "Solution" বলা উচিত। আমাদের ক্ষেত্রে, এই নিয়ম পুরোপুরি পালন করা হয় না এবং দলগুলো প্রায়শই কারিগরি দিক থেকে ভিন্ন পণ্যে কাজ করে, কারণ বেশিরভাগ ব্যবসায়িক ফিচ সমন্বিতভাবে বাস্তবায়িত হয় এবং একাধিক পণ্যকে স্পর্শ করে। এটি কারিগরি দিক। তবে, আমি নিশ্চিত যে কেউ কেউ সমস্ত আইটি সিস্টেমকে কোম্পানির একটি পণ্য হিসেবে বিবেচনা করেন এবং সম্ভবত এটি আরও সঠিক।

পরস্পরক্রিয়াশীল দলের সংখ্যা আমাদের SAFe-এ উল্লেখযোগ্যভাবে বেশি, মোট একটি ট্রেনে ১২৫ জন পর্যন্ত সুপারিশ করা হয়। আমাদের ৩টি ট্রেন আছে এবং প্রতিটিতে এই নিয়ম পালন করা হয় না, ১২৫ জনের বেশি সদস্যবিশিষ্ট ট্রেনও আছে। SCRUM বর্ণনা করে না কীভাবে অন্য দলগুলোর সাথে মিথস্ক্রিয়া করতে হবে, আমার জানামতে, SAFe-এর বিপরীতে, যেখানে এই বিষয়ে খুব স্পষ্ট সুপারিশ রয়েছে। আমার মতে এর জন্য সবচেয়ে উল্লেখযোগ্য আর্টিফ্যাক্ট হলো Program Board।

এতে ট্রেনের দলগুলোর মধ্যে পারস্পরিক সম্পর্ক দেখানো হয় এবং এটি আলোচনা করে আমাদের এখানে সাপ্তাহিক Scrum Of Scrums (SOS) কার্যক্রম অনুষ্ঠিত হয়।

প্রায় প্রতি ২.৫ মাসে (প্রতি ৫টি স্প্রিন্টে) একটি ইভেন্ট ঘটে PIPE - Programm Increment Planning Event. এটি হলো যখন সমস্ত বিতরণকৃত দল ২ দিনের জন্য একটি হলরুমে একত্রিত হয় এবং পরবর্তী ২.৫ মাসের জন্য তাদের কাজ পরিকল্পনা করে। এই ইভেন্টের প্রক্রিয়ায় Program board-এর মতো আর্টিফ্যাক্ট তৈরি হয়, উদাহরণস্বরূপ, যেখানে প্রতিটি ট্রেনের জন্য দলগুলোর মধ্যে সমস্ত নির্ভরতা দেখানো হয়, উপরে আমি ইতিমধ্যে এটি কেমন দেখায় তা দেখিয়েছি। এই ইভেন্টে প্রতিটি দলের Scrum Master-এর কাজ হলো সর্বাধিক সংখ্যক নির্ভরতা চিহ্নিত করতে সহায়তা করা, তারপর সম্ভব হলে সেগুলো অপসারণ করা (যেমন মৌখিকভাবে দক্ষতা এক দল থেকে অন্য দলে হস্তান্তরের মাধ্যমে বা একটি দলের নির্ভরতা অন্য দলে নিয়ে যাওয়ার মাধ্যমে, যাতে দলটি কারও উপর নির্ভর না করে স্বায়ত্তশাসিতভাবে তাদের ফিচ বাস্তবায়ন করতে পারে)। অনুশীলনে আমাদের ক্ষেত্রে এভাবেই ঘটে। প্রথমে ফিচগুলো User Story-তে বিভক্ত করা হয়, User Story-গুলো ৪টি স্প্রিন্টে বিতরণ করা হয়। ফিচগুলো Program Board-এ স্থাপন করা হয় এবং অন্য দলগুলোর সাথে যে নির্ভরতা আছে তা দেখানো হয়। ইভেন্ট চলাকালীন এটি আলোচনা ও সংশোধন করা হয়।

SOS - Scrum Of Scrum. এই ইভেন্ট প্রতি ট্রেনের জন্য আলাদাভাবে সপ্তাহে একবার অনুষ্ঠিত হয়। ট্রেনের সমস্ত দলের Scrum Master-রা অনলাইনে একত্রিত হন, ট্রেনের Program Board সম্প্রচারিত হয় এবং নির্দিষ্ট ট্রেনের দলগুলোর সমস্ত নির্ভরতা ও ফিচের স্ট্যাটাস আলোচনা করা হয়। মূলত এই ইভেন্ট ট্রেনের মধ্যে দলগুলোর কেন্দ্রীভূত সমন্বয়ের জন্য প্রয়োজন। এক ধরনের স্ট্যান্ডআপ, তবে সপ্তাহে একবার এবং দলের জন্য নয়, বরং Scrum Master-দের জন্য।

PO (প্রোডাক্ট ওনার) - ব্যবসার মালিক নন। একজন Product Manager আছেন - তিনি সংশ্লিষ্ট ব্যবসায়িক ক্ষেত্রের Bussiness Owner-দের সাথে কাজ করেন এবং মূলত প্রোডাক্ট ওনারদের কাছে ফিচ বিতরণ করেন। প্রোডাক্ট ওনার ইতিমধ্যে সরাসরি দলে কাজ করেন - ফিচগুলোকে User Stories-এ বিভক্ত করেন (আমাদের ক্ষেত্রে দলের সাথে যৌথভাবে) এবং সবসময় বিভক্ত করেন না, কিন্তু আমরা এই দিকে ক্রমাগত অগ্রগতি করছি।

RTE (Release Train Engineer - ট্রেন ড্রাইভার। স্ক্রাম মাস্টার অফ স্ক্রাম মাস্টার্স। নিজের ট্রেনের SOS ইভেন্ট পরিচালনা করেন। ফিচার পর্যায়ে প্রোডাক্ট ম্যানেজারের সাথে যোগাযোগ করেন। PIPE ফ্যাসিলিটেট করেন।

শেখার জন্য পঞ্চম স্প্রিন্ট - হ্যাঁ, স্ক্রামের বিপরীতে এখানে ইনক্রিমেন্টের শেষে শেখার জন্য পুরো একটি স্প্রিন্ট দলকে বরাদ্দ দেওয়া হয়। আমরা সাধারণত অনুশীলনে এটি প্রথমে অভ্যন্তরীণ প্রশিক্ষণে যাওয়ার জন্য ব্যবহার করি, যার মধ্যে SAFe-ও অন্তর্ভুক্ত, তবে শুধু তাই নয়। ব্যক্তিগত কোর্স ও মিটআপগুলো সম্ভব হলে এই সময়ে পরিকল্পনা করার চেষ্টা করি। এছাড়াও আমাদের এমন ডেভেলপার আছে যারা ৫ম স্প্রিন্ট চলাকালীন নিজেদের স্ট্যাক расширяют, যাতে দলে কারও দক্ষতা কভার করা যায় (প্রয়োজনে ব্যাকআপ দেওয়া যায়)।

সিস্টেম ডেমো। PIPE-এর ফলস্বরূপ প্রতিটি দলের কাছে ইনক্রিমেন্টের জন্য লক্ষ্যের একটি তালিকা থাকে এবং এই প্রতিটি লক্ষ্য ট্রেনের Business Owner ১০-পয়েন্ট স্কেলে মূল্যায়ন করেন। এটিকে Business Value বলা হয়। এই লক্ষ্যগুলো মূল ও বর্ধিত — দুই ভাগে বিভক্ত। মূল লক্ষ্য হলো সেই লক্ষ্য যেখানে দল অর্জনে কোনো ঝুঁকি দেখে না। বর্ধিত হলো অর্জনের ঝুঁকিসহ লক্ষ্য। সব লক্ষ্যই বাধ্যতামূলক এবং কাজের পরিমাণ সব লক্ষ্যের জন্য পরিকল্পনা করা হয়। System Demo-তে Business Owner ইনক্রিমেন্টের কাজের ফলাফল গ্রহণ করেন। ধরুন, একটি দলের ৩টি মূল লক্ষ্য ছিল যার মূল্যায়ন ১০, ৬, ৮ এবং ২টি বর্ধিত লক্ষ্য যার মূল্যায়ন ১০, ৩। কল্পনা করুন Business Owner যথাক্রমে নিম্নলিখিত মূল্যায়ন দিলেন: ৮, ৬, ৪, ২, ০। এখন লক্ষ্য অর্জনের শতাংশ গণনা করা যায়: ১০০% ধরা হয় মূল লক্ষ্যের প্রাথমিক মোট পয়েন্ট, আমাদের ক্ষেত্রে এটি ১০+৬+৮=২৪। অর্জিত পয়েন্ট বর্ধিত লক্ষ্যসহ গণনা করা হয় (অর্থাৎ ২৪-এর মধ্যে দল ২০ অর্জন করেছে), ফলে দলের লক্ষ্য অর্জনের শতাংশ হবে (২০*১০০)/২৪ = ৮৩.৩%। ৮০% থেকে ১০০% অর্জনকে স্বাভাবিক ফলাফল ধরা হয়।

বাকি সব বিষয়ে আমরা SCRUM অনুসরণ করি। হ্যাঁ, বা প্রায় সব বিষয়ে :) আমাদের অভিজ্ঞতার বিষয়ে: আমি বলতে পারি, আমার দৃষ্টিকোণ থেকে বিবর্তন স্পষ্ট। এক বছরের কাজে দলগুলো অনেক বেড়েছে, স্ব-সংগঠিত হয়েছে, কিছু দল অবশ্য ভেঙে পড়েছে, তবে সেখানেও একটি নির্দিষ্ট বিবর্তন দেখা যায়। বেড়ে ওঠার আরও জায়গা আছে।

ফেসবুক থেকে সহকর্মীদের মন্তব্য

«ঝেনিয়া, হ্যালো! লিখছেন — দারুণ, ভালো কাজ! ট্রেন সম্পর্কে একটু সংশোধন করি — এগুলো পণ্যের চারপাশে নয়, বরং মূল্য সৃষ্টির প্রবাহের চারপাশে গঠিত হয়। আর খুচরা ব্যবসায় আমাদের ক্ষেত্রে SAFe-এর দৃষ্টিকোণ থেকে এটি ট্রেন নয়, Solution। শুধু যোগাযোগের সুবিধা ও বোঝার সরলতার জন্য আমরা এটিকে ট্রেন বলেই ডাকি)»

– কনস্টান্টিন ভোরোনিন (ইনগোসস্ট্রাখের প্রজেক্ট অফিসের প্রতিনিধি)

«আর হয়তো কেউ লক্ষ্য করবেন যে SAFe-এর দৃষ্টিকোণ থেকে লক্ষ্যের মূল্যায়ন I&A-তে হয়; (যেখানে SD একটি অংশ হিসেবে অন্তর্ভুক্ত, তবে সরাসরি মূল্যায়নের সাথে সম্পর্কিত নয়) আর SD-গুলো প্রতিটি স্প্রিন্টে হওয়া উচিত (দলের ডেমোর পরে)। তবে আমরা এখনো এটি থেকে দূরে, তাই সচেতনভাবেই সবকিছুকে আপনার নিবন্ধে লেখা অনুযায়ী ডাকি)»

– কনস্টান্টিন ভোরোনিন (ইনগোসস্ট্রাখের প্রজেক্ট অফিসের প্রতিনিধি)

«ঝেনিয়া, চালিয়ে যান, দয়া করে, খুবই উপকারী!»

– আলেক্সি ইওনভ (SAFe-এর সার্টিফায়েড প্রশিক্ষক)