Agile Software Development Part-1 | Software Engineering

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

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

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

এখই এই পরিস্থিতে যদি Plan-driven বা Waterfall মডেল ব্যবহার করা হয়, যেটা অনেক সময় সাপেক্ষ , তাহলে দেখা গেল কাস্টমার এটা ব্যবহার করায় ছেড়ে দিছে।

দ্রুত সফটওয়্যার ডেভেলপমেন্ট করার এমন কিছুর প্রসেস দরকার যেটার দ্বারা পরিবর্তন গুলো সহজে পরিচালনা করা যায়। এজন্য একমাত্র সমাধান হচ্ছে Agile Development or Agile methods.

Agile methods

Agile methods হলো একটি incremental development method যেখানে increments গুলো ছোট ছোট এবং সাধারনভাবে ২-৩ সপ্তাহের মধ্যে মধ্যে নতুন নতুন ফিচার রিলিজ করা হয়ে থাকে। এখানে কাস্টমারকে সংযুক্ত করা হয় এবং তার ফিডব্যাকের প্রহন করা হয়। এই ফিডব্যাকের উপর নির্ভর করে নতুন ফিচার পরবর্তী রিলিজে অ্যাড বা রিমুভ করে দেওয়া হয়।

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

এই ভারী পদ্ধতি ব্যবহার করে একধরনের অশান্তির সৃষ্টি হয় তখন আর্বিভাব ঘটে Agile methods এর। Agile methods এর দর্শন বা ফিলোসফি এর ম্যানিফেস্টতে বোঝা যায়।

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.

Visit Agile Manifesto

Agile এর সবগুলো methods একটা জিনিসের পরামর্শ দিয়ে থাকে, দ্রুত ডেভেলপমেন্ট এবং ডেলিভারি করা। এসব মেথডস গুলো বিভিন্ন পদ্ধতিতে কাজ করে থাকে কিন্তু এতের ভিতরে বিদ্যমান নীতি বা প্রিন্সিপাল গুলো একই ধরনের।

Agile methods গুলো দুই ধরনের সিস্টেম ডেভেলপ করা জন্য সব থেকে সফল।

• প্রোডাক্ট ডেভেলপমেন্ট সেখানে কোন কোম্পানি বিক্রয় করা জন্য ছোট অবথা মিডিয়াম সাইজের প্রোডাক্ট ডেভেলপ করছে।
• কোন সংগঠনের জন্য কাস্টম সিস্টেম ডেভেলপমেন্ট

Agile Development Techniques

Agile methods মুলত ডেভেলপ হয় নব্বই এর দশকে। সফটওয়্যার এর ডেভেলপমেন্ট কালচারে পরিবর্তন এক্সট্রিম প্রোগ্রামিং এর মধ্যে দিয়ে। এই পদ্ধতিতে বেস্ট প্রাক্টিস গুলো ফলো করা হয়, iterative ডেভেলপমেন্ট করা হয় এবং ডেভোলোপমেন্ট চরম পর্যায়ে পুশ করা হয়। একটা সিস্টেমের একটা নতুন ভার্সন একই দিনে আলাদা আলাদা প্রোগ্রামার ডেভেলপ, ইন্টিগ্রড এবং টেস্ট করবে।

extreme programming-এ requirements গুলোকে বিভিন্ন সিনারিও হিসেবে প্রকাশ করা হয়, যেগুলো মুলত সিরিজ টাস্ক হিসবে ইমপ্লিমেন্ট করা হয়। প্রোগ্রামাররা এই টাস্ক গুলোর উপর ভিত্তি করে বিভিন্ন টেস্ট কেস ডেভেলপ করে এবং টেস্ট কোড লেখার এই টেস্ট গুলো অবশ্যই পাস করাতে হয়।

