চটপটে - আমরা কী ভুল করছি?


22

আমি একটি চৌকস দলে একজন বিকাশকারী এবং আমরা স্ক্রামটি ব্যবহার করার চেষ্টা করি।

সুতরাং পরিস্থিতি চিত্রিত করার জন্য আমি এখানে একটি অনুমানমূলক সমস্যা রাখব।

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

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

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

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

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

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


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

চটপটে কীভাবে তা আটকাবেন? লোকেরা হাঁসের টেপিং ঠিক করে ফিক্সিং হিসাবে ইনক্রিমেন্টাল বোঝে।
গ্যাব্রিয়েল স্লোমকা

7
"লোকেরা হাঁসের টেপিং ঠিক করে ফিক্সিং হিসাবে ইনক্রিমেন্টাল বোঝে" " - এটা অবশ্যই স্ক্র্যাম কি না। যদি "লোকেরা" মনে করে তবে তারা স্ক্র্যামকে ভুল বুঝে।
ব্রায়ান ওকলে

9
এরিক লিপার্টকে উদ্ধৃত করার জন্য: আপনি যদি নিজেকে কোনও গর্তে খনন করেন তবে প্রথমে বেরিয়ে আসুন: খনন বন্ধ করুন।
ডক ব্রাউন

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

উত্তর:


56

এগ্রিল বা স্ক্রামের সাথে এর কোনও যোগসূত্র নেই।

"এখন এটি নালী টেপ করুন এবং আমরা এটি পরে ঠিক করব" সমস্যাটি হ'ল পরে কখনই আসে না এবং মাঝামাঝি সময়ে আপনি প্রচুর প্রযুক্তিগত debt ণ সংগ্রহ করছেন ।

পুনরুদ্ধারের প্রথম পদক্ষেপটি সমস্যাটি সনাক্ত করা এবং আরও খারাপ করা বন্ধ করা।

প্রতিটি নতুন ব্যবহারকারীর গল্পের জন্য, দলটিকে "এটি কোড করার সঠিক উপায়টি কী?" বিবেচনা করা উচিত, "এটি হ্যাক করার দ্রুততম উপায় কোনটি নয়?" এবং সেই অনুযায়ী স্প্রিন্টের পরিকল্পনা করুন।

বিদ্যমান সমস্যাটি পরিষ্কার করতে, আমি স্প্যাগেটি কোডের 200K লাইন উত্তরাধিকার সূত্রে পেয়েছি - এখন কী?


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

1
উত্তরটি কেবল এই। ভাল রাখা এবং খুব সুনির্দিষ্ট। এসসিআরএম হ'ল কাজ করার এক উপায়, আপনি যদি টেপ শেষ না করে ডक्ट টেপ দিয়ে কাজ করার সিদ্ধান্ত নেন, এটি আপনার উপর।
কোটায়ার

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

22

আপনার যা আছে সেখানে মার্টিন ফোলারকে "ফ্ল্যাসিড স্ক্রাম" বলে।

আপনি যদি এগ্রিল ইশতেহারের পিছনে সমস্ত 12 টি মূলনীতি সঠিকভাবে পড়ে থাকেন তবে আপনি বেশিরভাগের মধ্যেই ব্যর্থ হয়েছেন তা খুঁজে পাবেন।

সংক্ষিপ্ত টাইমস্কেলের অগ্রাধিকার সহ প্রায় কয়েক সপ্তাহ থেকে কয়েক মাস পর্যন্ত কার্যক্ষম সফটওয়্যারটি প্রায়শই বিতরণ করুন।

আপনি কি বলতে পারবেন যে আপনি সত্যিকারের কাজের সফটওয়্যার সরবরাহ করেছেন? বা সবেমাত্র সফ্টওয়্যার যা সবেমাত্র কাজ করে?

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

আপনি কি বলতে পারেন আপনার প্রক্রিয়াটি টেকসই? আপনি কি স্থায়িত্বের কথা মাথায় রেখে সিদ্ধান্ত নেন? অথবা আপনি দীর্ঘমেয়াদী প্রভাবগুলি বিবেচনায় না নিয়ে এমন সমস্যার সমাধান করেন যা বর্তমান সমস্যার সমাধান করে?

প্রযুক্তিগত উৎকর্ষতা এবং ভাল ডিজাইনের দিকে অবিচ্ছিন্ন মনোনিবেশ তত্পরতা বাড়ায়।

সত্যই প্রধান নীতি। আমি বিশ্বাস করি এটি পৃষ্ঠাতে বিশাল রেড লেটারে রাখা উচিত। আপনি এখানে সবচেয়ে ব্যর্থ হন।

