ক্লায়েন্টের জড়িততা ছাড়াই কি চপলতা সম্পাদন করা যায়?


23

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

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

আমি কি ভুল? চকচকে ক্লায়েন্টের জড়িততা ছাড়াই কাজ করতে পারে? যদি তা হয় তবে আমি আলোচিত বিষয়গুলি কীভাবে এবং কীভাবে কাটিয়ে উঠতে পারি?


12
"চটজলদি" আপনার হাতুড়ি হয়ে উঠতে দেবেন না যাতে অন্য সমস্ত কিছুই পেরেকের মতো দেখায় যা আপনার কাছে ধাক্কা খায়।
প্যাট্রিক হিউজেস

1
আমার অভিজ্ঞতায় জলপ্রপাতের পদ্ধতির দিকে অগ্রাধিকার সাধারণত সফ্টওয়্যার বা ডিজাইন কীভাবে কাজ করে তা বোঝার অভাবের কারণে হয়। সুসংবাদটি হ'ল এর অর্থ এগিলটি বড় সমস্যা নয়, এটি ক্লায়েন্টের মনোভাব / বোঝার। খারাপ খবরটি ক্লায়েন্টের মনোভাব।
বেন ব্রোকা

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

@ বেনব্রোকা: ... এটি কার্যকর হয় না। অবাক করার মতো বিষয় হ'ল কেন কেউ এমনকি এমন একটি প্রক্রিয়া ব্যবহার করতে চান যা বিশেষত কাজ না করার জন্য তৈরি করা হয়েছে। আমি অনুমান করি কেউ আসলে কাগজ পড়তে বিরক্ত করে না।
Jörg W Mittag

1
@ জার্গডাব্লু মিটাগ জলপ্রপাতের বাস্তব গ্রহণ (তারা এটি জলপ্রপাত বুঝতে পারে বা না) বেশিরভাগ কারণেই এটি ব্যবসায়ের সিদ্ধান্তগুলির একটি আদর্শ মডেল; বস কিছু চায়, আন্ডারলিং করে, গ্রাহক খুশি, তাই না? অবশ্যই এটি কাজ করে না তবে এটি দুর্দান্ত সাধারণ মনের জন্য একটি দুর্দান্ত সাধারণ মডেল :)
বেন ব্রোকা

উত্তর:


17

এটা কিভাবে পারে? কৌশলটির প্রকৃতি গ্রাহক এবং বিকাশকারীদের মধ্যে এক ধরণের প্রতিক্রিয়া লুপকে নির্দেশ করে।

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

এটি পছন্দ করুন বা না করুন, গ্রাহক নকশা প্রক্রিয়ায় জড়িত থাকবেন; তারা পুনর্নির্মাণের ব্যয়টি কতটা চায় তার বিষয়টি কেবলমাত্র (যত বেশি দেরি হবে তত বেশি ব্যয়বহুল)।

যেহেতু গ্রাহক "বিগ ডিজাইন আপ ফ্রন্ট" চান তাদের তাদের বুঝতে সাহায্য করুন যে ডিজাইনটি প্রথমবারের জন্য সঠিকভাবে পেতে আরও বেশি সময় এবং প্রচেষ্টা লাগবে।


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

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).আসলে এটি কার জন্য বেশি ব্যয়বহুল? বেশিরভাগ ক্লায়েন্টরা তাদের সমাধানের বর্তমান দৃষ্টিভঙ্গিটি পেতে আপনার সময় দেওয়ার জন্য এটি দেখছে না। কখনও কখনও তাদের কেবল সমস্যা হয় এবং সমাধানটি কী হওয়া উচিত তা জানার কোনও উপায় নেই যতক্ষণ না আপনি তাদের বলছেন যে এটি কী হবে। এই মুহুর্তে আপনি তাদের যা বলেছিলেন তা যদি তাদের সমস্যার সমাধান না করে তবে এটি আপনার সত্য নয় not তাদের দোষটি কীভাবে হয় যে আপনি প্রথমে তাদের আসল সমস্যাগুলি বুঝতে পেরেছেন? চলছে ...
maple_shaft

কনস ... তাদের কেন এটির মূল্য দিতে হবে? কেবল গ্রাহকের সাথে মুখ বাঁচাতে এবং পুনরাবৃত্ত ব্যবসায়ের কোনও সুযোগের জন্য পুরোপুরি ঝাঁকুনির জন্য নয় তবে আপনাকে ঘুরে ফিরে নিখরচায় পুনরায় কাজ করতে হবে কারণ তারা প্রথম স্থানে স্থির দাম চুক্তির দাবি করেছিল। এটি হ'ল আরও প্রচলিত মনোভাব এবং ঠিক কীভাবে পি ব্রায়ান.ম্যাকি অনুভব করছেন। গ্রাহকরা এই আলোচনার দৃ strong় বাহু এবং যখন আপনি চুক্তিটি স্কোর করার চেষ্টা করছেন 100 টির মধ্যে একটি মাত্র তখন বাস্তববাদী এবং ন্যায্য চপল ভিত্তিক চুক্তিযুক্ত লোকটিকে লাইনের পিছনে অপেক্ষা করতে হবে। এখনই এটি খুব শক্ত।
maple_shaft

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

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

7

