আপনি যা বর্ণনা করেছেন তা হ'ল - অন্তত আমার অভিজ্ঞতায় - "চতুর হতে চেষ্টা করুন" এমন টিমের একটি প্রচলিত উদীয়মান প্যাটার্ন । এটি বিতর্কটির জন্য উন্মুক্ত যদি এটি প্রকৃতপক্ষে নিজেই Agile এর অংশ বা এটির একটি সাধারণ ভুল-বাস্তবায়ন হয়, চতুর প্রকাশ / নীতিগুলি বা এর অন্তর্নিহিত পরিণতির বিরুদ্ধে থাকে এবং ইত্যাদি। কেবল একটি অভিজ্ঞতাগত দৃষ্টিকোণ থেকে এবং আমার নিজের অভিজ্ঞতার ছোট নমুনা সেট (এবং যাদের সাথে আমি কথা বলি) এর উপর ভিত্তি করে যদি কোনও দল চটপটে থাকে তবে মনে হয় এটি এই প্যাটার্নটিতে চলে যাওয়ার গড় সম্ভাবনার চেয়ে বেশি। আসুন এটি এখান থেকে ছেড়ে দিন এবং আপনার দৃ concrete় উদাহরণে ফোকাস করুন।
আছে দুটি পৃথক দিক কি আপনি বর্ণনা করতে:
- সাধারণ বোঝাপড়া / দৃষ্টি হারিয়েছে এবং তাই দক্ষ হচ্ছে না
- সাফল্য / অগ্রগতি এবং মোট ব্যয় কীভাবে পরিমাপ করা যায়
ভুল পথে নামা বা চেনাশোনাগুলিতে চলছে
আমার অভিজ্ঞতায়, এটি হওয়ার মূল কারণটি হ'ল দ্রুত কোড তৈরির প্রয়াসে, দলগুলি সক্রিয়ভাবে তাদের ইতিমধ্যে জানা বা প্রয়োজনীয়তাগুলি সহজেই সন্ধান করতে পারে বা তাদের সম্পর্কে জানতে পারে use এটি এইভাবে চিন্তা করুন: 10-20 বছর আগে, লোকেরা দৈত্য চশমা লেখার চেষ্টা করেছিল এবং সমস্ত কিছু আগেই চিন্তা করে এবং প্রায়শই ব্যর্থ হয়। তারা হয় খুব দীর্ঘ সময় নিয়েছে বা কিছু উপেক্ষা করেছে। অতীতের একটি শিক্ষা হ'ল সফটওয়্যার বিকাশে এমন কিছু জিনিস রয়েছে যা আপনি জানেন না এবং জিনিসগুলি অনেক পরিবর্তন করে, তাই দ্রুত পুনরাবৃত্তি করা এবং দ্রুত কিছু বুদ্ধিমান আউটপুট উত্পাদন করার ধারণা। যা একটি খুব ভাল নীতি। তবে আজ, আমরা অন্য চূড়ান্তভাবে রয়েছি: "আমি এটি সম্পর্কে পরোয়া করি না কারণ এটি পরবর্তী স্প্রিন্টের অংশ" বা "আমি যে বাগটি ফাইল করি না, এটি আবার সামনে আসার সাথে সাথেই মোকাবিলা করি"।
- আপনি খুঁজে পেতে পারেন এমন সমস্ত উচ্চ স্তরের ব্যবহারের কেসগুলি সংগ্রহ করুন you এটিকে কিছু উইকে রাখুন যাতে সমস্ত স্টেকহোল্ডার এবং ডেভস তাদের দেখতে পারে। নতুন কিছু এলে তাদের যুক্ত করুন। আপনার শেয়ারহোল্ডার এবং ব্যবহারকারীদের সাথে কথা বলুন। চূড়ান্ত পণ্যটিতে অবদান রাখে না এমন বা কার্যকরভাবে কাজ করা / হ্যাক যা একটি সমস্যার সমাধান করে তবে তিনটি নতুন সমস্যা সৃষ্টি করে তা বাস্তবায়িত করতে বাধা দেওয়ার জন্য বিকাশের সময় এটিকে চেক তালিকারূপে ব্যবহার করুন।
- একটি উচ্চ স্তরের ধারণা তৈরি করুন । আমি ইন্টারফেস বা ক্লাস ডিজাইনিংয়ের কথা বলছি না, তবে এর পরিবর্তে সমস্যা ডোমেনটি স্কেচ করে নিন। চূড়ান্ত সমাধানের মূল উপাদানগুলি, প্রক্রিয়া এবং মিথস্ক্রিয়াগুলি কী কী? আপনার ক্ষেত্রে, এটি স্পষ্ট করে তোলা উচিত যখন jquery-workaround ব্যবহার করা একটি মধ্যবর্তী পদক্ষেপ হিসাবে সহায়তা করে এবং যখন এটি কেবল অতিরিক্ত কাজের কারণ হয়।
- আপনি জড়ো তালিকাটি ব্যবহার করে আপনার ধারণাটি বৈধ করুন । এটিতে কোনও সুস্পষ্ট সমস্যা আছে কি? এটা কি কোন মানে আছে? দীর্ঘ সময়ের প্রযুক্তি debtণ না দিয়ে একই ব্যবহারকারীর মূল্য অর্জনের আরও কার্যকর উপায় আছে কি?
এটি অতিরিক্ত না। আপনার কেবলমাত্র কিছু দরকার তাই দলের এমবিদের (অ-দেবগুলি সহ) আপনার এমভিপি-র সবচেয়ে ভাল পথটি কী তা সাধারণভাবে বোঝা যায়। প্রত্যেকেরই একমত হওয়া উচিত যে কোনও সুস্পষ্ট তদারকি নেই এবং এটি আসলে কাজ করতে পারে। এটি সাধারণভাবে মৃত প্রান্তে যেতে বা একই জিনিসটিকে একাধিকবার পুনরায় করতে বাধা দেয়। চটপট আপনাকে অপ্রত্যাশিতদের সাথে আরও ভাল আচরণ করতে সহায়তা করতে পারে, যা জানা তা উপেক্ষা করার কোনও যুক্তি নয়।
ডুবে যাওয়া-ব্যয়-ভ্রান্তি সম্পর্কে সচেতন হন : আপনি যদি কোনও স্থাপত্য বা ডেটাবেস টাইপ দিয়ে শুরু করেন, তবে বেশিরভাগ লোকেরা মধ্য প্রকল্পে এটি পরিবর্তন করতে দ্বিধা বোধ করেন। সুতরাং স্টাফ বাস্তবায়ন শুরু করার আগে "শিক্ষিত সেরা অনুমান" করার জন্য কিছুটা সময় বিনিয়োগ করা ভাল ধারণা। ডেভগুলির একটি কোড রয়েছে যাতে দ্রুত কোড লিখতে চান। তবে প্রায়শই বেশ কয়েকটি বিদ্রূপ, লাইভ প্রোটোটাইপ, স্ক্রিনশট, ওয়্যারফ্রেম ইত্যাদির ফলে কোড লেখার চেয়ে আরও দ্রুত পুনরাবৃত্তির অনুমতি দেয়। কেবল সচেতন হন যে কোডের প্রতিটি লাইন বা এমনকি ইউনিট পরীক্ষাগুলি আপনার সামগ্রিক ধারণাটি আবার পরিবর্তন করা আরও শক্ত করে তোলে।
সাফল্য পরিমাপ
আপনি অগ্রগতি কীভাবে পরিমাপ করবেন তা একটি সম্পূর্ণ পৃথক দিক। আসুন ধরা যাক আপনার প্রকল্পের লক্ষ্যটি এমন একটি টাওয়ার তৈরি করা যা চারপাশে থাকা জিনিসগুলি ব্যবহার করে 1 মিটার উঁচু। কার্ডের ঘর তৈরি করা সম্পূর্ণ বৈধ সমাধান হতে পারে যদি উদাহরণস্বরূপ স্থিতির চেয়ে বাজারে যাওয়ার সময় আরও গুরুত্বপূর্ণ। যদি আপনার লক্ষ্য স্থায়ী হয় এমন কিছু তৈরি করা হয়, তবে লেগো ব্যবহার করা আরও ভাল। বিষয়টি হ'ল: হ্যাক কী হিসাবে বিবেচিত হয় এবং কীভাবে প্রকল্পটির সাফল্য পরিমাপ করা হয় তার উপর পুরোপুরি একটি মার্জিত সমাধান নির্ভরশীল ।
আপনার "লোডিং" এর উদাহরণটি বেশ ভাল। আমার অতীতে এমন জিনিস ছিল যেখানে সবাই (বিক্রয়, পিও, ব্যবহারকারীগণ সহ) সম্মতি জানায় এটি বিরক্তিকর ছিল। তবে এটি পণ্যের সাফল্যের উপর কোনও প্রভাব ফেলেনি এবং দীর্ঘমেয়াদী debtণের কারণ হয়নি। সুতরাং আমরা এটিকে ফেলে দিয়েছি কারণ দেব-সংস্থানগুলির সাথে করার মতো আরও মূল্যবান জিনিস ছিল।
আমার পরামর্শ এখানে:
- আপনার টিকিট সিস্টেমে টিকিট হিসাবে সবকিছু, এমনকি ছোট বাগগুলি রাখুন । প্রকল্পের ক্ষেত্রের মধ্যে কী রয়েছে এবং কী নয়, একটি সক্রিয় সিদ্ধান্ত নিন। মাইলফলক তৈরি করুন বা অন্যথায় আপনার ব্যাকলগ ফিল্টার করুন যাতে আপনার সবসময়েই এখনও করা দরকার এমন একটি "সম্পূর্ণ" তালিকা থাকে।
- গুরুত্বের একটি কঠোর ক্রম এবং পরিষ্কার কাট পয়েন্ট রয়েছে যেখানে প্রকল্পটিকে সাফল্য হিসাবে বিবেচনা করা যেতে পারে। চূড়ান্ত পণ্যটি আসলে কোন স্তরের স্থায়িত্ব / কোডের মান / ডকুমেন্টেশনের প্রয়োজন? উপরে থেকে বাছাই করে যতটা সম্ভব কাজের প্রতিটি দিন ব্যয় করার চেষ্টা করুন। একটি টিকিটে কাজ করার সময়, নতুন টিকিট প্রবর্তন না করে এটি সম্পূর্ণরূপে সমাধান করার চেষ্টা করুন (যদি না এটি কম অগ্রাধিকারের কারণে পোস্ট পোনে জিনিসগুলি বোঝা না যায়)। প্রতিটি প্রতিশ্রুতিবদ্ধতা আপনাকে আপনার শেষ লক্ষের দিকে এগিয়ে নিয়ে আসে, পাশাপাশি বা পিছনের দিকে নয়। তবে এটি আবার চাপ দেওয়ার জন্য: কখনও কখনও এমন হ্যাক যা পরে অতিরিক্ত কাজ করে তা এখনও প্রকল্পের জন্য নেট পজিটিভ হতে পারে!
- ব্যবহারকারীর মানটি নির্ধারণ করতে আপনার পো / ব্যবহারকারীদের ব্যবহার করুন তবে প্রযুক্তিগত ব্যয়টিও আপনার ডিভসটি নির্ধারণ করুন । নন-ডেভস সাধারণত প্রকৃত দীর্ঘমেয়াদী খরচ (কেবল বাস্তবায়নের ব্যয় নয়) কী তা বিচার করতে পারে না, তাই তাদের সহায়তা করুন। ফুটন্ত-ব্যাঙের সমস্যা সম্পর্কে সচেতন হন: প্রচুর অল্প, অপ্রাসঙ্গিক সমস্যা সময়ের সাথে সাথে একটি দলকে ধরে রাখতে পারে। আপনার দল কীভাবে দক্ষতার সাথে কাজ করতে পারে তা নির্ধারণের চেষ্টা করুন।
- সামগ্রিক লক্ষ্য / ব্যয়ের দিকে নজর রাখুন। স্প্রিন্ট থেকে স্প্রিন্টের পরিবর্তে চিন্তা না করে বরং "আমরা কী প্রকল্প হিসাবে শেষ পর্যন্ত একটি দল হিসাবে প্রয়োজনীয় সবকিছু করতে পারি" এর মানসিকতা রাখুন । স্প্রিন্টগুলি জিনিসগুলি ভেঙে ফেলার একমাত্র উপায় এবং চেক-পয়েন্ট রয়েছে।
- কিছু তাড়াতাড়ি কিছু দেখানোর ইচ্ছা না করে, ব্যবহারকারীকে দেওয়া যেতে পারে এমন ন্যূনতম টেকসই পণ্যটির দ্রুততম পথে আপনার কোর্সটি প্লট করুন । তবুও, আপনার সামগ্রিক কৌশলটির মধ্যে যাচাইযোগ্য ফলাফলের অনুমতি দেওয়া উচিত।
সুতরাং যখন কেউ এমন কিছু করে যা আপনার চূড়ান্ত বাস্তবায়নের লক্ষ্যে ফিট করে না, আদর্শভাবে করা গল্পটি বিবেচনা করবেন না। গল্পটি বন্ধ করা যদি উপকারী হয় (যেমন, গ্রাহকদের কাছ থেকে প্রতিক্রিয়া জানাতে), সাথে সাথে সংক্ষিপ্ত কম্পনগুলির সমাধান করার জন্য একটি নতুন গল্প / বাগ খুলুন open এটিকে স্বচ্ছ করুন যে শর্টকাট নেওয়া ব্যয় হ্রাস করে না, এটি কেবল তাদের লুকায় বা বিলম্বিত করে!
কৌশলটি এখানে প্রকল্পের মোট ব্যয়ের সাথে তর্ক করা: উদাহরণস্বরূপ যদি কোনও পিও শর্টকাট নেওয়ার জন্য একটি সময়সীমা তৈরির জন্য চাপ দেয়, তবে প্রকল্পটি সম্পন্ন করার বিষয়টি বিবেচনা করার জন্য কত পরিমাণ কাজ করা উচিত তা পরিমাপ করুন!
মানদণ্ড-ভিত্তিক-অপ্টিমাইজেশান থেকেও সাবধান থাকুন : আপনার দল যদি স্প্রিন্ট পর্যালোচনাতে প্রদর্শিত গল্পগুলির সংখ্যা দ্বারা মাপা হয় তবে একটি ভাল "স্কোর" অর্জনের সর্বোত্তম উপায় হ'ল প্রতিটি গল্পকে দশটি ছোট করে ফেলুন। এটি লিখিত ইউনিট পরীক্ষার সংখ্যা দ্বারা পরিমাপ করা হয়, এটি অনেক অপ্রয়োজনীয় লিখতে ঝোঁক হবে। গল্প গণনা করবেন না, বরং প্রয়োজনীয় ব্যবহারকারীর কার্যকারিতা কতটা কাজ করে তার একটি পরিমাপ করুন, প্রকল্পের ক্ষেত্রের মধ্যে সমাধান করার জন্য কারিগরি debtণ দ্বারা কত বেশি ব্যয় হবে ইত্যাদি have
সারাংশ
এটি সিদ্ধ করতে: দ্রুত এবং ন্যূনতম দিকে যাওয়া একটি ভাল পদ্ধতির। টি সমস্যা হ'ল "দ্রুত" এবং "ন্যূনতম" ব্যাখ্যায়। যে কোনও একটি সর্বদা দীর্ঘমেয়াদী খরচ বিবেচনা করা উচিত (যদি না আপনার কাছে এমন প্রকল্প থাকে যেখানে এটি অপ্রাসঙ্গিক)। একটি শর্টকাট ব্যবহার করা যা কেবল 1 দিন সময় নেয় তবে শিপিংয়ের তারিখের পরে 1 মাসের টেক debtণ উত্পাদন করে যা আপনার সংস্থাকে 1 সপ্তাহ সময় নিয়েছে এমন সমাধানের চেয়ে বেশি খরচ করে। তাত্ক্ষণিকভাবে পরীক্ষাগুলি লেখা শুরু করুন দ্রুত মনে হচ্ছে, তবে যদি আপনার ধারণাটি ত্রুটিযুক্ত না হয় এবং তারা কোনও ভুল পদ্ধতির সিমেন্ট করে।
এবং আপনার ক্ষেত্রে "দীর্ঘমেয়াদী" এর অর্থ কী তা মনে রাখবেন: আমি একাধিক সংস্থাকে জানি যে দুর্দান্ত কোড লেখার চেষ্টা করে আবদ্ধ হয়েছিল এবং অতএব দেরি করে পাঠিয়েছে। একটি ভাল আর্কিটেকচার বা ক্লিন কোড - কোনও সংস্থার দৃষ্টিকোণ থেকে - কেবলমাত্র মূল্যবান যদি তা অর্জনের জন্য ব্যয়টি এটির না থাকার ব্যয়ের চেয়ে কম হয়।
আশা করি এইটি কাজ করবে!