একটি ওয়ার্কিং সিস্টেম প্রতিস্থাপনের সময় কীভাবে চঞ্চল কাজ করে?


15

একটি আদর্শ চতুর বিশ্বে আপনি দ্রুত কাঙ্ক্ষিত শেষ সিস্টেমটির একটি ছোট, তবে দরকারী উপসেট তৈরি করুন এবং এটি ব্যবহারকারীদেরকে দিন। তারা উত্সাহিত, কারণ এটি কার্যকর, তারা এটি ব্যবহার শুরু করে এবং প্রতিক্রিয়া দেয়। তারপরে আপনি এতে কী যুক্ত করতে চান তা তৈরি করুন, এটি তৈরি করুন এবং সময় শেষ না হওয়া পর্যন্ত পুনরাবৃত্তি করুন।

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

"ক্ষুদ্রতম দরকারী উপসেট" "সমস্ত কিছু" হয়ে গেলে আপনি কীভাবে চপল প্রয়োগ করবেন?


3
আমার একটি প্রশ্ন আছে, এই নতুন সিস্টেমটি কি কোনও বিদ্যমান বৈশিষ্ট্যের সেটের সরাসরি আয়না, এবং যদি তাই হয় তবে আপনি কেন এটি পরিবর্তন করছেন?

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

উত্তর:


14

চটপটে সমাধানটি একসাথে সমস্ত প্রতিস্থাপন না করা হতে পারে , তবে প্রতিস্থাপনটি ধীরে ধীরে ফেজ করা।

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


2
ব্যবহারিকভাবে একই জিনিস বলার আগে +1 এমনকি আপনার উত্তরটি এখানে দেখেনি। দুর্দান্ত মন এবং সমস্ত;)
মাইকেল ব্রাউন

+1 দেখানোর জন্য যে নির্দিষ্ট ধরণের বাস্তব জীবনের বাস্তবায়নের জন্য এগিলি আদর্শ পন্থা নাও হতে পারে।
পেপ

@ পেপ হ্যাঁ, চটপটে (টিএম) এতই বেশি হাইপাই করা হয়েছে যে আপনার নিজের নির্দিষ্ট পরিস্থিতি সম্পর্কে চিন্তা না করে অন্ধভাবে একটি নির্দিষ্ট পদ্ধতি ব্যবহারের ঝুঁকি রয়েছে।
মার্কজে

পুরানো সিস্টেমের অংশগুলি চালিত রাখার অর্থ পুরানো সিস্টেমের সাথে সংহত করার জন্য উন্নয়নের ব্যয় ব্যয় করা বোঝায়, তাই না?
স্টিভ বেনেট

1
@ স্টিভবেনেট: হ্যাঁ, তা হয়। এটি অবশ্যই একটি ট্রেড অফ is তবে বেতনটি ঝুঁকি হ্রাস করে এবং আপনার কেবল সেই অংশটিই আবার করতে হবে যা পুনরায় করা দরকার।
sleske

6

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

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


5

বিশ্বে ছোট বৃদ্ধি বৃদ্ধি গ্রীনফিল্ড প্রকল্পের জন্য কাজ করতে পারে তবে তার পরেও সংখ্যক বৈশিষ্ট্য খুব বেশি কার্যকর নাও হতে পারে।

স্ক্রাম পরামর্শ দেয় যে প্রতিটি স্প্রিন্টের পরে পণ্যটি "সম্ভাব্য শিপযোগ্য"। এটি প্রেরণ করতে হবে না তবে একটি শিপযোগ্য পণ্যটির গুণমান থাকতে হবে।

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

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


1
+1 এটি ঠিক এটির কাছে আমরা এসেছি। যদিও 'শুরু করার' পুরো ধারণাটি খুব অচেতন ag আপনি কীভাবে পুরানো সমাধানটিকে খানিকটা বিকল্প হিসাবে বিবেচনা করার চেষ্টা করেছেন?
ক্রিস ভ্যান বায়েল

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

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

3

