আজকের আলোচনার বিষয়বস্তু অ্যাজাইল ও স্ক্রাম। এই শব্দ দুটো সফটওয়্যার ডেভলপার ও ইঞ্জিনিয়াররা প্রায়শই বলে থাকে। চলুন তাহলে এগুলো সম্পর্কে জানা যাক-

Agile এর বাংলা অর্থ হতে পারে কর্মদক্ষ কিংবা চটপটে। অর্থাৎ যা খুব সহজে নিজেকে পরিবর্তন করতে পারে প্রয়োজন অনুসারে।

সফটওয়্যার ডেভেলপমেন্টের বেশ কয়েকটি পদ্ধতি বা মেথডোলজি রয়েছে। যেমন- ওয়াটারফল ডেভেলপমেন্ট, প্রোটোটাইপিং, স্পাইরাল, রেপিড সফটওয়্যার ডেভেলপমেন্ট, অ্যাজাইল সফটওয়্যারড ডেভেলপমেন্ট ইত্যাদি। এগুলো বিভিন্ন সফটওয়্যার ইনড্রাস্টিতে ব্যবহার করা হয়। এগুলোর মধ্যে বর্তমানে অ্যাজাইল অনেক বেশি প্রচলিত এবং বলা যায় যে সব সফটওয়্যার ইনড্রাস্ট্রি এই মেথডোলজির দিকে ধাবিত হচ্ছে।

একটা সফটওয়্যার তৈরি করার জন্যে বেশ কতগুলো প্রক্রিয়ার মধ্য দিয়ে যেতে হয়। মনে করুন, আপনি একজন সফটওয়্যার ডেভেলপার। আপনাকে একজন আইডিয়া দিল যে তার একটি ই-কমার্স ওয়েবসাইট লাগবে যা ব্যবহার করে যে কেউ বিভিন্ন পণ্য কিনতে পারবে। এটি একটা আইডিয়া। আপনি এই আইডিয়া নিয়ে বিশ্লেষণ করতে বসে গেলেন। সবকিছু চুলচেড়া বিশ্লেষণ হয়ে গেলে আপনি একটা ডিজাইন করলেন। ডিজাইন সম্পূর্ণ করার পর আপনি তা তৈরি করতে বসে গেলেন। সম্পূর্ণ সফ্টওয়্যার তৈরি করার পর আপনি টেস্ট করলেন ভাল করে। সবকিছু ঠিকঠাক থাকলে আপনার সাইটটি তৈরি হয়ে গেলো।

ওপরের উপায়টিকে ওয়াটারফল মেথডোলজি(waterfall methodology) বলা হয়। তবে এর একটা সমস্যা হলো, আপনার ডেভেলপমেন্ট করার পর আগেই সবকিছু ঠিকঠাক করে ডিজাইন করতে হবে। একটা স্টেজে থেকে আরেকটি স্টেজে যাওয়ার সময় কোনোরকম ভুল করার উপায় নেই। আপনি যখন রিকোয়ারমেন্ট নিয়ে বিশ্লেষণ বা ডিজাইন করছেন তখন কিন্তু মূল প্রোডাক্ট বা সাইটটি তৈরি হয়নি। আপনি যখন পুরোপুরি তৈরি করে ফেললেন তখন আপনার ক্লায়েন্টকে দেখালেন। কিন্তু ক্লায়েন্ট হয়তো সাইটটি দেখে বললো, না আমিতো এভাবে চাইনি। এটি এভাবে করতে হবে। ইতিমধ্যে আপনি পুরো সফটওয়্যার তৈরি করে ফেলেছেন, এখন আর পরিবর্তন করার কোন উপায় নেই। করতে গেলে পুরো প্রক্রিয়ার মধ্যে দিয়ে আবার যেতে হবে যা কষ্টসাধ্য।

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

অ্যাজাইলের ১২ টি ম্যানিফেস্টো রয়েছে।

http://agilemanifesto.org/principles.html

ওপরের সাইটিতে গেলে সেগুলো দেখা যাবে।

মূল কথা হচ্ছে, অ্যাজাইলে অনেকগুলো আইটারেশন থাকে। একবারে সবগুলো না করে ছোট ছোট অংশে ভেঙ্গে কাজ করা এবং খুব সহজে পরিবর্তনকে বরণ করা।

হেরাক্লিটাস নামে এক গ্রিক দার্শনিক বলে গেছেন-