প্রাক্টিক্যালি দেখলে, দেখা যাবে XP যেমন টা সহজ মনে হয়, আসলে এটা ততটায় কঠিন একটা প্রসেস। এখানে বেশিরভাগ কোম্পানির ক্ষেত্রে এই প্রসেস টা ইন্টিগ্রেট করা সম্ভব হয় না। বিভিন্ন ধরনের সমস্যা দেখা দেয়। ম্যানেমেন্ট করতে সব থেকে বেশি সমস্যার সৃষ্টি হয়। বর্তমানে বেশির ভাগ কোম্পানিই Scrum কে ব্যবহার করছে কারন এটা সম্পূর্ণ ম্যানেজমেন্ট ফোকাস।

User Stories

software requirements প্রতিনিয়ত পরিবর্তন হতে থাকে। এসব পরিবর্তনকে হ্যান্ডেল করা করা জন্য Agile methods এর আলাদা কোন requirements engineering আকটিভিটি নাই। মুলত requirements elicitation করা হয় ডেভেলপমেন্ট করার সময়। এই জিনিস টাকে সহজ করার জন্য উদ্ভব হয় “user stories”। “user stories” হল একটা সিনারিও যেখানে সিস্টেম ডেভেলপ হওয়ার পর একজন ব্যবহারকারীর কি রকম অভিজ্ঞতা হবে তার বিবরন।

কাস্টমার এবংডেভেলপমেন্ট টিম একসাথে আলোচনার মাধ্যমে একটা স্টোরি কার্ড ডেভোলোপ করে যেখানে সব কিছু বিস্তারিত উল্লেখ থাকে। story card গুলো নিচের মত হতে পারে,

user stories সিস্টেম ডেভেলপ করা জন্য প্লানের কাজে ব্যবহার করা যেতে পারে, যেখানে ইটারেটিভ ভাবে কাজ গুলো করা হবে। একবার story card গুলো ডেভেলপ হয়ে গেলে সেগুলো কে ভেঙ্গে আলাদা আলাদা টাস্ক এ পরিনত করা হয়। এখানে মুলত রিসোর্স requirements এস্টিমেট করা হয় এবং কাস্টমার এর সাথে আলোচনা করা হয় এবং দেখা হয়, কোন পরিবর্তন করার প্রয়োজন আছে কিনা। এখানে টাস্ক গুলোকে এমনভাবে বিভক্ত করা হয় যাতে সেগুলো ২ সপ্তাহের ভিতরে তৈরি করা সম্ভব হয়।

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

user stories এর সব থেকে বড় সমস্যা হল এর পূর্ণতা নিয়ে। একটা সম্পূর্ন সিস্টেমের requirements পূরনের জন্য প্রয়োজনীয় সকল স্টোরি গুলো ডেভেলপ হয়ে কিনা তা বোঝা খুব কঠিন। আবার একটা স্টোরির সিস্টেমের কোন একটিভিটি সম্পুর্ণ রুপে আলোচনা করছে কিনা তাও বোঝা কঠিন। ইউজার প্রায়শ অনেক কিছুই উল্লেখ করতে ভুলে যান।

Refactoring

Software Engineering এর মৌলিক উদ্দেশ্য হচ্ছে সিস্টেম ডিজাইন করা পরিবর্তনের জন্য। এমন ভাবে সিস্টেমটাকে ডিজাইন করতে হবে , যাতে সহজে পরিবর্তন করা যায়। Refactoring এর মানে হচ্ছে, প্রগ্রামিং টিম সম্ভাব্য ইম্প্রুভমেন্ট গুলো খুজবে এবং তৎক্ষণাৎ সেগুলোকে ইমপ্লিমেন্ট করবে।

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

Incremental development একটি মৌলিক সমস্যা হচ্ছে, এখানে সিস্টেম স্ট্রাকচার ধীরে ধীরে খারাপে দিকে যেতে থাকে। একটা পর্যায়ে এমনও হতে পারে যে সিস্টেম এ আর কাজ করা সম্ভব হচ্ছে না। Refactoring সিস্টেম স্ট্রাকচার এর মান বৃদ্ধি করে বোধ্যগম করে তোলে এবং স্ট্রাকচার যাতে অবনতি না হয় সেদিকে লক্ষ্য রাখা হয়।

