একটি স্প্রিন্টে জুজু পরিকল্পনা করার উদ্দেশ্য কী?


15

আমাদের ব্যবসায় বিশ্লেষক এবং প্রকল্পের শীর্ষস্থানগুলি আমাদের ক্লায়েন্টের স্টোরিস হিসাবে প্রয়োজনীয়তা বলে। প্রতিটি স্প্রিন্ট পরিকল্পনা, আমাদের (বিকাশকারীদের) পরিকল্পনা পোকার খেলতে বলা হয়।

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

তবে তারা (ব্যবসায়িক বিশ্লেষক ও প্রকল্পের নেতৃত্ব) আসলে 'প্রয়োজনীয়তা বোঝা' এবং 'কার্ড বাড়ানো' বলতে কী বোঝায়?

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

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


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

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

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

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

1
পরিকল্পনার জুজু অন্যের অনুমান শোনার আগে সবার কাছ থেকে অনুমান পাওয়া।
থরবজর্ন রাভন অ্যান্ডারসন

উত্তর:


20

প্রকল্প পরিচালকের দৃষ্টিভঙ্গি বিবেচনা করুন

জটিলতার জন্য জিজ্ঞাসা করে তারা এমন একটি সংখ্যা চায় যা তারা আপনার পরবর্তী স্প্রিন্টের সাথে একটি দল হিসাবে আপনার বেগ খুঁজে পেতে তুলনা করতে পারে। সমস্ত গল্প কখন করা হবে সে সম্পর্কে একটি অতিরিক্ত অনুমান দেওয়ার জন্য তারা অন্যান্য দলের অনুমানের সাথে আপনার ফলাফলকে একত্রিত করার জন্য এটি ব্যবহার করার চেষ্টা করতে পারে।

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

সংখ্যার চেয়ে আলোচনা বেশি গুরুত্বপূর্ণ

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

জটিলতা বনাম প্রচেষ্টা

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

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

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

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

কারণ আপনি কোনও অনুমান দিতে পারবেন না

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

  1. গল্পটি অনেক বড়। এটিকে ছোট এবং আরও নির্দিষ্ট ব্যবহারকারীর কাহিনী হিসাবে বিভক্ত করুন। মনে রাখবেন যে প্রতিটি ব্যবহারকারীর গল্পটি ব্যবহারকারীকে এক টুকরো মূল্য সরবরাহ করা উচিত; ইনপুট - প্রক্রিয়া - আউটপুট = মান।
  2. তারা সমস্যা ডোমেনটি এতক্ষণ বুঝতে পারে না যে এটি কতক্ষণ লাগবে বা এমনকি সমস্ত প্রশ্ন সঠিকভাবে জিজ্ঞাসা করতে পারবে তা বলতে সক্ষম হবেন। এমন ব্যক্তিদের সাথে কথা বলুন যারা স্টেকহোল্ডারদের ডোমেন / প্রোগ্রামিং সম্পর্কে আরও বেশি জানেন সেই ধরণের অ্যাপ্লিকেশন, যা যা তা আপনি আগে দেখেন নি। যদি এটি সম্ভব না হয় বা আপনি সেখানে পুরোপুরি না পান তবে আপনি ডিজাইনের স্পাইক ব্যবহার করতে পারেন। যান এবং কোনও সমাধান প্রোটোটাইপ করুন তবে কেবলমাত্র সীমিত এবং নির্দিষ্ট সময়ের জন্য। প্রোটোটাইপিং পর্যায়ে কত দিন চলবে তা নির্ধারণ করুন, খুব বেশি দীর্ঘ নয় এবং তারপরে আপনার নতুন বোঝাপড়াটি ভাগ করে নেওয়ার জন্য আবার ফিরে দেখা করুন meet
  3. আপনার স্টেকহোল্ডারদের যথেষ্ট নির্দিষ্ট করা হচ্ছে না। "আমাকে একটি মেঘ তৈরি করুন" কোনও গ্রহণযোগ্য ব্যবহারকারীর গল্প নয়। "আমাকে এমন একটি সিস্টেম তৈরি করুন যেখানে আমি ভিএমএসগুলিকে চাহিদার ভিত্তিতে স্পিন করতে পারি" এটি আরও ভালভাবে ভেঙে যাওয়ার পরে আরও ভাল তবে এটি এখনও এমন পর্যায়ে নেই যেখানে এটি আপনাকে কতটা সময় নেবে সে সম্পর্কে একটি সঠিক অনুমান দিতে পারেন যেখানে একশটি লুকানো থাকবে এই বিবৃতিতে অনুমান যে আপনার স্টেকহোল্ডারের রয়েছে যে আপনি তাদের কিছু না দেখানো পর্যন্ত আপনি তা খুঁজে পাবেন না।
  4. অবশেষে, আপনি যদি কোনও অনুমান দিতে পারেন তবে এটি সম্ভবত প্রথমবারেই ভুল হবে। প্রাক্কলন করা একটি কঠিন সমস্যা এবং কঠিন সমস্যাগুলি সমাধান করার সবচেয়ে ভাল উপায় হ'ল বৈজ্ঞানিক পদ্ধতিটি ব্যবহার করা। প্রতিটি দলের সদস্য অনুমান করেন যে সংখ্যার উপর ডেটা সংগ্রহ করুন, তারপরে এটি কতটা সময় নিয়েছে বা কীভাবে 'জটিল' হয়েছিল তা ডেটা সংগ্রহ করুন, যদিও এটি আরও কঠোর এবং তারপরে সময়ের সাথে এগুলি তুলনা করুন। পরিণামে আপনি কে বেশি মূল্যায়ন করেন এবং কারা অবমূল্যায়ন করেন সে সম্পর্কে আপনার একটি অনুভূতি পাওয়া যাবে এবং তারপরে আপনার এটি দলের সাথে ভাগ করা উচিত। লোকেরা একে অপরকে অনুমানের ক্ষেত্রে আরও উন্নত হতে সহায়তা করতে পারে। এই সংখ্যাগুলি আপনার ট্র্যাকিং সরঞ্জামে ফিরিয়ে দেওয়া যেতে পারে যাতে গল্পগুলি আরও কত সময় নেবে তা আরও ভালভাবে অনুমান করতে সহায়তা করে।

