ডেডলাইন কি চতুর?


100

স্পষ্টতার জন্য, একটি সময়সীমা হ'ল:

একটি সময়সীমা বা সময়সীমা একটি সংকীর্ণ ক্ষেত্র, বা সময় নির্দিষ্ট পয়েন্ট, যার দ্বারা একটি উদ্দেশ্য বা কার্য সম্পাদন করতে হবে।

উইকিপিডিয়া থেকে

আমার সম্পূর্ণ সফটওয়্যার বিকাশ ক্যারিয়ারটি আমি "চটজলদি" করে চলেছি যা সর্বত্রই মনে হচ্ছে কমপক্ষে নিম্নলিখিত রীতিগুলি মেনে চলছিল:

  • সাপ্তাহিক বা দ্বি-সাপ্তাহিক স্প্রিন্ট
  • প্রসারণমূলক পরিকল্পনা স্প্রিন্ট পরিকল্পনা
  • একটি পণ্য মালিক
  • স্ক্রাম
  • ব্যবহারকারী গল্প

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

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


36
স্প্রিন্ট হিসাবে একটি সময়সীমা না?
জেফো

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

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

8
রন জেফরিস '( এগ্রিল
জুলাই

4
আমার কিছু সময়সীমা বেশ চটজলদি প্রমাণ করেছে।
psr

উত্তর:


147

সময়সীমা একটি বাস্তবতা। বেশির ভাগ সময়ই আপনি আছে কিছু একটি নির্দিষ্ট তারিখ অনুসারে। এটা অনিবার্য। সময়সীমা ব্যতীত, এমনকি চটজলদি প্রকল্পগুলি পার্কিনসনের আইনে আত্মত্যাগ করতে পারে :

কাজের প্রসার ঘটে যাতে এর সমাপ্তির জন্য উপলব্ধ সময় পূরণ করতে পারে।

অন্য কথায়, আপনার প্রকল্পের যদি পারেন চিরকাল যান, এটা করবে না।

সময়সীমা সম্পর্কিত, আগলে কিছু জিনিস করার চেষ্টা করে:

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

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

তাই হ্যাঁ. "চতুর" এবং "সময়সীমা" পুরোপুরি সামঞ্জস্যপূর্ণ হতে পারে।


10
@ স্টিভবোট ঠিক এমনই পরিস্থিতি যা পারকিনসন আইনকে অনুরোধ করে। আমি এমন কোনও ক্লায়েন্টের সাথে কখনও দেখা করি নি যা আরও বেশি বৈশিষ্ট্য যুক্ত করার কথা ভাবতে পারে না। সময়সীমা ছাড়াই বৈশিষ্ট্য তালিকা এবং এইভাবে প্রকল্পটি অসীম।
এরিক কিং

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

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

7
"২৮ শে জুলাইয়ের মধ্যে আমাদের কিছু পাঠাতে হবে।" নির্দিষ্ট সময়সীমা এই বাক্যের মধ্যে জুলাই 28 তম হয়। আপনার কাছে "কিছু" প্রয়োজনীয়তার একটি পূর্বনির্ধারিত সেট হতে পারে বা এটি যা প্রস্তুত তা হতে পারে। "কিছু" অংশটি সময়সীমা নয়। তারিখ নির্দিষ্ট সময়সীমা নেই।
এরিক কিং

5
@ স্টেভবোট "(উত্তর) পাঠককে বিশ্বাস করে যে এগিল + ডেডলাইনস = পুরোপুরি ঠিক আছে বিভ্রান্ত করে।" যদিও বিষয়টি। তত্পর হয় সময়সীমা সঙ্গে পুরোপুরি জরিমানা। বা ছাড়া। তোমারটা নাও. অন্যথায় বলতে গেলে মূলত বলা হয় "আচ্ছা, যেহেতু আমাদের একটি সময়সীমা রয়েছে তাই আমরা এই প্রকল্পটি তত্পর হিসাবে করতে পারি না!" যা ব্যালনি। আমি এমন অনেক প্রকল্পে কাজ করেছি যেগুলির দু'জনের সময়সীমা ছিল এবং "চতুর" ছিল। চূড়ান্ত সময়সীমা কি? ঠিক আছে, তারা চটজলদি নয়
এরিক কিং

