স্ক্রামে, উন্নয়ন পরিবেশ সেট আপ এবং সক্ষমতা বিকাশের মতো কাজগুলিকে প্রকৃত ব্যবহারকারীর গল্পের মধ্যে সাবটাস্ক হিসাবে পরিচালনা করা উচিত?


23

কখনও কখনও প্রকল্পগুলিতে আমাদের যেমন কাজের জন্য সময় ব্যয় করা প্রয়োজন:

  1. বিকল্প ফ্রেমওয়ার্ক এবং সরঞ্জামগুলি এক্সপ্লোর করে
  2. প্রকল্পের জন্য নির্বাচিত কাঠামো এবং সরঞ্জামগুলি শিখছি
  3. সার্ভার এবং প্রকল্পের অবকাঠামো স্থাপন করা (সংস্করণ নিয়ন্ত্রণ, পরিবেশ তৈরি, ডাটাবেসগুলি ইত্যাদি)

যদি আমরা ব্যবহারকারীর গল্পগুলি ব্যবহার করি তবে এই সমস্ত কাজ কোথায় যাওয়া উচিত?

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


আমি প্রশ্ন একটু করতে পরিবর্তিত হয়েছে এটি আরো পরিষ্কার .. প্রশ্ন আছে এখন সত্যিকারের ব্যবহারকারী গল্প মধ্যে subtasks পরিবর্তে গল্প যেমন
অসীম গাফফার

উত্তর:


12

আমরা গত এক বছরে এই সমস্যাটি সম্পর্কে অনেক ভেবেছিলাম।

যদিও আমি একমত যে প্রকল্পটি শুরুর আগে একটি প্রাথমিক কাঠামো থাকা উচিত, ব্যবহারিক ব্যবহারে এটি প্রকল্পেরই অংশ হতে পারে। সুতরাং আপনি একরকম পরিচালনা করতে হবে।

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

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

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

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

আমরা এমনকি কার্যগুলিতে গল্পের পয়েন্টগুলি নির্ধারণ করি এবং মাঝে মাঝে গল্পগুলির সাথে আমরা তাদের মতো করে কাজ করি work

শেষ পর্যন্ত আমি আপনার ক্ষেত্রে এই সমাধানের জন্য যাব (যা সাধারণভাবে প্রয়োগ করা যেতে পারে):

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

? তাই কি আপনি টাস্ক আহ্বান করা হয় মূলত ব্যবহারকারী গল্প বা বাগ মত একটি কাজ আইটেম .. এটা টাস্ক ব্যবহারকারী গল্প যেমন কোড, পরীক্ষা মধ্যে কর্ম, স্থাপন ইত্যাদি হিসাবে
অসীম গাফফার

2
হ্যাঁ তাদের মধ্যে পার্থক্য পাওয়ার জন্য আমরা গল্পগুলির উপ-টাস্কগুলিকে "ক্রিয়াকলাপগুলি" বলি।
ম্যালেট

আপনি যাকে টাস্ক বলছেন তা মূলত এমএসএফ অনুযায়ী এগিল 5.0 এর জন্য একটি ইস্যু
অসীম গাফফার

আপনি যদি এখানে এই বিবরণটি উল্লেখ করেন: এমএসডিএন.মাইক্রোসফটকম /en-us/library/dd997897.aspx - আপনি সেখানে এটি বর্ণিত হিসাবে এটি একটি সমস্যা বলতে পারেন, এটি আমার মনে হয় উপযুক্ত। সুতরাং এটি এটি আপনার বিকল্প নম্বর 3 করবে
ম্যালেট

