ব্যর্থ স্প্রিন্ট এবং সময়সীমা নিয়ে কাজ করা


80

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

এটি বিকাশকারীর দৃষ্টিকোণ থেকে দুর্দান্ত দেখায়, তবে, আমরা বলি যে আমাদের কাছে একটি সফ্টওয়্যার সংস্থা " স্ক্রাম-অ্যাডিক্টস এলএলসি " রয়েছে গুরুতর ক্লায়েন্টদের জন্য কিছু বিকাশকারী (" মানি-ব্যাগস কর্পোরেশন "):

  1. স্ক্র্যাম-অ্যাডিক্টস ম্যানেজাররা মানি-ব্যাগের জন্য এক টুকরো সফ্টওয়্যার তৈরির পরামর্শ দেন
  2. তারা বৈশিষ্ট্যের তালিকায় একমত এবং মানি-ব্যাগগুলি একটি শিপিংয়ের তারিখ সরবরাহ করতে বলে
  3. স্ক্র্যাম-আসক্ত পরিচালকরা তাদের স্ক্র্যাম দলের সাথে পরামর্শ করেন এবং দলটি বলেছে যে সমস্ত বৈশিষ্ট্য সম্পূর্ণ করতে 3 সপ্তাহ ব্যাপী স্প্রিন্ট লাগবে
  4. স্ক্র্যাম-অ্যাডিক্টস ম্যানেজার নিরাপদ থাকতে 1 সপ্তাহ যোগ করে, 1 মাসে সফটওয়্যারটি শিপিংয়ের প্রতিশ্রুতি দেয় এবং মানি-ব্যাগের সাথে একটি চুক্তি স্বাক্ষর করে
  5. ৪ টি স্প্রিন্টের পরে (শিপিংয়ের সময়সীমা) স্ক্রাম টিম কেবলমাত্র ৮০% বৈশিষ্ট্য সরবরাহ করতে পারে (নতুন সিস্টেমের সাথে অভিজ্ঞতার কারণে, উত্পাদন পরিবেশে পূর্ববর্তী বৈশিষ্ট্যগুলিতে সমালোচনামূলক বাগগুলি ঠিক করার প্রয়োজন ইত্যাদি ...)
  6. স্ক্র্যামের পরামর্শ অনুসারে, এই মুহুর্তে পণ্যটি সম্ভাব্যভাবে শিপযোগ্য, তবে মানি-ব্যাগের 100% বৈশিষ্ট্য প্রয়োজন, যেমন চুক্তিতে উল্লেখ করা হয়েছে। সুতরাং তারা চুক্তি ভঙ্গ করে কিছুই দেয় না।
  7. স্ক্র্যাম-অ্যাডিক্টস দেউলিয়ার দ্বারপ্রান্তে রয়েছে কারণ তারা মানি-ব্যাগ থেকে কোনও অর্থ পায়নি এবং বিনিয়োগকারীরা ফলাফলগুলি নিয়ে হতাশ হয়ে পড়েছিল এবং তারা আর কোনও সংস্থাকে সহায়তা করতে রাজি নয়।

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

কে দোষী?

  1. পরিচালকগণ, কারণ সঠিক পরিকল্পনা করা তাদের কাজ
  2. দল, কারণ তারা তাদের চেয়ে বেশি কাজ করার প্রতিশ্রুতিবদ্ধ
  3. অন্য কেউ

কি করা হয়?

  1. পরিচালকদের মূল দলের অনুমানের চেয়ে সময়সীমা 2x (বা 3x) বার পরে যাওয়া উচিত।
  2. দলের সদস্যরা যে কাজই না করে প্রতিশ্রুতিবদ্ধ সমস্ত কাজ করার জন্য উত্সাহিত করা উচিত (ব্যর্থ স্প্রিন্টের জন্য জরিমানা জারি করে)
  3. দলের স্ক্র্যাম বাদ দেওয়া উচিত কারণ এটি কোম্পানির সময়সীমা নীতিমালার সাথে ফিট করে না
  4. আমাদের সকলের সফ্টওয়্যার বিকাশ ছেড়ে একটি মঠে যোগদান করা উচিত
  5. ???

31
আপনি "করণীয়" এর অধীনে 3 পয়েন্টটি ধরে নিয়েছেন ধরে নিন যে স্ক্রামটি ব্যবহার না করা এক মাসের মধ্যে মাত্র 80% বৈশিষ্ট্য প্রস্তুত করার ক্ষেত্রে কোনও কিছু পরিবর্তন করতে পারে। ওটা হাস্যকর.
ডক ব্রাউন

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

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

