যখন ক্লায়েন্টের প্রয়োজনীয়তাগুলি একেবারেই পরিবর্তন হয় না তখন কি Agile ব্যবহার করা ভুল?


12

আমি সম্প্রতি প্রচুর পোস্ট দেখেছি যে Agile ব্যবহৃত হওয়ার অন্যতম প্রধান কারণ হ'ল ক্লায়েন্টরা প্রায়শই প্রয়োজনীয়তা পরিবর্তন করে।

তবে, যাক ক্লায়েন্টরা প্রায়শই প্রয়োজনীয়তাগুলি পরিবর্তন করে না । আসলে, ক্লায়েন্টদের দৃ requirements় প্রয়োজনীয়তাগুলি যদিও কিছুটা অস্পষ্ট হতে পারে (তবে কিছুই অযৌক্তিকভাবে অস্পষ্ট নয়) তবে আমি যাইহোক চটপটি ব্যবহার করি।

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

আমার প্রশ্ন: এটিকে কি খারাপ, কাউবয় কোডিং, অ্যান্টি-প্যাটার্ন ইত্যাদি হিসাবে বিবেচনা করা হবে? এগ্রিলের 'চলুন এটি করুক' মানসিকতার পরিবর্তে প্রয়োজনীয়তা স্থিতিশীল হওয়ার সাথে সাথে কোডিং শুরু করার আগে আমরা কী জলপ্রপাতটি ব্যবহার করা উচিত এবং দুর্দান্ত বিবরণে যথাসম্ভব পরিকল্পনা করব?

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


2
@ আরন্ডোমা: আসলে, আইএমএইচও আপনার কখনই খাঁটি জলপ্রপাতের চেষ্টা করা উচিত নয় যদি আপনি এমন একটি পণ্য তৈরি করতে চান যা এক সপ্তাহের পরিশ্রমের চেয়ে বেশি প্রয়োজন।
ডক ব্রাউন

10
দয়া করে আমাকে আপনার ক্লায়েন্টগুলি দিন
রাজেস্টেস্ট্রে

7
আমি 2x আরো অনেক কিছু আপনার ক্লায়েন্টদের @razethestray চেয়ে দেব
euphoric

2
যদি আপনার ক্লায়েন্ট "দৈনিক উদ্বিগ্ন হতে না চান", তার সাথে কীভাবে কার্যকর যোগাযোগ করবেন তা শিখুন। উদাহরণস্বরূপ, অস্পষ্ট পয়েন্টগুলি সম্পর্কে (সম্ভবত ভুল) অনুমান করার পরিবর্তে একটি তালিকায় প্রশ্ন সংগ্রহ করুন এবং আপনার ক্লায়েন্টকে নিয়মিত বিরতিতে তালিকাটি প্রেরণ করুন। আরও ভাল: পয়েন্টগুলি আলোচনার জন্য একটি সভার ব্যবস্থা করুন। প্রয়োজনীয়তাগুলি যদি এতটা পরিষ্কার হয় যে তালিকাটি খালি থাকে: কোনও সভা হয়নি (তবে আমি অনুমান করি এটি হবে না)। আপনি যদি আপনার সফ্টওয়্যারটিতে ভুল অনুমানগুলি প্রয়োগ করতে শুরু করেন তবে পরে এটি পরিবর্তন করার জন্য আপনার আরও অনেক প্রচেষ্টা হবে।
ডক ব্রাউন

3
@ আরন্ডোমা: আপনি কিছু না জিজ্ঞাসা করে কিছু সময়ের জন্য আপনাকে ক্লায়েন্টকে খুশি রাখতে পারবেন এবং তারপরে, আপনি যখন চূড়ান্ত জিনিসটি সরবরাহ করবেন তখন তাকে খুব অসন্তুষ্ট করুন যেহেতু দেখা যাচ্ছে আপনি প্রয়োজনীয়তাগুলি এতটা মিস করেছেন যে আপনি আপনার প্রোগ্রামটি ফেলে দিতে এবং শুরু করতে পারবেন শুরু থেকেই (যা ক্লায়েন্ট প্রদান করতে রাজি হবে না)। অথবা আপনি সঠিক প্রোগ্রামটি তৈরির জন্য তাকে যথেষ্ট সময় জিজ্ঞাসা করে কিছুটা হলেও অসন্তুষ্ট করে তুললেন, তবে শেষ পর্যন্ত খুব খুশি হয় যখন প্রোগ্রামটি আসলে যা চায় তা করবে এবং সে যা পেয়েছিল তার জন্য সে পাবে। আপনার পছন্দ চয়ন করুন।
ডক ব্রাউন

উত্তর:


16

এটিকে কী খারাপ, কাউবয় কোডিং, অ্যান্টি-প্যাটার্ন হিসাবে বিবেচনা করা হবে?

সংক্ষিপ্ত উত্তর: না। "চটজলদি" সঠিকভাবে করা মানে "পরিকল্পনা নয়", এর অর্থ জিনিসগুলিকে অতিরিক্ত না দেখানো।

Agile কেন ব্যবহৃত হয় তার একটি বড় কারণ হ'ল ক্লায়েন্টরা প্রায়শই প্রয়োজনীয়তাগুলি পরিবর্তন করে।

