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

Question

জলপ্রপাত থেকে স্ক্রাম ব্যবহার করে চটপটে আমাদের উত্তরণের মধ্য দিয়ে আমরা মাঝখানে প্রায়; আমরা প্রযুক্তি / শৃঙ্খলা সিলোজের বড় দলগুলি থেকে ছোট ক্রস-ফাংশনাল দলে পরিবর্তন করেছি।

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

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

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

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

Comments

There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice.আপনি কেন তা করছেন তা বুঝতে না পারলে আপনি চটচটে করছেন না।

— কেউ নয়

তাদেরকে দেখান যে সহযোগিতা করা আরও মজাদার, কারণ তারপরে তারা আরও ভাল কোড লিখবে, আরও শিখবে এবং সমস্যা কম হবে।

যদিও প্রোগ্রামিংয়ের জন্য বিশদটি স্পষ্টতই, এটি পরিবর্তন পরিচালনার ক্ষেত্রে একটি জেনেরিক কর্মক্ষেত্রের সমস্যা এবং কর্মক্ষেত্র.se এ আরও ভালভাবে জিজ্ঞাসা করা হবে।

— mattnz

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

— ওমর ইকবাল

Answer 1

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

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

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

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

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

Comments

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

— ক্রিস

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

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

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

— রওয়ং

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

— রওয়ং

Answer 2

তারা আগের মতো কাজ করে আনন্দ খুঁজে পায় না।

সঠিক।

এটি একটি বড় লক্ষণ যা আপনি এটি ভুল করছেন।

চতুর লোকের উপর কোনও খারাপ নতুন আদেশ চাপানো উচিত নয় ।

চতুর এমনভাবে দলকে স্ব-সংগঠিত করার অনুমতি দেওয়া উচিত যা এটি সবচেয়ে কার্যকর করে তোলে।

স্ব-সংস্থা মানে পরিচালনা অদ্ভুত নিয়ম চাপায় না। এটি খারাপ সময়সূচি চাপায় না এবং এটি অপ্রয়োজনীয় মিথস্ক্রিয়া চাপায় না।

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

তারা কেন এই কাজ চালিয়ে যেতে পারে না?

কেন তাদের পরিবর্তন?

দয়া করে কয়েকবার অ্যাগ্রিল ম্যানিফেস্টোটি পড়ুন।

এজিলেল ইশতেহারে বলা হয়েছে

প্রক্রিয়া এবং সরঞ্জামগুলির উপর ব্যক্তি এবং ইন্টারঅ্যাকশন

এটি লোককে এমন উপায়ে কাজ করতে বাধ্য করে না যা অস্বস্তিকর এবং অনুফলহীন।

আপনি যদি লোকেদেরকে অত্যধিক নিম্ন-মানের "মিথস্ক্রিয়া" করতে বাধ্য করেন তবে আপনি খুব বেশি চলে গেছেন।

বিস্তৃত ডকুমেন্টেশন ওভার সফ্টওয়্যার।

তারা কি এটা করছে? তারপরে তাদের একা ছেড়ে দিন।

চুক্তি আলোচনার উপর গ্রাহকের সহযোগিতা।

আপনি কি ইতিমধ্যে এটি করছেন? তাহলে বদলে যাবেন না।

একটি পরিকল্পনা অনুসরণ করে পরিবর্তন সাড়া।

এই লোকেরা ইতিমধ্যে পরিবর্তনের প্রতিক্রিয়া জানাতে সক্ষম? যদি তা হয় তবে তারা ইতিমধ্যে চতুর ছিল। তাদের পরিবর্তন করার দরকার নেই।

Comments

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

— ক্রিস

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

— ক্রিস

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

— এসলট

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

— এসলট

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

— আমার সঠিক মতামতটি

Answer 3

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

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

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

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

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

তাহলে আপনি কি করবেন?

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

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

এটি আসলে কোনও উত্তর নয় তবে এটি আমার অভিজ্ঞতা / পর্যবেক্ষণের যোগফল দেয়। অন্যেরা এ সম্পর্কে কী বলবে তা আমি দেখতে চাই না।

Comments

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

Answer 4

চটপটি কি?

তাই কি:

• নিয়মের একটি সেট যা নিয়ম-সেটারদের উদ্দেশ্য কী তা অর্জন করতে আপনাকে অবশ্যই অনুসরণ করতে হবে?

• আপনার নির্দিষ্ট শক্তি, প্রয়োজনীয়তা এবং সীমাবদ্ধতার মধ্যে জিনিসগুলি সম্পন্ন করার জন্য একটি সেরা অনুমানের পদ্ধতির?

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

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

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

