২০ ডিসে, ২০২৫·6 মিনিট
পুনরায় কাজ এড়াতে অ্যাপ স্পেসে বাধ্যবাধকতা ও না-লক্ষ্য
কীভাবে অ্যাপ স্পেক-এ কনস্ট্রেইন্ট ও নন-গোল লিখলে পুনরায় কাজ দ্রুত কমে—স্ট্যাক, বাজেট, ডেডলাইন ও কি পরিবর্তন হতে পারে তা সংক্ষিপ্তভাবে ঠিক করার উপায়।
কীভাবে অ্যাপ স্পেক-এ কনস্ট্রেইন্ট ও নন-গোল লিখলে পুনরায় কাজ দ্রুত কমে—স্ট্যাক, বাজেট, ডেডলাইন ও কি পরিবর্তন হতে পারে তা সংক্ষিপ্তভাবে ঠিক করার উপায়।
রিওয়ার্ক ঘটে যখন আপনি এমন কিছু তৈরি করেন যা কাজ করে, কিন্তু প্রকল্পের জন্য ভুল। টিমগুলো স্ক্রীনগুলো পুনরায় তৈরি করে, লগিক পুনরায় লিখে, ডেটা মাইগ্রেট করে, বা কোনো ফিচার পুনর্গঠন করে কারণ একটি গুরুত্বপূর্ণ সিদ্ধান্ত পরে আসে।
এটি সাধারণত পরিচিত কিছু ভাবে দেখা দেয়: কোনো ফ্লো পুনর্গঠিত হয় কারণ ভুল ইউজার রোল ধরা হয়েছিল; স্ক্রীনগুলো পুনরায় ডিজাইন করতে হয় কারণ মোবাইল সাপোর্ট প্রত্যাশিত ছিল কিন্তু কখনও বলা হয়নি; ডেটা মডেল বদলে যায় কারণ "আমাদের অডিট ইতিহাস দরকার" বলে পরে এসেছে; কোনো ইন্টিগ্রেশন বদলানো হয় কারণ ক্লায়েন্ট থার্ড-পার্টি সার্ভিস ব্যবহার করতে পারে না; অথবা কমপ্লায়েন্স বা রিজিয়ন নিয়ম কারণে হোস্টিং সরাতে হয়।
ক্যান্সেল করা কনস্ট্রেইন্টগুলো পরে আচমকাই সিদ্ধান্ত তৈরি করে। যখন একটা স্পেকে লেখা থাকে "একটি CRM তৈরি করুন," সেটা ডজনখানেক প্রশ্ন খোলা রেখে দেয়: কে এটি ব্যবহার করবে, কোন প্ল্যাটফর্মগুলো গুরুত্বপূর্ণ, কোন সিকিউরিটি নিয়ম প্রযোজ্য, কি কি স্কোপ থেকে রাখা হবে, বাস্তব বাজেট ও সময়সীমা কী। যদি উত্তরগুলো কোড তৈরি হওয়ার পরে আসে, প্রজেক্ট দ্বিগুণ খরচ ওঠে: একবার বানাতে, আরেকবার উল্টে ফেলতে।
একটি সহজ উদাহরণ: একজন প্রতিষ্ঠাতা চায় "অ্যাপয়েন্টমেন্ট + রিমাইন্ডার।" প্রথম সপ্তাহে ইমেল রিমাইন্ডার চালু হয়। দ্বিতীয় সপ্তাহে তারা বলে SMS দরকার, কিন্তু SMS তাদের দেশে অনুমোদিত নয় বা বাজেট ভেঙে দেয়। এখন রিমাইন্ডার সিস্টেম পুনরায় ডিজাইন করা লাগল, স্ক্রীন পরিবর্তন হলো, এবং টেস্টিং আবার শুরু হলো। এই রিওয়ার্ক খারাপ কোডিং-এর কারণে নয়—এটি দেরিতে আসা কনস্ট্রেইন্টের কারণে।
লক্ষ্য হলো কোড লেখা বা জেনারেট হওয়ার আগে বারবারে কমানো। আপনি হাতে কোড করুক বা চ্যাট-ভিত্তিক বিল্ডার ব্যবহার করুন, আউটপুট কেবলমাত্র আপনার দেয়া নিয়মগুলো অনুসরণ করতে পারে। যদি নিয়মগুলো পরে আসে, কাজ সরে যায় এবং আপনাকে তা আবার করতে হবে।
এটি দীর্ঘ ডকুমেন্ট লেখার ব্যাপার নয়। একটি হালকা স্পেকও যেখানে প্রয়োজন সেখানে কঠোর হতে পারে। শুরুতেই এটা উত্তর দেওয়া উচিত:
কনস্ট্রেইন্ট ও নন-গোলস প্রথমে লেখা হলে তারা গার্ডরেইলের মতো কাজ করে। সারপ্রাইজ কমে, পুনর্গঠন কমে, এবং প্রথম দিন থেকেই সিদ্ধান্তগুলো স্পষ্ট হয়।
কনস্ট্রেইন্টগুলো হল ফিক্সড সিদ্ধান্ত যা আপনার প্রজেক্টকে মানতে হয়। সেগুলো উপেক্ষা করলে আপনি দ্বিগুণ কাজ করবেন, কারণ আপনি এমনভাবে তৈরি করছেন যা শিপ করা যায় না।
নন-গোলস হলো স্পষ্ট সিদ্ধান্ত যে আমরা কিছু বানাবো না। এগুলো বাদ দিলে স্পেক চুপিচুপি বাড়তে থাকে যখন মানুষ "ছোট" অতিরিক্ত যোগ করে। এভাবেই আপনি স্ক্রীন, ফ্লো, ও ডেটা মডেল পুনরায় করতে হয়।
একটি দ্রুত নিয়ম: কনস্ট্রেইন্টগুলো কিভাবে বানাবেন তা সীমাবদ্ধ করে; নন-গোলস কি বানাবেন না তা সীমাবদ্ধ করে।
কনস্ট্রেইন্ট হলো এমন একটি অবশ্য যা প্রকৃত সিদ্ধান্ত (এবং ট্রেড-অফ) ছাড়া বদলায় না।
উদাহরণ:
যখন একটি কনস্ট্রেইন্ট বাস্তব, এটাকে এমন এক বাক্য হিসেবে লিখুন যাকে নিয়ে বিতর্ক করা যায় না। যদি কেউ বলে “হয়ত,” তাহলে এটা এখনও কনস্ট্রেইন্ট নয়।
নন-গোল হলো স্পষ্ট “আমরা এটা করছি না,” এমনকি যদি এটি কার্যকর মনে হয়। এটি প্রথম রিলিজকে রক্ষা করে।
উদাহরণ:
নন-গোলস নেগেটিভিটি নয়। এগুলো ব্যয়বহুল ভ্রমণগুলোর থেকে রক্ষা করে। উদাহরণস্বরূপ, “v1-এ কাস্টম রোল নেই” লাইনে ডাটাবেস ও UI পুনর্গঠনের সপ্তাহগুলো বাঁচাতে পারে।
বিস্তারিত পাতার আগে একটি বাক্য লিখুন যা প্রজেক্টকে ফিক্স করে রাখে। এটি ট্রেড-অফের সময় সবার এলাইনমেন্ট রাখে।
একটি ভালো ওয়ান-লাইনার উত্তর দেয়: এটা কার জন্য, এবং মূল কাজ কী?
উদাহরণ ওয়ান-লাইনার:
এরপর একটি ছোট সাফল্য সংজ্ঞা যোগ করুন: ৩ থেকে ৫টি আউটকাম যা একটি বাস্তব ব্যবহারকারী প্রকল্প শেষ হলে অর্জন করতে পারবে। এগুলো ফিচারের বদলে ব্যবহারকারীর ফলাফল হিসেবে লিখুন।
টিউটর বুকিং উদাহরণের জন্য:
যদি আপনার কাছে এখনও মেট্রিক্স না থাকে, শব্দে সাফল্য বর্ণনা করুন। “দ্রুত” অস্পষ্ট, কিন্তু “ফোনে দ্রুত মনে হবে” উপকারী। “সহজ” অস্পষ্ট, কিন্তু “কোনো সেটআপ কল লাগবে না” স্পষ্ট। পরে আপনি সংখ্যা যোগ করতে পারেন।
এই অংশ ছোট রাখুন। এটি পরবর্তী সব কিছুর প্রেক্ষাপট হবে: কি অবশ্যই সত্য হতে হবে, কি করা যাবে না, এবং কি পরিবর্তন হতে পারে।
রিওয়ার্ক প্রায়ই তখন শুরু হয় যখন সময়সূচি ও সিদ্ধান্ত প্রক্রিয়া কেবল কারও মাথায় থাকে। স্পেকের শিরোনামে প্রজেক্ট কনস্ট্রেইন্টগুলো রাখুন, তারপর স্ক্রীন ও ফিচারের বর্ননা দিন।
তারা প্লেইন, টেস্ট করা যায় এমন বর্ণনায় লিখুন:
একটি সহজ উদাহরণ:
“প্রথম রিলিজ ৩০ মে-র মধ্যে শিপ করতে হবে। এতে লগইন, একটি বেসিক কাস্টমার লিস্ট, এবং এক মাসিক রিপোর্ট অন্তর্ভুক্ত। v1-এ কোনো ইন্টিগ্রেশন নেই। বাজেট $8,000 কেপ, প্রথম মাসের হোস্টিং সহ। রিভিউ সপ্তাহের কার্যদিবসে ২৪ ঘণ্টার মধ্যে হবে। প্রডাক্ট ওনার সম — Sam — যিনি স্কোপ পরিবর্তন অনুমোদন করেন।”
ফিডব্যাক স্পিড আলাদা লাইনে রাখুন কারণ এটি কতো নিরাপদে আপনি এগোতে পারবেন তা নির্ধারণ করে। যদি স্টেকহোল্ডাররা কেবল সাপ্তাহিক একবার রিভিউ দিতে পারে, তাহলে স্পেকটি ছোট রিলিজ ও কম এজ কেসের পক্ষে হওয়া উচিত।
বাস্তবতার সাথে মিলে এমন রিভিউ কেডেন্স বেছে নিন: একই দিন ফিডব্যাক, কার্যদিবসে ২৪–৪৮ ঘণ্টা, সাপ্তাহিক রিভিউ মিটিং, বা (দুর্লভভাবে) “কোনো ফিডব্যাক প্রয়োজন নেই।”
যদি আপনি প্রযুক্তিগত কনস্ট্রেইন্ট অল্পতেই লিখে না রাখেন, মানুষ অনুমান দিয়ে ফাঁকগুলো পূরণ করে। এভাবেই টিমগুলো স্ক্রীন, মাইগ্রেশন, বা ইন্টিগ্রেশন পরে পুনরায় করে।
শুরুতে কি লক করা হয়েছে এবং কি কেবল পছন্দ সেটা বলুন। “React পছন্দ” আর “React হওয়া আবশ্যক কারণ ইন-হাউস কম্পোনেন্ট লাইব্রেরি নির্ভর” এক নয়। এক সিদ্ধান্তের প্রতিটি আলাদা লাইন যথেষ্ট।
ওয়েব, ব্যাকএন্ড, ডাটাবেস এবং মোবাইল জুড়ে স্পষ্ট হোন। যদি কোনো অংশ নমনীয় হয়, তা বলুন এবং একটি সীমা যোগ করুন (উদাহরণ: “v1-এ মোবাইল ওয়েব-অনলি”)।
লিখবার সহজ উপায়:
তারপর আপনি যে ইন্টিগ্রেশনগুলো এড়ানো যাবে না সেগুলো তালিকাভুক্ত করুন। সিস্টেমগুলোর নাম দিন (পেমেন্ট, ইমেল, অ্যানালিটিক্স, CRM) ও কঠোর সীমা উল্লেখ করুন। উদাহরণ: “বিলিংয়ের জন্য Stripe ব্যবহার করতে হবে,” “ইমেল পাঠাতে আমাদের বিদ্যমান প্রোভাইডার ব্যবহার করতে হবে,” “অ্যানালিটিক্স পার্সোনাল ডেটা ট্র্যাক করবে না।” যদি অথেনটিকেশন ঠিক থাকে (SSO, Google লগইন, পাসওয়ার্ডলেস), তা উল্লেখ করুন।
হোস্টিং পছন্দ আর্কিটেকচার বদলে দেয়। বলুন অ্যাপ কোথায় চালাতে হবে এবং কেন: “জার্মানিতে চালাতে হবে,” “ডেটা EU-তেই থাকতে হবে,” অথবা “গ্লোবালি চলতে পারবে।”
যদি কমপ্লায়েন্স প্রয়োজন থাকে, সেগুলো konkreৎ রাখুন: রিটেনশন পিরিয়ড, ডিলিশন রুল, এবং অডিটের চাহিদা।
উদাহরণ: “রেকর্ড ৭ বছর সংরক্ষণ, যাচাইকৃত অনুরোধ পেলে ৩০ দিনের মধ্যে মুছে ফেলতে হবে, কোন রেকর্ড কে দেখেছে তার অডিট লগ রাখতে হবে, এবং যেখানে রোগী থাকে সেই দেশে ডিপ্লয় করা হবে।” এই লাইনগুলো লঞ্চের সময় আচমকা সারপ্রাইজ ঠেকায়।
নন-গোলস স্পেকের গার্ডরেইল। তারা বলে আপনি কি না বানাচ্ছেন, কি সাপোর্ট করবেন না, বা প্রথম রিলিজে কি নিখুঁত করার চেষ্টা করছেন না। এটি দ্রুত সারপ্রাইজ কমানোর সবচেয়ে কার্যকরি উপায়—কারণ অনেক “ছোট” অনুরোধ পরে আসে এবং নীরবে পুরো পরিকল্পনাকে বদলে দেয়।
একটি ভালো নন-গোল একটি সহজ বাক্যে এতটুকু নির্দিষ্ট হওয়া উচিত যাতে সহকর্মী এক বাক্যে স্কোপ ক্রিপ চিনতে পারে। এটিকে সময়-সংকীর্ণও রাখুন। “v1-এ নেই” স্পষ্ট, “আমরা এটা করব না” চেয়ে বেশি কার্যকর।
মানুষ সাধারণত যা অন্তর্ভুক্ত মনে করে এমন ফিচারগুলো দিয়ে শুরু করুন। একটি সাধারণ বুকিং অ্যাপের জন্য এটি হতে পারে:
এগুলো খারাপ ফিচার নয়—এগুলো ব্যয়বহুল। এগুলো লিখে রাখলে প্রথম রিলিজ ফোকাসড থাকে।
এছাড়াও ধারাবিবরণি আইটেমগুলো বলুন যা বড় নক-অন কাজ করে: রোল, পারমিশন, এবং এজ-কেস ফ্লো। “কাস্টম রোল নেই; শুধু দুই রোল: Owner ও Member।” এই এক লাইনে সপ্তাহগুলো সেভ হবে।
টিমগুলো প্রায়ই নন-গোল ভুলে যায় যা ফিচার না হলেও পরে ব্যথার কারণ হয়। এগুলো পরে রিওয়ার্কে পরিণত হতে পারে।
নির্ধারণ করুন আপনি কী না অপ্টিমাইজ করবেন। উদাহরণ: “1M ব্যবহারকারীর জন্য টিউন করব না। v1-এ আমরা সর্বোচ্চ 500 সাপ্তাহিক অ্যাকটিভ ইউজার ধরে নেব।”
এছাড়া কি সাপোর্ট করা হবে না তা উল্লেখ করুন যাতে টেস্টিং বাস্তবসম্মত থাকে: “No Internet Explorer,” “No tablet-specific layouts,” অথবা “লগইন কেবল ইমেল ও পাসওয়ার্ড (না SSO, না ম্যাজিক লিঙ্ক)।”
একটি স্পেক তখনই নিরাপদ মনে হয় যখন এটা ছোট সিদ্ধান্তগুলো ঢুকতে দেয়। যদি আপনি কেবল ফিক্সড জিনিসগুলো লিখেন, প্রতিটি নতুন আইডিয়া আবার বিতর্কে পরিণত হয়। একটি সংক্ষিপ্ত “পরিবর্তন হতে পারে” তালিকা লোকদের কাজ উন্নত করার সুযোগ দেয় ছাড়া পুরো পরিকল্পনা নতুন করে খোলার।
ব্যবহারিক রাখুন। আপনি কোন বিষয়গুলো পরীক্ষার পরে শিখবেন সেগুলো কভার করুন, বড় নতুন ফিচার নয়। সাধারণ নমনীয় আইটেমগুলো: UI টেক্সট, ছোট ফ্লো টুইক, রিপোর্টিং কলাম, নামকরণ (রোল, স্ট্যাটাস, ক্যাটেগরি), ও মৌলিক লেআউট পছন্দ।
এরপর নির্ধারণ করুন কিভাবে পরিবর্তনগুলো গৃহীত হবে। একটি সহজ অনুমোদন নিয়ম না থাকলে “দ্রুত টুইক” গোপনে স্কোপ ক্রিপে পরিণত হয়ে যায়।
একটি সাধারণ ওয়ার্কফ্লো যা বেশিরভাগ ছোট টিমের জন্য কাজ করে:
মূল নিয়ম: নমনীয় পরিবর্তনগুলো ফিক্সড কনস্ট্রেইন্ট ভাঙতে পারবে না। যদি আপনার স্ট্যাক React + Go + PostgreSQL হয়, একটি “পরিবর্তন করা যাবে” অনুরোধ ব্যাকেন্ড বদলে দেওয়ার অনুরোধে পরিণত হতে পারবে না। যদি ডেডলাইন ফিক্সড হয়, “পরিবর্তন” মানে দুই সপ্তাহ লাগে এমন নতুন মডিউল যোগ করা নয়।
একটি ট্রেড-অফ নোট যোগ করুন সবাই একমত হবে এমন। উদাহরণ: “যদি আমরা একটি নতুন ইউজার রোল কাস্টম পারমিশনসহ যোগ করি, আমরা অ্যাডভান্সড রিপোর্টিং ফেজ ২-এ সরাব।”
একটি ভালো স্পেক অপশনগুলো সীমিত করে শুরু করে, না বাড়িয়ে। এই ফরম্যাট আপনাকে কাজ শুরু করার আগে নিয়ম লিখতে বাধ্য করে।
ডকের হেডারে এটা ব্যবহার করুন:
SPEC v0.1 (date)
Owner:
Reviewers:
1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]
2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]
3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]
4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]
5) Open questions
- Q: [question]
Owner: [name]
Due: [date]
6) Lock rule
- After review: changes require: [what approval looks like]
(উপরের কোড-ব্লক অনুবাদ করা হয়নি — এটি যেভাবে আছে সেভাবেই রেখে দেবেন।)
অধিকাংশ সারপ্রাইজ ভাগ্য নয়; সেটা ঘটে কারণ স্পেক বিভিন্ন ব্যাখ্যা করার জায়গা রাখে।
একটি সাধারণ ফাঁক হলো লক্ষ্য ও সমাধান মিশিয়ে ফেলা। টিমগুলো স্ক্রীন ও ওয়ার্কফ্লো থেকে সরাসরি শুরু করে দেয় যখন তারা ফিক্সড জিনিসগুলো (ডেডলাইন, বাজেট, টেক স্ট্যাক) আগে লিখে না। ফলাফল হলো একটি সুন্দর UI পরিকল্পনা যা কনস্ট্রেইন্টে ফিট করে না।
আরেকটি ফাঁক হলো অস্পষ্ট নন-গোলস। “কোনও অতিরিক্ত ফিচার নয়” কঠোর শোনালেও, যখন কেউ বলে “আরও একটি রিপোর্ট” বা “একটি দ্রুত অ্যাডমিন প্যানেল,” তখন তা রোধ করে না। ভালো নন-গোল স্পষ্ট ও টেস্টেবল হয়।
লুকানো বাজেট বা “সফট” ডেডলাইনও স্কোপ বোমা। যদি বাস্তব বাজেট $5k এবং স্পেকটি $50k পণ্য যেন দেখায়, টিম ভুল জিনিস বানাবে। অস্বস্তিকর সংখ্যাগুলো পৃষ্ঠায় রাখুন।
ইন্টিগ্রেশন ও ডেটা মালিকানাও নীরবে সারপ্রাইজ দেয়। আপনি যদি বলুন “Stripe-এ কানেক্ট করুন” কিন্তু কোন ইভেন্ট, কোন ফিল্ড, और কে ডেটার মালিক তা নির্ধারণ না করেন, আপনি একই সিদ্ধান্ত বারবার পুনরায় বিবেচনা করবেন।
শেষ ফাঁক হলো বিল্ডের মাঝপথে কনস্ট্রেইন্ট বদলানো কিন্তু ট্রেড-অফ না বলা। “ওয়েব-অনলি” থেকে “ওয়েব + মোবাইল” বা “Postgres ব্যবহার” থেকে “যেটা সস্তা” তে পরিবর্তন করলে পরিকল্পনা বদলে যায়। আপনি পরিবর্তন করতে পারবেন, কিন্তু স্কোপ, টাইমলাইন, বা গুণমান প্রত্যাশা আপডেট করা জরুরি।
স্পেক এ একটি সংক্ষিপ্ত নোট যোগ করুন যা পাঁচ পয়েন্টের উত্তর দেয়:
কারো কিছু বানানোর আগে, আপনাকে “কি ফিক্স?” প্রশ্নগুলো সহজে উত্তর দিতে সক্ষম হতে হবে, দীর্ঘ ডক খুঁটিয়ে না পড়ে।
দ্রুত চেক:
যদি এর কোনো একটাই অনুপস্থিত থাকে, প্রথম বিল্ড হবে কিন্তু দ্বিতীয় বিল্ডই বাস্তবে হতে পারে।
মোমেন্টাম বজায় রেখে কিন্তু খারাপ সিদ্ধান্তে আটকে না পড়ার পরবর্তী ধাপগুলো:
আপনি যদি Koder.ai (koder.ai) ব্যবহার করেন, “Planning Mode” এবং স্পষ্ট কনস্ট্রেইন্ট ও নন-গোল সেকশন প্ল্যাটফর্মকে আপনার স্ট্যাক, হোস্টিং রিজিয়ন, এবং স্কোপ অনুযায়ী প্রথম খসড়া জেনারেট করতে সাহায্য করবে। এবং যদি অগ্রাধিকার বদলে যায়, স্ন্যাপশট ও রোলব্যাক আপনাকে একটি স্থিতিশীল বেসলাইন হারানো ছাড়া পরিবর্তন পরীক্ষা করতে দেবে।
যখন এই নিয়মগুলো আগে লেখা থাকে, ফিচার আলোচনা সহজ হয় কারণ সবাই জানে কি থাকতে হবে ফিক্সড এবং কি সরানোর অনুমতি আছে।
রিওয়ার্ক হলো এমন কিছু তৈরি করা যা কার্যকর হলেও প্রকল্পের জন্য ভুল — কারণ কোনো দেরিতে সিদ্ধান্ত নিয়ম বদলে দেয়। এটি সাধারণত ঘটে যখন স্পেক্সে প্রাথমিক কনস্ট্রেইন্ট লেখা থাকে না, ফলে টিম যুক্তিসঙ্গত অনুমান করে যা পরে ভুল প্রমাণিত হয়।
প্রকৃত ট্রেড-অফ ছাড়া বদলাতে না হওয়া জিনিসগুলো দিয়ে শুরু করুন: ডেডলাইন, বাজেট কেপ, হোস্টিং অঞ্চল, অনিবার্য স্ট্যাক, এবং কমপ্লায়েন্স নিয়ম। তারপর একটি সংক্ষিপ্ত নন-গোলস সেকশন যোগ করুন যাতে “ছোট” অতিরিক্তগুলোর মাধ্যমে কেউ স্তব্ধভাবে স্কোপ বাড়াতে না পারে।
কনস্ট্রেইন্ট কিভাবে তৈরি করবেন তা জানায় — উদাহরণ: “EU-তে চালাতে হবে” বা “React ও PostgreSQL ব্যবহার করতে হবে।” নন-গোলস বলে দেয় আমরা কী বানাব না — যেমন “v1-এ মোবাইল অ্যাপ নয়” বা “লঞ্চে কাস্টম রোল নেই।” কনস্ট্রেইন্ট কিভাবে বানাবেন তা সীমাবদ্ধ করে; নন-গোলস কি বানাবেন না তা সীমাবদ্ধ করে।
টেস্ট করা যাবে এমন এক বাক্য হিসেবে লিখুন — একটি পছন্দ নয়। যদি কেউ “হয়ত” বলতে পারে এবং কেউ তা পরিণত করতে না পারে, তাহলে সেটা বাস্তব কনস্ট্রেইন্ট নয়; সেটাকে খোলা প্রশ্ন হিসেবে রাখুন।
প্রথম রিলিজের জন্য ৩–৫টি ব্যবহারকারীর ফলাফল (outcomes) বেছে নিন যা সাফল্য বুঝায়, সহজ ভাষায়। ফলাফলগুলো ফিচারের বদলে ব্যবহারকারীর উদ্দেশ্য বর্ণনা করে; এতে টিমের ফিল্টার হিসেবে কাজ করে এবং অপ্রয়োজনীয় ফিচারকে না বলাই সহজ হয়।
সবচেয়ে সাধারণ লুকানো কনস্ট্রেইন্টগুলো হল: মোবাইল সাপোর্ট, রোল ও পারমিশন, অডিট হিস্ট্রি, ডেটা রেসিডেন্সি, এবং এমন ইন্টিগ্রেশন যা ক্লায়েন্ট ব্যবহার করতে পারে না। এগুলো আগে তুলে নিলে স্ক্রীন, ডেটা মডেল বা সার্ভিস সোয়াপ করার মতো বড় পরিবর্তন এড়ানো যায়।
নন-গোল যতটা সম্ভব নির্দিষ্ট ও সময়-সংকীর্ণ রাখুন, যেমন “v1-এ নেই” বা “ট্যাবলেট সাপোর্ট না”। অস্পষ্ট নন-গোল যেমন “অতিরিক্ত ফিচার নেই” স্কোপ ক্রিপ আটকাতে কাজ করবে না কারণ তা কোনো নির্দিষ্ট অনুরোধ আটকায় না।
লিখে রাখুন কে পরিবর্তন অনুমোদন করে, রিভিউ কত দ্রুত হবে, এবং কোন কডিং কন্ডিশনে পরিবর্তন স্বল্পভাবে গ্রহণযোগ্য। ধীর প্রতিক্রিয়া নিজেই একটি কনস্ট্রেইন্ট কারণ এটি ইটারেশনের নিরাপত্তা ও অনিশ্চয়তার পরিমাণ নিয়ন্ত্রণ করে।
এসব খোলা প্রশ্নগুলোর জন্য একটি মালিক এবং একটি নির্ধারিত সময়সীমা লিখে রাখুন, এবং প্রভাবিত অংশে কাজ শুরু না করা পর্যন্ত অপেক্ষা করুন। অবশ্যই কাজ শুরু করতে হলে ব্যবহৃত অনুমান স্পষ্টভাবে নোট করুন যাতে পরে বিভ্রান্তি না হয়।
Planning Mode-এ কনস্ট্রেইন্ট ও নন-গোল লক করে নিয়ে জেনারেট করার আগে প্ল্যানিং করুন, যাতে প্রথম খসড়া আপনার স্ট্যাক, অঞ্চল ও স্কোপের সাথে মিলবে। যখন অগ্রাধিকার বদলায়, স্ন্যাপশট ও রোলব্যাকের মতো ফিচারগুলো পরিবর্তন পরীক্ষা করতে সাহায্য করে বিনা ঝামেলায় স্থিতিশীল বেসলাইন বজায় রাখতে, এবং সোর্স কোড এক্সপোর্ট দরকার হলে কাজে লাগবে।