নিয়মিত বিরতিতে, দলটি আরও কার্যকর হওয়ার বিষয়ে প্রতিফলিত করে, তারপরে সুর করে এবং সে অনুযায়ী তার আচরণটি সামঞ্জস্য করে।

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

আপনার মন্তব্য থেকে

চটপটে কীভাবে তা আটকাবেন?

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


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

1
@ ব্রায়ানওকলে আমি যা বলতে চাই তা হ'ল প্রক্রিয়াটি যদি এক্স করার নির্দেশ না দেয় তবে লোকেরা এক্স করবে না And একেবারে বিপরীত, যেমন করা হবে কেবল পিও দ্বারা নির্ধারিত কাজ, তবে কোনও প্রযুক্তিগত debtণ সরানো হবে না। পিও হিসাবে এটি যত্ন করার কোন কারণ নেই। প্রযুক্তিগত debtণ কেবল দলের দায়িত্ব is
ইউফোরিক

2
"স্ক্রাম প্রযুক্তিগত reduceণ হ্রাস করতে পারে এমন কোনও অনুশীলন লিখে দেয় না।" - বা এটি প্রযুক্তিগত increaseবৃদ্ধি করে এমন কোনও অনুশীলনও লিখে দেয় না ।
ব্রায়ান ওকলি

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

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

9

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

আছে দুটি পৃথক দিক কি আপনি বর্ণনা করতে:

  • সাধারণ বোঝাপড়া / দৃষ্টি হারিয়েছে এবং তাই দক্ষ হচ্ছে না
  • সাফল্য / অগ্রগতি এবং মোট ব্যয় কীভাবে পরিমাপ করা যায়

ভুল পথে নামা বা চেনাশোনাগুলিতে চলছে

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

  1. আপনি খুঁজে পেতে পারেন এমন সমস্ত উচ্চ স্তরের ব্যবহারের কেসগুলি সংগ্রহ করুন you এটিকে কিছু উইকে রাখুন যাতে সমস্ত স্টেকহোল্ডার এবং ডেভস তাদের দেখতে পারে। নতুন কিছু এলে তাদের যুক্ত করুন। আপনার শেয়ারহোল্ডার এবং ব্যবহারকারীদের সাথে কথা বলুন। চূড়ান্ত পণ্যটিতে অবদান রাখে না এমন বা কার্যকরভাবে কাজ করা / হ্যাক যা একটি সমস্যার সমাধান করে তবে তিনটি নতুন সমস্যা সৃষ্টি করে তা বাস্তবায়িত করতে বাধা দেওয়ার জন্য বিকাশের সময় এটিকে চেক তালিকারূপে ব্যবহার করুন।
  2. একটি উচ্চ স্তরের ধারণা তৈরি করুন । আমি ইন্টারফেস বা ক্লাস ডিজাইনিংয়ের কথা বলছি না, তবে এর পরিবর্তে সমস্যা ডোমেনটি স্কেচ করে নিন। চূড়ান্ত সমাধানের মূল উপাদানগুলি, প্রক্রিয়া এবং মিথস্ক্রিয়াগুলি কী কী? আপনার ক্ষেত্রে, এটি স্পষ্ট করে তোলা উচিত যখন jquery-workaround ব্যবহার করা একটি মধ্যবর্তী পদক্ষেপ হিসাবে সহায়তা করে এবং যখন এটি কেবল অতিরিক্ত কাজের কারণ হয়।
  3. আপনি জড়ো তালিকাটি ব্যবহার করে আপনার ধারণাটি বৈধ করুন । এটিতে কোনও সুস্পষ্ট সমস্যা আছে কি? এটা কি কোন মানে আছে? দীর্ঘ সময়ের প্রযুক্তি debtণ না দিয়ে একই ব্যবহারকারীর মূল্য অর্জনের আরও কার্যকর উপায় আছে কি?

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

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

সাফল্য পরিমাপ

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

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

আমার পরামর্শ এখানে:

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

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

কৌশলটি এখানে প্রকল্পের মোট ব্যয়ের সাথে তর্ক করা: উদাহরণস্বরূপ যদি কোনও পিও শর্টকাট নেওয়ার জন্য একটি সময়সীমা তৈরির জন্য চাপ দেয়, তবে প্রকল্পটি সম্পন্ন করার বিষয়টি বিবেচনা করার জন্য কত পরিমাণ কাজ করা উচিত তা পরিমাপ করুন!

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

সারাংশ

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

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

আশা করি এইটি কাজ করবে!


