স্ক্রাম - বিকাশকারীরা স্প্রিন্টের বাইরে কাজ করছেন


12

স্ক্রাম দল

  • 3 এক্স বিকাশকারী
  • 2 এক্স পরীক্ষক
  • 1 এক্স অটোমেশন টেস্ট বিশ্লেষক

আমরা কোনও মাল্টি-ফাংশনাল টিম নই যে বিকাশকারীরা পরীক্ষা করে না এবং পরীক্ষকরা বিকাশ করে না। আমি বিশ্বাস করি এটিই এই সমস্যার মূল কারণ।

আমরা বর্তমানে দুই সপ্তাহের স্প্রিন্ট করি do

স্প্রিন্টের শুরুতে সবাই ব্যস্ত, বিকাশকারীরা উন্নয়নের কাজ শুরু করে এবং পরীক্ষকরা তাদের পরীক্ষার প্রস্তুতি নিচ্ছেন (পরীক্ষার কেস লিখতে, ইত্যাদি) doing

পরীক্ষকগণ তাদের প্রস্তুতি শেষ করার পরে তারা এখন উন্নয়নের কাজ শেষ হওয়ার অপেক্ষায় আছেন বা বিকাশ কাজ শেষ হয়ে গেছে এবং বিকাশকারীরা প্রতিক্রিয়া / বাগের জন্য অপেক্ষা করছেন।

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

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

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

আমি সম্ভব হলে এটির সাথে অন্যান্য ব্যক্তির অভিজ্ঞতা জানতে চাই :)


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

... অথবা সম্ভবত আপনি আপনার স্প্রিন্টগুলিতে দু'সপ্তাহ ধরে থাকার জন্য যথেষ্ট পরিমাণে রাখছেন না।
blrfl

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

3
যে কাজটি প্রাথমিকভাবে একটি স্প্রিন্টের জন্য পরিকল্পনা করা হয়েছিল তা কি পর্যাপ্ত মানের সাথে শেষ হয়? অথবা আপনিও মূল পরিকল্পনার বাইরে অর্ধ-সমাপ্ত গল্প রেখে গেছেন?
বার্ট ভ্যান ইনজেন শেেনা

2
আপনি কেবল আপনার প্রক্রিয়াটি রাখতে পারেন তবে এটিকে 'স্ক্রাম' এর পরিবর্তে 'কানবান' বলে ডাকতে পারেন এবং তারপরে আপনার প্রক্রিয়াটি স্ক্রামের সাথে ঠিক আছে কিনা তা নিয়ে আপনাকে চিন্তার দরকার নেই। / কিছুটা ব্যঙ্গাত্মক, তবে সত্যই নয়
এরিক কিং

উত্তর:


16

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

প্রথমত আমি কয়েকটি বিষয় নোট করতে চাই যা আমি গুরুত্বপূর্ণ বলে মনে করি:

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

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

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

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

আমার জন্য যা খুব ভাল কাজ করেছে তা হ'ল এই দুটি সরঞ্জাম:

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

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

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


1
আপনার উত্তর করার জন্য আপনাকে ধন্যবাদ। আমি বিকাশকারী এবং কিউএ সংস্থানকে একসাথে যুক্ত করার ধারণাটি পছন্দ করি। আমি আমাদের পরবর্তী সভায় এটি প্রস্তাব করতে যাচ্ছি এবং আশা করি আমরা এটি পরবর্তী স্প্রিন্টে পরীক্ষা করতে পারি। আমি প্রশ্নটি আপডেট করব এবং আপনাকে জানাব যে এটি কীভাবে চলে!
এফএমএল

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

1
যদি এটি উপরে পরিষ্কার না হয় তবে "পরবর্তী উচ্চ-অগ্রাধিকারের কাজটি হবে" কিউএ ব্যাকলোগ হ্রাস করা যাতে আইটেমগুলি সরবরাহ করা যায় "ব্যাকলগ থেকে পরবর্তী উচ্চ-অগ্রাধিকার বিকাশের কাজ নয়
এডউইন বাক

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

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

2

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

আমরা বর্তমান স্প্রিন্টে সর্বদা পরবর্তী স্প্রিন্টের কাজগুলি বিকাশ করি

ওহো! এটি স্ক্র্যামে প্রযুক্তিগতভাবে সম্ভব নয়। আপনি জানেন না যে পরবর্তী স্প্রিন্টে ব্যাকলগ আইটেমগুলি কী হবে, এটি একটি স্প্রিন্ট পরিকল্পনা সেশনে পরবর্তী স্প্রিন্টের শুরুতে প্রতিষ্ঠিত হবে।

সংস্থাটি স্ক্রমকে নাশকতার জন্য উদ্ভাবিত নতুন সৃজনশীল উপায়গুলি সম্পর্কে জানতে আগ্রহী থেকে যায় remains


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

@ ডেভিড আরনো এটি দুর্দান্ত, আপনি মূলত বলছেন যে কোনও পদ্ধতিই সংজ্ঞায়িত নয় non এমনকি চটফটে ইশতেহারও। কেবল নিছক অনির্দেশ্য বিশৃঙ্খলা চঞ্চল হবে। তবে অপেক্ষা করুন .. কে বলছে আমাকে বিশৃঙ্খল হতে? এখন গুরুতর: দ্বিধা নিরসনের জন্য চতুর অ্যাডাজিয়াম "প্রক্রিয়াগুলির আগে লোক" রয়েছে। যদি কাউকে বাছাই করতে হয়, বিধিগুলি যা বলছে তা অগত্যা নয়, এমনটি করা উচিত যা বোঝায়। আমার কাছে মনে হয় ওপি'র দল কোনও সমস্যা ছাড়াই স্ক্রাম বইটি নিয়ে যেতে পারে। এবং সম্ভবত তারা তা করে, মূল প্রশ্নটি মনে হয় তারা কতটা স্বচ্ছ।
মার্টিন মাট

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

1

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

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

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

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


0

আমি মনে করি যে এখানে মূল সমস্যাটি হ'ল:

বেশিরভাগ বিকাশকারীদের মতামত রয়েছে যে পরীক্ষাগুলি তাদের নীচে রয়েছে

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

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

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

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


আমি বলব প্রোগ্রামাররা কোডটি পরীক্ষা করছে, তারা কেবল স্বয়ংক্রিয় পরীক্ষাগুলি তৈরি করে না। একটি বড় পার্থক্য আছে।
জেফো

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

0

তাত্ত্বিকভাবে একটি এসসিআরএম টিমের সমস্ত সদস্যের একই জ্ঞান থাকা উচিত, যাতে প্রতিটি সদস্য প্রতিটি সদস্যের কাছ থেকে প্রতিটি কাজ নিতে পারে। যদি তা না হয় তবে আপনার জ্ঞান ছড়িয়ে দেওয়া উচিত।

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

জ্ঞান ছড়িয়ে দেওয়া ম্যানেজমেন্টের চেয়ে বেশি সময় নিতে পারে।

আমার অভিজ্ঞতার সাথে আপনি বেশ কয়েকটি কাজ করতে পারেন:

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

এই পরামর্শগুলি 100% এসসিআরএম থিউরি নাও হতে পারে তবে প্রথমে আপনাকে উন্নয়নকে কাজ করতে হবে। এসসিআরুম কেবল একটি সরঞ্জামবাক্স।


0

এটি আপনাকে আপনার দলকে আলাদা করে আনা দরকার বলে মনে হচ্ছে। সে রকমই:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

আমি যদি বুঝতে পারি টেস্ট অটোমেশন ছেলেরা কয়েক দিন আগে শুরু করতে হবে।

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

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