Claude Code টাস্ক স্কোপিং: অস্পষ্ট অনুরোধ থেকে কমিট পর্যন্ত

কেন অস্পষ্ট ফিচার রিকোয়েস্ট সময় নষ্ট করে

একটা অস্পষ্ট অনুরোধ ক্ষতিকর বলে মনে নাও হতে পারে: “Add a better search,” “Make onboarding smoother,” “Users need notifications.” বাস্তব দলের মধ্যে এটি প্রায়ই এক লাইনের চ্যাট মেসেজ, তীর সহ একটি স্ক্রিনশট, বা অর্ধেক স্মৃতিশক্তির একটি কাস্টমার কল হিসেবে আসে। সবাই সম্মত, কিন্তু প্রত্যেকে ভিন্ন কিছু কল্পনা করে।

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

আপনি সাধারণত একটি অসম্পূর্ণ টাস্ক দ্রুত চিনতে পারবেন:

• ব্যবহারকারী কি করতে পারবে তার ধাপে ধাপে উদাহরণ নেই
• কোন এজ কেস নেই (খালি স্টেট, পারমিশন, এরর)
• “জাস্ট ইন কেস” কাজ যা বড় PR এ নিয়ে যায়
• রিভিউ মন্তব্যগুলো বাস্তব আচরণ নিয়ে, বাস্তবায়ন নিয়ে নয়
• “আমরা ধীরে ধীরে ঠিক করে নেব” পরিকল্পনা হয়ে যায়

একটা ভালভাবে স্কোপ করা টাস্ক টিমকে একটি ফিনিশ লাইন দেয়: স্পষ্ট অ্যাকসেপ্টেন্স ক্রাইটেরিয়া, একটি মিনিমাল UI ও API পরিকল্পনা, এবং কি অন্তর্ভুক্ত নয় তার স্পষ্ট সীমানা। এটাই “improve search” এবং একটি ছোট পরিবর্তনের মধ্যে পার্থক্য যা তৈরি ও রিভিউ করা সহজ।

একটি বাস্তব অভ্যাস: “definition of done” কে “nice-to-have” থেকে আলাদা করুন। “Done” হল কিছু সংক্ষিপ্ত চেক তালিকা যা আপনি চালাতে পারবেন (উদাহরণ: “Search টাইটেল দ্বারা রেজাল্ট ফেরত দেয়, খালি হলে ‘No results’ দেখায়, এবং কুয়েরিটি URL-এ থাকে”)। “Nice-to-have” হলো পরে করা যায় এমন সব (সিনোনিম, র‍্যাংকিং টুইক, হাইলাইটিং, অ্যানালিটিক্স)। এগুলো আগে থেকেই লেবেল করলে দুর্ঘটনাবশত স্কোপ বাড়া প্রতিরোধ হয়।

ফলাফল দিয়ে শুরু করুন, সমাধান দিয়ে নয়

অস্পষ্ট অনুরোধ প্রায়ই প্রস্তাবিত ফিক্স হিসেবে শুরু হয়: “Add a button,” “Switch to a new flow,” “Use a different model.” থামুন এবং প্রথমে সুপারিশকে একটি ফলাফলে অনুবাদ করুন।

একটি সহজ ফরম্যাট সাহায্য করে: “As a [user], I want to [do something], so I can [reach a goal].” সরল রাখুন। যদি এক শ্বাসে না বলা যায়, তবে এটা এখনও খুব অস্পষ্ট।

এরপর বর্ণনা করুন ব্যবহারকারীর জন্য কী পরিবর্তন হবে যখন এটি করা হবে। দৃশ্যমান আচরণে ফোকাস করুন, বাস্তবায়নের বিবরণে নয়। উদাহরণ: “ফর্ম সাবমিট করার পরে, আমি একটি কনফার্মেশন দেখি এবং তালিকায় নতুন রেকর্ড খুঁজে পাই।” এটি একটি স্পষ্ট ফিনিশ লাইন তৈরি করে এবং “আরো একটা টুইক” স্লিপ ইন করা কঠিন করে তোলে।