Refactoring এর উদাহরন অনেক রয়েছে। Code duplication remove, unused code remove, unwanted feature remove, make code organize ইত্যাদি। আরো ভালো করে বললে, কোড অনেক অংশ আছে যেগুলো বার ব্যবহৃত করে হয়েছে। একট কোড কপি পেস্ট করা হয়েছে। এক্ষেত্রে ওই কোডকে একটা ফাংশন বানিয়ে ব্যবহার করে কোড ডুপ্লিকেশন কমে যাবে।

Test Driven Development

Test Driven Development বা TDD একটা পদ্ধতি যেখানে কোন কিছু ইমপ্লিমেন্ট করার আগেই তার প্রয়োজনীয় টেস্ট কেস লেখা হয়। TDD একটা Extreme Programming এর একটি অংশ। XP তে টেস্টিং এর কিছু বৈশিষ্ট রয়েছে।

• Test First Development
• incremental test development from scenarios
• user involvement in the test development and validation
• the use of automated testing frameworks

Test Driven Development বা TDD সফটওয়্যার ইঞ্জিনিয়ারিং -এ একটি গুরুত্বপূর্ণ উদ্ভাবন। সাধারন ভাবে আমরা কি করি কোন ফিচারকে ইমপ্লিমেন্ট করি । তারপর তার জন্য প্রয়োজনীয় টেস্ট কেস লিখি। এখানে সমস্যা হচ্ছে আমরা অনেক কিছুই উপেক্ষা করতে পারি আবার কোড লেভেল ফোকাস করতে অনেক টেস্ট কেস এর কথা মাথায় থেকে চলে যেতে পারে। অনেক ক্ষেত্রে অনেক বাগ দেখা দিতে পারে। TDD কোন কিছু ইমপ্লিমেন্টশন করা আগে তার জন্য প্রয়োজনীয় সকল টেস্ট কেস গুলো লিখে ফেলা হয়। এবং তারপর কোড লেভেলে কাজ করা হয়। বাগ হওয়ার সম্ভাবনা কমে যায়। তাছার কোডার কে বেশি চিন্তা করা লাগে না। আর সব থেকে বড় কথা টেস্ট কেস গুলো যতক্ষন তা পাস হচ্ছে ততখন সেটা মূল সিস্টেমের সাথে যোগ করা হবে না।

TDD এর আরেক টা সুবিধা হচ্ছে কাস্টমারকে হ্যাপি রাখা যায়। আমি ব্যক্তিগত ভাবে কাজ করতে যেয়ে অনেক সমস্যার সম্মুখীন হয়েছি।

“এইটা কেন কাজ করছে, এইটা কেন কাজ হচ্ছে না? এই এমন হচ্ছে কেন? কাল রাতেই তো ঠিক ছিল আজকে আবার কি হল ? ইত্যাদি “

এখানে আমার ভুল ছিল আমি তার Story কে ভালো করে ব্যাখা করতে পারিনি। কিরকম ফিচার লাগবে সেটা নিয়ে তেমন আলোচনা করলেও সেগুলো অনেক হাই লেভেল এর ছিলো (কোড থেকে অনেক উপরে )। এখানে যদি TDD প্রয়োগ করা হয়, তাহলে কি হত, কাস্টমার এর ভাব পরিবর্তন হয়ে যেত। তখন তার কথা নিম্নরুপ হতে পার,

“এই ফিচার টা এমন করা যায় না? এই টা নিচে না দিয়ে উপরে দিকে দেওয়া যেতে পারে কিনা? এই ফিচার টা নতুন করে অ্যাড করা যায় কিনা ? ইত্যাদি”

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

