স্ক্রামের সাথে পেয়ার প্রোগ্রামিং


10

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

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

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

এটি দেওয়া, জুটি বাঁধার জন্য আমাদের উপযুক্ত সময় বরাদ্দ করেছে তা নিশ্চিত করার জন্য, জুটি বাঁধার দৃশ্যে প্রচেষ্টা / ঘন্টা / গল্পের পয়েন্টগুলির জন্য অ্যাকাউন্ট করার সর্বোত্তম উপায় কী?

বিবেচিত কিছু বিকল্পগুলি হ'ল:

  1. দু'জনকে প্রতিটি কাজের জন্য সাইন আপ করার অনুমতি দিন এবং (মোটামুটি) আনুমানিক ঘন্টা দ্বিগুণ করুন
  2. কেবলমাত্র "কীবোর্ডে হাত" দলের সদস্য প্রতিটি কাজের জন্য সাইন আপ করে, যা অনুমান করা হয় সেই ব্যক্তির আনুমানিক ঘন্টাগুলির ভিত্তিতে। এই দলে যে কেউ জুটি সমর্থন করছেন তারা জুটি সমর্থন করার সময় দেওয়ার জন্য স্প্রিন্টে কয়েকটি কম কাজের জন্য সাইন আপ করবেন।

উত্তর:


4

স্ক্রমের মধ্যে জোড় প্রোগ্রামিং নিযুক্ত করার সময় আমি সবচেয়ে সাধারণ বিকল্পটি বিকাশের অনুমানকে দ্বিগুণ করতে হয়।

অর্থাত্, যদি কোনও ব্যক্তির জন্য এই কার্যটি 3 ঘন্টা গ্রহণের অনুমান করা হয়, তবে এই জুটির জন্য বরাদ্দ সময়টি 6 ঘন্টা হবে।

পয়েন্টগুলির জন্য বিকল্প ঘন্টা যদি এটি আপনাকে আরও পরিচ্ছন্ন বোধ করে;)


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

15

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

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

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

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

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

এছাড়াও আরেকটি জিনিস যা আমার কাছ থেকে জঞ্জাল খুঁজে বের করে তা হ'ল কীভাবে লোকদের বলা হয় যে তাদের ক্ষমতা সর্বদা মোট ঘন্টাের 75%, তাই তারা যা প্রতিশ্রুতিবদ্ধ এবং তারপরে পুনরাবৃত্তির পুরো সময়কালে তারা অভিযোগ করে যে ক) তারা পারে না আপনাকে বা খ) তারা সঠিক কাজটি করতে পারে না কারণ তাদের অনেক বেশি সময় বরাদ্দ করা হয়েছে। লোককে কত ঘন্টা কমিট করতে হবে তা বলা উচিত নয় এবং যদি স্ক্রাম মাস্টার এই জাতীয় কিছু টানতে চেষ্টা করে তবে তাদের অবশ্যই পিছনে ঠেলা উচিত! প্রত্যেকেরই ঠিক তারা যেটাতে স্বাচ্ছন্দ্য বোধ করে তার প্রতিশ্রুতিবদ্ধ হওয়া উচিত। উদাহরণস্বরূপ, আমি একটি দল নেতৃত্ব এবং প্রায়শই আমি এলোপাতাড়ি অপরিকল্পিত ডিজাইন আলোচনার মাধ্যমে, বা কোড সহ কাউকে সহায়তা করা বা অদ্ভুত জিনিসগুলির সমস্যা সমাধানের মাধ্যমে শেষ করতাম, তাই আমার ক্ষমতা কখনই ৫০% এর উপরে হয় না।

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

আপডেট 1: ক্লিফের মন্তব্যের প্রতিক্রিয়া ভাল আপনি আপনার কানটি অফার করেছেন তাই এখানে ...