কি অপরিবর্তিত থাকবে তাও লিখে রাখুন। নন-গোলস আপনার স্কোপকে রক্ষা করে। যদি অনুরোধ হয় “improve onboarding,” একটি নন-গোল হতে পারে “কোন ড্যাশবোর্ড রিডিজাইন নয়” বা “কোন প্রাইসিং-টিয়ার লজিক পরিবর্তন নয়।”

অবশেষে, প্রথমে একটি প্রধান পাথ নির্বাচন করুন: যে একক end-to-end স্লাইসটি ফিচার কাজ করে তা প্রমাণ করে।

উদাহরণ: “add snapshots everywhere” এর বদলে লিখুন: “As a project owner, I can restore the latest snapshot of my app, so I can undo a bad change.” নন-গোলস: “no bulk restore, no UI redesign.”

সামান্য প্রশ্ন করুন যা অস্পষ্টতা দূর করে

একটি অস্পষ্ট অনুরোধ সাধারণত প্রচেষ্টা নেই বলে নয়—এটি সিদ্ধান্তের অভাব।

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

তারপর একটি কনক্রিট উদাহরণ জিজ্ঞাসা করুন। একটি স্ক্রিনশট, প্রতিদ্বন্দীর আচরণ, বা আগের টিকিট দেখায় “better” আসলে কী। যদি রিকোয়েস্টার কাছে কিছুই না থাকে, তাদের বলুন শেষবার কবে ব্যথা অনুভব করেছিলেন তা পুনরায় বলুন: তারা কোন স্ক্রিনে ছিল, কি ক্লিক করেছিল, এবং কি আশা করেছিল।

এজ কেসেই স্কোপ ফুলে ওঠে, তাই বড়গুলো আগে নাম করুন: খালি ডেটা, ভ্যালিডেশন এরর, ধীর বা ব্যর্থ নেটওয়ার্ক কল, এবং “undo” আসলে কি বোঝায়।

অবশেষে, সিদ্ধান্ত নিন কীভাবে আপনি সফলতা যাচাই করবেন। টেস্টেবল আউটকাম না থাকলে টাস্ক মতামতে পরিণত হয়।

এই পাঁচটি প্রশ্ন সাধারণত বেশিরভাগ অস্পষ্টতা দূর করে:

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

উদাহরণ: “Add custom domains for clients” ভিজিবল হয়ে ওঠে যখন আপনি ঠিক করেন কোন টিয়ার এটি পাবে, কে সেট আপ করতে পারবে, হোস্টিং লোকেশন কমপ্লায়েন্সে প্রভাব ফেলে কি না, invalid DNS-এ কী এরর দেখাবে, এবং “done” মানে কী (ডোমেইন ভেরিফায়েড, HTTPS অ্যাক্টিভ, এবং একটি নিরাপদ রোলব্যাক প্ল্যান)।

এলোমেলো নোটকে অ্যাকসেপ্টেন্স ক্রাইটেরিয়ায় রূপান্তর করুন

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

একটি সরল প্যাটার্ন এটিকে পরিষ্কার রাখে। আপনি Given/When/Then ব্যবহার করতে পারেন, অথবা এগুলোর সমতুল্য সংক্ষিপ্ত পয়েন্ট।

একটি দ্রুত অ্যাকসেপ্টেন্স-ক্রাইটেরিয়া টেমপ্লেট

প্রতিটি ক্রাইটেরিয়াকে একটি একক টেস্ট হিসেবে লিখুন যা কেউ চালাতে পারবে:

• Given একটি আরম্ভিক অবস্থা, when ব্যবহারকারী X করে, then Y ঘটে।
• ভ্যালিডেশন রুল অন্তর্ভুক্ত করুন (কোন ইনপুট অনুমোদিত)।
• অন্তত একটি ব্যর্থ কেস অন্তর্ভুক্ত করুন (ব্যবহারকারী কি ত্রুটি দেখবে)।
• “ডান সিগনাল” সংজ্ঞায়িত করুন (QA কী চেক করবে, রিভিউয়াররা কী আশা করবে)।

এখন এটি প্রয়োগ করুন। ধরুন নোট বলে: “Make snapshots easier. I want to roll back if the last change breaks things.” এটিকে টেস্টেবল বিবৃতিতে বদলে দিন:

