প্রক্রিয়া উন্নয়নের কাজে আমি কি "ব্যবহারকারীর গল্প" ব্যবহার করতে পারি?

Question

আমরা বর্তমানে আমাদের উন্নয়ন কাজগুলি ট্র্যাক করতে JIRA ব্যবহার করি। আমার পরিচালনা অ-সফ্টওয়্যার বিকাশ সম্পর্কিত কাজগুলি সহ সবকিছুকে "ব্যবহারকারীর গল্প" হিসাবে ফর্ম্যাট এবং শ্রেণিবদ্ধ করতে চায়। উদাহরণ স্বরূপ:

"একটি পরীক্ষা পরিচালক হিসাবে, আমি কি কেবলমাত্র স্বয়ংক্রিয় পরীক্ষার সাহায্যে অ্যাপ্লিকেশনটির পরীক্ষা করতে পারি এবং কোনও ম্যানুয়াল টেস্টিং করতে পারি যাতে আমি যতটা সম্ভব দক্ষতার সাথে অ্যাপ্লিকেশনটি পরীক্ষা করতে পারি?

গ্রহণের মানদণ্ড: 1. বিদ্যমান 50 টি ম্যানুয়াল টেস্টগুলিকে সম্পূর্ণ স্বয়ংক্রিয় পরীক্ষায় রূপান্তর করুন 2. টেস্টগুলি অবশ্যই 1 ঘন্টারও কম সময়ে সম্পাদন করতে হবে "

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

6/7/2011 আপডেট হয়েছে - "ব্যবহারকারীর গল্প" শব্দটিতে ফোকাস করতে পুনঃপ্রকাশিত প্রশ্ন।

Comments

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

— ড্যান সি

Answer 1

হ্যাঁ

যে কোনও স্টেকহোল্ডার, কোনও বৈশিষ্ট্য যা সিস্টেমকে উন্নত করে

[পিউরিস্ট ডাউনভোটগুলি শুরু করা যাক!]

Comments

+1 স্ট্যাকহোল্ডাররা, অর্থাৎ ডেভস, ম্যানেজার ইত্যাদির উপর কেবল স্পষ্ট হয়ে উঠুন [শিখা শুরু করা যাক!]

— মাইকেল কে

আমি একজন বিশুদ্ধবাদী, এবং আমি এই উত্তরটি অনুমোদন করি।

— টম অ্যান্ডারসন

আমি দ্বিমত পোষণ করি না তবে হ্রাস করব না কারণ আমি আপনার সাহসের প্রশংসা করি :)

— ম্যাপেল_শ্যাফট

একটি দীর্ঘ ঘূর্ণিত সংস্করণ দিতে যাচ্ছিল, কিন্তু এটি সব বলে! "রক্ষণাবেক্ষণকারী" এবং "3 বছরে এই জিনিসটিতে কাজ করা লোক" বিবেচনা করার জন্য বৈধ স্টেকহোল্ডার!

— আল বিগলান

Answer 2

"আমার ব্যবস্থাপনায় অ সফটওয়্যার বিকাশ সম্পর্কিত কাজগুলি সহ সমস্ত কিছুর জন্য Agile ব্যবহার করতে চায়।"

এর অর্থ প্রতিটি বৈশিষ্ট্যের জন্য ব্যবহারকারীর গল্প লেখা নয় ।

আপনি প্রতি বৈশিষ্ট্যের জন্য ব্যবহারকারী গল্প লিখতে চান, আপনি নও অগত্যা তত্পর হচ্ছে। আপনি কেবল প্রতিটি বৈশিষ্ট্যের জন্য ব্যবহারকারীর গল্প লিখছেন।

ব্যবহারকারীর গল্প!

ব্যবহারকারীর গল্পগুলি প্রয়োজনীয়তাগুলি সংগ্রহ এবং বোঝার একটি উপায়। আপনি চাইলে এগুলি নিখুঁত জলপ্রপাত উপায়ে ব্যবহার করা যেতে পারে। কিছু লোক এটি করে।

চতুরতা প্রকল্পগুলি পরিচালনা করার একটি উপায়। আপনি কোনও Agile প্রকল্পে ব্যবহারকারীর গল্পগুলি ব্যবহার করতে পারেন, বা না।

প্রযুক্তিগত debtণ এবং অভ্যন্তরীণ কাজগুলি পরিচালনা করতে ব্যবহারকারীর গল্পগুলি - আবার - চতুর হওয়ার সাথে কিছুই করার নেই।