13
একই সমস্যাটি যে কোনও সিস্টেমের অধীনে থেকে যায় - নোট করুন যে আপনি একটি সমমানের জলপ্রপাতের সাথে স্ক্রামকে প্রায় প্রতিস্থাপন করতে পারেন এবং সংস্থাটি এখনও আবদ্ধ হয়
জে কে।

6
সম্ভবত যদি সেই স্ক্র্যাম-অ্যাডিক্টস পরিচালনাকারীরা সেইসব বেঁচে থাকা "প্রত্যাবর্তনমূলক" সভাগুলির সময় আরও মনোযোগ দিতেন, তবে প্রকল্পটি ক্লিফের দিকে চালিত না করে দেখার জন্য এবং গ্যাসের প্যাডেলটিতে আঘাত করার পরিবর্তে তাদের 1 বা 2 সপ্তাহের মধ্যে ব্রেক চাপার সুযোগ পেতাম they ।
ডোরাস

উত্তর:


134

আমি আপনার উদাহরণে বেশ কয়েকটি মৌলিক পরিচালনার সমস্যাগুলি দেখতে পাচ্ছি:

  • যদি কোনও স্ক্র্যাম-অ্যাডিক্টস পরিচালক "হার্ড-ডেডলাইন" চুক্তি স্বাক্ষর করে তবে "একটি নতুন সিস্টেম জড়িত" এমন পরিস্থিতিতে কেবলমাত্র 33% এর সুরক্ষা মার্জিন যুক্ত করে, এটি বেশ বেপরোয়া।

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

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

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


47
জন্য +1 "একটি সম্পূর্ণ বা বাজে চুক্তি কিছু তন্ন তন্ন সফ্টওয়্যার বিক্রেতা হয় না গ্রাহকের কাছ থেকে উপকৃত হবে" । চতুর চুক্তি সম্পর্কে এটি মূল বিষয়।
guillaume31

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

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

6
তবে এই সুনির্দিষ্ট উদাহরণের জন্য ... অবশ্যই যদি কেউ ক্যামেরার হার্ডওয়ারাইডার শেষ করতে ব্যর্থ হয় তবে কেউ নতুন দিগন্ত প্রেরণ করতে পারত না। তবে সেই স্কেল প্রকল্পের জন্যও আমি বাজি ধরতে পারি যে তারা যে বৈশিষ্ট্যটি কল্পনা করেছিল প্রতিটি বৈশিষ্ট্য নিয়ে মহাকাশে যাচ্ছেনা।
জায়েবিস

6
মাইলফলক বা কার্যকারিতা প্রতি প্রদান করাও একটি বিকল্প হতে পারে।
ব্রাম

68

" অ্যাগ্রিল সফটওয়্যার ডেভলপমেন্ট ফর ম্যানিফেস্টো " এর একটি মূল্য বিবরণ হ'ল:

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

সত্য যে স্ক্র্যাম-আসক্তি এলএলসি কোনও গ্রাহকের সাথে সহযোগিতা স্থাপনের পরিবর্তে একটি চুক্তির জন্য আলোচনা করেছে, তা আমাকে তাদের তত্পরতা নিয়ে প্রশ্ন তোলে।

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

এটি গ্রাহকের দোষ যে তারা নির্ধারিত সময়সীমার সাথে চালিত বিকাশের সাথে তাদের চুক্তি বুদ্বারে লক হয়ে আছে।


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

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

3
@ রেমকো গ্রিলিচ বিদ্রূপাত্মকভাবে, "আসুন কী করা দরকার তা স্থির করুন এবং এটি করা উচিত" উল্লেখযোগ্যভাবে নিজেই চটপটে :-)
gbjbaanb

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

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

15

কে দোষী?

পরিচালক, আইনী বিভাগ, হিসাবরক্ষক - আপনার বাছাই করুন ...

আমি জানি উদাহরণটি কিছুটা স্বতঃস্ফূর্ত তবে এটি যে 100% সন্তুষ্ট না হলে সংস্থাটি একটি পয়সা না দিয়েই চলে যেতে পারে, জলপ্রপাত এবং চটজলদি চিন্তার মিশ্রণ করার জন্য অবিলম্বে অ্যালার্মের ঘণ্টা বাজানো উচিত ছিল।