এটি একটি অতি বিবরণী বক্তব্য। "পরিবর্তনের প্রয়োজনীয়তা" প্রয়োজনীয়তার বিষয়ে দলের বোঝাপড়া কীভাবে পরিবর্তিত হয় সে সম্পর্কেও। এবং এটি যখন সফ্টওয়্যারটির কয়েকটি প্রকাশ প্রকাশিত হয় তখন প্রয়োজনীয়তার বিষয়ে গ্রাহকের অগ্রাধিকারগুলি কীভাবে পরিবর্তিত হয় সে সম্পর্কে।

প্রকৃতপক্ষে, "চটজলদি" আপনার বর্ণিত পরিস্থিতিতে আইএমএইচওকে সঠিকভাবে কাজ করে - ক্লায়েন্ট তার সামগ্রিক প্রয়োজনীয়তা সম্পর্কে ভাল জ্ঞান রাখে, আপনি এটি থেকে একটি সাধারণ পরিকল্পনা লিখতে পারেন, প্রচুর "ব্যবহারকারী গল্প" দিয়ে আপনার ব্যাকলগটি পূরণ করতে পারেন এবং ইতিমধ্যে পেয়েছেন সঠিক সিস্টেম আর্কিটেকচার চয়ন করার জন্য পর্যাপ্ত তথ্য। তত্পরতাপূর্ণ বিকাশের কৌশলটির সংক্ষিপ্ত পুনরাবৃত্তিগুলি যদি আপনি এখনও সঠিক পথে চলে যাচ্ছেন তবে প্রচুর প্রতিক্রিয়া সহ "অস্পষ্ট প্রয়োজনীয়তাগুলি" আরও সুনির্দিষ্ট করতে সহায়তা করবে। এটি আপনাকে আসল প্রচেষ্টা এবং ব্যয় সম্পর্কে প্রাথমিক প্রতিক্রিয়া জানাবে (যা এমন একটি বিষয় যা আপনি এখনও জলপ্রপাতের পদ্ধতির ক্ষেত্রে ব্যর্থ হতে পারেন, এমনকি যদি প্রতিটি প্রয়োজনীয়তার বিস্তৃত বিবরণও জানেন তবে)।


3
"জলপ্রপাত" সঠিকভাবে করা মানে "সমস্ত কিছু পরিকল্পনা" করা নয়, এর অর্থ জিনিসগুলিকে অপ্রত্যাশিত না করা।
জর্জিও

1
@ জর্জিও: "জলপ্রপাত" সঠিকভাবে করা মানে যখন প্রয়োজনগুলি "কিছুটা অস্পষ্ট" হয় তখন এটি প্রয়োগ না করা এবং "সফ্টওয়্যারটি যথেষ্ট জটিল যে বিশদ, সমস্যাগুলি যা আমি আসলে তাদের মুখোমুখি না হওয়া পর্যন্ত আমি চিনতে পারি না" (উদ্ধৃত করা মূল প্রশ্ন))
ডক ব্রাউন

6

এই পরিস্থিতিতে চতুর ব্যবহার এখনও খুব ভাল ধারণা good চটজলদি করার জন্য অনেকগুলি সুবিধা রয়েছে যার মধ্যে একটি হ'ল গ্রাহকের নিয়মিত প্রতিক্রিয়া এবং আপনি উল্লেখ করার সাথে সাথে প্রয়োজনীয় পরিবর্তনগুলির প্রতিক্রিয়া জানানোর ক্ষমতা।

জলপ্রপাত প্রকল্পগুলি ব্যর্থতার জন্য কুখ্যাত হওয়ার অন্যতম প্রধান কারণ হ'ল 'প্রায় সম্পন্ন' সমস্যা - শেষের দিকে তৈরি বাগের গাদা পরীক্ষা করা, একটি অপ্রকাশনীয় পণ্য রেখে যায় এবং অসামান্য বাগগুলি ঠিক করতে আরও দু'দিন বা দু'বছর লাগবে কিনা সে সম্পর্কে ধারণা নেই। চতুরতা এই ঝুঁকি পুরোপুরি সরিয়ে দেয়। যদি একটি চতুর প্রকল্পটি অতিরিক্ত চলমান থাকে তবে আপনি এখনও একটি কার্যকরী সংস্করণ সরবরাহ করতে পারেন যা:

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

খ) তাদের যেভাবেই হোক খুশি হতে এবং ছেড়ে দেওয়ার জন্য তাদের পক্ষে যথেষ্ট যথেষ্ট।

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


আমি জানি না যে ক) আপনার উত্তরের শুরুতে আপনি উল্লিখিত সমস্যাটি সমাধান করেছেন: শেষ কয়েকটি গল্পের কয়েক দিন বা দু'বছর লাগবে কিনা আপনি কীভাবে জানবেন? আপনি কেবল তখনই জানেন যখন আপনি তাদের আসলে করেন, তাই না?
জর্জিও