"এটিকে এভাবে ভাবুন: ১০-২০ বছর আগে, লোকেরা দৈত্য চশমা লেখার চেষ্টা করেছিল এবং সব কিছু আগে থেকেই চিন্তা করে দেখেছিল এবং প্রায়শই ব্যর্থ হয়" ": নব্বইয়ের দশক থেকে ব্যবসায়ে এসেছি এবং, ভাল, না, আমরা এর মতো কাজ করি নি did । এটি কেবল একটি পৌরাণিক অতীতের তুলনায় চতুরতার বিপরীতে কেবল বিপণনের একটি সাধারণ জায়গা যেখানে লোকেরা খুব বেশি পরিকল্পনা করে ভুল করে ফেলছিল। খুব বেশি পরিকল্পনা না করা এবং প্রথম দিকে প্রোটোটাইপ তৈরি করা 1998 বা তারও বেশি সময় আগে আমি প্রথম শিখেছি among চৌকস আন্দোলন আংশিকভাবে সুনির্দিষ্ট অনুশীলনের জন্য নতুন শব্দ ব্যবহার করছে এবং সেগুলি নতুন হিসাবে বিপণন করছে।
জর্জিও

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

7

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

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

যদি তারা বলে যে এটিই পরে, তবে আপনি যা করছেন তা হ'ল আপনি তাদের যা চান তা দিচ্ছেন না।

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


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

1
@ এরিক: দুর্দান্ত মন্তব্য। এজন্য আমি প্রথমে _ "তারা" চেয়ে "তাদের চেয়ে" তাদের কী প্রয়োজন তা বোঝার জন্য "" লিখেছিলাম _ তবে আমি দেখতে পাচ্ছি যে এটিতে বেশি জোর দেওয়া হয়নি। আমি আরও কিছুটা জোর এবং ব্যাখ্যা যুক্ত করব। মন্তব্যের জন্য ধন্যবাদ.
ব্রায়ান ওকলে

5

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

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

স্ক্রামে আপনি (বিকাশকারী হিসাবে) আপনার নিজের পরিকল্পনা নিজেই করতে পারেন। কেউ আপনাকে x দিনের মধ্যে কিছু বৈশিষ্ট্য সরবরাহ করতে বলছে না। যদি কেউ আপনাকে x দিনের মধ্যে বিতরণ করতে বলে তবে আপনি স্ক্রাম করছেন না।

সমস্যা যাই হোক না কেন এটি ঠিক করা দরকার, আপনার সময় দাবি করুন। আপনি কি মনে করেন প্রথমে কিছু পুনরায় কাজ করার জন্য আপনার দরকার সময়? এটি আপনার অনুমানের সাথে অন্তর্ভুক্ত করুন। আপনি কি এটা সামর্থ্য করতে পারেন?


3

আসুন আপনি যা করছেন তা পরীক্ষা করে দেখুন, এক মুহুর্তের জন্য এগিলিকে আলাদা করে দিন।

যখন আমরা পরিকল্পনাটি করি, আমরা উন্নয়নের সময়ের ক্ষেত্রে সহজ সমাধানের দিকে এগিয়ে যাই, সুতরাং উদাহরণস্বরূপ যদি আমরা একটি নতুন কথোপকথন বা কিছু তৈরি করি, তবে আমরা পুরানো jqueryটিকে দ্রুত ব্যবহার করি কারণ আমরা বলি যে আমরা পরে ফিরে যাব পরিপাটি করা এবং প্রতিক্রিয়ার রূপান্তর, কিন্তু এটি খুব কমই ঘটে।

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

আপনি সুস্পষ্টভাবে পরিচিত পুরাতন প্রযুক্তির jquery ব্যবহার করার সিদ্ধান্ত নেবেন যা আপনাকে আপনার এক্সপ্রেস লক্ষ্যগুলির (যেমন একটি একক পৃষ্ঠার অ্যাপ্লিকেশন) থেকে আরও দূরে সরিয়ে দেয় । আপনি "দ্রুত" সরবরাহ করার জন্য এটি করেন। এটা ইচ্ছাকৃত।

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

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

আপনি যা করছেন তা খুব বেসিক স্তরে ভুল । এটা খারাপ ইঞ্জিনিয়ারিং !

আপনি এই debtণ পরিশোধ করতে হবে এবং সুদের চার্জ নিতে হবে তা উপেক্ষা করে আপনি প্রযুক্তিগত debtণ গ্রহণ করেছেন । এবং আপনি এটি চালিয়ে যান যতক্ষণ না আপনার intণের সুদের হার আপনার স্প্রিন্ট চলাকালীন আপনার উপলব্ধ কাজটি বন্ধ করতে শুরু করে।