আপনি ঠিক বলেছেন, সাংস্কৃতিক শিফটটি মূল, তবে এই শিফটটি নির্বাহী পর্যায়ে হওয়ার দরকার নেই। আপনার নিজস্ব গ্রুপ ম্যানেজার আপনার দলের মধ্যে সংস্কৃতি পরিবর্তন করতে পারে এবং আপনাকে কর্পোরেট বিএস থেকে ছেলেরা আলাদা করতে পারে যা তাকে মোকাবেলা করতে হবে। আপনি যেটি বর্ণনা করছেন তা হ'ল 2007 থেকে 2010 সাল অবধি আমাদের সম্পর্কে release রিলিজের পরে আমাদের দল (এবং অন্যান্য দলগুলিও) ফ্লপ হয়েছে। পরিচালনার "চৌকস হওয়ার প্রক্রিয়া" ব্যবহার করে একটি রিলিজে আমরা 9 ​​জন লোককে এমন কাজ তৈরি করতে পরিচালিত করি যা সাধারণত একজন ব্যক্তির দ্বারা সম্পন্ন হয় এবং এটি আমাদের দ্বিগুণ সময় নিয়েছিল। আমার এত ফ্রি সময় ছিল, আমি এমনকি আমার জীবনবৃত্তিকে আপডেট করেছিলাম।

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

সুতরাং গত 12 মাসে আমরা এত "বোকা" মুছে ফেলেছি এটি মজারও নয়। আমাদের স্থিতি মিটিংগুলি আসলে এখন বোধগম্য কারণ আমরা একসাথে কাজ করি না, বিচ্ছিন্ন হয়ে নয়। আমাদের এখনও পণ্যটির নির্দিষ্ট অংশগুলির মালিকানা রয়েছে (কমপক্ষে এখনকার জন্য) তবে আমরা একে অপরের কোডেও খুব ঘন ঘন অতিক্রম করি। আমরা ক্রমাগত কোড পর্যালোচনা করি যাতে কেবল দলের সদস্যরা অন্যান্য কোড শিখেন না, তবে তারা আরও ভাল কোডিং এবং ডিজাইনের কৌশলগুলিও শিখতে পারেন। আমরা একচেটিয়া, দৈত্য "চৌকস" টিমকে 3 টি আলাদা দলে ভেঙে ফেলেছি তাই পরিকল্পনা এবং অন্যান্য সভাগুলি অনেক খাটো হয় এবং লোকেরা আসলে তাদের যত্ন নেয় কারণ তারা আশেপাশে বসে না এবং এমন জিনিস শুনে না যা তারা যত্ন করে না। আমি ' রাতে দেখেছি যখন আমাদের 5 জনের মধ্যে 4 জন (দলের মধ্যে একটি) রাত 11 টা 11 মিনিটে অনলাইনে আসত এবং কেউই আসলে আমাদের বলেনি যে আমাদের কঠোর পরিশ্রম করতে হবে বা 40 ঘন্টারও বেশি সময় ধরে কাজ করার জন্য আমাদের উপর চাপ দেওয়া হয়েছিল। যে লোকেরা অর্ধ বছর আগে কম যত্ন নিতে পারেননি, হঠাৎ করে তারা যা করছেন তা নিয়ে ব্যস্ত এবং উত্তেজিত। এবং আমাদের ব্যবস্থাপককে যা করার দরকার তা হ'ল "আপনি ছেলেরা ঠিক কি ঠিক করবেন এবং আপনার যা করা দরকার তা করুন এবং আমি কর্পোরেট বিএসকে যতটা পারি দল থেকে বাইরে রাখব।"

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

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

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


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

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

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

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

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

2

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

থেকে স্ক্রাম গাইড :

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


1
মজাদার. আমার কাছে মার্চ ২০০৯ এর স্ক্র্যাম গাইড রয়েছে এবং তারা আসলে সেই উক্তিটি পরিবর্তন করেছে। এটি ব্যবহৃত হত: " স্প্রিন্ট পরিকল্পনার মিটিং চলাকালীন বা স্প্রিন্ট চলাকালীন সময়ে-সময়ে স্প্রিন্ট ব্যাকলগে কাজ নির্ধারণ ও সম্পাদনের জন্য দলটি স্ব-সংগঠিত করে ।"
ক্লিফ

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

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

0

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

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

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

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

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

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

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

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

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