মধ্য বিকাশের পরিবর্তন থেকে উন্নয়নকে কীভাবে থামানো যায়?

Question

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

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

প্রশ্ন : আপনি ছেলেরা মাঝের দিকে বা উন্নয়নের পরে ফসল কাটা থেকে নির্দিষ্ট পরিবর্তনগুলি হ্রাস এবং প্রতিরোধের সন্ধানের জন্য সেরা উপায়গুলি কী কী?

Comments

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

— মশা

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

— maple_shaft

আপনি কি কেবল পঠনযোগ্য ফাইলে সেই অনুমানটি সংরক্ষণ করার চেষ্টা করেছেন?

— orlp

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

— সাইমন রিখটার

এ কারণেই কি চপলতা বিদ্যমান? আপনি চক্রটি হিমায়িত করতে পারবেন না তাই আপনার প্রক্রিয়াটিকে একটি পরিবর্তনশীল স্পেক হ্যান্ডেল করুন।

— ক্রেগ

Answer 1

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

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

Comments

আপনি এগুলিকে পর্যায়ক্রমে 'হিমায়িত' করতে এবং 'পরবর্তী সংস্করণে' পরিবর্তনগুলি ঠেলাতে পারেন ।

— গ্র্যান্ট থমাস

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

— 15-15

6 নম্বরের জন্য +1 + আমার একমাত্র প্রধানমন্ত্রী সেই প্রয়োজনীয়তা বাস্তবায়নের সাথে একটি চমৎকার অভিজ্ঞতা পেয়েছিলেন।

— জোশুয়া ড্রেক

সংক্ষিপ্ত চক্র মূল। "পরবর্তী প্রকাশ" ছয় মাস দূরে থাকার চেয়ে লোকেরা পরবর্তী দু'সপ্তাহের স্প্রিন্টে কিছু ঠেলে দেওয়ার বিষয়ে খুব কম বিচলিত।

— অ্যাডাম জ্যাসকিউইচ

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

— মাইকেল বর্গওয়ার্ট

Answer 2

প্রথম দিকে কিছু সরবরাহ করুন (আমি কোনও শব্দটি ব্যবহার করতে দ্বিধায় থাকি) এবং প্রায়শই বিতরণ করি। তা হ'ল - কিছু ধরণের পুনরাবৃত্তি বিকাশের পদ্ধতি ব্যবহার করুন।

এটি চৌকস বিকাশের ভিত্তি, তবে (প্রায়) যে কোনও পদ্ধতি ব্যবহার করে এটি ব্যবহার করা যেতে পারে।

প্রজেক্টটি মিনি প্রকল্পের একটি ধারাবাহিকতায় ভাঙ্গার মাধ্যমে আপনি আরও নিয়ন্ত্রণ পেতে পারেন কারণ আপনি প্রথমদিকে ক্লায়েন্টের সামনে কিছু রাখতে পারেন, আপনি একটি দীর্ঘ বিকাশের সময়সূচীতে আবদ্ধ হন না যা ক্লায়েন্টের মন পরিবর্তন করার সাথে সাথে (যেমন) তারা করবে).

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

Answer 3

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

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

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

Comments

নাসা তাদের কিছু সফ্টওয়্যার দিয়ে এটি করে বা অন্তত শাটলগুলি মহাশূন্যে প্রেরণ করতে পারে। বিষয়টি হ'ল তারা প্রকৃতপক্ষে জলপ্রপাতের মডেলটি অনুসরণ করে। অনুমানটি আসলে হিমশীতল। অন্তত সংগঠনের বাইরে থেকে আমার বোঝার বিষয়টি from

— জোশুয়া ড্রেক

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

— টিএমএন

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

— ডাঙ্ক

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

— টিএমএন

@ টিএমএন আমি অবাক করে দেখি যে তখন সাফল্যের মূল চাবিকাঠি। জলপ্রপাত মডেল ব্যবহার, বা আপনার শৃঙ্খলাবদ্ধ পদ্ধতির? আমি ভাবছি পরে দুজনের মধ্যে আরও গুরুত্বপূর্ণ।

— রস গড্ডার্ড

Answer 4

পরিবর্তন রোধ করার চেষ্টা করবেন না, এটি আলিঙ্গন করুন। আপনি যত বেশি পরিকল্পনা করবেন ততই আপনার পরিকল্পনার পরিবর্তন হবে। সুতরাং, কম পরিকল্পনা করুন , বেশি নয়। একটি চৌকস বিকাশ পদ্ধতি অবলম্বন করুন যেখানে আপনি ঘন ঘন ওয়ার্কিং কোড সরবরাহ করেন এবং গ্রাহককে প্রতি কয়েক সপ্তাহের মধ্যে বিশদ পরিবর্তন করার সুযোগ করে দেন।

Comments

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

— ডাঙ্ক

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

— রস গড্ডার্ড

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

— ডাঙ্ক

Answer 5

আপনি ভুল প্রশ্ন জিজ্ঞাসা করছেন। স্পেস পরিবর্তনগুলি সর্বদা যে কোনও আকারের সফ্টওয়্যার বিকাশ প্রকল্পগুলিতে ঘটবে।

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

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

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

আমি বলছি না এটি আপনার সমস্ত সমস্যার সিলভার বুলেট, তবে এগুলি আপনি যে পরিস্থিতিটি বর্ণনা করছেন খুব সামান্যতম তারা কিছুটা তদন্তের যোগ্য, তা পরিচালনা করার ইচ্ছার কারণেই ঘটেছে।