The Only Thing That Is Constant Is Change

সুতরাং পরিবর্তন তো থাকবেই।

এছাড়াও এটি একটি মানসিকতাও। এতে করে সঠিক কাজটি করা যায়। আপনি একটি ভুল করলে, বুঝতে পারার সঙ্গে সঙ্গে তা শুধরে নেওয়ার মানসিকতা থেকে সঠিকটাকে গ্রহণ করা।

মানুষ হিসেবেও অ্যাজাইল হওয়া জরুরী।

এই আইডিয়া বেশ কয়েকভাবে ইমপ্লিমেন্ট করা হয়েছে। এগুলো হলো – স্ক্রাম (Scrum), এক্সট্রিম প্রোগ্রামিং (extreme programming), কানবান(Kanban) ইত্যাদি।

এগুলোর মধ্যে স্ক্রাম অনেক বেশি ব্যবহার হয়। বলা যেতে পারে যেসব ইন্ড্রাস্ট্রি অ্যাজাইল ব্যবহার করে তাদের ৮০-৮৫% শতাংশ স্ক্রাম ব্যবহার করে।

স্ক্রাম মূলত একটি ফ্রেমওয়ার্ক যা কতগুলো ভ্যালুজ, প্রিন্সিপালস, এন্ড প্র্যাকটিসেস দিয়ে থাকে যা দিয়ে কোনো অর্গানাইজেশনে ইঞ্জিনিয়ারিং প্রজেক্ট বা সমস্যা সমাধানের মৌলিক ভিত্তি তৈরি করে দেয়।

উপরে বলেছি যে, অ্যাজাইলে একটি প্রজেক্টকে কতগুলো ছোট ছোট অংশে ভাগ করা হয়। এই ছোট অংশগুলোকে আইটারেশন (iteration) বলা হয়। স্ক্রামে এই প্রত্যেকটি আইটারেশনকে স্প্রিন্ট (sprint) বলা হয়।

প্রত্যেকটি স্প্রিন্টের শেষে মূল প্রজেক্টের একটা নিদির্ষ্ট অংশ(end product) তৈরি হয় যা ক্লায়েন্টকে ডেলিভার করা যায়। এটি ক্লায়েন্ট ব্যবহার করে সাথে সাথে ফিডব্যাক দিতে পারে। এতে করে ক্লায়েন্ট-ডেভেলপার সবসময় একটি কনস্ট্যান্ট ফিডব্যক লুপের মধ্যে থাকে এবং এতে ভুল হওয়ার সম্ভবনা কমে যায়। এতে করে ক্লায়েন্টের সম্পূর্ণ ভিজিবিলিটি থাকে। অন্যদিকে ওয়াটারফলে এই ভিজিবিলিটি থাকেই না।

তাহলে প্রশ্ন হতে পারে একটি প্রজেক্টকে কীভাবে ছোট ছোট অংশে ভাগ করা যায়। স্ক্রামে রিকোয়ারমেন্টগুলোকে ইউজার স্টোরি (user story) আকারে লেখা হয়।

ইউজার স্টোরি একটি সংক্ষিপ্ত বর্ণনা যেখানে সফটওয়্যারের একটি ফিচার একজন ইউজারের পার্সপেক্টিভ থেকে লেখা হয়। অনেকটা এমন- একজন ব্যবহারকারী (user) যখন কোনো নির্দিষ্ট ফিচার ব্যবহার করবে সে কী প্রত্যাশা করে। উদাহরণ-

As an admin, I want to do < certain things in the site> so that I can do < this things>

As a website user, I need a home button, so that I can return back to the homepage with a single click.

 প্রত্যেকটি ইউজার স্টোরিতে তিনটি বিষয় থাকে।

১. Role বা ক্যারেক্টার অর্থাৎ যে ইউজার স্টোরির নির্দিষ্ট কাজটি করতে যাচ্ছে
২. feature – অর্থাৎ ক্যারেক্টারটি আসলে যে কাজটি করতে যাচ্ছে
৩. benefit – এই কাজটি করে কী লাভ হবে?

কোনো একটি ইউজার স্টোরিতে যদি এই তিনটি অংশ থাকে, তাহলে এই প্রত্যেকটি স্টোরি হবে একটি অখণ্ড, একটি নির্দিষ্ট ফিচার যা তৈরি করার (কোড লেখার) পর একটি এক্সিকিউটেবলে পরিণত হবে এবং তা ইউজার ব্যবহার করতে পারবে।

