ইংরেজি এজাইল (Agile) শব্দটির বাংলায় অভিধানিক অর্থ দাঁড়ায় কর্মতৎপর বা গতিশীল। অর্থাৎ কোন কাজ দ্রুত করতে পারে যে ব্যক্তি। কোন অফিসে যার কাজের গতি সবার চেয়ে বেশি, তাকেই এজাইল ওয়ার্কার বলা যায়। তবে পণ্য বা সফটওয়ার প্রস্তুতকারী প্রতিষ্ঠানগুলোতে এই শব্দটি একটু আলাদাভাবে পরিচিত…

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

তাহলে একটি ইউজার স্টোরি ‘এজাইল’ বা গতিশীল কি করে হবে?

• ইউজার স্টোরির ভাষা হতে হবে সংক্ষিপ্ত ও সহজ। যেকোন ফিচার বা কাজের বর্ণনা লিখতে হবে ব্যবহারকারীর দৃষ্টিকোণ থেকে।
• এজাইল মেথডোলজিতে ইউজার স্টোরি লেখার একমাত্র উদ্দেশ্য কাজের গতি বাড়ানো। তাই ইউজার স্টোরিটা স্মার্ট হওয়া জরুরি।
• তবে পণ্য ব্যবহারকারী বা তার চাহিদা সম্পর্কে স্পষ্ট ধারণা না থাকেলে ইউজার স্টোরি লেখার কাজটা আপনার জন্য নয়…

 সফলভাবে ইউজার স্টোরি লিখতে এই ধাপগুলো অনুসরণ করা অত্যাবশ্যক:

• পণ্যের ভোক্তা বা ব্যবহারকারী কে, সেটি জানতে চেষ্টা করুন। তার কাছে কোনটি জরুরি এবং কেন তিনি এই পণ্য ব্যবহার করেন সেটিও বুঝতে চেষ্টা করুন।
• ব্যবহারকারীর বৈশিষ্ট্যগুলো নোট করে নিন, এরপর নির্দেশনাগুলো তার দৃষ্টিকোণ থেকে চিন্তা করে লিখুন। প্রয়োজনে এপিক বা গল্প আকারে বড় করে নির্দেশনা লিখে সেটিকে ঘষামাজা করে নিন।
• তারপর সেই নির্দেশনাটি আরও ছোট ছোট অংশে ভাগ করুন। ব্যাস। তবে খেয়াল রাখতে হবে, আপনার ইউজার স্টোরি যেন অন্যরা সহজে বুঝতে পারে এবং প্রতিটি নির্দেশনা অন্যটির সঙ্গে সামঞ্জস্যপূর্ণ হয়। আর প্রয়োজনে অন্য কাউকে সেটি পড়তে দিন ও একাধিকবার সংশোধন করুন।

একটা উদাহরণ দেখি তাহলে:

As a < type of user >, I want < some goal > so that < some reason >.

একজন < ব্যবহারকারী হিসেবে >, আমি চাই < আমার উদ্দেশ্য >, কেননা <ব্যবহারের কারণ>

<type of user>, <action>, <expected outcome>

< ব্যবহারকারীর ধরণ>, < ব্যবহারের ‘উদ্দেশ্য’ > , <ফলাফল>

এজাইল বা গতিশীল ইউজার স্টোরি লেখার অন্যতম সুবিধা হলো, এতে খুঁটিনাটি বিষয়গুলো কয়েকটি স্তরে সম্পূর্ণভাবে লেখা যায়। অনেক সময় একটা ইউজার স্টোরিতে কয়েকটি বড় বড় কাজের বিবরণ দেয়া যায়। এ ধরণের ইউজার স্টোরিকে বলা হয় ‘এপিক’ (Epic)।

যেমন :

ব্যবহারকারী হিসেবে, আমি আমার একাউন্টের পাসওয়ার্ড রিসেট বা পুনরুদ্ধার করতে পারি।

As a user, I can reset my account password.

তবে একটা এজাইল টিমের জন্য এপিক লেখার কাজটা কষ্টকর হয়ে পড়ে। পুরো ব্যাপারটা জটিল বলে একে ভেঙে ছোট ইউজার স্টোরিতে রূপান্তর করা হয়, যাকে বলে স্প্রিন্ট ‘sprints’।  এর ফলে কাজ করাটা সহজ হয়ে যায়। যেমন উপরের এপিকটাকে ভেঙে এরকম এক ডজন ইউজার স্টোরি লেখা যাবে:

ব্যবহারকারী হিসেবে, আমি যখন ‘রিসেট পাসওয়ার্ড’ (reset password) লিঙ্কে ক্লিক করবো, তখন আমাকে একটি সঠিক ইমেইল এড্রেস (valid email address) লেখার পেইজে পাঠানো (redirected) হবে।

