চতুরতা, জলপ্রপাত এবং প্রয়োজনীয় পরিবর্তন


10

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


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

@ এমদাদ ইউএটি-র চলাকালীন প্রয়োজনীয় পরিবর্তনগুলি ঘটে যখন ব্যবহারকারীরা মনে করেন যে নির্দিষ্ট উপায়ে ব্যবহারযোগ্যতা উন্নত করা যেতে পারে। এটি পূর্ব প্রস্তুতিতে ইস্যুগুলি তৈরির কারণ হয়ে থাকে। এটি অবশ্যই চটজলদি নয়।
অরবিন্দ এ

@ অরবিন্দ এ: স্প্রিন্টের শেষে ইউএটি হয়, তাই না? তারপরে ইউএটি চলাকালীন যে কোনও নতুন ধারণা / পরিবর্তনগুলি সাধারণত পরবর্তী স্প্রিন্টের (যদি আপনি স্প্রিন্ট ব্যবহার করেন) গল্পের হয়ে ওঠে।
sleske

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

উত্তর:


9

একটি চৌকস প্রক্রিয়াটির প্রয়োজনীয়তাগুলি একটি স্প্রিন্টের শুরুতে সংজ্ঞায়িত করা উচিত এবং এর দিকে পর্যালোচনা করা উচিত। আমি কি এই ঠিক আছে?

না, এটি প্রকল্পের প্রকৃতি (এবং প্রক্রিয়া) এর উপর নির্ভর করে।

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

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

আপনি কোন মডেলটি অনুসরণ করেন তা প্রতিটি প্রকল্পের বিবরণের উপর নির্ভর করে।

তাই হ্যাঁ, যদি গ্রাহক মনে করেন যে তাদের ক্রমাগত প্রয়োজনীয়তাগুলি পরিবর্তনের সম্ভাবনা প্রয়োজন, তবে একটি চটজলদি প্রক্রিয়া এটিকে সামঞ্জস্য করতে পারে। তবে গ্রাহককে ধ্রুবক পরিবর্তনের পরিণতি সম্পর্কে সচেতন হওয়া উচিত এবং তাদের বুঝতে হবে যে তারা প্রকল্পটি ধীর করে দেবে।

এটি চৌকস ইশতেহার - "প্রক্রিয়া এবং সরঞ্জামগুলির ওপরে ব্যক্তি এবং ইন্টারঅ্যাকশন" এবং "একটি পরিকল্পনা অনুসরণ করে পরিবর্তিত হওয়ার প্রতিক্রিয়া" থেকে নীতির দিকে ফোটে


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

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

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

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

@ সলেস ব্যাখ্যার জন্য ধন্যবাদ। আমি এখন এটি পেয়েছি বলে মনে করি। আমি মনে করি আমাকে চটপটি আরও জানতে হবে।
অরবিন্দ এ

12

আমার মনে হয় আপনার যে প্রশ্নটি জিজ্ঞাসা করা উচিত তা হ'ল: প্রয়োজনীয় পরিবর্তনগুলি করে আপনি কেন ছাপিয়ে যাচ্ছেন? সাধারণ কারণগুলির মধ্যে রয়েছে:

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

মূল সমস্যা যাই হোক না কেন, আপনার এটি ঠিক করা দরকার। এটি "চতুর" (বা অন্য কোনও পদ্ধতি) এর স্তরের অধীনে ডুবানো কাজ করবে না।


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

9

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

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

আপনার কি আরও ছোট স্প্রিন্ট দরকার?


সংক্ষিপ্ত স্প্রিন্টের জন্য +1। 2 সপ্তাহ পিছনে স্কেল করুন এবং দেখুন এটি সাহায্য করে কিনা।
জন

1
স্প্রিন্টের জন্য 4 সপ্তাহ প্রকৃতপক্ষে বেশ দীর্ঘ লাগে, বিশেষত এমন প্রকল্পে যা প্রয়োজনের অস্থিরতায় ভুগছে।
কারসন 63000

7

প্রোগ্রামারদের বিগ্রহের জন্য এটি সর্বোত্তম যে যদি কোনও সংশোধন / স্প্রিন্টের সময় প্রয়োজনীয়তাগুলি পরিবর্তন না হয়।

আপনার পরিস্থিতিতে দুটি সুস্পষ্ট বিকল্প রয়েছে:

  1. খাটো স্প্রিন্ট
  2. সম্পূর্ণ সংশোধন / স্প্রিন্ট বাতিল না করে এবং পুনঃ পরিকল্পনা না করা হলে গ্রাহককে পুনর্বিবেচনা / স্প্রিন্টের সময় প্রয়োজনীয়তাগুলি পরিবর্তন না করার বিষয়ে সম্মত হন get

আমি উভয় অত্যন্ত সুপারিশ ।


3

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

আপনি করতে পারেন এমন সহজ পরিবর্তন (আপনি যদি স্ক্রাম অনুসরণ করতে চান) আপনার স্প্রিন্টকে আরও খাটো করে তোলে - উদাহরণস্বরূপ এক সপ্তাহ। স্ক্রমের প্রথম দিনগুলিতে 4 সপ্তাহের স্প্রিন্টগুলি বিকল্প হিসাবে বিবেচিত হত তবে আজ সাধারণ 1 - 2 সপ্তাহ এবং 3 সপ্তাহের উপরের সীমানা হিসাবে বিবেচিত হয়। পরিবেশ পরিবর্তন করার ক্ষেত্রে 4 সপ্তাহ খুব দীর্ঘ সময় হয়।

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