24

শেষ তারিখগুলি জীবনের সত্য are কিছু জিনিস আছে যা খুব দৃ firm় তারিখ আছে।

কমডেক্স দ্বারা আমাদের সফ্টওয়্যারটি দরকার

অথবা

গেমগুলি অবশ্যই ব্ল্যাক ফ্রাইডে দ্বারা স্টোর তাকগুলিতে থাকতে হবে

এবং পছন্দ. কেউ কমডেক্স বা ব্ল্যাক ফ্রাইডে স্থগিত করতে পারে না - বাকি বিশ্বে সেভাবে কাজ করে না।

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

শেষ তারিখটি একটি শক্ত তারিখ যা দৃly়ভাবে সেট করা হয়। Agile একটি সরঞ্জাম যা সফ্টওয়্যারটি মূলত আশানুরূপ হিসাবে বিকাশ করতে দ্বিগুণ দীর্ঘ সময় নিতে চলেছে এমন চক্রের আগে উপলব্ধি করতে দেয়। প্রকল্প ব্যবস্থাপকদের পক্ষে এই বিষয়গুলি পরবর্তী সময়ের চেয়ে উপলব্ধি করতে সক্ষম হওয়া উচিত যাতে আরও বেশি সংস্থান যুক্ত করা যায়, সুযোগ পরিবর্তন হয়, সময়সীমাটি সমন্বিত হয় (এমন পরিস্থিতিতে যেখানে এটি দৃ solid় স্থির সময়সীমার চেয়ে দৃ firm় হয়) বা প্রকল্পে বাতিল করা হয়েছে।

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

অ্যাগিল একটি সময়সীমার প্রেক্ষাপটে অন্যান্য অংশটি করতে চাচ্ছে তা হ'ল যদি সম্মতিযুক্ত বৈশিষ্ট্যগুলির কেবলমাত্র একটি অংশ সম্পূর্ণ হয় (যাই হোক না কেন কারণেই), সফ্টওয়্যারটির বর্তমান সংস্করণটি কার্যকর এবং প্রয়োগযোগ্য।

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


2
আমি আপনার সাথে একমত, যদিও আমি আপনার দুটি বক্তব্যের গুরুত্বকে সরিয়ে দেব। # 1। তত্পর হয় প্রাথমিকভাবে নিশ্চিত সফ্টওয়্যার এর বর্তমান সংস্করণ দরকারী এবং deployable যে উপার্জন নিবদ্ধ করুন। # 2। দ্বিতীয়ত, সুযোগটি আগে যখন পুরোপুরি অযৌক্তিক হয় তা উপলব্ধি করতে আমাদের সহায়তা করে যাতে পণ্য মালিকরা # 1 এর লক্ষ্যটিকে পুনরায় তৈরি করতে এবং বজায় রাখতে পারে।
ক্যালফুল

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

18

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

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

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

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


13

স্বেচ্ছাচারিত সময়সীমা যা চূড়ান্ত না হলে কোনও পরিণতি হয় না, তবে এমন পরিস্থিতি রয়েছে যেখানে উন্নয়ন দলের নিয়ন্ত্রণের সময়সীমার বাইরে কারণ থাকতে হবে এবং তা রাখতে হবে। সৌভাগ্যক্রমে, সময়সীমা যুক্তিসঙ্গত হলে সমীকরণটি উল্টে দেওয়ার এবং চৌকস উপায়ে সময়সীমা হ্যান্ডেল করার প্রচুর উপায় রয়েছে।

সময়সীমা সর্বদা ভুল হয় না। যেমনটি আমরা সবাই ওবি-ওয়ানের কাছ থেকে শিখেছি:

"কেবলমাত্র সিথ চুক্তিতেই রহিত"

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

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

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


11

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

TL; ড

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

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

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

