আমি এটি সত্য বলে মনে করি, কিছু পরিবেশে অগিল কোনও শৃঙ্খলার অজুহাত হিসাবে ব্যবহৃত হয়। আসল সমস্যাটি হ'ল আমাদের কেন কোনও পদ্ধতি আছে তা আমরা ভুলে গেছি। ব্যক্তিগতভাবে, আমি অনুভব করি যে পদ্ধতিটি এই অর্থে একটি স্থাপত্যগত সমস্যা যে সিস্টেমের আর্কিটেকচারটি অ-কার্যকরী, গুণগত বৈশিষ্ট্যগুলিকে সম্বোধন করার কথা বলেছে, পদ্ধতিটি সেই একই বৈশিষ্ট্যগুলির কয়েকটিকে সম্বোধন করা উচিত (রক্ষণাবেক্ষণযোগ্যতা, উন্নয়ন উত্পাদনশীলতা, জ্ঞান স্থানান্তর, ইত্যাদি।)
প্রক্রিয়া বৈশিষ্ট্যগুলির জন্য একটি নিয়ন্ত্রণ হিসাবে পদ্ধতিটি দেখা কয়েকটি বিষয়কে বোঝায়: 1) মেট্রিক্স ব্যতীত আমরা অন্য পদ্ধতির একটি পদ্ধতির কার্যকারিতা তুলনা করতে পারি না, ২) কী কী বৈশিষ্ট্য গুরুত্বপূর্ণ তা সম্পর্কে একটি সক্রিয় সিদ্ধান্ত নেওয়া দরকার (বিতরণ সময় বনাম কোড) মানের বনাম জ্ঞান স্থানান্তর)।
মেট্রিক এবং একটি স্পষ্ট লক্ষ্য উভয়ই ব্যতীত আমরা কেবল আমাদের "ম্যাজিক পালক" হিসাবে একটি পদ্ধতি বেছে নিই যে আমরা যদি দৃ tight়ভাবে ধরে থাকি তবে আমরা সফ্টওয়্যার সরবরাহ করতে সক্ষম হব।
এখন এগিল, এক্সপি, স্ক্রাম ইত্যাদির নায়ে-বক্তারা সেই নির্দিষ্ট বিভাগের পদ্ধতিগুলির ভঙ্গুরতা সম্পর্কে কথা বলেন। যুক্তিটি হ'ল: কেন এমন একটি পদ্ধতি ব্যবহার করুন যা কোনও ব্যক্তির সমস্ত নিয়ম অনুসরণ করতে শৃঙ্খলা না থাকাতে নাশকতা হতে পারে? প্রশ্ন একটি বৈধ এক; তবে এটি লক্ষণ, কারণ নয়, যদি প্রক্রিয়া মেট্রিকগুলির একটি সঠিক এবং অর্থবোধক (এটিই শক্ত অংশ) সেট করা হয় তবে আমি মনে করি যে আমরা নির্দিষ্ট পদ্ধতিটি সাফল্যের সাথে খুব কম করবো তা আবিষ্কার করব think (উপাখ্যান্তভাবে বলতে গেলে আমি একাধিক পদ্ধতি ব্যবহার করে সফল প্রকল্প দেখেছি এবং একই পদ্ধতিতে দ্বিগুণ ব্যর্থ হয়েছি)
সুতরাং মেট্রিক কি? এগুলি প্রকল্প থেকে প্রকল্প, দলে দলে এবং সময়ে সময়ে পরিবর্তিত হয়। প্রসবের সময়সূচীটি যখন গুরুত্বপূর্ণ তখন তার জন্য দরকারী, আমি ব্যক্তিগতভাবে ব্যবহার করেছি তা হল অনুমানের দক্ষতা এবং গুণগত মান। বেশিরভাগ বিকাশকারীরা এক সপ্তাহ বা তার চেয়ে কম সময়ের কাজগুলি সঠিকভাবে অনুমান করতে পারেন। সুতরাং একটি পদ্ধতির মধ্যে রয়েছে প্রকল্পটিকে এক বিকাশকারী-সপ্তাহ দীর্ঘ কর্মগুলিতে ভাগ করা এবং কে অনুমান করেছে তা ট্র্যাক করে। প্রকল্পটি এগিয়ে চলার সাথে সাথে তারা তাদের অনুমান পরিবর্তন করতে পারে। কোনও কাজ সমাপ্ত হওয়ার পরে, যদি এটি 10% (এক দিনের মধ্যে 1/2) দ্বারা বন্ধ হয়ে যায় তবে আমরা এটিকে বাগের মতোই মনে করি - আমরা অনুমান করি কেন অনুমানটি বন্ধ ছিল (যেমন একটি ডাটাবেস সারণী বিবেচনা করা হয়নি), চিহ্নিত করুন সংশোধনমূলক পদক্ষেপ (যেমন অনুমানের মধ্যে ডিবিএ জড়িত) এবং তারপরে এগিয়ে যান। এই তথ্যটি ব্যবহার করে আমরা মেট্রিক তৈরি করতে পারি যেমন প্রতি সপ্তাহে # অনুমানের বাগ, প্রতি বিকাশকারী # বাগের মতো,
তাতে কি? পদ্ধতিগুলি যখন তখন আসে - আপনার যদি ভবিষ্যদ্বাণীপূর্ণ মডেল থাকে যা প্রক্রিয়াটির গুণাবলী পূরণ করতে ব্যর্থ হয়, আপনি পদ্ধতিটির কিছু দিক যুক্ত করতে বা মুছে ফেলতে এবং এটি কীভাবে আপনার মডেলকে প্রভাবিত করে তা দেখতে পারেন। মঞ্জুর, ব্যর্থতার ভয়ে কেউ উন্নয়ন প্রক্রিয়া নিয়ে খেলতে চায় না তবে আমরা ইতিমধ্যে ধারাবাহিকভাবে উচ্চ এবং প্রত্যাশিত হারে ব্যর্থ হয়েছি। স্বতন্ত্র পরিবর্তন করে এবং ফলাফলটি পরিমাপ করার মাধ্যমে আপনি দেখতে পাচ্ছেন যে আপনার দলের জন্য Agile হ'ল সঠিক পদ্ধতি, তবে আপনি কেবল খুব সহজেই RUP, জলপ্রপাত বা সেরা অভ্যাসের একটি হজ-পডকে আদর্শ হতে পারেন।
সুতরাং আমার পরামর্শটি হ'ল আমরা প্রক্রিয়াটিকে কী বলি তা নিয়ে চিন্তা করা বন্ধ করে দেওয়া, আমাদের বিকাশের প্রক্রিয়া লক্ষ্যগুলির সাথে প্রাসঙ্গিক চেক স্থাপন এবং সেই প্রক্রিয়াটি উন্নত করার জন্য বিভিন্ন কৌশল নিয়ে পরীক্ষা করা।
