স্প্রিন্টের মধ্যে একটি ওয়ার্কিং বিল্ডিং ব্যতীত চতুর অভ্যাসের আরও কী কী সুবিধা রয়েছে?


9

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

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

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

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

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

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


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

হ্যাঁ, "জলপ্রপাত" দ্বারা আমি বোঝাচ্ছি (বেশিরভাগ মূলত) কার্যকরী চশমা -> ডিজাইন -> মাইলফলকের মধ্যে কোড, স্প্রিন্ট নয়। এবং, অবশ্যই, 2000 পৃষ্ঠাগুলির প্রয়োজনীয়তা এবং প্রযুক্তিগত চশমাগুলি অবশ্যই আবশ্যক নয়, ক্লাসগুলির মৌলিক দায়িত্ব এবং একে অপরের সাথে তাদের সম্পর্ক প্রায়শই শীর্ষ স্তরের নকশা হিসাবে যথেষ্ট।
tux91

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

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

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

উত্তর:


7

প্রথমত, "জলপ্রপাত" মডেলটি সর্বদা একজন খড়ের মানুষ ছিলেন যা কীভাবে সফ্টওয়্যার ডেভলপমেন্ট প্রকল্প চালাবেন না তা বর্ণনা করে। এটা দেখ.

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

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

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

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

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


দুর্দান্ত ধন্যবাদ যে
নকশাগুলি

8

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

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

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


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

2
জলপ্রপাত প্রকল্পগুলির সাথে আমার অভিজ্ঞতা হ'ল তারা পরিকল্পিত সময়ের প্রথম 90% সময়ে সময় মতো থাকে, যে মুহুর্তে তারা হঠাৎ কয়েক মাস পিছিয়ে থাকে। প্রতিটি স্প্রিন্টে ডেমোসের প্রতি জোর দেওয়ার চতুর মডেল এটি খুব কম সম্ভাবনা তৈরি করে। লোকেরা যখন জানে যে তারা দেড় সপ্তাহের মধ্যে দায়বদ্ধ হবে, তখন তারা সাধারণত আরও ভালভাবে উত্সাহিত হয় যখন তারা নয় মাসে দায়বদ্ধ হবে held এটি শুধুই মানুষের মনস্তত্ত্ব।
রোবট

1
হ্যাঁ, আমি অনুভব করি যে আমি অভিজ্ঞতার সাথে তর্ক করতে পারি না, যদিও আমার অভিজ্ঞতাটি কিছুটা আলাদা ছিল, হাতের কোডিংয়ে একটি ভাল ডিজাইনের ফলে অনেক ঝামেলা নেই এবং অনুমানগুলিও বেশ ভাল বলে মনে হয়েছিল। আমি এখনও মনে করি যে যদিও জলপ্রপাতটি ব্যবহার করা হয় তবে ফলস্বরূপ আর্কিটেকচার আরও দৃ solid় হবে।
tux91

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

4

প্রশ্নের উত্তরের প্রতিক্রিয়া হিসাবে, যা বিরোধী বিরোধীদের মৌলিক ভুল ধারণা

"... যেখানে জলপ্রপাত আপনাকে কিছু ছাড়ার আগেই আপনার আর্কিটেকচারকে নিখুঁত করতে দেয় ।" একটি মিথ্যাচার, আমি আপনার জন্য এটি ঠিক করতে দিন; "... যেখানে জলপ্রপাত আপনাকে আপনার আর্কিটেকচারকে নিখুঁত করতে দেয় যাতে আপনি কখনই কোনও কিছুই প্রকাশ করেন না "

যে জলপ্রপাতটি কীভাবে উচ্চমানের আর্কিটেকচার সরবরাহ করে তা মূলত মিথ্যা এবং irতিহাসিক প্রমাণ দ্বারা সম্পূর্ণ অস্বীকার করা হয় disp

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

ইউটিউব, টুইটার এবং অন্যান্য অসংখ্য সংস্থার সাথে একই।

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

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


3
"কখনই না" শব্দটি ব্যবহার করে আপনি কি বলছেন যে জলপ্রপাত ব্যবহার করে এমন কোনও সফ্টওয়্যার পণ্য নেই? এছাড়াও, আপনি সফলভাবে প্রয়োগ করা একটি নির্দিষ্ট মাইলফলকটির জন্য প্রয়োজনীয়তার একটি সেট থাকলে কেন "কখনই" কিছু ছাড়েন না?
tux91

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

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

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

1
@ জ্যোতিঃ হ্যাঁ, আমি অনুমান করি যে আমি কখন এই শব্দটি নিখুঁতভাবে ব্যবহার করেছি , আমি চাই না যে আমি আসলে বোঝাতে
চাইছি

3

নিজে থেকে স্ক্রাম কোনও প্রযুক্তিগত অনুশীলনগুলি লিখে দেয় না কারণ এটি একটি সাধারণ কাঠামো।

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

এটি এমনভাবে করা দ্রুত এবং নিরাপদে পরিবর্তন পরিচালনা করা সম্ভব করে তোলে, এটি প্রথম স্থানে চতুর বিকাশের জন্য প্রাথমিক কারণ is

আপনি যদি নিয়মিতভাবে (সাপ্তাহিক, দ্বিপক্ষীয়) আপনার গ্রাহকের কাছে মূল্যবান, কার্যক্ষম সফটওয়্যার প্রকাশ করতে পরিচালনা করেন তবে একমাত্র পরিশ্রমের মাপকাঠি matters আপনি এটা করতে পারেন? তারপরে আপনি আমার বইয়ে চটপটে আছেন।


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

@ tux91 আমার উত্তর আপডেট করেছে। আর্কিটেকচারের ক্ষেত্রে, আমরা "বর্ধিত নকশা" বলি সে সম্পর্কে আমি এটি পড়তে বা এটি 26:20 এ দেখার পরামর্শ দিই ।
মার্টিন উইকম্যান

2

আমার জন্য, চটপটে আসার প্রধান সুবিধা প্রকল্পে ঝুঁকি হ্রাস করা।

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

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


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

1

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

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

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


0

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

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

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

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