দেব দল (ডি): "দয়া করে আপনি যে বৈশিষ্ট্যগুলি বিতরণ করতে চান সেটি সবচেয়ে গুরুত্বপূর্ণ দিয়ে প্রথমে অগ্রাধিকার দিতে পারেন?"

গ্রাহক (সি): "সবকিছুই অগ্রাধিকার 1 - আমি চাই আগামী মাসের শেষের মধ্যে সেগুলি হয়ে গেছে" "

ডি : "এটি সম্ভব হতে পারে, তবে প্রয়োজনীয়তাগুলি পরিবর্তিত হয় বা আমরা এমন সমস্যাগুলি আবিষ্কার করি যেগুলি উন্নয়নের মধ্য দিয়ে যাওয়ার সময় আমরা প্রত্যাশা করি না।"

সি: "আচ্ছা আমি যদি তোমাকে আরও বেশি টাকা দিই?"

ডি: " দীর্ঘশ্বাস ... আরও রিসোর্স থাকা সত্ত্বেও তাদের সত্যিকারের পথে যেতে এক মাস সময় লাগবে; সুতরাং আপনি কীভাবে বৈশিষ্ট্যগুলিকে অগ্রাধিকার দিতে হবে তা নিশ্চিত না হলে আপনি প্রথমে কোনটি করতে চান তা আমাদের জানান" "

সি: "ঠিক আছে আমি বড় বোতামটি চাই তবে এটিকে সত্যই বড় করে তুলি এবং তারপরে ... ইত্যাদি"

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

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

কখনও কখনও গ্রাহক পছন্দ করেন না যে তারা একটি নির্দিষ্ট তারিখের মধ্যে তারা যা চান তা পাবেন না তবে তারা বুঝতে পারবেন কেন এবং কী পান তারা ভাল মানের হবে। এবং বৈশিষ্ট্যগুলি সরবরাহ করার months মাস পরে গ্রাহক কোনও নির্দিষ্ট তারিখের মধ্যে আপনি সরবরাহ করেছেন তা যত্নশীল বা মনে রাখবেন না, তারা যে পণ্যটির এখনও ব্যবহার করছেন তার গুণাগুণ তারা মনে রাখবেন।


7
"সুতরাং কেউ যদি একটি সময়সীমা নির্ধারণ করতে চান তবে তা ঠিক আছে এবং সময়সীমা স্থির করা যেতে পারে, তবে তাদের কী বুঝতে হবে তা যদি সময়সীমা স্থির হয় তবে অবশ্যই সুযোগটি নমনীয় থাকতে হবে।" একেবারে।
এরিক কিং

এটি সম্ভবত এখানে সবচেয়ে চতুর উত্তর। এর বেশি ভোট নেই তা সত্য যে বিস্তর ভুল বোঝাবুঝির তা প্রমাণ test
পোস্টকোড়িজম

10

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

তত্পর ইশতেহার পদ বলে:

প্রক্রিয়া এবং সরঞ্জামগুলির উপর ব্যক্তি এবং ইন্টারঅ্যাকশন

বিস্তৃত ডকুমেন্টেশন ওভার সফ্টওয়্যার

চুক্তি আলোচনার উপর গ্রাহকের সহযোগিতা

একটি পরিকল্পনা অনুসরণ করে পরিবর্তন সাড়া

সময়সীমা একটি চুক্তি। তারা একটি পরিকল্পনা। তারা আপনার দলের গতিতে সাড়া দেয় না। আপনি আপনার তিনটি সেরা বিকাশকারীকে হারাতে পারলে এগুলি পরিবর্তন হয় না।

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

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


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

@ এরিকিং হ্যাঁ, আপনি ঠিকই বলেছেন, এগিল ডেডলাইন নিয়ে কাজ করতে পারে, আমি মনে করি "অ্যাডিল ডেডলাইনের সাথে কাজ করে" এর পরিবর্তে "ডেডলাইনস এগিলি" হিসাবে আপনার বক্তব্যগুলি পড়েছি।
স্টিভবট