2
পয়েন্ট 3 "এই কাজগুলি প্রকল্পের সময়কালের মধ্যে পপ-আপ করুন" এটি বিশেষভাবে গুরুত্বপূর্ণ। এগিল ইউনিফাইড প্রক্রিয়াটির একটি দুর্দান্ত চিত্র রয়েছে যা এটি দেখায়: i.stack.imgur.com/CUVFI.jpg । লক্ষ্য করুন যে তারা "পরিবেশ" শৃঙ্খলা আসলেই অদৃশ্য হয় না। এছাড়াও লক্ষ্য করুন যে পরিবেশের কাজগুলি বেশিরভাগ সামনে up সুতরাং যদি আপনি হঠাৎ করে দেখতে পান যে আপনি পরবর্তী পর্যায়ে প্রচুর পরিবেশের কাজ করছেন তবে কিছু ভুল হতে পারে।
মাইকেল 23

4

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

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

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

জ্ঞান হস্তান্তর আরেকটি চলমান প্রক্রিয়া যা সাধারণ বিকাশের গতির বাইরে পরিচালনা করা উচিত।


যখন আমি কাঠামোটি বললাম .. এটি জেএসএফ বা স্প্রিংয়ের জন্য যাওয়া উচিত ছিল .. বা যখন আমি হাতিয়ারটি বলেছিলাম .. এমন ছিল যেন আমরা জবস বা গ্লাসফিশের পক্ষে যাই ..
অসীম গাফফার

1
আমি জানি না আপনি কী বলতে চাইছেন "আপনি উন্নয়ন শুরু করার অনেক আগে" .. যখন প্রকল্প শুরু হয়, 1 প্রারম্ভিক ASAP স্প্রিন্ট করা উচিত নয় যেমন প্রকল্প শুরুর তারিখের 2 সপ্তাহের মধ্যে ... এবং স্প্রিন্ট 1 এ আসল কোডিং রয়েছে।
অসীম গাফফার

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

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

@ এস.লট এইচ এমএম আমি ভেবেছিলাম যে একজন জব-এ প্রয়োজনীয় দক্ষতা অর্জন করে অর্থাত্ প্রকল্পে কাজ করার সময় এবং স্প্রিন্ট ১-এর জন্য কোন শিখন-সরঞ্জামের পূর্বশর্ত নেই
অসীম গাফফার

2

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


1

একটি বিকল্প হ'ল তাদের প্রথম ব্যবহারকারীর গল্পের সমস্ত অংশ তৈরি করা উদাহরণস্বরূপ অ্যাপ্লিকেশনের জন্য হোমপেজ তৈরি করুন।

একটি ধারণা হিসাবে "ব্যবহারকারীর গল্প" বিরতি দেয়। কোন ব্যবহারকারী এর সাথে জড়িত? কোনটিই নয়। এটি এমন কাজ যা আপনার ইতিমধ্যে করা উচিত ছিল।

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

খারাপ না.

তৃতীয় বিকল্পটি হ'ল ব্যবহারকারীর গল্প না করে ইস্যুটির (যেমন উন্নয়নের পরিবেশটি এখনও নির্বাচিত হয়নি) অংশ হিসাবে তৈরি করা।

পরিকল্পনা এবং ওভারহেডগুলি যতটা স্পাইক হিসাবে স্পাইকের মতো প্রায়।

সেটআপ না একটি ব্যবহারকারী গল্প।

এটা কি তুমি উচিত জায়গায় করা আগে আপনি এমনকি এই প্রকল্পের শুরু করে।

আপনার কাঠামো / সরঞ্জাম এবং সার্ভার সেটআপ না থাকলে এবং যেতে প্রস্তুত না হলে আপনি প্রকল্পটি সত্যিই শুরু করতে পারবেন না।

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


ইস্যু স্পাইক হিসাবে একই নয় .. সাধারণ স্প্রিন্টে নির্ধারিত কাজের আইটেম হিসাবে ইস্যুটি ভাবেন তবে গল্পের পয়েন্ট নেই .. ইস্যুর উদাহরণ: এসভিএন নির্বাচন করা হয়নি। আমি এমএসএফ থেকে এগিল 5.0 এর জন্য
অসীম গাফফার