এবার ব্যবহারকারী হিসেবে আমি যদি ইতিমধ্যেই ডাটাবেজে সংরক্ষিত আছে এমন একটি ইমেইল এড্রেস টাইপ করি, তাহলে সেখানে আমাকে নতুন পাসওয়ার্ড (reset password) লেখার একটি লিঙ্ক ইমেইল করা হবে।

এভাবে লিখলে আগের এপিকটি আরও সমৃদ্ধ হয়, ফলে কোডাররা পাসওয়ার্ড রিসেট করার ফিচারটি কিভাবে কাজ করবে সেটি বুঝে সে অনুযায়ী প্রোগ্রাম তৈরি করে টেস্ট করতে পারবে।

ইউজার স্টোরিতে যে একেবারে পুঙ্খানুপুঙ্খ বর্ণনা লিখতে হবে এমন কোন কথা নাই। ব্যাপারটা এমন না যে, একজন ইঞ্জিনিয়ার আপনার ইউজার স্টোরি পড়েই সব ফাংশন হুবহু বুঝে নিবেন। এটা শুধুমাত্র তাকে একটি কাজের প্রাথমিক ধারণা দেয় আর ফাংশনটি ব্যবহারের কারণটা জানতে সাহায্য করে।

আপনার ইউজার স্টরি যদি ইনভেস্ট (INVEST) মডেলের সঙ্গে মিলে যায়, তাহলে কিন্তু দারুণ হবে। ইনভেস্ট (INVEST) এর মানে দাঁড়ায় স্বাধীন (ইনডিপেন্ডেন্ট ), আলোচনাসাপেক্ষ (Negotiable), গুরুত্বপূর্ণ (Valuable), যাচাই করা যায় এমন কিছু (Estimatable), সংক্ষিপ্ত (Small) ও গ্রহণযোগ্য (Testable)।

অর্থাৎ,

• আপনার ইউজার স্টোরি কোন বাঁধা ছাড়াই কাজ আগাতে পারবে
• এটি নিয়ে সবাই মিলে আলোচনা করতে পারবে বা ডেভলপাররা প্রয়োজনমতো একে ব্যবহার করতে পারে
• এটি ব্যবহারকারীর গুরুত্ব বৃদ্ধি করবে
• ডেভলপাররা এর কার্যকারিতা উপলব্ধি করতে পারবে
• সংক্ষিপ্ত হলেও এটি ব্যবহারকারীর চাহিদা সঠিকভাবে ভাষায় প্রকাশ করতে পারবে।
• সর্বোপরি এটি সবার কাছে গ্রহণযোগ্য হতে হবে।

ইউজার স্টোরি লেখার দায়িত্ব আসলে কার?

এর উত্তর হচ্ছে, যে কেউ ইউজার স্টোরি লিখতে পারে। অনেকক্ষেত্রে সফটওয়ার বা প্রোডাক্টের মালিক এর দায়িত্বে থাকলেও দলের অন্য সদস্যরাও প্রয়োজন অনুযায়ী ইউজার স্টোরি লিখে থাকেন। আর সব ইউজার স্টোরি যেন ঠিকভাবে কাজ করে তার তদারকি করার দায়িত্ব প্রোজেক্ট ম্যানেজারের।

ইউজার স্টোরি লেখার জন্য এই ১০টি টিপস মনে রাখা দরকার:

• সবকিছু বিস্তারিত লিখতে যাবেন না।
• একটি ফিচার কিভাবে কাজ করবে সেটি লাইন টু লাইন ডেভলপারকে বুঝানোর দরকার নেই।
• সব কাজের নির্দেশনা ইউজার স্টোরির উপরে নির্ভর করে না।
• এটি যেকোন সময় বদলাতে হতে পারে।
• সব ইউজার স্টোরির আকার বা কাজের ধরণ এক না।
• প্রোডাক্ট ব্যাকলগের (product backlog) মতন এখানে সব ফিচার লিখে দেয়ার প্রয়োজন নেই।
• আগাগোড়া সবকিছুই যে ব্যবহারকারীর দৃষ্টিকোণে লিখতে হবে তা কিন্তু না।
• ইউজার স্টোরি স্ক্রামের (Scrum) অংশ নাও হতে পারে।
• কাস্টমারদের কাছে সচরাচর ইউজার স্টোরি প্রকাশ করা হয় না।
• ইউজার স্টোরি লেখার কোন নির্দিষ্ট ফরম্যাট বা বিধিবিধান নাই।