بسیاری از تیم‌های نرم‌افزاری ماه‌ها وقت صرف توسعهی قابلیت‌هایی می‌کنند که در نقشهی راه تعریف شده‌اند، غافل از این‌که کل این مسیر بر پایه‌ی حدس‌ها و پیش‌فرض‌های اثبات‌نشده ساخته شده است. وقتی محصولی شکست می‌خورد، معمولاً ایراد از کیفیت کدنویسی نیست؛ بلکه فرضیه‌ای درباره‌ی رفتار کاربر، نیاز واقعی یا ایمنی سیستم نادرست بوده است.
نگاشت فرضیات (Assumption mapping) ابزاری است که مجهولات پنهان پشت هر تسک فنی را آشکار میکند. این متدولوژی به شما کمک میکند پیش از دست‌به‌کد شدن برای پیاده‌سازی‌های سنگین و پرهزینه، متوجه شوید چه شرایطی حتماً باید برقرار باشند تا محصول اصلاً ارزش ساختن داشته باشد.
در این درس می‌آموزید چطور فرضیات مبهم را به گزاره‌های ابطالپذیر تبدیل کنید، آن‌ها را با سنجه‌های مشخص مانند اثرگذاری، عدم قطعیت و برگشت‌ناپذیری امتیاز دهید و به‌جای انجام کارهای صرفاً هیجان‌انگیز، خطرناک‌ترین مجهول را زودتر از بقیه حل کنید.
نقشهی راه (Roadmap) عدم قطعیت را پشت قابلیت‌ها پنهان میکند. در مقابل، نقشهی فرضیات (Assumption map) نشان می‌دهد چه چیزهایی باید درست باشند تا اصلاً ساخت آن قابلیت‌ها توجیه داشته باشد.
اهداف یادگیری
- تبدیل کارهای پیشنهادی به فرضیات صریح و شفاف.
- امتیازدهی جداگانه به اثرگذاری، عدم قطعیت و برگشت‌ناپذیری.
- انتخاب آزمایش بعدی بر اساس ریسک، نه اشتیاق تیم.
- جایگزینی فرضیات سنجیده‌شده با شواهد (Evidence) و تصمیم‌ها.
هر فرآیند ساختی نوعی شرط‌بندی است
ابزاری برای مدیریت رخدادها (Incidents) ممکن است به درست بودن تمام گزاره‌های زیر وابسته باشد:
- زمینه‌ی هشدار (Alert context) اطلاعات کافی برای شناسایی سرویس را داشته باشد؛
- مهندسان به پیشنهادی که خودشان به آن نرسیده‌اند اعتماد کنند؛
- زمان پاسخ مطلوب، از نظر عملیاتی واقعاً مهم باشد؛
- بتوان به داده‌های موردنیاز بدون دسترسی‌های ناامن رسید؛
- این گردش کار آن‌قدر تکرار شود که هزینه‌ی نگهداری ابزار توجیه داشته باشد.
هیچ‌کدام از این موارد، تسک‌های پیاده‌سازی نیستند؛ بلکه شرایطی هستند تا ساخت محصول ارزشمند، کاربردی، شدنی و ایمن باشد.
دسته‌بندی فرضیات
| دسته | پرسش |
|---|---|
| ارزش (Value) | آیا دستاورد نهایی به اندازه‌ی کافی اهمیت خواهد داشت؟ |
| کاربردپذیری (Usability) | آیا کاربر می‌تواند آن را بفهمد و بر اساسش اقدام کند؟ |
| امکان‌پذیری (Feasibility) | آیا سیستم می‌تواند با داده‌ها و محدودیت‌های فعلی، این خروجی را تولید کند؟ |
| پایداری (Viability) | آیا سازمان توان تأمین هزینه‌ها، مالکیت و نگهداری عملیاتی آن را دارد؟ |
| ایمنی (Safety) | در صورت خرابی، آیا پیامدها در محدوده‌ی پذیرفتنی می‌مانند؟ |
فرضیات را به‌شکل گزاره‌های ابطالپذیر بنویسید. «این قابلیت مفید است» قابل‌آزمایش نیست؛ اما گزاره‌ی «8 نفر از 10 مهندس آن‌کال (On-call) با دیدن نتیجه‌ی فقط‌خواندنی (Read-only)، سرویس درست را سریع‌تر شناسایی می‌کنند» آزمون‌پذیر است.
ریسک یک عدد تک‌بُعدی نیست
در این کارگاه از سه بُعد با بازه‌ی 1 تا 5 استفاده می‌کنیم:
- اثرگذاری (Impact): خسارت ناشی از نادرست بودن فرضیه.
- عدم قطعیت (Uncertainty): ضعف شواهد فعلی.
- برگشت‌ناپذیری (Irreversibility): هزینه‌ی پی بردن به اشتباه پس از commit کردن.
امتیاز نمونه، اثرگذاری و عدم قطعیت را ضرب میکند و سپس با برگشت‌ناپذیری جمع می‌زند. این فرمول جهان‌شمول نیست؛ هدفش این است که تیم را وادار کند توضیح دهد چرا یک مجهول باید پیش از مجهول دیگری رفع شود.
آزمایش طراحی کنید، نه مناسک تأیید خود
یک آزمون کارآمد شامل این موارد است:
- ادعایی که ممکن است نادرست باشد؛
- یک جامعهی هدف یا نمونهی واقعگرایانه؛
- نتیجهای مشاهده‌پذیر؛
- یک آستانه (Threshold) که پیش از مشاهده‌ی نتیجه تعیین شده باشد؛
- تصمیم بعدی برای هر حالت: قبولی، رد و شواهد مبهم.
از آزمون‌هایی که فقط نشان می‌دهند تیم می‌تواند ایده را بسازد دوری کنید.
برگشت‌پذیری ترتیب کارها را تغییر می‌دهد
انتخاب‌های پرپیامد و برگشت‌ناپذیر به شواهد زودهنگام‌تری نیاز دارند. یک بازپخش فقط‌خواندنی می‌تواند پیش از ادغام در پروداکشن (Production) انجام شود. یک تطبیق‌دهنده (Adapter) موقت می‌تواند پیش از مهاجرت داده پیاده شود. توصیه‌ای که انسان تأییدش میکند می‌تواند پیش از اقدام خودکار آزمایش شود.
شکل ساخت باید از شکل عدم قطعیت پیروی کند.
ساخت آن
این کارگاه فرضیات را رتبه می‌دهد، ادعاهای آزموده‌شده را از ادعاهای باز تفکیک میکند، بالاترین ریسک باز را برمی‌گزیند و فایل outputs/assumption-map.json را می‌نویسد.
python3 code/main.py
python3 -m unittest discover code/tests -vشواهد مربوط به پرریسک‌ترین فرضیه را تغییر دهید و ببینید آزمایش بعدی چطور تغییر میکند.
تمرین‌ها
- پنج فرضیه برای قابلیتی که می‌خواهید بسازید بنویسید.
- یک فرضیه‌ی ایمنی اضافه کنید که در فهرست قابلیت‌هایتان از قلم افتاده بود.
- آستانه‌ای تعریف کنید که باعث شود ساخت پروژه را متوقف کنید.
- یک آزمایش بزرگ را با آزمونی ارزان‌تر اما سرنوشت‌ساز جایگزین کنید.
- رتبه‌بندی بر اساس ریسک را با اولویت‌های نقشهی راه مقایسه کنید و دلیل ناهمخوانی را توضیح دهید.
مطالعه‌ی بیشتر
- Barry Boehm, A Spiral Model of Software Development and Enhancement؛ برای چرخه‌ی توسعهی ریسک‌محوری که عدم قطعیت را پیش از تعهد عمیق‌تر برطرف میکند.
- Dardenne, van Lamsweerde, and Fickas, Goal-Directed Requirements Acquisition؛ برای تدقیق اهداف هم‌زمان با آشکارسازی موانع و محدودیت‌ها.
چیزی که پیش خود نگه می‌دارید
فایل outputs/assumption-map.json را نگه دارید. درس بعدی از آن برای انتخاب کوچک‌ترین برشی استفاده میکند که می‌تواند شواهد تعیین‌کننده تولید کند.