আপনার মন্তব্যের জন্য ধন্যবাদ. আমি মনে করি আমরা দুজনেই একে অপরের সাথে কিছু সময়ের জন্য কথা বলছিলাম, এবং জিনিসগুলিকে ক্লিক করতে কেবল এটি একটি নির্দিষ্ট ফ্রেসিং লাগবে। "ডিলাইনগুলি চটজলদি" বলার অর্থ আমার ছিল না তবে আমি দেখতে পাচ্ছি যে এটি কীভাবে এগিয়ে আসবে। এর জন্যে দুঃখিত.
এরিক কিং

6

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

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


বিটিডাব্লু, ক্যাল, আপনি এখানে যা বলছেন তার সাথে আমি অনেকটাই একমত। এবং আমি মনে করি না যে এটি আমার লেখার সাথে বিরোধিতা করে।
রবার্ট ব্রিস্টো-জনসন 16 '13

5

টি এল; ডিআর

ডেডলাইনগুলি [ক] গিল? ... [ডি] এডলাইনগুলি [এ] গিলের বিকাশের সাথে একসাথে যেতে দেখা হয়

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

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

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

সময়-বাক্সগুলি চিন্তা করুন, সময়সীমাগুলি নয়

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

এটি চতুর নীতিগুলির একটি সাধারণ ভুল বোঝাবুঝি। স্ক্রাম এবং কানবানের মতো চতুর ফ্রেমওয়ার্কগুলি সময়সীমার দিকে মনোনিবেশ করে না, বরং সময়-বক্সিং এবং সরবরাহের একটি টেকসই ক্যাডেন্সের দিকে মনোযোগ দেয়।

উদাহরণস্বরূপ, স্ক্রামে স্প্রিন্ট কোনও "সময়সীমা" নয়। এটি এমন একটি টাইম-বাক্স যা দলের অনুমানের পরিমাণের পরিমাণে ভরাট হয়ে যায় যাতে এটি উপচে না পড়ে টাইম-বক্সের মধ্যে ফিট হয়ে যায় এবং টাইম-বক্সের মেয়াদ শেষ হওয়ার পরে তা হয় "সম্পন্ন" বা "সম্পন্ন হয় না"। একবার গেলে, টাইম-বক্সটি চিরতরে চলে যায়; যে কোনও কাজ করা হয়নি তার জন্য প্রকল্পটির তত্ক্ষণিক (historicalতিহাসিক নয়) প্রয়োজনের ভিত্তিতে একটি নতুন, সমান তাত্পর্যপূর্ণ টাইম-বক্সের মধ্যে পুনঃ পরিকল্পনা এবং পুনর্নির্মাণ করতে হবে।

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

সময়-বাক্সের ভিত্তিতে প্রকাশের পরিকল্পনা Planning

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

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

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

আরো দেখুন


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

4

প্রতিশ্রুতি হিসাবে সময়সীমা ভাবেন। প্রকল্পটি চৌকস হওয়ার অর্থ এই নয় যে আপনি একটি নির্দিষ্ট তারিখের জন্য প্রদত্ত বৈশিষ্ট্যগুলি সরবরাহ করার প্রতিশ্রুতিবদ্ধ হবেন না।

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

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

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

গ্রাহকের দৃষ্টিভঙ্গিটিও আপনার বোঝা উচিত:

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

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

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


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

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

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

1

এক্সট্রিম প্রোগ্রামিং মুক্তির পরিকল্পনা সম্পর্কে বলে:

রিলিজ পরিকল্পনার বেস দর্শনটি হ'ল কোনও প্রকল্প চারটি ভেরিয়েবলের দ্বারা পরিমাপ করা যেতে পারে: সুযোগ, সংস্থান, সময় এবং গুণমান।

যা ন্যায্য বলে মনে হচ্ছে। এটিও বলে যে