গ্রাহকরা তাদের কেক রাখতে এবং এটি খেতে চান - তারা জলপ্রপাত, মিনি-জলপ্রপাত, চটপটে, লা-লা-জমি গ্রহণ করতে পেরে যতক্ষণ না তারা তারিখের জেড অনুসারে $ ওয়াইয়ের জন্য পণ্য এক্স পাবেন long

চৌকস বিকাশের জন্য একেবারে বিকাশের দল এবং গ্রাহককে একটি পদ্ধতির দৃষ্টিকোণ থেকে একই পৃষ্ঠায় থাকা প্রয়োজন। সংস্কৃতি চিন্তাভাবনা পার্থক্য কেবল ধুয়ে বেরিয়ে আসবে ইচ্ছুক চিন্তাভাবনা।


12

আইটি প্রকল্প সঙ্গে চুক্তি অজানা ; এই অজানা কিছু এমনকি অজানা । ওটার মানে কি?

উদাহরণস্বরূপ আপনার মডেল রেলপথের জন্য খেলনা ব্রিজটি ধরুন। আপনার জানা সমস্ত পরামিতি রয়েছে:

  • আপনি জানেন যে উপত্যকাটি কত বড়

  • আপনি পর্বতের উপাদান, তাদের উচ্চতা, স্থিতিশীলতা ইত্যাদি জানেন

  • আপনার কতটুকু উপাদান প্রয়োজন তা আপনি জানেন

  • আপনি আগের "প্রকল্পগুলি" থেকে জানেন যে একই ধরণের জিনিসগুলি তৈরি করতে আপনাকে কতক্ষণ সময় লেগেছে

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

উদাহরণটি আরও একধাপ এগিয়ে নিন:

  • বলুন যে আপনি নিজের মডেল রেলপথের জন্য সেতুটি তৈরি করেন না, পরিবর্তে আপনি এটি সম্পূর্ণ অপরিচিত ব্যক্তির জন্য তৈরি করেন: আপনার কাজটি দুটি পর্বতের মাঝখানে রেলপথ ব্রিজ তৈরি করা is

  • বলুন মডেল ল্যান্ডস্কেপের আগে আপনার কোনও তথ্য নেই

  • ল্যান্ডস্কেপ সম্পর্কিত তথ্য হ'ল, এটিতে দুটি পর্বত রয়েছে, যা খুব বড় বলে মনে হয় না

  • পর্বতের ধারাবাহিকতা শিলা এবং জেলির মধ্যে রয়েছে

  • মোট ব্যয় সর্বাধিক 10 $ রয়েছে $

  • কর্মক্ষেত্রটি সম্পূর্ণ অন্ধকার এবং আলোর কোনও সম্ভাবনা নেই: আপনার কাছে কেবল 8 টি ম্যাচের একটি বাক্স রয়েছে

  • সময়সীমা ৩ ঘন্টা

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

প্রতিটি আইটি সংস্থার এটি জানা উচিত। তাদের প্রকল্পের ঝুঁকি মোকাবেলা করতে হবে।

1) (আর্থিক) ঝুঁকি হ্রাস করার বিভিন্ন উপায় রয়েছে: এই চুক্তিতে গ্রাহক প্রতিটি কাজের বর্ধনের জন্য যে অর্থ প্রদান করেন তা অন্তর্ভুক্ত থাকতে পারে। সুতরাং ইনক্রিমেন্ট 1 প্রদানের পরে, একটি আংশিক হার প্রদান করতে হবে। যতক্ষণ না স্ক্র্যাম-অ্যাডিক্টস এলএলসি সরবরাহ করে, ততক্ষণে সেখানে আর্থিক ঝুঁকি ন্যূনতম থাকে। আরও সূক্ষ্ম স্প্রিন্ট লক্ষ্যগুলি পরিকল্পনা করা হয়, প্রতিটি স্প্রিন্টের মোট ঝুঁকি তত কম। তার অর্থ, মানি-ব্যাগ কর্পোরেশন যদি চুক্তির ৮০% পেয়ে থাকে তবে তারা কমপক্ষে চুক্তির মূল্যের ৮০% দিতে হবে। যদি তারা ব্যর্থ স্প্রিন্টের পরে অর্থ প্রদান করতে অস্বীকৃতি জানায় তবে 100% প্রদান করতে অস্বীকার করার ঝুঁকি তত বেশি নয়।

2) স্ক্রাম-আসক্তি এলএলসি তাদের বিকাশকারীদের সাথে একটি সমস্যা আছে