আপনার যা করা উচিত তা হ'ল debtণের স্তর হ্রাস করা । আপনার বসের সাথে কথা বলুন, আপনার ক্লায়েন্টের সাথে কথা বলুন। গতকাল আপনার রক্ষণাবেক্ষণের জন্য কাজ করা দরকার।


2

কেবল চটপটি ব্যবহার বন্ধ করুন ...

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

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

যে কারণে এই অভাব হতে পারে সেগুলি হ'ল:

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

এর সহজ সমাধান হ'ল এই সমস্ত যাদু শব্দের বাদ দেওয়া এবং পরিস্থিতিটির বাস্তবতার দিকে নজর দেওয়া, যা সংক্ষিপ্ত আকারে বলা যেতে পারে:

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

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

এটি বলার পরে, পরিচালকরা জিনিসগুলিকে বাড়িয়ে তোলার জন্য প্রচুর কাজ করতে পারেন:

  1. আপনার ডেভস ডেডমার্কিং ডেডলাইনে to
  2. "চিন্তাভাবনা, একীকরণ এবং গুণমানের রিফ্যাক্টরিং" এর জন্য টিকিট এবং সেগুলির জন্য একটি উদার সময় ভাতা ছাড়াই ডিভগুলি কেবলমাত্র টিকিটের বিপরীতে সময় লগ করতে পারে St
  3. কোনও একটি ব্যক্তিকে দীর্ঘকাল ধরে আর্কিটেকচারের মালিকানা না দেওয়ার পক্ষে এটির একটি হ্যান্ডেল পাওয়া যায়
  4. সেই ব্যক্তিকে তাদের যে পরিবর্তনগুলি প্রয়োজন বলে মনে হচ্ছে তা করার অনুমতি না দেওয়া

এদিকে এটি দেখলে, সহজেই চটজলদি ও স্ক্র্যামের কিছু ব্যাখ্যা আপনাকে আরও দ্রুত এই রুটে নামিয়ে দেবে তা দেখতে সহজ!

একটি পদ্ধতি হ'ল প্রতিটি বিট রিফ্যাক্টরিংয়ের জন্য টিকিট তৈরি করা। সমস্যাটি হ'ল আপনি প্রায়শই বুঝতে পারবেন না যে আপনি একটি ছোট টিকিটের উপর কাজ শুরু না করা পর্যন্ত আপনার একটি বড় রিফ্যাক্টর প্রয়োজন, যা সময়সীমা পিছনে ফেলে দেয় এবং এটি টিকিট অনুমোদনের মধ্য দিয়ে যায় এটি কেবল সবকিছু ধীর করে দেয়।

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

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


-1

আপনি কোন ভুল করছেন না। এই ধরণের পদ্ধতিটি বৈশিষ্ট্যগুলিকে বৈশিষ্ট্যগুলি সরবরাহ করার জন্য এবং যত দ্রুত সম্ভব নকশাকৃত।

যদি আপনার গৌণ লক্ষ্য থাকে যে দিকে আপনি কাজ করছেন তবে তাদেরকে 'অ-কার্যকরী প্রয়োজনীয়তা' বা 'সম্পন্নের সংজ্ঞা' হিসাবে প্রকাশ করার পক্ষে সেরা।

উদাহরণস্বরূপ, আপনার একটি অ-কার্যকরী প্রয়োজন থাকতে পারে:

"সমস্ত নতুন বৈশিষ্ট্য অবশ্যই প্রতিক্রিয়াতে লেখা উচিত"

এবং

"সমস্ত অ্যাসিনক্রোনাস কল অবশ্যই একটি লোডিং স্পিনার এবং ত্রুটি পরিচালনার ক্ষেত্রে প্রয়োগ করতে পারে"

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


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

দুঃখিত, ইঞ্জিনিয়ারড এবং দেরীতে বৈশিষ্ট্যগুলি সরবরাহ করার বিষয়ে আমি এটি অনুমান করি?
ইভান

না সত্যিই না. স্ক্রাম একটি উচ্চ দৃশ্যমান, পুনরাবৃত্ত ফ্যাশনে উচ্চ মানের সফ্টওয়্যার সরবরাহ করতে গ্রাহকের সাথে কাজ করার বিষয়ে। স্ক্রাম সঠিক ইঞ্জিনিয়ারিং না করে নিম্নমানের বৈশিষ্ট্য সরবরাহ সম্পর্কে কিছুই বলে না।
ব্রায়ান ওকলে

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

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