দুঃখিত, যদি এটি কোন নিবিড় সমাধান সরবরাহ না করে তবে আমি মনে করি যে পরিবর্তনকে মেনে নেওয়ার ও পরিচালনার ক্ষেত্রে মানসিকতা পরিবর্তনটি এড়াতে চেষ্টা করার চেয়ে আরও বেশি লভ্যাংশ প্রদান করবে।

Comments

হাঁ। আসল প্রশ্নটির পুনঃব্যবহারের জন্য: "আমরা কীভাবে গ্যারান্টি দিতে পারি যে ক্লায়েন্টরা প্রকল্পের শুরুতে যা চেয়েছিল তার চেয়ে শেষের দিকে যা চেয়েছিল তার চেয়ে আমরা কী সরবরাহ করব?"

— স্টিভ বেনেট

Answer 6

পরিবর্তন কেবল অবাক ... যদি অবাক হয়!

আমি এই সম্পর্কে চিন্তা করার পরামর্শ দেব:

• পৃথিবীতে এই পরিবর্তনগুলি যেভাবেই আসে?
• আপনি তাদের সম্পর্কে আগে অবগত নন কেন?
• আপনি কেন এই পরিবর্তনগুলিতে অবদান রাখছেন না (এবং সম্ভাব্যত এগুলি আরও বেশি করে দিচ্ছেন)?

পরিবর্তন আমরা যা করি তা প্রকৃতি। আপনি কখন থেকে প্রথম দিনটিকে যেমন কল্পনা করেছিলেন ঠিক তেমন একটি অ্যালগরিদম কোড করেছিলেন?

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

Comments

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

— ডাঙ্ক

Answer 7

যদিও কলটি শুরু হয়েছে, ক্লায়েন্টরা সর্বদা বেশি চায় তবে এখানে কয়েকটি বিষয় বিবেচনা করা উচিত:

এইচটিএমএল মক-আপস: কোনও অ্যাপ্লিকেশনের ইউআই অংশটি সংজ্ঞায়িত করতে সর্বদা এইচটিএমএল মক আপগুলি তৈরি করুন, এটি দেখতে কেমন হবে তা তাদের দেখান এবং তাদের মতামত জিজ্ঞাসা করুন। যদি আপনি পরিবর্তনযোগ্য যুক্তিসঙ্গত কিছু পান তবে এটি এটি HTML প্রোটোটাইপে ঘটে। এটি ব্যবহার করে আপনি ইউআই ইস্যুগুলি, বেসিক ফ্লো এবং কিছু অ্যাড অন্সের মতো বাছাই করবেন (যেমন বাছাই করা, প্যাজিনেশন, প্রদর্শিত রেকর্ডের নম্বর ইত্যাদি) things

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

মডুলার রিলিজ: আপনার কোডটি একটি মডুলার ফ্যাশনে প্রকাশ করুন, প্রকাশ করুন, পরীক্ষা করুন, প্রতিক্রিয়া নিন এবং আবার প্রকাশ করুন।

Answer 8

এ কারণেই খুব দূরে পরিকল্পনা করা প্রায় অসম্ভব, তবে পরিকল্পনা না করার অজুহাত নয়। আপনার পরিকল্পনার প্রেমে খুব গভীরভাবে পড়বেন না এবং সেগুলি আপনার হৃদয় ভেঙে ফেলার বিষয়ে আপনাকে চিন্তা করতে হবে না।

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

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

Answer 9

বিকাশ চক্র জুড়ে সক্রিয় ব্যবহারকারীর সম্পৃক্ততা, এবং যথাসম্ভব চতুর পদ্ধতি ব্যবহার আমাদের পণ্যগুলিতে সত্যই আমাদের সহায়তা করে।

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

Answer 10

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

গীত। যদি এটি "পিও" না হয় তবে আমি বলব যে আমার সাথে "পিও" দিয়ে কথা বলবেন না

Answer 11

মাঝপথে বা বিকাশের পরে আপনি ছেলেরা কিছু সেরা উপায়গুলি কীভাবে কমিয়ে আনা এবং নির্দিষ্ট পরিবর্তনগুলি ফসল থেকে রোধ করতে পেরেছেন?

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

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

Answer 12

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

Comments

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

— চাকরি

Answer 13

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

Answer 14

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

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

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

Answer 15

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

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

সত্যি বলতে, আমি আশা করি প্রোগ্রামারদের সাধারণত বল বেশি থাকে। আসুন এটি দেখুন:

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

যদি আপনি কোনও $-প্রদেয় ক্লায়েন্টের সাথে কাজ করে থাকেন এবং যদি আপনি একটি চুক্তি করে নিজের গাধাটি 2েকে রাখেন (http://vimeo.com/22053820?utm_source=swissmiss), তবে স্পেকের পরিবর্তনগুলি এই ক্লায়েন্টকে আরও সময় এবং আরও বেশি অর্থ ব্যয় করতে পারে ( বা সম্ভাব্যভাবে একই বা কম সময় তবে তাত্পর্যপূর্ণভাবে আরও বেশি অর্থ)। আপনার সংস্থা আরও সময় এবং আরও অর্থ ব্যয় না করে স্পেক পরিবর্তন করে পালানোর চেষ্টা করছে।

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

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

তারপরেও চতুর বিকাশের প্রতিশ্রুতি রয়েছে, যা কোনও কঠোর সময়সীমা বোঝায় না।

আমি এখনও প্রোগ্রামারদের ধর্মঘটে যেতে দেখিনি, তবে এটি কিছু হত। অযোগ্য পরিচালকগণ সফ্টওয়্যার সংস্থাগুলিতে খুব বেশি abund ক্রেগলিস্টে বা একটি আসল সংস্থার মধ্যে অনেক লোক কিছুতেই কিছু পেতে চায় না। http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

প্রোগ্রামারদের আরও বল থাকা দরকার।

Answer 16

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