খাঁটি অভ্যন্তরীণ, সীমাবদ্ধ-মান-যুক্ত, অ-স্টেকহোল্ডিং ব্যবহারকারীদের জন্য নকল "ব্যবহারকারীর গল্প" লেখার সময় নষ্ট না করে অনেক লোকেরা "প্রযুক্তিগত" বা "সহায়তা" বৈশিষ্ট্যগুলিকে পুরোপুরি খুশি করে।

কিউএ যদি তাদের গল্প না পায় তবে ব্যবসায়ের প্রকৃত ক্ষতি কতটা?

যদি প্রকৃত স্টেকহোল্ডাররা তাদের গল্প না পান তবে ব্যবসায়টি সত্যই ক্ষতিগ্রস্থ হয়।

Comments

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

— ড্যান সি

@ ড্যান সি: আমদানি হ'ল এটি। আপনার প্রশ্ন দুটি সম্পর্কিত নয় এমন ধারণাকে বিভ্রান্ত করে। আপনার প্রকৃত প্রশ্নের তুলনায় "পরিচালন চটজলদি ব্যবহার করতে চায়" সম্পূর্ণ বিভ্রান্তিকর। দয়া করে এটি পরিষ্কার করুন।

— এসলট

ভাল যুক্তি. আমি প্রশ্নটি পুনরায় চাপিয়ে দিয়েছি এবং আরও প্রসঙ্গ সরবরাহ করেছি।

— ড্যান সি

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

— এগিল

Answer 3

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

এই নোটটিতে, সফ্টওয়্যারটি হ'ল:

1. দ্বারা চিহ্নিত
2. Testable

প্রক্রিয়া উন্নতিগুলি খোলা সমাপ্ত এবং সাধারণত বিষয়গত।

গ্রহণের মানদণ্ড: ১. পরীক্ষার উন্নতি (এক্স / ওয়াই দ্বারা)

আপনি পরীক্ষার উন্নতি কীভাবে পরিমাপ করবেন? এর জন্য কোনও নির্দিষ্ট চুক্তি নেই।

এবং কোনও সম্পর্কযুক্ত নোটের উপর আমি দৃ H় আশা করি যে উপরে আপনার উদাহরণটি দেওয়া হয়েছে,

পরীক্ষার পরিচালক হিসাবে, আমি কি কেবলমাত্র স্বয়ংক্রিয় পরীক্ষার সাহায্যে অ্যাপ্লিকেশনটির পরীক্ষা করতে পারি এবং কোনও ম্যানুয়াল টেস্টিং করতে পারি যাতে আমি যতটা সম্ভব দক্ষতার সাথে অ্যাপ্লিকেশনটি পরীক্ষা করতে পারি?

... এটি কেবল একটি উদাহরণ, কারণ এটির সাথে এখানে এত বেশি ভুল রয়েছে যা আমি বর্ণনাও করতে পারি না।

Comments

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

— আল বিগলান

Answer 4

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

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

Answer 5

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

Answer 6

আপনি প্রকৃত ব্যবহারকারী গল্পগুলির সাথে মিশ্রণে অভ্যন্তরীণ "ব্যবহারকারীর গল্প" রাখলে আপনার গভীর সমস্যা রয়েছে issue

"স্টেকহোল্ডার" এর যত সংজ্ঞা আপনি খুঁজে পেতে পারেন তা আবার পড়ুন।

http://en.wikedia.org/wiki/Scrum_( উন্নতি )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

এগুলি খুব, খুব সাবধানে পড়ুন যাতে আপনি মুরগি এবং শূকরগুলির মধ্যে পার্থক্য দেখতে পান।

অভ্যন্তরীণ "ব্যবহারকারীর গল্প" মুরগী ​​দ্বারা রচিত।

আসল ব্যবহারকারীর গল্পগুলি শূকর দ্বারা রচিত।

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

আর্গুমেন্টের অস্পষ্ট প্রান্তে QA ইস্যু। কিউএ গুরুত্বপূর্ণ এবং এটি ছাড়া কিছুই কার্যকর হয় না।

এটি কিউএকে হঠাৎ করে শূকর তৈরি করে না। এটি তাদের এখনও একটি অংশীদার নয় makes তারা বাকী কাজের জন্য সহায়তা, অবকাঠামো এবং একটি প্রয়োজনীয় ভিত্তি সরবরাহ করে। তবে তারা "ব্যবহারকারীর গল্প" প্রকৃত ব্যবহারকারীর আসল ব্যবহারকারীর গল্প থেকে মূলত আলাদা।

যদি QA পরীক্ষার উন্নতি পরীক্ষা করে না দেখায়, কেউই ব্যবসায়ের বাইরে যায় না। অর্থ নষ্ট হয় না।

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

অভ্যন্তরীণ ("মুরগী") এবং আসল ("শূকর") অংশীদারদের একত্রিত করবেন না।

Answer 7

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

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

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