বাংলায় সফটওয়্যার ইঞ্জিনিয়ারিং-এর উপর লেখা কিছু নোট : সফটওয়্যার ডেভেলপমেন্ট -র ক্লাসিক ভুলগুলো

সফটওয়্যার ডেভেলপমেন্ট -র ক্লাসিক ভুলগুলো

ডিসেম্বর ৩, ২০১৫, বৃহস্পতিবার

অন্য অনেক লেখার মত আবারও প্রথমেই বলে নেই, আমি কোনো ভাবেই সফটওয়্যার ইঞ্জিনিয়ারিং কিংবা ডেভেলপমেন্টের “পন্ডিত” কোনো ব্যক্তি না, কাজ করতে গিয়ে শেখা কোনো অভিজ্ঞতা বা পড়া কোনো ইন্টারেষ্টিং আর্টিকেল নিয়ে বাংলায় লিখি। আজকেও এমন একটা বইয়ের আর্টিকেল আর অনলাইন-এ ফ্রি একটা কোর্স নিয়ে লিখছি।

স্টিভ ম্যাককনেল সফটওয়্যার ডেভেলপমেন্ট আর ম্যানেজমেন্ট -র উপর অনেকগুলো বই লিখেছেন। তাঁর সবচেয়ে বিখ্যাত বই হচ্ছে কোড কমপ্লিট। বইটা এতই উপকারী যে, যতটুকু জানি, মাইক্রোসফট এক সময় তাদের কোম্পানিতে ইন্টারভিউ দিতে আসা লোকজনকেও বিনামূল্যে বইটা দিয়ে দিত (আমাদের ডিপার্টমেন্ট-এর শিশির ভাইয়ের কাছ থেকে বইটা আমি পেয়েছিলাম)। আজকের লেখাটা আসলে এই বই নিয়ে না, তাঁর আরেকটা বই Rapid Development - Taming Wild Software Schedules -র একটা টপিক-এর নিয়ে।

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

এইরকম কয়েকটা পরিস্থিতি - আর তার প্রেক্ষিতে নেয়া (ভুল )সিদ্ধান্ত বা প্রাকটিস হচ্ছে:

প্রজেক্ট ডেডলাইন ধরতে পারবে না? - ত সমস্যা নাই, আরো বেশি ডেভেলপার প্রজেক্ট-এ যোগ করে দিলেই হবে
কোনো এক ব্যক্তি তার কাজ ঠিককমত, সময়মত করছে না, ফলে অন্যরা আটকে আছে - ওকে এখন কিছু বলার দরকার নেই, প্রজেক্ট শেষ হয়ে নেক, ব্যাটাকে বিদায় করে দিতে হবে
মার্ক চরম বস লোক, ও একাই সব পারে - ওকেই সব সাবটাস্কে ডেভেলপার বা লিড করে দাও, ও ঠিক-ই সময় মত সব করে ফেলবে, চিন্তার কোনো কারণ নেই
এই প্রজেক্ট খুবই কঠিন, অনেকগুলো পার্ট আছে। কোনোভাবেই ৩ মাসে শেষ করা যাবে না - কিন্তু সবাই যদি খুব খেটে-খুটে কাজ করে, তাহলে শেষ হয়েও যেতে পারে। ঠিক আছে, ডেডলাইন তাহলে ৩ মাস -ই থাকুক
আমাদের কাজের জায়গাটা খুবই এনার্জেটিক, সবাই ওপেন স্পেস -এ কাজ করি - সব সময়ই হই-হুল্লোড় করে কাজ করাতেই বেশি মজা
আমরা রেপিড/ এজাইল ডেভেলপমেন্ট-এ বিশ্বাসী - রিস্ক ম্যানেজমেন্ট করার দরকার নাই।
৬ মাসের প্রজেক্টে ২ মাস পর পর একেকটা মাইলস্টোন আছে, কিন্তু প্রথমটা করতেই ৩ মাস লেগে গেছে - সমস্যা নাই, পরের মাইলস্টোন-র আগেই পুষিয়ে নেব।
টেস্টিং এনভায়রনমেন্ট কনফিগার করতে বেশি সময় বা অনেকদিন লেগেছে - ব্যাপার না, স্টেজিং কিংবা প্রোডাকশন এনভায়রনমেন্ট কনফিগার করতে এত সময় লাগবে না, ১ দিনেই হয়ে যাবে। আরে আমরা ত প্রথমবারের ভুলগুলো থেকে শিখেছিই, নাকি ?
অফ-শোর টীম সময় অনুযায়ী আমাদের ঠিক উল্টো দিকে, আমাদের রাত তো ওদের দিন। কিন্তু ওদের টীম -এ খুব ভালো ডেভেলপার / টেস্টার আছে - দুই টিমের কাজের জন্য কমন কোনো টাইম দরকার নাই, আমরা কাজ শেষ করলে ওরা শুরু করবে।
প্রজেক্ট ম্যানেজমেন্ট ভালো হচ্ছে না, কাজের গতি বাড়ানো দরকার - প্রজেক্ট-এর মাঝামাঝি সময়, তাতে কী, একটা নতুন টুল পাওয়া গেছে, ঐটা ইমপ্লেমেন্ট করে এখন থেকে আমরা সব কাজ ট্র্যাক করবো।
আমাদের প্রজেক্ট আসলে এত বড় না - কোনো প্রকার অটোমেটিক ভার্সন কন্ট্রোল সিস্টেম ব্যবহার করার দরকার নাই

এরকম তিন ডজন ভুলের লিস্ট স্টিভ ম্যাককনেল ‘র বইয়ের এই লিঙ্কে, দেয়া আছে। আর প্রথম ১২ টা এই লিংকে দেয়া আছে। উপরের প্রায় সবগুলোই সেখান থেকেই নেয়া। আরেকটা ভালো রিসোর্স হচ্ছে Udacity তে Georgia Tech -র প্রফেসর আলেক্স অর্সো -র সফটওয়্যার ডেভেলপমেন্ট প্রসেস-র উপর একটা ফ্রি কোর্স। ওই কোর্স-এর লেসন -২’র শেষ দিকে এই ভুল গুলো নিয়ে তিনি আলোচনা করেছেন। রেফারেন্স হিসাবে অবশ্য তিনিও স্টিভ ম্যাককনেল -র ওই লিংক উল্লেখ করেছেন।

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

ধন্যবাদ,

--ইশতিয়াক।