আমি একটি বড় জাতীয় কেবল টিভি নেটওয়ার্কের জন্য বিস্তৃত ব্যবসায়ের অ্যাপ্লিকেশন প্রতিস্থাপনের কাজ করেছি। নতুন সিস্টেম ডেভলপমেন্ট এসসিআরইউএম দিয়ে হয়েছিল, প্রায় সমস্ত বড় সাব-সিস্টেমগুলি পুনরায় বাস্তবায়নের জন্য প্রায় 18-24 মাসের উন্নয়ন প্রকল্প ছিল; যেগুলি 10 বছরের পুরানো ছিল।

উন্নয়ন শুরু হওয়ার আগে 6 মাসের মতো পরিকল্পনা করার পর্ব ছিল তবে এটি এসসিআরইউএম হিসাবেও পৌঁছেছিল। এইখানে পণ্য মালিক বিদ্যমান সিস্টেম বিশ্লেষণ এবং গ্রাহকদের সাক্ষাত্কার দেওয়ার পরে উচ্চ স্তরের স্টোর এবং মহাকাব্য লিখেছেন।

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

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

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

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


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

2

আমি এখনও মনে করি চটপটে এই দৃশ্যে অনেক মান যুক্ত হয়।

এটি কেবলমাত্র 'বর্তমান সিস্টেমটি প্রতিস্থাপন করুন' এর একটি অত্যন্ত সংজ্ঞায়িত শেষ লক্ষ্য রয়েছে।

চতুর কৌশল এবং প্রক্রিয়াগুলি আপনাকে আরও কার্যকরভাবে সেখানে পেতে পারে ।

এই ক্ষেত্রে:

আপনি এখনও সিস্টেমে পুনরাবৃত্তভাবে এবং ছোট স্প্রিন্টে বিতরণ করতে পারেন।

আপনি এখনও মূল লোকের সাথে যোগাযোগের পরে কাজের অগ্রাধিকার দিতে চতুর কৌশলগুলি ব্যবহার করতে পারেন।

আপনি পর্যবেক্ষণ গতির উপর ভিত্তি করে পরিকল্পনা করতে এখনও চটপট ব্যবহার করতে পারেন।

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

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


1

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

তাদের বুঝতে দিন যে আপনি এটি এভাবে করতে চান না কারণ আপনি মনে করেন এটি মজাদার হবে এবং আপনি জলপ্রপাত প্রক্রিয়াটি ব্যবহার করে একাকী হয়ে যাবেন। এটি দীর্ঘকালীন আরও ভাল অ্যাপ তৈরি করবে।

একটি মূল বিক্রয় কেন্দ্র হতে পারে তারা সর্বদা চেয়েছিল নতুন অ্যাপ তৈরির সময় সেই পরিবর্তনটি বাস্তবায়ন করতে পারে তবে পুরানো সিস্টেমে কখনই পেতে পারেনি।


0

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

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

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

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

সম্ভবত গাড়ী গ্রাহক হিসাবে আপনি কেবল ইঞ্জিনটি সন্ধান করতে এবং মূল্যায়ন করতে চান তা নিশ্চিত করতে যে আপনি প্রকৃতপক্ষে যা প্রত্যাশিত তা পেয়ে যাচ্ছেন make ওফস, আমি আসলে 4 সিলিন্ডারের ইঞ্জিনের পরিবর্তে 6 টি সিলিন্ডার ইঞ্জিন চেয়েছিলাম! এর আগে কি বলিনি? কোনও সমস্যা নেই, কারখানার ক্রমে পরিবর্তন আনুন।

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


হ্যাঁ, তবে রূপকটি অনুসরণ করার জন্য আমার অভিজ্ঞতা এখনও অবধি ছিল, যে গাড়ী গ্রাহকরা ইঞ্জিন সম্পর্কে কিছুই জানেন না, এবং কোনও দিকে নজর দেওয়া থেকে আপনাকে দরকারী কিছু বলতে পারবেন না। যখন তারা হাইপোটিকাল মোডে থাকে, তখন প্রতিক্রিয়াটি বেশ আঞ্চলিক হয় "ওহ, দেখে মনে হচ্ছে এটি আমরা যা চাই তা করবে" এবং তারা সত্যিকারের সমস্যার সমাধানের জন্য প্রথমবার এটি ব্যবহার না করা পর্যন্ত আপনি বেশি কিছু পাবেন না।
স্টিভ বেনেট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.