১৪ ডিসে, ২০২৫·6 মিনিট
Claude Code টাস্ক স্কোপিং: অস্পষ্ট অনুরোধ থেকে কমিট পর্যন্ত
Claude Code টাস্ক স্কোপিং শিখুন: এলোমেলো ফিচার রিকোয়েস্টকে স্পষ্ট অ্যাকসেপ্টেন্স ক্রাইটেরিয়া, একটি মিনিমাল UI/API পরিকল্পনা, এবং কয়েকটি ছোট কমিটে কিভাবে বদলায়।
Claude Code টাস্ক স্কোপিং শিখুন: এলোমেলো ফিচার রিকোয়েস্টকে স্পষ্ট অ্যাকসেপ্টেন্স ক্রাইটেরিয়া, একটি মিনিমাল UI/API পরিকল্পনা, এবং কয়েকটি ছোট কমিটে কিভাবে বদলায়।
একটা অস্পষ্ট অনুরোধ ক্ষতিকর বলে মনে নাও হতে পারে: “Add a better search,” “Make onboarding smoother,” “Users need notifications.” বাস্তব দলের মধ্যে এটি প্রায়ই এক লাইনের চ্যাট মেসেজ, তীর সহ একটি স্ক্রিনশট, বা অর্ধেক স্মৃতিশক্তির একটি কাস্টমার কল হিসেবে আসে। সবাই সম্মত, কিন্তু প্রত্যেকে ভিন্ন কিছু কল্পনা করে।
খরচ পরে দেখা দেয়। যখন স্কোপ অস্পষ্ট থাকে, মানুষ অনুমান করে কাজ করে। প্রথম ডেমো আরেক দফা ক্লারিফিকেশনে পরিণত হয়: “এটাই আমি চাইনি।” কাজ পুনরায় করা হয়, এবং পরিবর্তন টেপে বাড়তে থাকে। ডিজাইন টুইকের ফলে কোড বদলায়, যা আরও টেস্টিং ডেকে আনে। রিভিউ ধীর হয় কারণ অস্পষ্ট পরিবর্তন যাচাই করা কঠিন। যদি কেউই “সঠিক” কেমন তা সংজ্ঞায়িত করতে না পারে, রিভিউয়াররা আচরণ নিয়ে বিতর্ক করে, গুণগত মান যাচাই করার বদলে।
আপনি সাধারণত একটি অসম্পূর্ণ টাস্ক দ্রুত চিনতে পারবেন:
একটা ভালভাবে স্কোপ করা টাস্ক টিমকে একটি ফিনিশ লাইন দেয়: স্পষ্ট অ্যাকসেপ্টেন্স ক্রাইটেরিয়া, একটি মিনিমাল 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 ব্যবহার করতে পারেন, অথবা এগুলোর সমতুল্য সংক্ষিপ্ত পয়েন্ট।
প্রতিটি ক্রাইটেরিয়াকে একটি একক টেস্ট হিসেবে লিখুন যা কেউ চালাতে পারবে:
এখন এটি প্রয়োগ করুন। ধরুন নোট বলে: “Make snapshots easier. I want to roll back if the last change breaks things.” এটিকে টেস্টেবল বিবৃতিতে বদলে দিন:
যদি QA এই চেকগুলো চালাতে পারে এবং রিভিউয়ারেরা UI ও লগে যাচাই করতে পারে, আপনি UI ও API কাজ পরিকল্পনা করে ছোট কমিটে ভাগ করার জন্য প্রস্তুত।
মিনিমাল UI পরিকল্পনা হল একটি প্রমিজ: সবচেয়ে ছোট দৃশ্যমান পরিবর্তন যা ফিচারটি কাজ করে তা প্রমাণ করে।
কোন স্ক্রীনগুলো বদলাবে এবং ১০ সেকেন্ডে একজন ব্যক্তি কী লক্ষ্য করবে তা নাম দিয়ে শুরু করুন। যদি অনুরোধ বলে “make it easier” বা “clean it up,” সেটাকে একটি কংক্রিট পরিবর্তনে অনুবাদ করুন।
একটি ছোট মানচিত্র হিসেবে লিখুন, সম্পূর্ণ রিডিজাইন নয়। উদাহরণ: “Orders page: সর্ট টেবিলের উপরে একটি filter bar যোগ করুন,” অথবা “Settings: Notifications এর নিচে একটি নতুন toggle যোগ করুন.” যদি আপনি স্ক্রিন নাম ও সুনির্দিষ্ট উপাদান বলতে না পারেন, তবে স্কোপ এখনও অস্পষ্ট।
অধিকাংশ UI পরিবর্তনের কিছু প্রচলিত স্টেট লাগে। কেবল প্রযোজ্য গুলোই লিখুন:
UI কপি স্কোপের অংশ। অনুমোদিত হওয়া দরকার এমন লেবেল এবং মেসেজগুলো ধরুন: বাটন টেক্সট, ফিল্ড লেবেল, হেল্পার টেক্সট, এবং এরর মেসেজ। যদি শব্দচয়ন এখনও খোলা থাকে, তবে তা প্লেসহোল্ডার হিসেবে চিহ্নিত করুন এবং দেখান কে নিশ্চিত করবে।
যে কোন জিনিস যা ফিচার ব্যবহার করতে বাধ্যতামূলক নয় তাকে “নট নাউ” তালিকায় রাখুন (রেসপন্সিভ পলিশ, অ্যাডভান্সড সোর্টিং, অ্যানিমেশন, নতুন আইকন)।
একটি স্কোপড টাস্কের জন্য 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 সবচেয়ে ভালো কাজ করে যখন আপনি একটি পরিষ্কার লক্ষ্য এবং একটি টাইট বক্স দেন। এলোমেলো অনুরোধ এবং যে কোন কনস্ট্রেইন্ট (ডেডলাইন, প্রভাবিত ব্যবহারকারী, ডেটা রুল) পেস্ট করে দিন। তারপর একটি স্কোপড আউটপুট বলুন যাতে থাকে:
তারপর এটি রেস্পন্স দিলে, পুনরায় রিভিউ করে দেখুন। যদি আপনি “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 টেস্টের জন্য।
বড় পরিবর্তনগুলো বাগ লুকায়। ছোট কমিট রিভিউ দ্রুত করে, রোলব্যাক নিরাপদ করে, এবং আপনাকে দেখতে সাহায্য করে কখন আপনি অ্যাক্সেপ্টেন্স ক্রাইটেরিয়া থেকে সরে যাচ্ছেন।
উপযোগী নিয়ম: প্রতিটি কমিটে এক নতুন আচরণ আনলক করুন, এবং তা প্রমান করার একটি দ্রুত উপায় রাখুন।
একটি সাধারণ সিকুয়েন্স দেখায়:
প্রতিটি কমিট ফোকাসড রাখুন। “While I was here” রিফ্যাক্টরগুলো এড়িয়ে চলুন। UI যদি বেসিকই থাকুক, পুরো অ্যাপটি end-to-end কাজ করুক। মাইগ্রেশন, আচরণ, এবং UI একক কমিটে বেঁধে দেবেন না যখন না অবশ্য কারণ থাকে।
একজন স্টেকহোল্ডার বলে: “Can we add Export reports?” এর মধ্যে অনেক পছন্দ লুকানো থাকে: কোন রিপোর্ট, কোন ফরম্যাট, কে এক্সপোর্ট করবে, ডেলিভারি কেমন হবে।
কেবল সেই প্রশ্নগুলো জিজ্ঞাসা করুন যা ডিজাইন বদলাবে:
ধরা যাক উত্তরগুলো: “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” ধরনের রিকোয়েস্ট অনেক সময় ইনভাইট, এডিট, এবং বিদ্যমান ব্যবহারকারীদের কী হয় এসব রুল লুকায়। যদি আপনি অনুমান করতে শুরু করেন, সেই অনুমানগুলো লিখে রাখুন এবং প্রশ্ন হিসেবে তোলুন বা স্পষ্ট নিয়মনীতিতে পরিণত করুন।
একই টাসকে “কাজটিকে কাজ করা” এবং “দেখতে সুন্দর করা” একসাথে রাখলে দিন হারিয়ে যায়। প্রথম টাস্ককে আচরণ ও ডেটায় ফোকাস রাখতে বলুন। স্টাইলিং, অ্যানিমেশন, এবং স্পেসিং ফলো-আপ টাস্কে রাখুন যদি না তা ফিচার ব্যবহার করার জন্য অপরিহার্য।
এজ কেসগুলাই গুরুত্বপূর্ণ, কিন্তু সবকটাকে প্রথমে সমাধান করতে হবে না। ভরসা ভাঙে এমন কিছুকে কভার করুন (ডাবল সাবমিট, conflicting edits) এবং বাকি গুলো স্পষ্ট নোট দিয়ে পরবর্তী পর্যায়েও সরিয়ে নিন।
যদি আপনি লিখে না রাখেন, আপনি ভুলি। অন্তত একটি আনহ্যাপি-পাথ এবং অন্তত একটি পারমিশন রুল অ্যাকসেপ্টেন্স ক্রাইটেরিয়ায় রাখুন।
“Fast” বা “intuitive” মতো শব্দগুলো ব্যবহার করা থেকে বিরত থাকুন যতক্ষণ না আপনি একটি সংখ্যা বা কনক্রিট চেক যোগ না করেন। তাদের বদলে এমন কিছু রাখুন যা রিভিউতে প্রমাণ করা যায়।
টাস্কটি ঠিক করে পিন করুন যাতে একজন টিমমেট রিভিউ ও টেস্ট করতে পারে মাইন্ড-রিডিং ছাড়া:
উদাহরণ: “Add saved searches” হয়ে যায় “Users can save a filter and reapply it later,” নন-গোলস: “no sharing” এবং “no sorting changes.”
একবার আপনার কাছে একটি স্কোপড টাস্ক থাকলে, তাকে রক্ষা করুন। কোডিং শুরু করার আগে দ্রুত সংশ্লিষ্টদের সাথে স্যানিটি রিভিউ করুন:
তারপর ক্রাইটেরিয়া সেখানে সংরক্ষণ করুন যেখানে কাজ হয়: টিকিটে, 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.
নতুন আইডিয়া তৈরি হলে মাঝেমাঝে, স্কোপ স্থিতিশীল রাখুন: সেগুলোকে একটি ফলো-আপ লিস্টে লিখে রাখুন, যদি নতুনটি অ্যাক্সেপ্টেন্স ক্রাইটেরিয়া বদলে দেয় তাহলে রি-স্কোপ করুন, এবং প্রতিটি কমিটকে একটি ক্রাইটেরিয়ার সাথে টাইট রাখুন।
প্রথমে এক বাক্যে আউটকাম লিখুন (ফিচার শেষ হলে ব্যবহারকারী কি করতে পারবে), তারপর 3–7টি অ্যাকসেপ্টেন্স ক্রাইটেরিয়া যোগ করুন যা QA টেস্টার টেস্ট করতে পারবে।
যদি আপনি ঠিক করে বলতে না পারেন যে “সঠিক” আচরণটি কেমন, এবং সেটি নিয়ে বিতর্ক শুরু হয়, তবে টাস্কটি এখনও অস্পষ্ট আছে।
এই দ্রুত ফরম্যাট ব্যবহার করুন:
তারপর একটি নির্দিষ্ট উদাহরণ যোগ করুন যে প্রত্যাশিত আচরণটি কেমন হবে। যদি কোনো উদাহরণ না দিতে পারেন, তাহলে স্মরণ করুন সর্বশেষ কখন সমস্যা হয়েছে: ব্যবহারকারী কোন স্ক্রিনে ছিল, কী ক্লিক করেছিল, এবং কী আশা করেছিল।
সংক্ষিপ্ত “Definition of done” তালিকা প্রথমে লিখুন (কোন চেকগুলো অবশ্যই পাস করতে হবে), তারপর আলাদা “Nice-to-have” তালিকা রাখুন।
ডিফল্ট নিয়ম: যদি কোন অংশ end-to-end কাজ প্রমাণ করতে প্রয়োজন না হয়, সেটা nice-to-have-এ চলে যাবে।
স্কোপ বদলাতে পারে এমন কয়েকটি প্রশ্নই জিজ্ঞাসা করুন:
এই প্রশ্নগুলো অনিশ্চয়তাকে সামনে তুলে আনে।
এগুলোকে স্কোপ আইটেম হিসেবে বিবেচনা করুন, বিস্ময়ের মতো নয়। v1-এর জন্য তাদের মধ্যে যে গুলো বিশ্বাসহীনতা সৃষ্টি করে সেগুলো অন্তর্ভুক্ত করুন:
বাকি সব স্পষ্টভাবে আউট-অফ-স্কোপ হিসেবে.defer করুন।
সবার জন্য টেস্টেবল স্টেটমেন্ট ব্যবহার করুন:
কমপক্ষে একটি ফেলিওর কেস এবং একটি পারমিশন রুল যোগ করুন। যদি কোনো ক্রাইটেরিয়া টেস্ট করা না যায়, সেই ক্রাইটেরিয়াকে পুনঃলিখুন যতক্ষণ না তা টেস্টেবল হয়।
প্রতিটি পরিবর্তিত স্ক্রিন এবং স্ক্রিনে ১০ সেকেন্ডে যে দৃশ্যটি দেখা যাবে সেটি নাম দিন।
প্রয়োজনীয় UI স্টেটগুলোও তালিকাভুক্ত করুন:
কপি (বাটন টেক্সট, ফিল্ড লেবেল, এরর) স্কোপে রাখুন, এমনকি যদি তা প্লেসহোল্ডার হয়।
কন্ট্রাক্ট ছোট রাখুন: সাধারণত v1-এর জন্য একটি রিড এবং একটি রাইট যথেষ্ট।
নির্ধারণ করুন:
সিদ্ধান্ত: ফ্যাক্টগুলো সংরক্ষণ করুন; ভিউগুলি গণনা করুন।
এই বাক্সযুক্ত ডেলিভারেবলটি চেয়ে শুরু করুন:
পরে “make it cleaner” ধরনের ঝাঁকি-ঝুঁকি শব্দগুলোকে পরিমাপযোগ্য ভাষায় রি-প্রম্পট করুন।
স্বাভাবিক সিরিজ:
প্রতিটি কমিট = একটি নতুন ব্যবহারকারী-দৃশ্যমান আচরণ + দ্রুত প্রমাণের উপায়। “আমি এখানে থাকাকালীন” রিফ্যাক্টরগুলো ফিচার কমিটে প্যাক করবেন না।