TDD এর জন্য টেস্ট আটোমেশন অত্যাবশীকীয়। টেস্ট গুলো লেখা হয় কম্পোনেন্ট গুলো তৈরি হওয়ার আগে execute করা জন্য। এই টেস্ট কেস গুলো অবশ্যই স্বতন্ত্র হতে হবে যাতে ইনপুট দিয়ে সহজে টেস্ট করা যায়। টেস্টিং কে অবশ্যই অটোমেশন করতে হবে যাতে যখন কোন পরিবর্তন হয় তখন যেন টেস্টিং শুরু হয়ে যায়। ফলাফল ইতিবাচক হলে মূল সিস্টেমে যুক্ত করতে দেওয়া হবে আর না হলে আবার কোড কর।

TDD তে কিছু সমস্যা আছে।

• প্রোগ্রামার টেস্টিং কে অগ্রধিকার দেয় তবে অনেক ক্ষেত্রে টেস্ট লেখার সময় সটকাট ব্যবহার করে। এসময় অনেক টেস্ট কেস এড়িয়ে যায়। এক্ষেত্রে অনাকাক্ষিতে বাগের দেখা মিলে।
• কিছু কিছু টেস্ট আছে যেগুলো লেখা খুবই কষ্টকর বিষয়।

TDD তে অনেক টেস্ট কেস লেখা হয়। কিন্তু তারপরও এটা বলা মুশকিল যে টেস্ট কেস গুলো সম্পূর্ণ সিস্টেমকে কভারেজ দিতে পারছে।

Pair Programming

Pair এর বাংলা হচ্চে জোড়া। যখন দুইজন প্রোগ্রামার একসাথে একই কম্পিউটারে বসে প্রোগ্রামিং করবে তখন তাকে Pair Programming বলা হবে। কোন টাস্ক সম্পূর্ন করা জন্য আপনার একজান পার্টানার থাকবে। তবে এই পেয়ার প্রতিবার ডায়নামিক্যালি তৈরি করা হবে।

Pair Programming এর কিছু সুবিধা আছে।

• Collective Ownership: সিস্টেম সবাই একই সাথে কাজ করে তাই সিস্টেম এর Ownership সবার থাকে। কেউ কাউকে ব্লেম করতে পারে না। দায়িত্ব বা দায়ভার সবার থাকে।
• Informal Reviews: যেহেতু একজন পেয়ার থাকে সেহেতু কোডের একটা Informal review হয়ে যায়। এখান থেকে সিস্টেম এ অ্যাড হওয়ার আগেই অনেক এরর বের হয়ে আসতে পারে। যদি এই প্রসেসে অনেক সময় লেগে যায় বিধায় ডেভেলপমেন্ট প্রসেস এ ডিলে তৈরি হয়।
• Encourages Refactoring: নিজে নিজে কোড লিখলে অনেক সময় বোঝায় যায় না যে এখানে ইম্পূভ করা যেত । আর অন্য বিস্তারিত ভাবে বলে দেবে না। এখন একজন পেয়ার থাকলে দুইজনের মধ্যে আলোচনা অনেক ইম্পুভমেন্ট করা যেতে পারে।

এখানে যে কেউ মনে করবে যে, Pair Programming individual programming এর থেকে ভালো না। আসলে দুইজন আলাদা আলাদা ভাবে যে কোড লিখতে পারবে , Pair Programming -এ তা অর্ধেক হয়ে যাবে। অনেক কোম্পানি আছে যারা Pair Programming কে ব্যবহার করে তারা এই নিয়ে সন্দিহান এবং তার এটা আর ব্যবহার করে না। তবে ক্ষেত্রে বিশেষ সিনিয়র প্রোগ্রামার জুনিয়র প্রোগ্রামের সাথে এক সাথে কাজ করে।

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

Pair Programming ক্ষেত্র বিশেষ-এ এখনো ব্যবহার করা হয়। তবে বেশির ভাগই কোম্পানিই এতা ব্যবহার করতে চাইবে না।

To be continued...