স্ক্র্যাম-আসক্ত পরিচালকরা তাদের স্ক্র্যাম দলের সাথে পরামর্শ করেন এবং দলটি বলেছে যে স্ক্র্যাম-অ্যাডিক্টস পরিচালকের সুরক্ষার জন্য আরও 1 সপ্তাহ যুক্ত হবে, 1 মাসের মধ্যে সফ্টওয়্যারটি জাহাজে পাঠানোর প্রতিশ্রুতি দেয় এবং চুক্তি স্বাক্ষর করে মানি-ব্যাগ সহ

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

কে দোষী?

1) পরিচালনা

যেমন উপরে বলা হয়েছে: ঝুঁকি ব্যবস্থাপনায় স্পষ্টতই একটি ব্যর্থতা রয়েছে। সংস্থাটি দেউলিয়ার দ্বারপ্রান্তে থাকলে, সংস্থাটি এর প্রাপ্য। আপনি যদি এই জাতীয় সংস্থায় কাজ করেন: ছেড়ে দিন!

2) দল

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

কি করা হয়?

এখন: মানি-ব্যাগগুলি আদালতে নিয়ে যান

ভবিষ্যতের জন্য: এই জাতীয় চুক্তি করবেন না

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

  • যোগাযোগের উপায়গুলি গঠনের জন্য (কাদের সাথে কথা হয় কখন কী সম্পর্কে)

  • বিকাশকারীদের রিপোর্টিং ব্যর্থতার তাড়াতাড়ি উত্সাহ দেওয়া

  • টাস্ক এবং সাবটাস্কগুলিতে সমস্যাগুলি বিভক্ত করা

  • সময় এবং সক্ষমতা গঠনের জন্য (কখন কী কাজ করে)

  • সময় স্লট উপর কাজ বিতরণ

  • অপ্রত্যাশিত কিছুটা আরও অনুমানযোগ্য করে তুলুন (পরিকল্পনা পোকার)

বা সামগ্রিক: ঝুঁকি হ্রাস করতে।

হাতুড়ি হিসাবে স্ক্রাম একটি সরঞ্জাম। এটি একটি ভাল সরঞ্জাম কিনা তা আপনার জ্ঞানের উপর নির্ভর করে এটি কীভাবে ব্যবহার করবেন। তবে কখনও কখনও স্ক্রু ড্রাইভার ভাল ফিট করে। এটা আপনার উপর নির্ভর করছে.


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

9

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

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

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

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

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


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

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

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

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

4

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

এমন কিছু ক্ষেত্রে রয়েছে যেখানে একটি সময়সীমা একটি সময়সীমা থাকে তবে কল্পনা করুন যে আপনি একটি খেলা লিখছেন এবং এটি একেবারে ক্রিসমাসের ছুটির সময়ে প্রকাশ করতে হবে। যে ভুল পেয়ে অনেক কোম্পানী দেউলিয়া হয়েছে!

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

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

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

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


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

2
আপনি যে গেমটি ধরে নিয়েছেন সেগুলি @ মোটামুটি কার্যকরভাবে কাজ করে, যে 80% পরে যুক্ত করা যেতে পারে এমন বৈশিষ্ট্যগুলি হারিয়ে নাও পারে, তবে কার্যকারিতা ভেঙে বা বাগ ক্র্যাশ করছে। এটি কোনও গেম হতে হবে না, এমন কোনও সফ্টওয়্যার হতে পারে যা নির্দিষ্ট সময়ের জন্য প্রেরণ করা দরকার, এবং অপরিবর্তনীয় সময়সীমা (এমনকি অ্যাপল ক্রিসমাস পিছিয়ে দিতে পারে না!)
gbjbaanb

6
এটাই স্ক্রমের প্রাথমিক ভিত্তি! ভাঙা কার্যকারিতা গণনা করে না। আপনি যদি জলপ্রপাতের পটভূমি থেকে এসে থাকেন তবে আপনি দেখতে পাবেন যে স্ক্রাম নতুন বৈশিষ্ট্য যুক্ত করার চেয়ে বাগফিক্সিংকে অগ্রাধিকার দেয়। "৮০% সম্পন্ন" এর অর্থ হ'ল এখানে অনুপস্থিত স্তর, নিখোঁজ বস, ইত্যাদি রয়েছে
এমসাল্টাররা

1
@gbjbaanb এই যুক্তি দ্বারা, কিছু 99.9% হতে পারে তবে এখনও কাজ করে না কারণ এটি শুরু হওয়ার সাথে সাথেই ক্র্যাশ হয়ে যায়।
ইমিগ্রিস

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

4

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

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

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


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

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