উপসংহার

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

সতর্কতা

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

সরাইয়া

সংখ্যার প্ল্যানিং পোকার সেটটি সাধারণত বিতরণ করা হয় যে সংখ্যার মধ্যে ফাঁকগুলি আরও বাড়তে থাকে। আমি বিশ্বাস করি যে এটি ব্যবহারকারীর গল্পটি 16 বা 17 এর কিনা তা নিয়ে বিতর্ক করা থেকে নিরুৎসাহিত করার উদ্দেশ্যে, যদি এটি 13 এর চেয়ে বড় হয় তবে কেবল এটি 20 করুন।

উদাহরণ

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


9

আমি মনে করি ফ্র্যাঙ্ক এবং এনকায়েটের উত্তরগুলি এটিকে অনেক বেশি কভার করে তবে এখানে আরও কিছু বিষয় বিবেচনা করতে হবে:

গল্পের পয়েন্টগুলি কেন ব্যবহার করুন

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

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

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

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

তারপরে আপনি একটি দল হিসাবে সম্মত হন যে এই স্প্রিন্টের জন্য আপনি 13 দফা গল্প, একটি 8 পয়েন্টের গল্প এবং 1 পয়েন্ট ইউআরএল পরিবর্তনটি ইতিমধ্যে চিহ্নিত করেছেন done সুতরাং মোট 22 পয়েন্ট। পরবর্তী স্প্রিন্টে আপনি 27 পয়েন্ট পেয়েছেন, নীচের স্প্রিন্টটিতে আপনি 18 পয়েন্ট পেয়েছেন। 3 স্প্রিন্টের পরে আপনি আপনার বেগের উপর কিছুটা আস্থা অর্জন করতে শুরু করতে পারেন (বেগটি আপনার স্প্রিন্টে আপনার দল কাজ করতে পারে তার পরিমাণ) is বেগ পেতে পূর্ববর্তী স্প্রিন্টের গড় ধরুন। সুতরাং এই উদাহরণে গড় (22 + 27 + 18) / 3 = 22.3 সুতরাং এটি 21 এর কাছাকাছি ফাইবো স্কেলের নিকটতম দিকে গোল করে নিন।

এখন পরবর্তী স্প্রিন্টের জন্য কেবল 21 পয়েন্ট সম্পন্ন করার লক্ষ্য।

আপনার গল্পের পয়েন্টটি ঠিক সঠিকভাবে অনুমান করার জন্য স্তব্ধ হবেন না - এটি কোনও সঠিক বিজ্ঞান নয়। আপনি জানেন যে একটি ইউআরএল পরিবর্তন একত্রিত ডেটার চেয়ে অনেক কম জটিল তাই কেবল এটি অনুসারে স্কোর করুন।

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

