একাধিক স্ক্র্যাম দল একক ব্যাকলগে চলেছে


9

আমাদের কাছে বর্তমানে 5 টি স্ক্র্যাম দল রয়েছে যা গত বছরের জন্য তাদের নিজস্ব পণ্য ব্যাকলগ বন্ধ করে দেয়। প্রতিটি দল তাদের নিজস্ব ডেডিকেটেড সিস্টেমে কাজ করে তবে অন্তর্নিহিত প্রযুক্তি একই N নেট।

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

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

আমার প্রশ্নটি হল, আপনি কি দুটি বা আরও বেশি সিস্টেমের জন্য একক ব্যাকলগে যাওয়ার অভিজ্ঞতা অর্জন করেছেন? আপনার চ্যালেঞ্জ কি ছিল? এটি কাজ করার জন্য আপনার কী করার দরকার ছিল?


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

আপনি কি এই 2 টি দলকে একটি বৃহত্তর একটিতে বিভিন্ন পণ্যগুলিতে কাজ করার জন্য একক ব্যাকলগে মার্জ করছেন?
আইওনিস টিজিকাস

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

1
@ আইওনিসটিজিকাস - উভয় দলই একই থাকবে না। দলগুলিকে একীভূত করা তাদের আরও বড় করে তুলবে। সিনিয়র ম্যানেজমেন্ট ব্যাকলগগুলিকে একটিতে একত্রিত করতে চায় এবং উভয় দল বিকাশকারীদের ক্রস-স্কিলিং করার সময় একই ব্যাকলগটি বন্ধ করতে চায়।
ম্যালকম

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

উত্তর:


8

আমরা একটি একক ব্যাকলগ ব্যবহার করে প্রায় অর্ধ ডজন প্রকল্প পরিচালনা করি। আমি "সম্পর্কে" বলি কারণ এটি নির্ভর করে যে আপনি কীভাবে পৃথক প্রকল্পগুলি চান।

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

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

জিনিসগুলিকে সংগঠিত রাখা একটি বাস্তব ব্যথা হতে পারে, তাই এখানে কিছু বিষয় বিবেচনা করতে চাই যা এখানে রয়েছে।

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

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

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

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

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

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

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

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

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

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

  • গবেষণা ও উন্নয়ন প্রকল্পগুলির জন্য উত্সর্গের সময় অন্যথায় ফাটলগুলি কাটানো তাদের পক্ষে খুব সহজ এবং আপনি এই ক্ষেত্রগুলিতে বিনিয়োগের সুযোগ হারাবেন।

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

  • জড়িত দলগুলি একই কোডিং কনভেনশন এবং শৈলী ব্যবহার করছে তা নিশ্চিত করুন। আপনার একীকরণের প্রয়াসকে ধ্বংস করতে এখানে অসামঞ্জস্যতার মতো কিছুই নেই।

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


I can't speak to the effects on metrics like velocity or overall commitment and burndown rates. Those aspects just haven't been important enough for us to follow closely.- তাহলে আপনি কীভাবে জানবেন যে একটি স্প্রিন্টে কতটা ফিট হবে? বেশিরভাগ অজ্ঞান থাকলেও অবশ্যই কিছু চলছে।
ইজকাটা

2

সঠিক স্ক্রামের উত্তরটি "দল (গুলি) জিজ্ঞাসা করুন"। এটি স্ব-প্রতিষ্ঠানের নীতি যেখানে কাজটি দ্রুত করার জন্য তাদের পুনর্গঠন করতে সক্ষম হওয়া উচিত। আপনি দেখেন যে দলের মধ্যে অনেক লোকের বহিরাগতের চেয়ে প্রসঙ্গের জ্ঞান রয়েছে এবং তারা জানেন যে সবচেয়ে ভাল। এটিতে পণ্যের মালিকও অন্তর্ভুক্ত রয়েছে।

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

পণ্য মালিক

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

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

পণ্য বিকাশ বনাম রক্ষণাবেক্ষণ

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

প্রজেক্ট দলগুলির একবারে প্রসঙ্গের স্যুইচিং এবং প্রসবকে হ্রাস করতে একবারে একটি পণ্যতে ফোকাস করা উচিত। প্রসঙ্গের স্যুইচিংয়ের ফলে কিছুটা প্রযুক্তিগত debtণ নিয়ে অনেকগুলি মাঝারি পণ্য সরবরাহ করা যেতে পারে।

প্রসঙ্গ স্যুইচিং

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

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

ঝুঁকি

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

উদাহরণ

  • একটি হাস্যকর সময়ে রাজি। বরং বলুন যে কাজটি সঠিকভাবে করতে এবং ব্যবসায়কে সময় সমস্যা পরিচালিত করতে কী প্রচেষ্টা নিচ্ছে

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

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

পেশাদারি

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

পরিদর্শন এবং অভিযোজিত

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

শেষের সারি

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

চুক্তি

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

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


1

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

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

পরিবর্তে, উভয় দলই ঠিক আগে কী কাজ করছিল তা নিয়ে কাজ শুরু করে; পার্থক্য হ'ল সবকিছু একই ব্যাকলগে।

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

আপনি যদি সমস্ত লার্নিং আপ-ফ্রন্ট করেন তবে উল্লেখযোগ্য পারফরম্যান্সের জরিমানা হবে। সিনিয়র ম্যানেজমেন্টের কেউ অবশ্যই লক্ষ্য করবেন এবং আপনি নতুন দলের খারাপ পারফরম্যান্সের জন্য ক্ষতিপূরণ দিতে পারে এই আশায় অন্য দলের ব্যাকলগ শোষিত করতে বাধ্য হবেন ... :) রসিকতা বাদ দেওয়া, তবে এটি আমার প্রস্তাবনা।


1

আমি ধরে নিচ্ছি যে আপনি (বা পরিচালনা) দুটি দলের জন্য একীভূত ব্যাকলগ তৈরি করতে চাইছেন তা হ'ল আপনি সিস্টেমের মধ্যে একটির জন্য কেবল ব্যাকলগ আইটেম বেছে নিতে সক্ষম হতে চান এবং উভয় দলই তাদের উপর কাজ করতে চায়।

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

সুতরাং, এটিকে সফল করার একমাত্র উপায় হ'ল দুটি দলকে ভেঙে দুটি মিশ্র দলে পরিণত করা। তারপরেই, এমন একটি সুযোগ রয়েছে যে আপনি (বর্তমানে) "গুরুত্বপূর্ণ" সিস্টেমে সমস্ত বিকাশকারীকে দ্রুত গতিতে পাবেন।


0

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

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

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

এমনকি যদি তারা তাদের প্রকল্পে অলস হয়ে থাকে তবে তারা প্রকল্প থেকে প্রজেক্টে ঝাঁপিয়ে পড়ার চেয়ে তারা যেগুলির সাথে পরিচিত তারা অনেক বেশি উত্পাদনশীল।

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