2
@ অ্যান্ড্রেওর্জেস নিশ্চয়ই গ্রাহক 0% বৈশিষ্ট্য দেখার চেয়ে 80% বৈশিষ্ট্য দেখতে আরও খুশি হবেন? কমপক্ষে সেই পথে, গ্রাহক জানেন পণ্যটি বেশিরভাগ ক্ষেত্রে সম্পন্ন হয়।
ইমিগ্রিস

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

2
একদম ঠিক! এর অভ্যন্তরীণ আমলাতন্ত্র এবং অভিজ্ঞ পরিচালন কর্মীদের অভাবের কারণে অনেক সময় কোনও বৃহত সংস্থার পক্ষে ব্যর্থ সময়সীমাটিকে একটি "ব্যর্থ পরীক্ষা" হিসাবে বিবেচনা করা এবং সুযোগটি পুনরায় আলোচনা করার চেয়ে আরও প্রচেষ্টা চালিয়ে যাওয়ার চেয়ে প্রকল্পটি পুরোপুরি বাদ দেওয়া সহজ হয়। দুঃখজনক হলেও সত্য :(
আন্দ্রে বোর্জেস

1

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

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

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

স্ক্রাম-আসক্তি পরিচালকরা মানি-ব্যাগের জন্য একটি সফটওয়্যার তৈরি করার পরামর্শ দেন তারা বৈশিষ্ট্যের তালিকায় একমত হন এবং মানি-ব্যাগগুলি একটি শিপিংয়ের তারিখ সরবরাহ করতে বলে স্ক্রাম-আসক্ত পরিচালকরা তাদের স্ক্রাম দলের সাথে পরামর্শ করেন এবং দলটি বলে যে এটি 3 সপ্তাহের মত লাগবে স্ক্র্যাম-অ্যাডিক্টস ম্যানেজার নিরাপদ থাকার জন্য 1 সপ্তাহ যুক্ত করে, 1 মাসের মধ্যে সফটওয়্যারটি শিপিংয়ের প্রতিশ্রুতি দেয় এবং 4 টি স্প্রিন্টের পরে মানি-ব্যাগের সাথে একটি চুক্তি স্বাক্ষর করে (শিপিংয়ের সময়সীমা) স্ক্রাম দল কেবল 80% সরবরাহ করতে পারে বৈশিষ্ট্যগুলির (নতুন সিস্টেমের সাথে অনভিজ্ঞতার কারণে, উত্পাদন পরিবেশে পূর্ববর্তী বৈশিষ্ট্যগুলিতে সমালোচনামূলক বাগগুলি সংশোধন করার প্রয়োজন ইত্যাদি)) স্ক্র্যামের পরামর্শ অনুসারে, পণ্যটি সম্ভাব্যভাবে বহনযোগ্য, তবে মানি-ব্যাগগুলির 100% প্রয়োজন বৈশিষ্ট্য হিসাবে, চুক্তিতে উল্লিখিত। সুতরাং তারা চুক্তি ভঙ্গ করে কিছুই দেয় না।

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

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

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

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

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

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

এই মাসে সবকিছু হঠাৎ করে পুরোপুরি কার্যকর হবে এমন প্রত্যাশার চেয়ে তারা 1 থেকে 2 সপ্তাহের মধ্যে প্রথম সরবরাহকারীর মূল্যায়ন করার প্রত্যাশা করবে।

সুতরাং, সংক্ষেপে বলতে গেলে আমার কাছে দুটি প্রশ্ন রয়েছে:

কে দোষী? পরিচালকদের, কারণ তাদের সঠিক কাজটি করা কাজ
টিম, কারণ তারা
অন্য কারও চেয়ে বেশি কাজ করার প্রতিশ্রুতিবদ্ধ

আমরা রাস্তায় নামার আগে যে কেউ এই ট্র্যাভ্যাসিটি বন্ধ করতে পারত।

আমি এমন একটি দল নিয়োগের জন্য মানি-ব্যাগ কর্পসকে দোষারোপ করার পক্ষে যেতে পারি যে স্পষ্টতই জলবায়ু প্রক্রিয়াটি চতুর বলে প্রতারণামূলকভাবে প্রতিনিধিত্ব করে। চুক্তি নিজেই এটি পরিষ্কার করে দেয় এটি চটজলদি নয়। একমাসে করার পরিকল্পনা এটি চতুর করে না।

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

কি করা হয়?

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

পরিচালকদের মূল দলের অনুমানের চেয়ে সময়সীমা 2x (বা 3x) বার পরে যাওয়া উচিত।