• Given একটি প্রজেক্টে ২টি স্ন্যাপশট আছে, যখন আমি Snapshots খুলি, তখন আমি দুটোই দেখতে পাই সময় এবং ছোট লেবেল সহ।
• Given একটি স্ন্যাপশট, যখন আমি Roll back এ ক্লিক করে কনফার্ম করি, তখন প্রকল্পটি সেই স্ন্যাপশটে ফিরে আসে এবং অ্যাপ সফলভাবে বিল্ড হয়।
• Given আমি প্রজেক্ট মালিক নই, যখন আমি রোলব্যাক করতে গেলে, তখন আমি একটি এরর দেখি এবং কিছুই পরিবর্তন হয় না।
• Given একটি রোলব্যাক চলছে, যখন আমি পেজ রিফ্রেশ করি, তখনও স্ট্যাটাস এবং চূড়ান্ত ফলাফল দেখতে পাই।
• Given একটি রোলব্যাক ব্যর্থ হয়, যখন এটি থামে, তখন আমি একটি স্পষ্ট বার্তা দেখি এবং বর্তমান ভার্সন সক্রিয় থাকে।

যদি QA এই চেকগুলো চালাতে পারে এবং রিভিউয়ারেরা UI ও লগে যাচাই করতে পারে, আপনি UI ও API কাজ পরিকল্পনা করে ছোট কমিটে ভাগ করার জন্য প্রস্তুত।

একটি মিনিমাল UI পরিকল্পনা খসড়া করুন

মিনিমাল UI পরিকল্পনা হল একটি প্রমিজ: সবচেয়ে ছোট দৃশ্যমান পরিবর্তন যা ফিচারটি কাজ করে তা প্রমাণ করে।

কোন স্ক্রীনগুলো বদলাবে এবং ১০ সেকেন্ডে একজন ব্যক্তি কী লক্ষ্য করবে তা নাম দিয়ে শুরু করুন। যদি অনুরোধ বলে “make it easier” বা “clean it up,” সেটাকে একটি কংক্রিট পরিবর্তনে অনুবাদ করুন।

একটি ছোট মানচিত্র হিসেবে লিখুন, সম্পূর্ণ রিডিজাইন নয়। উদাহরণ: “Orders page: সর্ট টেবিলের উপরে একটি filter bar যোগ করুন,” অথবা “Settings: Notifications এর নিচে একটি নতুন toggle যোগ করুন.” যদি আপনি স্ক্রিন নাম ও সুনির্দিষ্ট উপাদান বলতে না পারেন, তবে স্কোপ এখনও অস্পষ্ট।

মূল UI স্টেটগুলো সংজ্ঞায়িত করুন

অধিকাংশ UI পরিবর্তনের কিছু প্রচলিত স্টেট লাগে। কেবল প্রযোজ্য গুলোই লিখুন:

• Loading
• Empty
• Error (এবং retry আছে কি না)
• Success (toast, inline message, আপডেট হওয়া তালিকা)

ব্যবহারকারীরা যে শব্দগুলো দেখবে তা নিশ্চিত করুন

UI কপি স্কোপের অংশ। অনুমোদিত হওয়া দরকার এমন লেবেল এবং মেসেজগুলো ধরুন: বাটন টেক্সট, ফিল্ড লেবেল, হেল্পার টেক্সট, এবং এরর মেসেজ। যদি শব্দচয়ন এখনও খোলা থাকে, তবে তা প্লেসহোল্ডার হিসেবে চিহ্নিত করুন এবং দেখান কে নিশ্চিত করবে।

যে কোন জিনিস যা ফিচার ব্যবহার করতে বাধ্যতামূলক নয় তাকে “নট নাউ” তালিকায় রাখুন (রেসপন্সিভ পলিশ, অ্যাডভান্সড সোর্টিং, অ্যানিমেশন, নতুন আইকন)।

একটি মিনিমাল API ও ডেটা পরিকল্পনা খসড়া করুন

একটি স্কোপড টাস্কের জন্য UI, ব্যাকএন্ড, এবং ডেটার মধ্যে একটি ছোট, স্পষ্ট কনট্রাক্ট দরকার। উদ্দেশ্য পুরো সিস্টেম ডিজাইন করা নয়—এটি হলো সবচেয়ে ছোট GET/POST সেট যা ফিচার কাজ করে তা প্রমাণ করবে।