1
আপনি ঠিক বলেছেন, তবে পার্থক্যটি হ'ল 90% সফটওয়্যারটি সম্পন্ন বগি টুকরো ছাড়া যা বর্তমান হতে পারে না তার পরিবর্তে আপনার বর্তমান অবস্থায় একটি রিলিজযোগ্য পণ্য রয়েছে। আপনার কাছে পুনরুদ্ধারযোগ্য বৈশিষ্ট্যগুলি সরবরাহ করতে আপনাকে কতক্ষণ সময় লেগেছিল এবং আপনার অবশিষ্ট কাজ সম্পর্কে আপনার অনুমানগুলি আরও আত্মবিশ্বাস জোগাতে পারে যে আপনি যে কিছু করেছেন তা আসলে কাজ করে না তার কোনও প্রমাণ নেই emp
স্পুনারএনজেড

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

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

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

3

আপনার যদি ক্লায়েন্টের সাথে ঘন ঘন প্রতিক্রিয়া লুপের প্রয়োজন হয় তবে চতুরতা আদর্শ। এটি হতে পারে কারণ প্রয়োজনীয়তাগুলি ঘন ঘন পরিবর্তিত হয় তবে এটি অন্যান্য কারণেও হতে পারে।

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


1
আমি প্রায়শই ভাবছি যে ক্লায়েন্টরা খুব বেশি জড়িত হতে চায় না তাদের যদি সত্যিকারের ব্যবসায়ের প্রয়োজন হয়। আমি প্রায়শই এমন প্রকল্পগুলিতে ঘটতে দেখেছি যেখানে একটি বিদ্যমান অ্যাপ্লিকেশন একটি নতুন প্রযুক্তিতে 'অনুবাদ' করা হয়। আপনার যদি প্রশ্ন থাকে তবে তারা আপনাকে যা বলছে তা আপনি কোডটি পরীক্ষা করতে পারেন। রিমেকটির জন্য কেউ অপেক্ষা করছে না।
ব্যবহারকারী 99561

@ ব্যবহারকারী 99561: আপনি ঠিক বলেছেন, তবে এই পরিস্থিতিতে প্রয়োজনীয়তাগুলি বেশিরভাগ ক্ষেত্রে অস্পষ্ট নয়, তারা স্ফটিক স্পষ্ট - যতক্ষণ না নতুন প্রোগ্রামটি পুরানোটির মতো ঠিক আচরণ করবে । এই পরিস্থিতিতে একটি "চটজলদি" পদ্ধতির অবশ্যই প্রয়োজন নেই। একটি পুনরাবৃত্ত, মাইল-পাথর ভিত্তিক পদ্ধতির (অনেক গ্রাহকের মিথস্ক্রিয়া ব্যতীত) যথেষ্ট যথেষ্ট হবে।
ডক ব্রাউন 21

ক্রিস্টাল পরিষ্কার? ভাগ্য সঠিক আচরণটি কী এবং ব্যতিক্রমগুলি কী তা নির্ধারণ করে। বেশিরভাগ সময় এমনকি ব্যবসায়ীরা অ্যাপ্লিকেশনটিতে কী ঘটে তা বুঝতে পারে না। আমার পরামর্শ: এই প্রকল্পগুলি থেকে যত তাড়াতাড়ি সম্ভব পালিয়ে যান। কারণ আপনি জানেন কখন প্রকল্পটি শুরু হয় তবে আপনি কখনই জানেন না কখন শেষ বাগটি পোস্ট করা হয়েছে কারণ অ্যাপ্লিকেশনগুলি আলাদাভাবে আচরণ করে তা ঠিক হয়ে যাবে।
ব্যবহারকারী 99561

0

আপনি সর্বদা বড় রিলিজকে ছোট রিলিজ (স্প্রিন্ট) এ বিভক্ত করতে পারেন এবং আপনার ক্লায়েন্টকে প্রতিক্রিয়া জানতে চাইতে পারেন। এই উপায়ে আপনি নিশ্চিত যে আপনি সঠিক জিনিসটি করছেন এবং ক্লায়েন্ট আপনার অগ্রগতির উপর নজর রাখতে পারে।

যদি কিছু ভুল হয় তবে আপনি আপনার ক্লায়েন্টকে আপনাকে তাড়াতাড়ি সংশোধন করার সুযোগ দিতে পারেন যা খুব ভাল। আপনার ভুলগুলি যত তাড়াতাড়ি সম্ভব শেষ করা বাঞ্ছনীয় না, শেষে তাকে বুলিশিট দেখানো এবং এটি ঠিক করার চেষ্টা করুন যখন আপনি জানেন না কোথায় শুরু করবেন।


আমি স্পষ্ট করতে একটি সম্পাদনা যুক্ত করেছি। ক্লায়েন্টগুলি পর্যাপ্ত বিবরণ এবং পরিষ্কার ইচ্ছার তালিকা সহ একটি সমস্যা দেখিয়েছে এবং আরও ঝামেলা না করতে চায়। সুতরাং ধরে নিন, কোনও ক্লায়েন্টের প্রতিক্রিয়া শেষ না হওয়া অবধি আপনি যখন কোনও ওয়ার্কিং প্রোটোটাইপ ডেমো করতে পারবেন।
অবহিত
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.