বিকাশকারীদের মধ্যে কাজের ভাগ করার সর্বোত্তম উপায় কী

Question

আমার দল এবং আমি প্রায় দশ বছর আগে আমাদের বিকাশিত একটি সাইটটি পুনর্নির্মাণ করছি এবং আমরা এগিলিতে এটি করতে চাই।

সুতরাং আমি পড়াতে প্রচুর সময় ব্যয় করার পরে (সম্ভবত যথেষ্ট নয়) বিকাশকারীদের মধ্যে কীভাবে কাজ ভাগ করা যায় তা নিয়ে আমার সমস্যা হচ্ছে।

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

বিকাশকারীদের মধ্যে কাজের ভাগ করার সর্বোত্তম / সর্বাধিক গ্রহণযোগ্য উপায় কী?

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

অথবা হতে পারে সম্পূর্ণ ভিন্ন কিছু?

Comments

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

আপনি যদি এই প্রশ্নের একটি সাধারণ উত্তর খুঁজে পেতে পারেন তবে অভিনন্দন, আপনি এটি পেয়েছেন। আপনার বয়স 40 বছর নাগাদ আপনি অবসর নিতে পারেন এবং তারা সম্ভবত আপনার পরে একটি কম্পিউটার বিজ্ঞানের পুরষ্কারের নামকরণ করবেন। ;)

— গর্ডনএম

Answer 1

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

• মডিউল প্রতি বিকাশকারী বিকাশকারী:

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

• প্রত্যেকে একই সময়ে একই মডিউলে কাজ করে

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

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

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

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

যদি আপনার দলের সদস্যরা কিছু বিচ্ছিন্নভাবে কাজ করতে পছন্দ করেন তবে তাদের (একটি মাত্রায়) আসুন। যদি তারা জোড়ায় কাজ করতে পছন্দ করে তবে তাদের এটি করতে দিন। আপনার লোকেদের যতটা সম্ভব নিজের কাজ তাদের বেছে নিতে দিন তা নিশ্চিত করুন।

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

Comments

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

— আমির

Answer 2

দলের সাথে একটি সভা করুন, তাদের করণীয় তালিকাটি দেখান এবং কে কী করতে চান তা জিজ্ঞাসা করুন।

Comments

অন্য একটি উপায় রাখুন, এবং এই উত্তরটি পুরোপুরি গুঞ্জন-শৃঙ্খলাবদ্ধ করতে, দলগুলিকে স্ব-সংগঠিত করা উচিত ।

— ব্রায়ান ওকলি

Answer 3

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

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

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

Comments

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

— DXM

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

— ডিএক্সএম

Answer 4

যদিও আমি ডেভিডের উত্তরের সাথে একমত নই, তবে আমি অনুভব করেছি যে এটি কিছু বিবরণ দিয়ে লাভ করতে পারে:

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

মূলত, নীচের লাইনটি হ'ল: এখানে এসই তে কেউ আপনার পক্ষে এই প্রশ্নের উত্তর দিতে পারে না, বা এর পক্ষে কোনও বক্তব্যও পাওয়া যায় না, কারণ আপনি দল হিসাবে কোনও উত্তর নিয়ে আসলে এটি আরও ভাল।

Comments

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

— এস রবিনস

Answer 5

সবচেয়ে সহজ পদ্ধতির প্রায়শই সেরা।

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

এই একই ধরণের দ্বিধাদ্বন্দ্বের মুখোমুখি হয়ে গেলে, আমি নিম্নলিখিত পদ্ধতিটি ব্যবহার করেছি:

• প্রকল্পের সুযোগ। আপনি নিজেকে কী মধ্যে নিয়ে যাচ্ছেন সে সম্পর্কে নিজেকে ধারণা দিন এবং এই প্রকল্পটিকে একাধিক কার্যের মধ্যে ভেঙে ফিচারগুলির একটি তালিকা বিকাশ করুন।

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

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

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

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

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

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

Answer 6

ডা। ফ্রেড ব্রুকসের সার্জিক্যাল টিমের কথা উল্লেখ না করে কোনও বিকাশকারী দলের সাংগঠনিক আলোচনা সম্পূর্ণ হবে না ।

মূল সূত্রটি হ'ল: কাজের ইউনিট প্রতি একটি সার্জিক্যাল টিম

একটি সার্জিকাল দল সংজ্ঞায়িত করা হচ্ছে

সার্জিকাল টিমের ধারণাটি দুটি মৌলিক ধারণার উপর ভিত্তি করে:

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

একটি অস্ত্রোপচার দল 3-10 বিকাশকারী নিয়ে গঠিত:

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

কাজের একটি ইউনিট নির্ধারণ করা

সুতরাং এখন যেহেতু আমরা একটি দল একসাথে রাখতে পারি, আমরা তাদের কী বরাদ্দ করব?

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

আপনার তিনটি প্রাথমিক, গ্রহণযোগ্য নিদর্শনগুলি দেখা উচিত:

1. প্রতিটি স্তরের (ইউআই, ডাল, ইত্যাদি) জন্য ঠিক 1 টি উপ-দল
2. প্রতিটি মডিউলের জন্য ঠিক 1 টি উপ-দল (হোম পেজ, সহায়তা সাইট, দোকান)
3. দু'জনের মিশ্রণ (প্রতিটি স্তরের একটি নিম্ন স্তরের কাঠামো দল এবং একটি ইউআই-কেন্দ্রিক দল)

Answer 7

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

অবশ্যই এটি সবসময় কাজ করে না ...

Answer 8

আমি এখানে যা করব তা এখানে:

সমস্ত মডিউল যদি ছোট হয়, তবে আপনি প্রতিটিকে কাজ করার জন্য একটি মডিউল দিতে পারেন। অন্যথায়, এটি করুন:

1. প্রতিটি মডিউল আকার, জটিলতা, এটি করতে প্রয়োজনীয় দক্ষতা নির্ধারণ করুন।
2. প্রতিটি দলের সদস্য দক্ষতা নির্ধারণ করুন।
3. কোনটি একসাথে ভাল কাজ করে এবং কোনটি অন্যের সাথে ভাল কাজ করে না তা সংজ্ঞায়িত করুন।
4. মডিউল দক্ষতা প্রয়োজনীয়তা এবং দলের দক্ষতার উপর ভিত্তি করে ভালভাবে কাজ করে এমন লোকদের দলগুলিকে বড় মডিউল বরাদ্দ করুন।
5. মডিউল দক্ষতার প্রয়োজনীয়তা এবং দলের দক্ষতার ভিত্তিতে অন্যান্য ব্যক্তিদের সাথে ভাল কাজ করতে পারে না এমন লোকগুলিকে অবশিষ্ট মডিউলগুলি বরাদ্দ করুন।

উপরের কাজ করবে না যদি অন্যদের সাথে কাজ করা লোকেরা সবচেয়ে দক্ষ হয় এবং এটি একটি সাধারণ ঘটনা, সুতরাং সেই অনুযায়ী 4 এবং 5 এ ব্যতিক্রম করুন