পুরো দলের অনুমান

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

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

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

কাজের সময় নির্ণয়

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

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

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

আমি বিকাশকারীদের জিজ্ঞাসা করেছি যে পরিকল্পনা করার জন্য আমরা কার্যগুলির জন্য সময় নির্ণয় করি তবে আমি আসলে এই পদ্ধতির সাথে একমত নই (বাস্তবে আমি এই পদ্ধতির সাথে দৃ strongly়ভাবে একমত নই) কারণ এটি সঠিক নয় যেমন এটি আমার 4 ঘন্টা কী সময় লাগবে তার অর্থ হল: কোনও দেব নিজের হাতে টাস্কের সময়টিই কেবল অন্তর্ভুক্ত করতে পারেন, অন্য কেউ চা কাপ তৈরির জন্য সময় যোগ করতে পারে!

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

অনুমান সবচেয়ে বড় সমস্যা নয়

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


জটিলতাগুলির মতো শব্দগুলি একটি আপেক্ষিক পরিমাপের এক ধরণের যা একটি ধারণা দিতে চলেছে যে আমাদের কতটা প্রচেষ্টা করা উচিত। তাই না?
জুড নিরোশন

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

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

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

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

8

পরিকল্পনা উইকিপিডিয়া বেশ ভাল ব্যাখ্যা । আপনার কেসটিতে ফোকাস দিয়ে সেখানে কী কী অবস্থা রয়েছে তা সম্পর্কে আমাকে আবারও বলি:

কেন জুজু পরিকল্পনা?

প্রথমত, আপনারা সবাই বোর্ডে থাকা উচিত যে আপনি কেন একটি "সাধারণ" অনুমানের বিরোধী হিসাবে পরিকল্পনা পোকার করছেন। কারণটি আসলে বেশ সহজ: কোনও কাজের জন্য সময় অনুমান করার সময় আমরা সকলেই বড় সময় স্তন্যপান করি । খুব সুন্দর প্রতিটি গবেষণায় প্রকাশিত হয়েছে যে, মানুষের মস্তিষ্ক যে কোনও যুক্তিসঙ্গত পরিমাণ সময় নেয় তা অনুমান করার জন্য কেবল অক্ষম। (এছাড়াও একটি কারণ, কেন যে টিকিটগুলি তাদের অনুমানের ২-৩ দিনের বেশি পরে যায় তার অনুমানের দিক থেকে এটি বেশ মূল্যহীন))

চেষ্টা না করে জটিলতা কেন?

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

কেন কার্ড গোপন?

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

ফাইবোনাচি সংখ্যা কেন?

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

কেন এই কাজ করে?

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

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

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

উদাহরণ

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

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


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

1
অ্যায় .. আবার কাছ থেকে পড়ুন। পরিকল্পনা জুজু সময় অনুমান করে না।
ফ্রাঙ্ক

3

আমার দলে কয়েক ডজন পুনরাবৃত্তির পরে, আমরা আবিষ্কার করেছি যে গল্পের পয়েন্টগুলি বেশিরভাগ মাঝারি-মেয়াদী প্রকল্পের স্টিয়ারিং সম্পর্কে। তারা পণ্য মালিককে নিজেকে 2 বা 3 টি স্প্রিন্ট প্রজেক্ট করার অনুমতি দেয় এবং একটি গড় গতিবেগের ভিত্তিতে মূলত একটি রিলিজ সম্পর্কে ব্যবসায় এবং সুযোগের সিদ্ধান্ত নিতে পারে।

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

এটি মাইক কোহনের তৈরি একটি পয়েন্টের সাথে এখানে সম্মত ।

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


3

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

ফলস্বরূপ, এটি একটি "সময়ের ভিত্তিতে নয়" যা "সময়ের ভিত্তিতে"। এতে অবাক হওয়ার কিছু নেই যে সবাই বিভ্রান্ত হয়ে পড়ে।

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

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


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

1
আমার অভিজ্ঞতায় স্প্রিন্ট পরিকল্পনার সভাগুলি কিছু সময়ের জন্য চলতে থাকে, এবং গল্পগুলি আলোচনা করার সময় এটি একটি ভাল জিনিস এটির সামনে যা করার দরকার হয় না, এটি ক্রমাগত আরও ভাল করা হয়।
gbjbaanb

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

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

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

0

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

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