প্রথমে তালিকা করুন আপনি কোন ডেটা লাগবে এবং তা কোথা থেকে আসবে: বিদ্যমান ফিল্ড যা পড়া যাবে, নতুন ফিল্ড যা সংরক্ষণ করতে হবে, এবং কোন ভ্যালু আপনি কম্পিউট করতে পারবেন। যদি প্রতিটি ফিল্ডের উৎস আপনি বলতে না পারেন, আপনার পরিকল্পনা নেই।

API সারফেস ছোট রাখুন। অনেক ফিচারের জন্য একটি রিড এবং একটি রাইট যথেষ্ট:

• GET /items/{id} রেন্ডার করার জন্য প্রয়োজনীয় স্টেট রিটার্ন করে
• POST /items/{id}/update শুধু ব্যবহারকারী যা বদলাতে পারে সেটাই গ্রহণ করে এবং আপডেটেড স্টেট রিটার্ন করে

ইনপুট এবং আউটপুটগুলো প্লেইন অবজেক্ট হিসেবে লিখুন, প্যারাগ্রাফে নয়। রিকয়ারড বনাম অপশনাল ফিল্ড এবং সাধারণ এরর হলে কী হবে (not found, validation failed) লিখুন।

ডাটাবেসে স্পর্শ করার আগে দ্রুত অথ পাস করুন। কে পড়তে পারে এবং কে লিখতে পারে তা এক বাক্যে লিখে ফেলুন (উদাহরণ: “any signed-in user can read, only admins can write”)। এটাই না করলে পরে রিওয়ার্ক হয়।

শেষে ঠিক করুন কি সংরক্ষণ করতে হবে এবং কি গণনা করা যাবে। সহজ নিয়ম: ফ্যাক্টগুলো সংরক্ষণ করুন, ভিউগুলো গণনা করুন।

Claude Code ব্যবহার করে একটি স্কোপড টাস্ক তৈরি করুন

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

1. স্বাভাবিক ভাষায় স্কোপ পুনর্বক্তি এবং একটি সংক্ষিপ্ত অ্যাকসেপ্টেন্স-ক্রাইটেরিয়া চেকলিস্ট।
2. ৩–৭টি কমিটের ছোট সিকুয়েন্স, প্রতিটির একটা স্পষ্ট আউটকাম।
3. প্রতিটি কমিটে সম্ভাব্য টাচ করা ফাইল/ফোল্ডারের তালিকা এবং তাদের ভেতরে কী বদলাবে।
4. প্রতিটি কমিটের জন্য দ্রুত টেস্ট প্ল্যান (একটি হ্যাপি পাথ এবং একটি এজ কেস)।
5. স্পষ্ট আউট-অফ-স্কোপ নোট।

তারপর এটি রেস্পন্স দিলে, পুনরায় রিভিউ করে দেখুন। যদি আপনি “improve performance” বা “make it cleaner” মতো শব্দ দেখেন, পরিমাপযোগ্য ভাষায় পুনরায় দাবি করুন।

একটি ছোট উদাহরণ (“ভাল” কেমন দেখায়)

রিকোয়েস্ট: “Add a way to pause a subscription.”

একটি স্কোপড ভার্সন বলতে পারে: “User can pause for 1 to 3 months; next billing date updates; admin can see pause status,” এবং আউট-অফ-স্কোপ: “No proration changes.”

এরপর কমিট প্ল্যান বাস্তবসম্মত হয়ে ওঠে: এক কমিট DB ও API শেপের জন্য, এক কমিট UI কন্ট্রোলের জন্য, এক কমিট ভ্যালিডেশন ও এরর স্টেটের জন্য, এবং এক কমিট end-to-end টেস্টের জন্য।

কাজগুলোকে ছোট, রিভিউযোগ্য কমিটে ভাগ করুন

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

উপযোগী নিয়ম: প্রতিটি কমিটে এক নতুন আচরণ আনলক করুন, এবং তা প্রমান করার একটি দ্রুত উপায় রাখুন।