এই ইউজার স্টোরিগুলোকে একটি কালেকশনে রাখা হয় যার নাম ব্যাকলগ (backlog)। এই ব্যাকলগ তিন রকম হতে পারে –
১. প্রোডাক্ট ব্যাকলগ – এখানে একটি প্রজেক্ট বা প্রোডাক্টের (যে সফটওয়্যারটি তৈরি করা হচ্ছে) সবগুলো ব্যাকলগ থাকে।

২. স্প্রিন্ট ব্যাকলগ – একটি নির্দিষ্ট স্প্রিন্টের ব্যাকলগ যা কোন নিদির্ষ্ট স্প্রিন্টে যে ইউজার স্টোরিগুলো নিয়ে কাজ করা হচ্ছে সেগুলো।

৩. রিলিজ ব্যাকলগ – এটি কয়েকটি স্প্রিন্ট মিলে হতে পারে। অনেক সময় স্প্রিন্ট ছোট সময়ে হয়(১ সপ্তাহ বা ২ সপ্তাহ)

এক্ষেত্রে অনেকগুলো স্প্রিন্টের কাজ নিয়ে একটি রিলিজ দেওয়া হয়, যাতে ক্লায়েন্টের কাছে একটা মিনিংফুল কিছু যায়।
এখন যেহেতু আমাদের কাছে অনেকগুলো ইউজার স্টোরি রয়েছে, তাহলে কোনগুলো আগে করা হবে আর কোনগুলো পরে করা হবে তা নিয়ে প্রশ্ন হতে পারে। এক্ষেত্রে অবশ্যই স্টোরিগুলোকে prioritize করতে হবে। এতে করে যে স্টোরিগুলো সবচেয়ে বেশি প্রাসঙ্গিক সেগুলোকে আগে করা যায়।

এই privatization নানাভাবে করা যায়। প্রথমত এই স্টোরিগুলো যেগুলো আগে দরকার সেগুলোকে টপ অর্ডারে সাজানো যেতে পারে। তারপর কোনটি করতে কেমন সময় লাগবে তার একটি হিসাব করা হয়। এই প্রক্রিয়ায় টিমের সবাই অংশ গ্রহণ করতে পারে। এই সময় নির্ধারণ করার জন্য প্রত্যেকটি স্টোরিকে একটি ফিবোনাচি সংখ্যা দেওয়া যেতে পারে। অনেক ছোট স্টোরিকে ১, এর থেকে একটি বেশি বড়কে ২, এভাবে তিন, মাঝারি স্টোরিকে ৫ এবং এর থেকে একটু বড় স্টোরিকে ৮ তারপর ১৩ এভাবে স্টোরি পয়েন্ট দেওয়া যেতে পারে। এরপর টিমের ক্যাপাসিটি দেখা হয়।

ধরা যাক, একটি টিমে দুইজন ডেভেলপার আছে, তারা দুই সপ্তাহে ১৫ পয়েন্ট স্টোরি নিয়ে কাজ করে, তাহলে সেই টিমের ক্যাপাসিটি হচ্ছে ১৫। স্প্রিন্টটি যদি দুই সপ্তাহের হয়, সেক্ষেত্রে একটি স্প্রিন্টে ব্যাকলগ থেকে প্রায়োরিটি অনুযায়ী ১৫ পয়েন্টের স্টোরি বেছে নিয়ে স্প্রিন্ট শুরু করা হয়। এর জন্যে একটি সংক্ষিপ্ত স্প্রিন্ট প্ল্যানিং মিটিং হয়ে থাকে। যেখানে ডেভেলপমেন্ট টিম মেম্বার, প্রোডাক্ট ওনার (product owner) মিলে সিন্ধান্ত নেয়। এই মিটিংয়ের পর ডেভেলপাররা স্টোরিগুলোকে আরও ছোট ছোট টাস্কে বিভক্ত করে এবং এতে টাইম এস্টিমেশন দেয়- একটি ছোট টাস্ক করতে কতক্ষণ লাগতে পারে ইত্যাদি।

