বাগ ফিক্সিংয়ের কাজের জন্য স্টোরি পয়েন্টস: এটি স্ক্রামের জন্য উপযুক্ত?


50

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

স্টোরি পয়েন্টস ক্ষেত্রের প্রযোজ্য ইস্যুর ধরণের ক্ষেত্রে কি আমাদের বাগ ইস্যু টাইপ যুক্ত করা উচিত ? উপকারিতা কি কি? এটি কি স্ক্রামের জন্য উপযুক্ত হবে?


1
এফওয়াইআই, যদিও ডিফল্টর সাথে বাগগুলি চিহ্নিত করা যায় না, এটি জিরাতে পরিবর্তন করা যেতে পারে
two1ejack

উত্তর:


55

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

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

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

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

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


3
আমি একটি উত্তর লেখার মাঝামাঝি ছিলাম যা শেষ হয়ে গেল আপনার প্রায় অভিন্ন। আমি আপনার ব্যাখ্যা ভাল পছন্দ।
maple_shaft

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

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

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

19

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

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

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


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

19

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

বাগ ফিক্সিংয়ের গতিতে নেতিবাচক প্রভাব থাকতে হবে have অন্যথায় গুণমান ছাড়ার ফলে অব্যবহৃত বা এমনকি বর্ধিত বেগ দিয়ে পুরস্কৃত হওয়া শেষ হয়!

সম্ভবত একটি দরকারী লিঙ্ক:

http://www.infoq.com/news/2011/01/story-points-to-bugs


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

4
বেগ (স্প্রিন্টের প্রতি গল্পের পয়েন্টগুলিতে পরিমাপ করা হয়) পরিমাপ করে যে দল একটি স্প্রিন্টে কতগুলি স্টাফ প্রয়োগ করতে পারে। আমি নিশ্চিত যে প্রতিটি পণ্যের মালিক ট্র্যাক রাখে এবং আরও বেশি আগ্রহী যে দলটি কতটা ব্যবসায়িক মূল্য উত্পাদন করে। বাগ ফিক্সের স্টোর পয়েন্ট দেওয়ার মাধ্যমে ব্যবসায়ের মান স্ফীত হয় না।
বুহব

4
@ বিহব স্টোরি পয়েন্টগুলি ব্যবসায়ের মান সম্পর্কে কিছুই বলে না। একটি 5 দফা গল্পের 100 টি ব্যবসায়িক মান থাকতে পারে। 100 পয়েন্টের গল্পের 1 টি ব্যবসায়িক মান থাকতে পারে। এটি ব্যবসায়িক মূল্য নয়, প্রচেষ্টার প্রকাশ করে।
জোপ্পে

3
@ টুঙ্গানো: হুবহু এজন্য বাগ ফিক্সগুলিতে পয়েন্ট নির্ধারণ করা বগি সফ্টওয়্যার তৈরির জন্য শক্ত উত্সাহ দেয় না।
বুহব

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

8

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

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

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


5

গল্প অনুমান করা সময়ের সাথে সাথে একটি দল সেগুলি সমাধান করার অভিজ্ঞতা অর্জন করে ion এটির সাথে সঠিকতাটি উন্নত হয় এবং একটি দলের গতি পরিমাপ করতে বেগ প্রতিষ্ঠিত হতে পারে। ভবিষ্যতের স্প্রিন্টগুলির জন্য নির্ভরযোগ্য অগ্রগতি স্থাপনের জন্য একটি নিখুঁত পদ্ধতি।

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

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

আমাদের দলে আমরা বাগগুলি অনুমানের জন্য কিছু কৌশল নিয়ে পরীক্ষা করেছি:

  1. সম্পূর্ণ অজানা ত্রুটিগুলি অনুমান করা
  2. ইতিমধ্যে বিশ্লেষণ করা বাগগুলি কেবল অনুমান করা হচ্ছে
  3. বাগ ফিক্সিংয়ের জন্য সময় বরাদ্দ করা এবং ত্রুটিগুলি অনুমান করার জন্য নয়, কেবল ব্যবসায়িক মানের উপর ভিত্তি করে এগুলি র‌্যাঙ্ক করুন