একটি সাধারণ সিকুয়েন্স দেখায়:

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

প্রতিটি কমিট ফোকাসড রাখুন। “While I was here” রিফ্যাক্টরগুলো এড়িয়ে চলুন। UI যদি বেসিকই থাকুক, পুরো অ্যাপটি end-to-end কাজ করুক। মাইগ্রেশন, আচরণ, এবং UI একক কমিটে বেঁধে দেবেন না যখন না অবশ্য কারণ থাকে।

ওয়াকথ্রু: “Export reports”

একজন স্টেকহোল্ডার বলে: “Can we add Export reports?” এর মধ্যে অনেক পছন্দ লুকানো থাকে: কোন রিপোর্ট, কোন ফরম্যাট, কে এক্সপোর্ট করবে, ডেলিভারি কেমন হবে।

কেবল সেই প্রশ্নগুলো জিজ্ঞাসা করুন যা ডিজাইন বদলাবে:

• v1-এ কোন রিপোর্ট টাইপ অন্তর্ভুক্ত?
• v1-এ কোন ফরম্যাট প্রয়োজন (CSV, PDF)?
• কে এক্সপোর্ট করতে পারবে (admins, নির্দিষ্ট রোল)?
• এটা ডাইরেক্ট ডাউনলোড না ইমেইলে পাঠানো?
• কোনো সীমা আছে কি (ডেট রেঞ্জ ম্যাক্স, রো কাউন্ট ক্যাপ, টাইমআউট)?

ধরা যাক উত্তরগুলো: “Sales Summary report, CSV only, manager role, direct download, last 90 days max.” এখন v1 অ্যাকসেপ্টেন্স ক্রাইটেরিয়া স্পষ্ট: ম্যানেজাররা Sales Summary পেজে Export ক্লিক করলে CSV ডাউনলোড হবে; CSV টেবিলের কলামগুলোর সাথে মিলে; এক্সপোর্ট বর্তমান ফিল্টার রিসপেক্ট করবে; ৯০ দিনের বেশি সিলেক্ট করলে একটি স্পষ্ট এরর দেখাবে; ৫০k রো পর্যন্ত ৩০ সেকেন্ডে ডাউনলোড সম্পন্ন হবে।

মিনিমাল UI প্ল্যান: টেবিল অ্যাকশনের কাছে একটি Export বাটন, জেনারেট হওয়ার সময় একটি লোডিং স্টেট, এবং একটি এরর মেসেজ যা বলে ব্যবহারকারী কী করবে (যেমন “Choose 90 days or less”)।

মিনিমাল API প্ল্যান: একটি এন্ডপয়েন্ট যা ফিল্টার নেয় এবং জেনারেট করা CSV ফাইল হিসেবে রিটার্ন করে, টেবিলের একই কোয়েরি পুনরায় ব্যবহার করে এবং সার্ভার-সাইডে ৯০-দিন বিধি প্রয়োগ করে।

পরে এটাকে কয়েকটি টাইট কমিটে পাঠান: প্রথমে একটি স্থির হ্যাপি-পাথের জন্য এন্ডপয়েন্ট, তারপর UI ওয়্যারিং, তারপর ভ্যালিডেশন এবং ব্যবহারকারী-ফেসিং এরর, তারপর টেস্ট ও ডকুমেন্টেশন।

সাধারণ স্কোপিং ভুল (এবং কিভাবে এড়াবেন)

লুকানো রিকোয়্যারমেন্টস ঢুকে পড়ে

“add team roles” ধরনের রিকোয়েস্ট অনেক সময় ইনভাইট, এডিট, এবং বিদ্যমান ব্যবহারকারীদের কী হয় এসব রুল লুকায়। যদি আপনি অনুমান করতে শুরু করেন, সেই অনুমানগুলো লিখে রাখুন এবং প্রশ্ন হিসেবে তোলুন বা স্পষ্ট নিয়মনীতিতে পরিণত করুন।

UI পলিশ মূল আচরণের সাথে মিশে যায়