ডেডলাইন মাল্টিপ্লায়াররা আপনার ঘড়িটি 15 মিনিটের তাড়াতাড়ি সেট করার মতো কার্যকর কারণ আপনি কখনই দেরী করবেন না। আপনি কী করছেন তা উপলব্ধি করার আগে আপনি এতদিন নিজেকে বোকা বানাতে পারেন।

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

দলের সদস্যরা যে কাজই না করে প্রতিশ্রুতিবদ্ধ সমস্ত কাজ করার জন্য উত্সাহিত করা উচিত (ব্যর্থ স্প্রিন্টের জন্য জরিমানা জারি করে)

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

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

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

দলটিকে স্ক্র্যাম ছেড়ে দেওয়া উচিত কারণ এটি সংস্থার সময়সীমার নীতিমালার সাথে ফিট করে না স্ক্রাম জলপ্রপাতের চেয়ে আরও সঠিকভাবে একটি সময়সীমাতে আঘাত করতে পারে। একটি সময়সীমা দেওয়া স্ক্র্যাম এটি পূরণ করতে পারে। এটি সময়, বৈশিষ্ট্য এবং দক্ষতার উপর নির্ভর করে 47 টির মধ্যে 1 টির সাথে এটি পূরণ করতে পারে তবে এটি এটি পূরণ করতে পারে।

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

আমাদের সকলের সফ্টওয়্যার বিকাশ ছেড়ে একটি মঠে যোগদান করা উচিত

ঠিক আছে, বাস্তব জীবন থেকে দূরে ঘরে আমাকে তালাবন্ধ রাখার ফলে আমি কম কোড লিখতে পারি।

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


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

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

@ আন্ড্রেবার্গেস আপনি ঠিক বলেছেন, আমি পণ্যের ব্যাকলগের কথা ভাবছিলাম। সম্প্রতি আমি এমন একটি সরঞ্জাম নিয়ে কাজ করছি যা স্প্রিন্টকে ব্যাকলজ স্প্রিন্ট এবং পণ্যটিকে ব্যাকলগ ব্যাকলগ বলে। আপনি আমার শব্দভান্ডারকে মালিকানা থেকে রক্ষা করার লড়াইয়ে আমাকে হারিয়ে ফেলেন।
candied_orange

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

0

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

আপনি ভবিষ্যতে খুব শিপিংয়ের তারিখ দিতে পারবেন না। আপনি একটি অনুমান দিন।

কারও কাছে ক্লায়েন্টের প্রত্যাশা পরিচালনা করতে হবে। কয়েকটা স্প্রিন্ট পিছনে পড়ে যাওয়ার বিষয়ে আপনি খুব বেশি চিন্তার কারণ না কারণ হ'ল আপনি পুরো প্রকল্পটি পিছিয়ে পড়তে রোধ করতে সামঞ্জস্য করেছেন। যদি আপনি কোনও স্প্রিন্ট বা দু'বারের পরে সিদ্ধান্তে পৌঁছেন যে আপনি "শিপিংয়ের তারিখ" পূরণ করতে যাচ্ছেন না, তখন আপনি ক্লায়েন্টকে বলবেন।

এখন আপনি কি করতে চান? আপনার প্রয়োজন নেই এমন বৈশিষ্ট্যগুলি থেকে মুক্তি পান বা তারিখটি সরান। আপনি যদি সময়মতো বিতরণ করতে পারতেন তবে আপনি দিতেন। খারাপ খবর আনতে দ্বিধা করবেন না।

কে জানে, কিছু প্রকল্পে আপনি শিগগির শিপিং করতে পারেন।

ক্লায়েন্ট না চাইলে আপনি চটচটে হতে পারবেন না।


0

লক্ষ্য

আমি বিশ্বাস করি যে কোনও ব্যবসায়ের সিদ্ধান্তের জন্য নিম্নলিখিত দুটি "মেট্রিক" ভিত্তি হওয়া উচিত:

  • কাজটি লাভজনক (ক্লায়েন্টের জন্য)
  • আমরা কি যথাসম্ভব দক্ষতার সাথে কাজ করছি?

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

সমস্যা

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

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

দিনের শেষে, আমাদের একটি সমঝোতা বেছে নিতে হবে যা আমাদের লক্ষ্যগুলি যথাসম্ভব উত্তম করতে দেয়।

এটি এইভাবে কাজ করা উচিত

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

ঠিক আছে আমি মূলত শুধু বলেছি "চটপটে"। এখন এখানে কেন:

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