"সমস্যাটি স্পাইকের মতো নয়"। শব্দের সংজ্ঞা জন্য, আপনি সঠিক। কিন্তু আপনি যখন স্প্রিন্ট 1 এর আগে অতিরিক্ত কাজ করার পরিকল্পনা করার কথা ভাবেন, আপনি এটিকে কোনও সমস্যা বা স্পাইক বলছেন তাতে কিছু আসে যায় না। একটা তোল. একটি মুদ্রা শিরসঁচালন. নেতৃবৃন্দ।
এস .লট

আবার আমি স্প্রিন্ট 1 এর মধ্যে গল্পগুলির পাশাপাশি সময়সূচী ইস্যুটি বুঝিয়েছি - স্প্রিন্ট 1 এর আগে নয় So সুতরাং স্প্রিন্ট 1 এর জন্য বলতে পারি যে আমরা 2 ব্যবহারকারীর গল্প এবং 1 টি সমস্যা বেছে নিই। যদিও ইস্যুটির জন্য কোনও গল্পের পয়েন্ট নেই। স্পাইকটি স্প্রিন্ট 1 এর আগেই হবে ..
অসীম গাফফার

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

1

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

আমরা আর্কিটেকচারাল কাজের জন্য টাস্কটিও ব্যবহার করি যার "আপাত" ব্যবসায়িক মূল্য না থাকে তবে এটি পণ্যের মান বিশেষ করে একটি বৃহত কোড বেস সহ একটি বিদ্যমান পণ্যের জন্য যুক্ত করে for

এগুলি আপনার কাজের পরিবেশে প্রযোজ্য নয় তবে এটি আমাদের পক্ষে ভাল কাজ করেছে।


0

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

কাঠামোর পছন্দ, সংগ্রহস্থল এবং সার্ভার স্থাপন এবং অন্যান্য কার্যগুলি প্রাথমিক পুনরাবৃত্তির মধ্যে চলে যাওয়া উচিত।


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

@ আসিমগাফার যা প্রাথমিক পুনরাবৃত্তিতে করা যেতে পারে। ব্যবহারকারীর কাহিনী হিসাবে নয়, যেহেতু ব্যবহারকারীরা তাদের প্রয়োজনীয়তা মেটাতে কোন প্রযুক্তি ব্যবহার করেছেন তা জানার প্রয়োজন নেই (বা তাদের যত্ন নেওয়া উচিত নয়)।
BЈовић

0

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

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

স্প্রিন্ট 0 আপনার অন্যান্য স্প্রিন্টের সমান সময়ের দৈর্ঘ্য হিসাবে এটি নিশ্চিত করার একটি উপায় হিসাবে কাজ করে যে আপনি জিনিসগুলি সেট আপ করতে খুব বেশি সময় ব্যয় করবেন না কারণ সেগুলি পরে সর্বদা টুইট করা যায়। মূল বিষয় হ'ল নিজেকে এমন একটি রাজ্যে নিয়ে যাওয়া যেখানে আপনি প্রকৃতপক্ষে পণ্যটির বিকাশ শুরু করতে পারেন।


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

0

2-3 বিকল্প কাঠামো / সরঞ্জাম অন্বেষণ উপর

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

তারপরে আমরা প্রকল্পের জন্য কাঠামোটি শিখি

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

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

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

আপনি যদি এটি লঙ্ঘন করেন তবে তা আপনার গতিতে যেভাবেই দৃশ্যমান হবে কারণ আপনি পুনরাবৃত্তি প্রতি খুব কম পরিমাণে ব্যবসায়িক মান সরবরাহ করবেন। গ্রাহক কারণ সম্পর্কে সচেতন না হলে তিনি সম্ভবত এই প্রকল্পটি বাতিল করবেন।

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

সার্ভার সেট আপ করার সময় (এসভিএন, ডাটাবেসগুলি, ইত্যাদি)

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


আমরা পণ্য বিকাশে গ্রাহক প্রকল্প নয় :)।
অসীম গাফফার

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