কোনও স্ক্রুম প্রক্রিয়াতে বাগ ফিক্সিংয়ের সর্বোত্তম উপায়? [বন্ধ]


88

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

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

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


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

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

আমি প্রসঙ্গ-বহির্ভূত হিসাবে এই প্রশ্ন বন্ধ করার ভোট করছি কারণ এটি উপর জন্যে pm.stackexchange.com
Piran

উত্তর:


84

এটি একটি খুব ভাল প্রশ্ন এবং যখন এই সমস্যার বিভিন্ন পদ্ধতির বিষয়টি আসে তখন আমার কিছু পর্যবেক্ষণ থাকে।

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

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

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


আমার দল একই ধরণের সমাধান অনুসরণ করে।
ম্যাট বি

YouTrack # 3 কভার করে। এটি যতটা বেদনাদায়ক নয় ততক্ষণ মনে হচ্ছে যতক্ষণ আপনি বাগ বর্ণনা করেছেন যথাযথভাবে যথাযথ বিভাগে ত্রুটিযুক্ত হয়।
জোন

32

আসলে আমি মনে করি এই প্রশ্নটি থেকে জেপিয়ক দ্বারা সবচেয়ে ভাল উত্তর দেওয়া আপনি কী স্ক্রমের দিকে বাগ ফিক্সে ব্যয় হওয়া ঘন্টাগুলি গণনা করেন?

আমাকে এটি উদ্ধৃত করা যাক:

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

24

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

ইনভেন্টরি বর্জ্য waste বাগ ট্র্যাকিং ইনভেন্টরি। বাগ ট্র্যাকিংয়ের অপচয়।

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

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


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

6

কোনও তালিকার ত্রুটিগুলি ট্র্যাক করবেন না, তাদের সন্ধান করুন এবং তাদের ঠিক করুন - মেরি পপপেন্ডিক

আসলে, যদি পণ্যগুলি অপচয় হয় তবে ত্রুটিগুলির একটি তালিকা সম্পর্কে কী ...

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

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


+ 1.আমি বাগের সাথে বিবৃতি গল্পগুলি যাইহোক সম্পন্ন হয় না। সুতরাং আপনি যখন এমন কোনও বাগ খুঁজে পেয়েছেন যা নতুন নয় (এক বছরেরও বেশি সময় ধরে সেখানে রয়েছে), আপনি কি কোনও কোনও দেবকে বাগটি নির্ধারণ করেন এবং এটিকে সর্বোচ্চ অগ্রাধিকার দেন?
জেডহেরেন

2

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

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

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


1

আমাদের ক্ষেত্রে (গ্রিনফিল্ড ডেভলপমেন্ট, ২-৩ ডিভস) পাওয়া বাগগুলি লিখিত রয়েছে, একটি বাগ হিসাবে স্পষ্টভাবে চিহ্নিত করা হয়েছে এবং তাদের তীব্রতার উপর ভিত্তি করে তাদের পরবর্তী পুনরাবৃত্তির জন্য বরাদ্দ করা হয়েছে বা ব্যাকলগে রেখে দেওয়া হয়েছে। গুরুতর এবং জরুরি ত্রুটির ক্ষেত্রে সেগুলি চলমান পুনরাবৃত্তিতে যুক্ত হয়।


1

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

কেন?

সুতরাং আপনি যদি ত্রুটি অর্থাৎ ব্যাকলগ ইস্যু পিবিআইতে যেতে চান বা এই স্প্রিন্টে থেকে যান এবং বিতরণ করেন তবে আপনি একটি দল হিসাবে যুক্তিযুক্তভাবে আলোচনা এবং চিন্তাভাবনা করুন ...


0

উন্নততর প্রশ্ন হল আমি কীভাবে উন্নয়ন পর্যায়ে বাগ তৈরি বন্ধ করব? -> http://bit.ly/UoTa4n দেখুন

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

আসলেই কি চঞ্চল নয়?


4
লিঙ্কটি নষ্ট হয়ে গেছে।
আইন তোহভরি

0

আমি প্রতি তৃতীয় স্প্রিন্টে একটি সংক্ষিপ্ত বাগ ফিক্স স্প্রিন্ট প্রবর্তনের জন্য আমাদের প্রকল্পে এই ধারণাটি রেখেছি। আমাদের বর্তমান স্প্রিন্ট তিন সপ্তাহ হয়।

ধারণাটি হ'ল এটি সমস্ত দেবকে একসাথে বাগ ফিক্সিংয়ে ফোকাস করতে, নিয়মিত স্প্রিন্টে কেবল নতুন গল্পগুলিতে ফোকাস দেওয়ার অনুমতি দেয় এবং প্রযুক্তি debtণ হ্রাস করার জন্য নিয়মিত ফোকাস রাখে।

বাগ ফিক্সগুলি প্রাসঙ্গিক গল্পগুলিতে শ্রেণিবদ্ধ করা হবে এবং অগ্রাধিকার দেওয়া হবে। ত্রুটির প্রকৃতি বোঝার জন্য আটকে না গিয়ে আকারের বাগ ফিক্সের জন্য সংগ্রাম করা স্প্রিন্টের আগে মাপ দেওয়ার উপর জোর দেয় না।

কেউ কি এটি চেষ্টা করেছে বা কীভাবে তারা কীভাবে এটি কাজ করতে পারে বলে মতামত পেয়েছে?

চিয়ার্স, কেভিন।

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