একই টাসকে “কাজটিকে কাজ করা” এবং “দেখতে সুন্দর করা” একসাথে রাখলে দিন হারিয়ে যায়। প্রথম টাস্ককে আচরণ ও ডেটায় ফোকাস রাখতে বলুন। স্টাইলিং, অ্যানিমেশন, এবং স্পেসিং ফলো-আপ টাস্কে রাখুন যদি না তা ফিচার ব্যবহার করার জন্য অপরিহার্য।

আপনি v1-এ সব এজ কেস সলভ করার চেষ্টা করছেন

এজ কেসগুলাই গুরুত্বপূর্ণ, কিন্তু সবকটাকে প্রথমে সমাধান করতে হবে না। ভরসা ভাঙে এমন কিছুকে কভার করুন (ডাবল সাবমিট, conflicting edits) এবং বাকি গুলো স্পষ্ট নোট দিয়ে পরবর্তী পর্যায়েও সরিয়ে নিন।

এরর স্টেট এবং পারমিশন পরে রাখাটা বিপজ্জনক

যদি আপনি লিখে না রাখেন, আপনি ভুলি। অন্তত একটি আনহ্যাপি-পাথ এবং অন্তত একটি পারমিশন রুল অ্যাকসেপ্টেন্স ক্রাইটেরিয়ায় রাখুন।

যাচাই করা যায় না এমন ক্রাইটেরিয়া

“Fast” বা “intuitive” মতো শব্দগুলো ব্যবহার করা থেকে বিরত থাকুন যতক্ষণ না আপনি একটি সংখ্যা বা কনক্রিট চেক যোগ না করেন। তাদের বদলে এমন কিছু রাখুন যা রিভিউতে প্রমাণ করা যায়।

কোড করা শুরু করার আগে দ্রুত চেকলিস্ট

টাস্কটি ঠিক করে পিন করুন যাতে একজন টিমমেট রিভিউ ও টেস্ট করতে পারে মাইন্ড-রিডিং ছাড়া:

• আউটকাম এবং নন-গোলস: আউটকাম এক বাক্যে এবং ১–৩টি স্পষ্ট নন-গোলস।
• অ্যাকসেপ্টেন্স ক্রাইটেরিয়া: ৫–১০টি টেস্টেবল চেকসাধারণ ভাষায়।
• UI স্টেট: মিনিমাম লোডিং, খালি, এরর, এবং সাকসেস স্টেট।
• API ও ডেটা নোট: সবচেয়ে ছোট এন্ডপয়েন্ট শেপ এবং যেসব ডেটা বদলাবে, এবং কে পড়তে/লিখতে পারবে।
• কমিট প্ল্যান সহ টেস্ট: ৩–৭টি কমিট, প্রতিটিতে দ্রুত প্রুফ।

উদাহরণ: “Add saved searches” হয়ে যায় “Users can save a filter and reapply it later,” নন-গোলস: “no sharing” এবং “no sorting changes.”

পরবর্তী ধাপ: তৈরি করার সময় স্কোপ স্থির রাখা

একবার আপনার কাছে একটি স্কোপড টাস্ক থাকলে, তাকে রক্ষা করুন। কোডিং শুরু করার আগে দ্রুত সংশ্লিষ্টদের সাথে স্যানিটি রিভিউ করুন:

• অ্যাকসেপ্টেন্স ক্রাইটেরিয়া পড়ে দেখুন এটি আউটকামটির সাথে মেলে কি না।
• পারমিশন, খালি স্টেট, এবং ফেলিওর আচরণ কনফার্ম করুন।
• আউট-অফ-স্কোপ আবার কনফার্ম করুন।
• যেটুকু UI ও API-চেঞ্জ ক্ষুদ্র হলেও সেটাই সম্মত করুন যা ক্রাইটেরিয়া পূরণ করে।
• নির্ধারণ করুন কিভাবে ডেমো করবেন এবং “ডান হওয়া” কি দেখতে হবে।

তারপর ক্রাইটেরিয়া সেখানে সংরক্ষণ করুন যেখানে কাজ হয়: টিকিটে, PR বর্ণনায়, এবং টিম যেখানে দেখে।

If you’re building in Koder.ai (koder.ai), it helps to lock the plan first and then generate code from it. Planning Mode is a good fit for that workflow, and snapshots and rollback can keep experiments safe when you need to try an approach and back it out.

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