4 টি সমস্ত ভেরিয়েবলকে কেউ নিয়ন্ত্রণ করতে পারে না। আপনি যখন একজনকে পরিবর্তন করেন আপনি অযাচিতভাবে অন্যটিকে প্রতিক্রিয়াতে পরিবর্তন আনার কারণ হন। মনে রাখবেন যে গুণমানের চেয়ে কম কোনও মান হ্রাস করা অন্যান্য 3 ভেরিয়েবলের উপর অপ্রত্যাশিত প্রভাব ফেলে

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

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


0

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

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

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


-1

সময়সীমাগুলি চটজলদি নয়, তারা হ'ল:

1) জলপ্রপাত, এবং 2) ভুল।

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

চটপটি "আপনি জানেন যে সময়সীমাটি বা বৈশিষ্ট্যগুলি স্লিপ হয়ে যায় এবং / অথবা পরিবর্তন হয়, আমরা তা জানি by" বলে পরিস্থিতিটি বাস্তবে প্রবেশের চেষ্টা করে, সুতরাং আসুন আমরা ডান পায়ে নামি এমনকি ভানও করি না "।

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

যিনি যে কোনও সময়ের জন্য কম্পিউটার গেম খেলেছেন তিনি জানেন যে এটি কীভাবে কাজ করে! যদি প্রথম প্রকাশটি বিটা স্ট্যান্ডার্ড অবধি হয় তবে অনেক গেমার খুশি, বাস্তব জীবনে "দৃ ,়, বাস্তব সময়সীমা" বলতে কী বোঝায় তার প্রত্যাশা এত কম।

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

ব্রিজ ডিজাইন কখনই না পারে সেভাবে প্রকল্পের কোর্সে লক্ষ্যগুলি বিকাশ এবং পরিবর্তন করার সুযোগ দিয়ে এই স্নিগ্ধতাটি কাজে লাগানোর চেষ্টা করে।


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

7
@ ক্যালফুল আমার কাছে এই কথাটি নিয়ে ইস্যু করেছে যে সময়সীমাগুলি জলপ্রপাত (তারা যে কোনও পদ্ধতিতে ব্যবহৃত হয় তা নির্ধারণ করে না - তারা এমনকি কাউবয় কোডারদের জন্যও বিদ্যমান) এবং ভুল (এগুলি সময়ের বহিরাগত সীমাবদ্ধতার কারণে বিদ্যমান - "আমাদের এটির চেয়ে বেশি ভুল নেই) কিছু ন্যূনতম পারফরম্যান্স সহ সেই হার্ডওয়্যারটিতে কোড চালানো হয় ")। এটি গ্রহণযোগ্য সমাধান কী তা একটি সময়ের সীমাবদ্ধতা। 15 এপ্রিলের মধ্যে ট্যাক্স ফাইল করা একটি সময়সীমা। ডিসেম্বর 1 এ বিতরণকারীর কাছে সফ্টওয়্যার থাকা যাতে এটি 27 নভেম্বর পর্যন্ত তাকের মধ্যে থাকতে পারে একটি সময়সীমা। এগুলির কোনওটিই ভুল নয়।

4
@ মিশেলটি: যদি আপনি ইতিমধ্যে না থাকেন তবে আমি আপনাকে টম অ্যান্ড মেরি পপপেন্ডিকস বই "লিডিং লিন ল্যান্ট সফটওয়্যার ডেভলপমেন্ট: রেজাল্ট আর দ্য পয়েন্ট নয়" পড়ার পরামর্শ দিচ্ছি। তিনি কেবল পাতলা / চটপটে চেনাশোনাগুলিতে মোটামুটি জনপ্রিয় মেম পৌঁছে দিচ্ছেন। আপনি এবং আপনার দলটি যদি অবিচ্ছিন্ন উন্নতির দিকে মনোনিবেশ করার চেয়ে সময়সীমার দিকে বেশি মনোনিবেশ করে থাকেন, তবে আপনি সত্যই চটপটে বাস করছেন না। আপনি স্ক্র্যাম করছেন, কিন্তু চটপটে বাস করছেন না। দীর্ঘমেয়াদী সময়সীমা কি বিদ্যমান? একথাও ঠিক যে। তারা কি চৌকস দলগুলিকে ফোকাস করা উচিত? একেবারে না. চূড়ান্ত চিন্তাভাবনার সময়সীমাগুলি ঘটনাচক্রে
ক্যালফুল

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

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