১. সহ আমরা ভুলভাবে ব্যর্থ হয়েছি। বেশিরভাগ বাগের জন্য আমরা খুঁজে পেয়েছি যে 90% সময় বাগ বিশ্লেষণে ব্যয় করা হয়। এর পরে বাগ ফিক্সটি গল্পের মতোই অনুমান করা যায়। বাগগুলিকে একটি স্প্রিন্টে পরিকল্পনার মাধ্যমে আমরা ভুল করেছিলাম যে অজানা স্কোপটি গল্পের রেজোলিউশনটিকে এমন পর্যায়ে প্রভাবিত করেছিল যেখানে আমরা প্রায় প্রতিটি স্প্রিন্ট এইভাবে ব্যর্থ হয়েছিল।

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

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

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

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


4

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

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

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

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


3

কিছু কাজ অনুমানযোগ্য, কিছু হয় না। অনুমান করা যায় না এমন জিনিসের জন্য, একটি বাজেট ব্যবহার করুন।

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

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

একটি বাজেট তৈরির জন্য বাগ ফিক্সিংয়ের কাজগুলি বেশ কয়েকটি উপায়ে করা যেতে পারে। আমি কার্যকরভাবে ব্যবহার করেছি কিছু ধারণা এখানে:

  • বাগ ফিক্সিংয়ের জন্য কত সময় বাদ দিতে হবে তা বুঝতে সহায়তা করতে historicalতিহাসিক ডেটা (আগের পুনরাবৃত্তি থেকে বলুন) ব্যবহার করুন।
  • আপনার ব্যাকলগটিতে বাগফিক্সিংয়ের "ব্লক" রাখুন (5 পয়েন্ট বা 20 ঘন্টা বলুন) এবং গ্রাহককে গল্পের পরিবর্তে এটি চয়ন করতে দিন।
  • আপনার দলের প্রত্যেক সদস্যের প্রতিটি পুনরাবৃত্তি ফিক্সিং ত্রুটিগুলি নির্দিষ্ট সময়ের জন্য উত্সর্গ করা প্রয়োজন।

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

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

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


2

গল্প, বাগ এবং কাজ এবং প্রতিটি পয়েন্টের প্রতি দৃষ্টি নিবদ্ধ করার পরিবর্তে গ্রাহকের জন্য বৈশিষ্ট্য সরবরাহ করার দিকে মনোনিবেশ করা আমার পক্ষে ভাল find

গ্রাহকরা সফ্টওয়্যারটি কাজ করার প্রত্যাশা করে এবং কেবল এই বিকাশ, বর্ধন এবং নতুন বৈশিষ্ট্যগুলিকে ব্যবসায়ের দিকে এগিয়ে যাওয়ার পক্ষে সত্যিকারের মূল্য দেয়।

বাগ ফিক্সগুলি, তারা যতটা গুরুত্বপূর্ণ, ব্যবসাকে নতুন অঞ্চল এবং নতুন গ্রাহকদের দিকে চালিত করবেন না (স্পর্শকাতরভাবে এবং অবশেষে সম্ভবত হ্যাঁ তবে তাত্ক্ষণিকভাবে নয় যা ম্যানেজমেন্ট যা মাপছে তা হ'ল)।

সুতরাং পয়েন্টগুলি বেগের উচ্চতর দৃষ্টিভঙ্গি থেকে সবচেয়ে ভালভাবে দেখা হয় এবং একইভাবে রচিত গল্পগুলির জন্য প্রতি সপ্তাহে কত পয়েন্ট historতিহাসিকভাবে করা হয়েছে।

এটি এই সপ্তাহের গল্পগুলি সম্পূর্ণরূপে হওয়া এবং প্রায়শই যেগুলি তা নয় তা খুঁজে পাওয়ার জন্য জরুরি প্রয়োজনটিকে চাপ দেওয়ার চেয়ে ট্র্যাক রেকর্ড ইতিহাসের দ্বারা পরিচালিত হতে পারে to তবে আপ-ফ্রন্ট কন্ট্রোলের ক্ষতি এবং এটির যে বিশ্বাস বাড়িয়েছে তাতে কিছু পরিচালকের ভয়াবহতার জন্য দৌড়াদৌড়ি করবে।

আমি পাইভোটাল ট্র্যাকার ব্যবহার করি (আমি কেবল জিরা, ট্র্যাক, ট্রেলো এবং অন্যরাও করেছি) এবং পিভোটাল ট্র্যাকারও কাজ বা বাগের জন্য পয়েন্টগুলি করে না। এটি উপরের একই ভাল কারণে সম্পন্ন হয়েছে যা আপনি নিজেকে দেখছেন বলে এটি JIRA এও সত্য করে তোলে।

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