بسیاری از تیم‌های فنی هنگام ساخت نسخه‌های اولیه یا MVP، به دام ساده‌سازی‌های گمراه‌کننده می‌افتند: ساختن فقط یک رابط کاربری زیبا، پیادهسازی مسیرهای ایده‌آل بدون در نظر گرفتن خطاهای پرتکرار، یا توسعه‌ی زیرساختی پیچیده بدون اعتبارسنجی نیاز واقعی کاربر. نتیجه‌ی چنین تلاش‌هایی چیزی جز کار ناتمام یا ارائه‌ی نمایشی نیست که در واقعیت هیچ‌کدام از فرضیات حیاتی سیستم را نمی‌سنجد.
یک «برش عمودی» (Vertical Slice) اصولی، قرار نیست تمام امکانات را داشته باشد؛ بلکه باید کوچک‌ترین جریان کاری سرتاسری و واقعی باشد که ریسک‌ها و عدم قطعیت‌های اصلی پروژه را ارزیابی می‌کند. اگر دادههای به‌دست‌آمده از یک پایلوت نتواند شما را از ادامه‌ی مسیر منصرف کند یا جهت حرکت را تغییر دهد، آن پیادهسازی صرفاً یک کدنویسی اضافی بوده و نامش آزمایش نیست.
در این درس می‌آموزید چطور فرضیات پرریسک را شناسایی کنید، شواهد برگشت‌پذیر را بر تعهد زودهنگام در محیط پروداکشن ترجیح دهید و با تعیین «قاعدهی توقف»، از هدررفت منابع روی ایده‌های نامطمئن جلوگیری کنید.
کوچک بودن تنها زمانی به درد می‌خورد که چیز مهمی را اثبات کند. پیاده‌سازیِ کوچکی که نتواند تصمیم بعدی را تغییر دهد، صرفاً کاری ناتمام است.
اهداف یادگیری
- تعریف برش (slice) بر اساس فرضیاتی که اثبات می‌کند.
- ایجاد تعادل میان ارزش دستاورد، کاهش عدم قطعیت، میزان تلاش و تبعات احتمالی.
- ترجیح دادن شواهد برگشت‌پذیر به commit زودهنگام در محیط پروداکشن (production).
- رد کردن برش‌هایی که بخش پرریسک جریان کاری را دور می‌زنند.
معنای عمودی: شواهد سرتاسری
یک برش کاربردی از حداقلِ جریان کاری واقعی لازم برای مشاهده‌ی نتیجه عبور می‌کند. این برش می‌تواند از نظر تعداد کاربران، داده، مدت‌زمان و قابلیت‌ها محدود باشد؛ اما نباید این محدودیت با حذف همان عدم قطعیتی به دست آید که باید بسنجید.
چند مثال:
- بازپخش فقط-خواندنی (read-only replay) روی 10 حادثه‌ی واقعی، شناسایی سرویس و اعتماد اپراتور را می‌سنجد.
- یک داشبورد صیقل‌خورده با دادههای ساختگی شاید کامپریهنشن را بسنجد، اما امکانپذیری دادهها را ارزیابی نمی‌کند.
- یک ابزار خودکار رفع اشکال در پروداکشن، همه‌چیز را یک‌جا اما با تبعاتی غیرقابل‌قبول می‌سنجد.
اول اثباتهای لازم را مشخص کنید
پرریسک‌ترین فرضیات بلاتکلیف را بردارید و آن‌ها را به مجموعه‌ای از اثباتهای لازم تبدیل کنید. یک برش کاندید تنها در صورتی واجد شرایط است که این مجموعه را پوشش دهد.
سپس برش‌های واجد شرایط را بر اساس این ابعاد مقایسه کنید:
| بعد | جهت مطلوب |
|---|---|
| ارزش نتیجه | هرچه بیشتر، بهتر |
| کاهش عدم قطعیت | هرچه بیشتر، بهتر |
| تلاش | هرچه کمتر، بهتر |
| تبعات | هرچه کمتر، بهتر |
| برگشت‌پذیری | هرچه بیشتر، بهتر |
امتیازدهی این کارگاه عمداً ساده طراحی شده است. دروازه‌ی واجد شرایط بودن (eligibility) بسیار مهم‌تر از محاسبات ریاضی آن است.
حالت‌های حداقلِ کاذب و رایج
- حداقلِ فقط رابط کاربری (UI-only): عدم قطعیت داده و عملیات را حذف می‌کند.
- حداقلِ فقط زیرساخت (Infrastructure-only): امکانپذیری فنی را بدون خلق ارزش برای کاربر اثبات می‌کند.
- حداقلِ مسیر ایده‌آل (Happy-path): استثناهایی را که بیشترین ریسک را رقم می‌زنند، نادیده می‌گیرد.
- حداقلِ نمایشی (Demo): یک دست‌سازهٔ (artifact) قانع‌کننده می‌سازد، اما سنجش تکرارپذیری ارائه نمی‌دهد.
- حداقلِ پلتفرمی (Platform): سازوکارهای با قابلیت استفاده‌ی مجدد را قبل از اینکه حتی یک جریان کاری ارزش آن را ثابت کند، می‌سازد.
یک قاعدهی توقف بگذارید
پیش از پیادهسازی، مشخص کنید که اگر برش شکست خورد چه تصمیمی می‌گیرید:
- رها کردن دستاورد مورد انتظار؛
- تغییر کاربر هدف یا شرایط مسئله؛
- آزمودن سازوکاری دیگر؛
- گردآوری شواهد بهتر؛
- محدودتر کردن اختیارات سیستم.
اگر هر نتیجه‌ای به «ادامه‌ی ساخت سیستم» ختم می‌شود، این برش اصلاً آزمایش نیست.
پیادهسازی
این کارگاه کاندیدها را بر اساس اثباتهای لازم فیلتر می‌کند، به گزینه‌های واجد شرایط امتیاز می‌دهد و نتیجه را در outputs/slice-decision.json می‌نویسد.
python3 code/main.py
python3 -m unittest discover code/tests -vیک کاندید کم‌هزینه‌تر اضافه کنید که فقط یکی از فرضیات لازم را اثبات کند. این کاندید حتی در صورت داشتن امتیاز عددی بالا، باید همچنان رد شود و واجد شرایط نباشد.
تمرین‌ها
- سه برش برای یک نتیجه‌ی مشخص، اما با سطوح مختلفی از تبعات طراحی کنید.
- پیش از امتیازدهی، مجموعهی اثباتهای لازم را بنویسید.
- یکی از قابلیت‌ها را بدون حذف شواهد تعیین‌کننده کنار بگذارید.
- یک قاعدهی توقف برای پروژه‌ی پایلوتِ شکست‌خورده بنویسید.
- یکی از مؤلفه‌های پلتفرمی با قابلیت استفاده‌ی مجدد را مشخص کنید که ساخت آن باید به بعد از ارزیابی برش موکول شود.
برای مطالعه‌ی بیشتر
- مقاله‌ی Barry Boehm, A Spiral Model of Software Development and Enhancement، برای تطبیق هر چرخه‌ی توسعه با ریسک‌هایی که باید برطرف کند.
- مقاله‌ی Lenarduzzi and Taibi, MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product، برای بررسی ابهامات پیرامون مفهوم «حداقل» و «حیاتی» در فرایند توسعه‌ی نرم‌افزار.
دستاورد شما از این درس
فایل outputs/slice-decision.json را نگه دارید. این فایل مستند می‌کند که چرا این برش، کوچک‌ترین برشی است که می‌تواند تصمیم بعدی را تغییر دهد.