-1

উত্তর "সম্ভবত না"

Project_management_triangle যে খরচ, সময় এবং সুযোগ (এবং মান) একে অপরের উপর নির্ভর করে। ("দুটি বাছুন এবং 3 য় পান")

একটি স্ক্রাম স্প্রিন্ট নির্ধারিত সময় (অর্থাত্ 7 দিন = স্প্রিন্টের দৈর্ঘ্য) এবং ব্যয় বেছে নেয় (অর্থাত্ 7 টি দলের সদস্যদের জন্য বাজেট) এবং সুযোগটি অনুমান করে (স্প্রিন্টে করা গল্পগুলির সংখ্যা)

যদি ব্যবস্থাপনা বা বিক্রয়-বিভাগ তিনটি (ব্যয়, সময় এবং সুযোগ) সংজ্ঞায়িত করার চেষ্টা করে তবে স্ক্র্যামের অর্থে এটি চতুর নয় কারণ দলটি লক্ষ্যে পৌঁছানোর প্রতিশ্রুতি দিতে পারে না (গুণগত মান = সংজ্ঞা লঙ্ঘন না করে)

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


-1

এর উত্তর কি সরল ও সরাসরি দেওয়া যাবে না?

কোনও সময়সীমা চটজলদি নয়।

পুরো বিষয়টি হ'ল পুনরাবৃত্ত ফ্যাশন শেখার ক্ষেত্রে আপনি যা যা পারেন তা তৈরি করা এবং আপনি যাওয়ার সাথে সাথে মানিয়ে নিতে।

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

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

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


-2

কারও কাজের ক্ষেত্রে প্রয়োজনীয় তত্পরতা ডিগ্রিটি প্রতিষ্ঠানের চার্টে তাদের অবস্থান কতটা উচ্চতর তার বিপরীতভাবে সমানুপাতিক।

"চটজলদি" ভাল, এটি কিসের জন্য। "চটজলদি" বাছাইয়ের অর্থ "যথেষ্ট দক্ষতার সাথে উন্মুক্ত মনের অধিকারী"। এটি নীচে grunts যে সবচেয়ে চতুর হতে হবে।

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

কিন্তু আলোকিত স্বার্থের মতো এটি সত্যই বিদ্যমান নেই।


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

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

ওয়ালমার্টের সাথে কি কখনও ব্ল্যাক ফ্রাইডে ডেডলাইন রয়েছে? আমার যে অনুভূতি হয়েছিল তা হ'ল যদি আপনি এই বছর ভুল করে ফেলেছেন তবে পরের বছর আপনি দ্বিতীয় সুযোগ পাবেন না। এটি আক্ষরিক "দ্বিতীয় সুযোগ নয়"।
এমসাল্টারস

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

5
ব্ল্যাক ফ্রাইডে বিক্রির জিনিসটি হ'ল লোকেরা অযৌক্তিকভাবে আচরণ করতে পারে এবং অন্যথায় না হয় এমন জিনিস কেনার জন্য এটি সময় এবং পণ্যের ভ্রান্ত ঘাটতি তৈরি করার বিপণনের প্রচেষ্টা। উত্সাহিত অযৌক্তিক আচরণের এই উদাহরণটি সফ্টওয়্যার প্রকল্প পরিচালনার কিছু পদ্ধতির থেকে সমস্ত আলাদা বলে মনে হয় না। সফ্টওয়্যার দিয়ে সময়ের ভ্রান্ত ঘাটতি তৈরি করা ভাল ধারণা নয় বলে যুক্তি দিয়ে আমি বলছি না যে সময়ের প্রকৃত ঘাটতি অসম্ভব কারণ তারা স্পষ্টতই কিছু প্রসঙ্গে রয়েছে (এবং এটি গুরুত্বপূর্ণ)।
শাটল 87
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.