আপনার প্রশ্নের সংক্ষিপ্ত উত্তরটি 'না'। আপনার প্রশ্নের কয়েকটি অংশে এখানে মন্তব্য রয়েছে। সঠিক হতে বেশিরভাগ উত্তরগুলি আমার ব্যক্তিগত অভিজ্ঞতা এবং পর্যবেক্ষণের ভিত্তিতে।

আমার অভিজ্ঞতায় জলপ্রপাত কাজ করে না।

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

গ্রাহকরা এটি না হওয়া পর্যন্ত তারা কী চান তা জানেন না।

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

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

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

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


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

1
@ ডাঙ্ক, আপনার মন্তব্যের জন্য ধন্যবাদ। আমি আপনার শব্দটি পছন্দ করি "" উইলি-নিল গ্রাহকরা!
NoChance

2

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

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

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

এক পর্যায়ে, আপনাকে তাদের বলতে হবে যে আপনি ভাবেন না যে জলপ্রপাতটি কাজ করবে। তাদের জিজ্ঞাসা করুন যে তারা এই পদ্ধতির সাথে সন্তুষ্ট ছিলেন এবং যদি তাই হয় তবে তাদের কাছে এই প্রকল্পটি শেষ লোকটি কেন করবে না?


2

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


2
এটি কি ক্লায়েন্টের অংশগ্রহণের পরিমাণ এবং ফ্রিকোয়েন্সি নিয়ে প্রশ্ন না এবং সমস্ত কিছু বা কিছুই নয়?
JeffO

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

2

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

  1. অনুমান। অস্পষ্ট কোন কিছু না চালানো পর্যন্ত প্রয়োগ করুন, তারপরে আপনি কীভাবে বৈশিষ্ট্যটি সর্বোত্তমভাবে প্রয়োগ করা হবে বলে মনে করেন সে সম্পর্কে সিদ্ধান্ত নিন। এটি স্পষ্টতই আদর্শ নয়, যেহেতু এটি "অপেক্ষা করুন, এটিই আমি চেয়েছিলাম না!" দৃশ্যকল্প।

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

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

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


আপনি বিকল্পটি 4 এড়িয়ে গেছেন You গ্রাহক পর্যালোচনা দিয়ে নকশা (সম্ভবত পুনরাবৃত্ত) করুন। কোডটি প্রয়োগ করুন এবং পরীক্ষা করুন (সম্ভবত পুনরাবৃত্তি)। পর্যায়ক্রমিক প্রোগ্রামের পর্যালোচনাগুলি গ্রাহককে অগ্রগতি এবং সিদ্ধান্তগুলি অবহিত করে রাখুন। তারা মতামত দেয়, আপনি তাদের মন্তব্য অন্তর্ভুক্ত এবং এগিয়ে যান।
ডাঙ্ক

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

আপনার বিকল্প 4টি আমি বিকল্প 3-এ বর্ণনা করার ইচ্ছা করেছিলাম
মরগান হের্লোকার

আমি কীভাবে আমার উত্তরটি আরও ভাল করতে পারি? আমি যা বলছি তার সাথে আপনি যদি একমত হন বা একমত হন তবে আমি বলতে পারি না।
মরগান হের্লোকার

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

1

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

তবে এক পর্যায়ে আপনাকে 'সত্যিকারের' ক্লায়েন্টকে সফ্টওয়্যারটি দেখাতে হবে ...


0

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


0

চটপটে বড় আপ-ফ্রন্ট ডিজাইনটি প্রতিস্থাপনের জন্য টাইট লুপের প্রয়োজন যা শক্ত - বেশ শক্ত কিন্তু আসলে এটি করা যায়, চটজলদি একমাত্র উপায় নয়।

আপনি অ্যাগিলের একটি পরিবর্তন খুঁজে বের করতে চাইতে পারেন - এই নির্দিষ্ট সমস্যাটির জন্য অনেকগুলি রয়েছে এবং সম্ভবত একটি রয়েছে, তবে আপনি যদি মনে করেন তবে আপনি নিজেই এটি তৈরি করতে পারেন না can

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

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

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


0

গ্রাহককে সংজ্ঞায়িত করুন।

এটা কি অন্য কোন সংস্থা? আরেকজন ব্যক্তি?

এটি কি আপনার সংস্থার মধ্যে অন্য দল?

এটি কি আপনার সংস্থার মধ্যে কোনও পণ্য চ্যাম্পিয়ন?

এটা কি তুমি?

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

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

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

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

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

তবুও, যদি আপনি কোনও শৃঙ্খলাবদ্ধভাবে কাজ করেন, আপনার পছন্দের পদ্ধতিটি কঠোরভাবে আঁকড়ে ধরে থাকেন এবং চটপটে অনুশীলনগুলি প্রয়োগ করেন এবং আপনি যখন পাশের দিকে নজর রাখেন, বা আপনি নিজের মন পরিবর্তন করেন (যখন আপনার গ্রাহকের টুপি পরেছেন) এবং আপনার পণ্যের নকশা বা দিকনির্দেশনা আপনি যদি আপনার সময়সূচিটি মানিয়ে নিতে পারেন এবং আপনার গ্রাহক যেভাবে আপনার প্রত্যাশা করবেন বলে ঠিক তেমনি আপনার অগ্রাধিকারগুলি সামঞ্জস্য করতে পারেন, তবে আপনি চটফটে হচ্ছেন turn

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