এখন স্প্রিন্ট শুরু হয়ে গেল। কিন্তু এখন প্রশ্ন হচ্ছে, কীভাবে কাজের ট্র্যাক রাখা যায়। খুব সংক্ষিপ্ত সময়ের টাইট টামইলাইনে নানাভাবে deviate হওয়ার সম্ভবনা থাকে। এরজন্য স্ক্রামে প্রতিদিন একটা নির্দিষ্ট সময়ে ১৫ মিনিটের একটি সংক্ষিপ্ত মিটিং হয়। একে daily scrum meeting বা daily scrum বলা হয়। এই মিটিং প্রত্যেকটি টিম মেম্বার উপস্থিত থাকে এবং প্রত্যেকেই তিনটি প্রশ্নের উত্তর দিয়ে থাকে –

১. আপনি গতকাল কী কাজ করেছেন? (status update)
২. আপনি আজ কী করতে যাচ্ছেন ? (planning update)
৩. আপনার কাজে কোনো ব্লকার বা কোনো কিছুতে আটকে আছেন কিনা? (obstacle update)এছাড়াও প্রত্যেকটি টিম মেম্বার যে নিদির্ষ্ট স্টোরিতে কাজ করছে, সেগুলোতে কে কতক্ষণ কাজ করেছে তা লগ করে থাকে। এতে করে কোন স্টোরিতে কতক্ষণ কাজ করা হয়েছে বা কতক্ষণ বাকি তা রেকর্ড করা থাকে। এর জন্য একটি স্ক্রাম বোর্ড ব্যবহার করা হয়।

এতে করে যেকোনো মুহূর্তে টিমের একটি কমপ্লিট পিকচার পাওয়া যায়। এই বোর্ডের অনলাইন সফটওয়্যার রয়েছে। এগুলোর মধ্যে Trello ও JIRA জনপ্রিয়।

একটি স্ক্রাম টিমে তিনটি ক্যারেক্টার বা এনটিটি থাকে – স্ক্রাম মাস্টার (Scrum Master) , প্রোডাক্ট ওনার (product owner) এবং ডেভেলপমেন্ট টিম (development team)। স্ক্রাম মাস্টারের কাজ হলো সবকিছু ঠিকঠাক মতো চলছে কিনা তা খেয়াল রাখা। সে অনেকটা কোচ (coach) হিসেবে কাজ করে। তার মূল উদ্দেশ্য থাকে কীভাবে একটি হাই পার্মমেন্স টিম তৈরি করা যায়। টিমে কোনো রকম bottleneck বা সমস্যা থাকলে তা স্ক্রাম মাস্টার সমাধান করার চেষ্টা করে।

সহজ বাংলায়, প্রোডাক্ট ওনার হচ্ছে, একজন ব্যক্তি যে পুরো প্রোডাক্টের মালিক। পুরো টিমের সামগ্রিক কিছুর দায়িত্ব তার । তিনি সবার সাথে যোগাযোগ রাখে। প্রোডাক্ট বা প্রজেক্ট নিয়ে তার একটি ক্লিয়ার ভিশন থাকে যা মূলত স্ক্রাম টিম অ্যাচিভ করতে চেষ্টা করে।

ডেভেলপমেন্ট টিম হলো যারা মূলত সফটওয়্যারটি তৈরি করে- এক্ষেত্রে সফ্টওয়্যার ডেভেলপার, টেস্টার ইত্যাদি।
স্প্রিন্ট শেষে একটি স্প্রিন্ট রিভিও মিটিং হয়। এই মিটিংয়ে মূলত ডেভেলপমেন্ট টিম নির্দিষ্ট স্প্রিন্টে কী কী কাজ হয়েছে তা ডেমোনস্ট্র্যাট করে।

স্প্রিন্ট শেষ হয় আরেকটি মিটিং দিয়ে যার নাম sprint retrospective.

এই মিটিং স্ক্রাম টিমের প্রসেসগুলো নিয়ে আলোচনা করা হয়। এতে কোথাও কোন সমস্যা থাকলে সেগুলো নিয়ে আলেচনা করা হয় এবং কিভাবে সেগুলো থেকে বের হওয়া যায়।

অর্থাৎ একটি স্প্রিন্ট শুরু হয় প্ল্যানিং মিটিং দিয়ে, শেষ হয় স্প্রিন্ট রিভিও ও স্প্রিন্ট রেট্রোসপেকটিভ দিয়ে। এভাবে এই সাইক্যাল চলতে থাকে প্রোডাক্ট বা সফওয়্যারটি সম্পূর্ণ শেষ হওয়ার আগ পর্যন্ত।