অ্যালিস্টার ককবার্ন তার পদ্ধতিতে এটি বর্ণনা করেছেন described আপনার যদি "স্তর 3 অনুশীলনকারী" থাকে তবে নিখুঁতভাবে বৈধ চতুর পদ্ধতিটি নিম্নরূপ:

"ওয়ার্কস্টেশন এবং হোয়াইট বোর্ড এবং ব্যবহারকারীদের অ্যাক্সেস সহ একটি ঘরে 4-6 জনকে রাখুন। তাদের প্রতি এক বা দুই মাসে ব্যবহারকারীদের কাছে চলমান, পরীক্ষিত সফ্টওয়্যার সরবরাহ করতে এবং অন্যথায় এগুলিকে ছেড়ে দিন leave

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

আপনি কোডটি সর্বনিম্ন সাধারণ ডিনোমিনেটরে পৌঁছে দেবেন না। আপনি অনভিজ্ঞকে উন্নত বিকাশকারীদের কাছে পৌঁছে দিন।

Answer 7

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

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

Comments

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

— ক্রিস

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

— জোয়েল সি

Answer 8

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

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

এই ধরণের বিকাশকারীকে একটি চটচটে পরিবেশের সাথে খাপ খাইয়ে নিতে অসুবিধা হতে পারে এবং তাদের দৃষ্টিভঙ্গিটি প্রায়শই "পরিবর্তন করতে ইচ্ছুকতা" হিসাবে প্রত্যাখ্যাত হয়, সম্ভবত অহংকার বা পুরানো being

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

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

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

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

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

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

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

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

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

শুধু আমার 2 সেন্ট।

Answer 9

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

দেখে মনে হচ্ছে এগুলি "লোন রেঞ্জার্স"। ক্যানোনিকাল স্ক্রামে, এই ব্যক্তিরা কেবল দলটিকে ফিট করতে পারে না (তারা "মিথস্ক্রিয়া" বিট মিস করে)।

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

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

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

Comments

-1 - ধরে নেওয়ার জন্য ব্যতিক্রমী উত্পাদনশীল লোকেরা একাকী রেঞ্জার কারণ তারা চতুর পদ্ধতির যত্ন নেয় না। আপনি কি কখনও "নিজের সম্ভাবনার সাথে বেঁচে থাকা" বা "একটি চ্যালেঞ্জ উপভোগ করা" বাক্যাংশটি শুনেছেন? চৌকস পদ্ধতির অনুশীলন করার সময় সম্ভবত তারা এটিকে মিস করে।

— ডঙ্ক

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

— সোরোঁথার

Answer 10

জো যদি (আপনার হিরো বিকাশকারী) কিছুটা নমনীয় হয়, তবে আমি কোনও সমস্যা দেখতে পাচ্ছি না:

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

কেবলমাত্র চ্যালেঞ্জগুলি যে স্ক্রাম আরোপ করেছে যে কয়েকটি প্রতিবন্ধকতার মধ্যে রয়েছে:

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

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

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

Comments

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

— রবিং

Answer 11

চৌকস দলের জন্য নিয়মগুলি টিমের সাথে মানিয়ে নিতে কাস্টমাইজ করা উচিত - এটি সত্যই ব্যক্তিগত কাস্টমাইজেশন হতে পারে; উদাহরণস্বরূপ, আমি এমন একটি দলে কাজ করেছি যেখানে নিয়ম ছিল:

সমস্ত কোড অবশ্যই একটি জুড়ি দ্বারা রচনা করা উচিত, ডেভিড একা কোড লিখতে পারে ছাড়া।

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

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

Comments

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

— আমার সঠিক মতামত

আপনি কি এমন একজনকে ধরে নিয়েছেন যে কোনও কঠিন সমস্যার জন্য কাজ করার জন্য কিছু সময় এবং ঘনত্বের প্রয়োজন যা অন্তর্মুখী? এটা কি এমন নয় যে কোনও ব্যক্তিকে কঠিন স্টাফগুলিতে কাজ করার জন্য মনোনিবেশ করা দরকার এবং বিভ্রান্ত হতে চান না?

— জর্জিও

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

— 2-29 এ Rwong

@ রাওং: আমি মনে করি না যে এর জন্য আপনার চটুল হওয়া দরকার: যে কোনও দল কোনও প্রকারের উন্নয়ন প্রক্রিয়া ব্যবহার করে দলের সদস্যদের মধ্যে জ্ঞানের আরও ভাল বিতরণ করে লাভ করতে পারে।

— জর্জিও