شکستن کار و ساخت برش عمودی

کار را طوری بشکنید که هر بخش چیزی واقعی را ببندد

فرض کنید برای فیلتر کارهای ناتمام یک Specification آمادهٔ پیاده‌سازی دارید. اگر آن را به «یک کار backend»، «یک کار frontend» و «یک کار تست» تقسیم کنید، ممکن است هر سه کار پیش بروند اما هیچ‌کدام به‌تنهایی یک رفتار قابل استفاده و قابل داوری را کامل نکند. نتیجه، چند خروجی نیمه‌کاره با وابستگی‌های پنهان است.

در این درس Vertical Slice Plan v1 می‌سازید: برنامه‌ای که یک Specification کامل را به واحدهای کوچک‌تر می‌شکند، اما دست‌کم یک واحد را به شکل برش عمودی end-to-end تعریف می‌کند؛ یعنی برشی که از لایه‌های لازم عبور می‌کند و یک معیار قابل مشاهده را می‌بندد. برای هر واحد، outcome، evidence، dependency order و merge/rollback boundary روشن می‌شود.

این درس کد اجرا نمی‌کند و AI run را آغاز نمی‌کند. خروجی فقط واحدهای کار و ترتیب کنترل‌شدهٔ آن‌هاست. اجرای یک واحد با AI در FND-003 انجام می‌شود.

زمان فعال تقریبی: ۵۰ دقیقه.

این درس برای شماست اگر: یک Specification آماده دارید اما backlog شما هنوز به taskهای بزرگ، لایه‌ای یا مبهم شکسته شده و نمی‌توانید نشان دهید کدام واحد به‌تنهایی ارزش یا evidence قابل داوری می‌دهد.

این درس برای این کارها نیست: بازتعریف Specification، تقسیم کار فقط بر اساس فایل یا تخصص، انتخاب کوچک‌ترین diff بدون outcome، یا اجرای کد/AI run.

پیش‌نیاز سخت — FND-001-P05: باید بتوانید یک Specification آمادهٔ پیاده‌سازی را بدون تصمیم پنهان بازسازی و review کنید.

پروب کوتاه پیش‌نیاز

این packet را در نظر بگیرید:

• Spec ID: TASK-FILTER-SPEC-v1
• Problem: کاربر باید بتواند فقط کارهای ناتمام را ببیند.
• IN: انتخاب All یا Unfinished و بازگشت به All.
• OUT: persistence انتخاب، تغییر schema، redesign.
• Constraint: معنی completed/unfinished و قرارداد داده تغییر نمی‌کند.
• AC-01: در حالت Unfinished فقط taskهای ناتمام دیده شوند.
• AC-02: بازگشت به All نمای عادی را برگرداند.
• Readiness: contradiction حل‌نشده = ۰؛ blocking unknown = ۰؛ review انسانی انجام شده است.

در چند خط توضیح دهید: outcome، scope boundary، دو criterion و constraint اصلی این Specification چیست و چرا برای decomposition کافی است.

PASS: بدون اضافه‌کردن requirement جدید، packet را درست بازسازی کنید و میان goal، boundary، criterion و constraint تفاوت بگذارید.

اگر این packet برای شما مستقل و روشن نیست، فقط همان بخش از FND-001-P05 را repair کنید. decomposition نباید ابهام Specification را پنهان کند.

مقدار راهنمایی مناسب را انتخاب کنید

همهٔ مسیرها به همان Vertical Slice Plan v1 و همان evidence bar می‌رسند.

پروب چهارمفهومی مسیر

1. یک work unit خوب چه چیزی بیشتر از «نام یک فایل یا تخصص» دارد؟
2. چرا یک task صرفاً frontend یا backend لزوماً Vertical Slice نیست؟
3. چرا کوچک‌ترین code diff ممکن است از «کوچک‌ترین برش مفید» کوچک‌تر باشد؟
4. dependency order و rollback boundary چه تصمیمی را روشن می‌کنند؟

۴/۴ → Fast Path؛ ۲–۳/۴ → فقط مفهوم‌های شکننده را ترمیم کنید؛ ۰–۱/۴ → مسیر پایه.

• مسیر پایه: مثال کامل فیلتر task را با template دنبال کنید.
• مسیر ترمیم: فقط misconception مرتبط را بازسازی کنید.
• مسیر باتجربه/Fast Path: مستقیماً سراغ کیس مستقل بروید؛ ambiguity و dependency بیشتر است ولی evidence bar تغییر نمی‌کند.

مدل ذهنی: برش عمودی از ارزش عبور می‌کند، نه از یک لایه

زنجیرهٔ این بخش از مسیر چنین است:

Implementation-Ready Spec → decomposition → useful vertical slice(s) → dependency/rollback plan → FND-003 execution

چهار مفهوم نقش‌های جدا دارند:

horizontal split ممکن است برای سازماندهی تخصص‌ها مفید باشد، اما اگر هیچ واحدی outcome قابل استفاده ندهد، هنوز برش تحویلی مناسبی نساخته‌اید.

چهار مفهوم پایه

۱. شکستن کار / Task decomposition

Specification را به واحدهایی می‌شکند که هرکدام هدف، boundary و evidence role دارند. واحد خوب صرفاً «تغییر فایل X» نیست؛ باید بتوان گفت بعد از اتمام آن چه چیزی درست‌تر، قابل مشاهده‌تر یا قابل بررسی‌تر شده است.

۲. برش عمودی / Vertical slice

یک برش کوچک end-to-end است که از لایه‌های لازم عبور می‌کند و یک رفتار قابل مشاهده یا ارزشمند را کامل می‌کند. لازم نیست همهٔ لایه‌های سیستم را لمس کند؛ فقط لایه‌هایی که برای بستن همان رفتار لازم‌اند.

۳. کوچک‌ترین برش مفید / Smallest useful slice

کوچک‌ترین برشی است که هنوز outcome واقعی دارد. اگر خروجی فقط یک component خالی، schema بی‌مصرف یا wiring بدون رفتار باشد، احتمالاً «کوچک» است اما هنوز «مفید» نیست.

۴. ترتیب وابستگی و مرز بازگشت

ترتیب کار باید از dependency یا risk دلیل بگیرد. هر واحد باید تا جای ممکن نقطهٔ merge و rollback قابل فهم داشته باشد تا شکست یک واحد کل مسیر را مبهم نکند.

Vertical Slice Plan v1 را بسازید

برای هر candidate work unit این فیلدها را ثبت کنید:

1. Unit ID و نوع: Vertical Slice، supporting dependency یا verification support.
2. Bounded outcome: بعد از پایان این واحد چه نتیجه‌ای به‌دست می‌آید؟
3. Criterion(s) closed: کدام acceptance criterion واقعاً در این واحد بسته می‌شود؟
4. Layers touched: فقط لایه‌های لازم؛ نه فهرست همهٔ فایل‌ها.
5. Prerequisites: چه dependency شناخته‌شده‌ای باید قبل از شروع برقرار باشد؟
6. Evidence: چه شاهدی نشان می‌دهد outcome بسته شده است؟
7. Order reason: چرا این واحد قبل/بعد از واحد دیگر می‌آید؟
8. Merge boundary: چه چیزی می‌تواند مستقل review یا ادغام شود؟
9. Rollback boundary: اگر evidence شکست خورد، دقیقاً تا کجا برمی‌گردیم؟
10. Next unit: واحد بعدی و دلیل انتقال.

قالب خالی و قابل استفادهٔ مجدد

برای هر work unit این قالب را پر کنید؛ بخش Next unit باید هم شناسهٔ واحد بعدی و هم دلیل handoff را داشته باشد.

Unit ID / type:
Bounded outcome:
Criterion(s) closed:
Layers touched:
Prerequisites:
Evidence:
Order reason:
Merge boundary:
Rollback boundary:
Next unit ID:
Next-unit handoff reason:

نسخهٔ machine-readable همین scaffold در artifacts/vertical_slice_plan_v1_template.json قرار دارد. این قالب فقط برنامهٔ کار را ثبت می‌کند و شامل دستور اجرای کد یا AI run نیست.

قانون مهم: decomposition را از criterion و outcome شروع کنید، نه از ساختار تیم یا پوشه‌ها. بعد مشخص کنید برای بستن آن outcome کدام لایه‌ها لازم‌اند.

AI می‌تواند candidate sliceها را پیشنهاد دهد، dependencyهای احتمالی را نقد کند یا missing evidence را پیدا کند؛ اما در این درس نباید کد، test change یا execution step تولید/اجرا کند. requirement جدید، acceptance و تصمیم نهایی دربارهٔ ترتیب/مرزها باید از Specification و review انسانی بیاید؛ اجرای تغییر برای FND-003 باقی می‌ماند.

مثال حل‌شده: فیلتر کارهای ناتمام

ورودی همان TASK-FILTER-SPEC-v1 است:

• AC-01: Unfinished فقط taskهای ناتمام را نشان دهد.
• AC-02: All نمای عادی را برگرداند.
• Constraint: data contract و معنی status تغییر نکند.
• OUT: persistence و redesign.

یک decomposition مناسب می‌تواند چنین باشد:

WU-01 — Vertical Slice

Outcome: کاربر بین All و Unfinished جابه‌جا شود و رفتار هر دو حالت قابل مشاهده باشد. Criteria closed: AC-01, AC-02 Layers touched: کنترل انتخاب view + state موجود list + render مسیر موجود Evidence: mixed-status list، بازگشت به All، all-completed case Order reason: اولین feedback واقعی را بدون persistence یا schema change می‌دهد. Merge boundary: تغییر bounded به رفتار view filter. Rollback boundary: حذف همین مسیر انتخاب/filter باید نمای قبلی All را برگرداند.

WU-02 — Verification support

Outcome: constraint عدم تغییر data contract و regression مسیر list بررسی شود. Criterion/role: نقش پشتیبان برای acceptance برش اول؛ value slice جدا ادعا نمی‌کند. Evidence: contract/schema inspection + existing-list regression check Order reason: قبل از acceptance نهایی WU-01 باید evidence محدودیت‌ها بسته شود. Rollback boundary: اگر contract تغییر کرده باشد، WU-01 پذیرفته نمی‌شود و تغییر مرتبط rollback/replan می‌شود.

این plan عمداً «تمام frontend اول، تمام backend بعد» نمی‌سازد. از رفتار قابل مشاهده شروع می‌کند و فقط dependencyهای لازم را به آن متصل می‌کند.

چهار شکست رایج

شکست ۱: تقسیم بر اساس تخصص

Frontend task و Backend task تعریف می‌شوند، اما هیچ‌کدام criterion کاربر را نمی‌بندند. Repair: از یک criterion observable شروع کنید و لایه‌های لازم را داخل یک Vertical Slice جمع کنید.

شکست ۲: ساخت همهٔ infrastructure قبل از رفتار

کار زیادی انجام می‌شود ولی هنوز feedback واقعی وجود ندارد. Repair: کوچک‌ترین flow قابل داوری را پیدا کنید؛ infrastructure فقط به اندازهٔ نیاز همان slice وارد شود.

شکست ۳: کوچک‌ترین diff به‌جای کوچک‌ترین برش مفید

یک component یا interface خالی ساخته می‌شود و «slice» نام می‌گیرد. Repair: بپرسید کدام user-visible criterion با این واحد بسته می‌شود. اگر هیچ‌کدام، یا supporting role آن را صریح کنید یا unit را دوباره ببرید.

شکست ۴: کار موازی روی dependency حل‌نشده

دو واحد هم‌زمان فرض‌های متفاوتی دربارهٔ state/contract دارند. Repair: dependency مشترک را روشن کنید، order reason را ثبت کنید و rollback boundary هر مسیر را پیش از parallelization مشخص کنید.

پل مسیر باتجربه: وابستگی پنهان و کار موازی

در پروژهٔ واقعی، «استقلال کامل» همیشه ممکن نیست. دو slice کوچک ممکن است روی یک capability مشترک تکیه کنند. مسئله این نیست که dependency صفر باشد؛ مسئله این است که dependency شناخته‌شده، bounded و دارای دلیل ترتیب باشد.

فرض کنید Slice A برای نمایش وضعیت جدید و Slice B برای ویرایش همان وضعیت هر دو به یک state contract وابسته‌اند، ولی نام و ownership آن هنوز قطعی نیست. شروع موازی هر دو مسیر فقط سرعت ظاهری ایجاد می‌کند. انتخاب حرفه‌ای‌تر این است که dependency را به‌عنوان prerequisite روشن کنید، evidence لازم برای تثبیت آن را مشخص کنید و سپس تعیین کنید چه بخش‌هایی واقعاً مستقل قابل حرکت‌اند.

برای مسیر باتجربه، plan را تحت این فشارها بررسی کنید:

• dependency مشترک اما محدود؛
• evidence ناقص برای یکی از order decisionها؛
• rollback ساده برای یک slice و پرهزینه برای دیگری؛
• temptation برای parallelization بدون contract روشن.

پاسخ درست گاهی «replan پیش از شروع» است، نه «همه‌چیز را موازی کن».

راه‌های مختلف شکستن کار و بده‌بستان‌ها

• Horizontal/layer split: برای ownership تخصصی ساده است، اما ممکن است feedback کاربر را دیر کند.
• Vertical slice: outcome قابل مشاهده را زودتر می‌بندد، ولی ممکن است هماهنگی چند لایه یا چند تخصص بخواهد.
• Dependency-first split: برای capability مشترک یا migration ضروری می‌تواند مناسب باشد، اما supporting work باید به value slice مشخص وصل بماند.
• Risk-first slice: uncertainty پرهزینه را زودتر می‌آزماید، به شرطی که outcome/evidence آن روشن باشد.
• Smallest-diff split: review کد را کوچک می‌کند، ولی به‌تنهایی تضمین نمی‌کند واحد مفید یا قابل پذیرش باشد.

هیچ template خاصی جای judgment را نمی‌گیرد. invariantها مهم‌اند: outcome bounded، حداقل یک vertical value slice، evidence روشن، order reason و rollback boundary.

تمرین هدایت‌شده و مستقل

کیس هدایت‌شده — جست‌وجوی سفارش

Specification packet:

• Problem: کاربر باید سفارش را با شمارهٔ کامل سفارش پیدا کند.
• IN: exact order-number search در صفحهٔ orders.
• OUT: fuzzy search، customer-name search، redesign.
• Constraint: order schema و مسیر list موجود تغییر نکند.
• AC-01: exact match سفارش درست را نشان دهد.
• AC-02: no-match پیام واضح بدهد.
• AC-03: list موجود بدون search همچنان کار کند.
• Readiness: requirement conflict گزارش نشده و lookup capability موجود تأیید شده است.

یک Vertical Slice Plan v1 با ۲ تا ۴ work unit بسازید. حداقل یک unit باید AC-01 یا AC-02 را end-to-end ببندد. برای هر unit outcome، evidence، prerequisites، order reason، merge/rollback boundary و شناسهٔ next unit + دلیل handoff را بنویسید. کد یا AI run تولید نکنید.

کیس مستقل — Fast Path destination: تازه‌سازی Avatar

Specification packet:

• پس از replacement موفق، avatar جدید در visit بعدی profile دیده شود.
• failure باید تصویر فعلی را حفظ و error واضح نشان دهد.
• upload API و storage provider تغییر نمی‌کنند.
• crop editor، history و profile redesign خارج از scope هستند.
• cache ownership برای مسیر فعلی مشخص است.
• AC-A: success در visit بعدی تصویر جدید را نشان دهد.
• AC-B: failure تصویر قبلی را حفظ کند و error واضح بدهد.
• AC-C: upload/storage contracts بدون تغییر بمانند.

این Specification را به ۲ تا ۴ work unit تقسیم کنید. حداقل یک smallest useful vertical slice، dependency order، rollback boundary و next-unit handoff با شناسه و دلیل ارائه دهید. wording و structure کیس task-list را کپی نکنید و هیچ execution step متعلق به FND-003 ننویسید.

چه زمانی برنامهٔ برش واقعاً قابل قبول است؟

پیش از پذیرش Vertical Slice Plan v1 این سؤال‌ها را بررسی کنید:

1. آیا هر work unit outcome و evidence role روشن دارد؟
2. آیا حداقل یک smallest useful slice یک criterion قابل مشاهده را end-to-end می‌بندد؟
3. آیا supporting dependencyها به slice مشخصی وصل‌اند و value مستقلِ ساختگی ادعا نمی‌کنند؟
4. آیا order از dependency/risk دلیل می‌گیرد؟
5. آیا merge و rollback boundary برای هر واحد روشن یا با دلیل مشترک شده است؟
6. آیا plan Specification را بازتعریف نکرده است؟
7. آیا execution و AI run برای FND-003 باقی مانده است؟
8. آیا acceptance plan با review انسانی انجام می‌شود و evidence صرفاً self-report نیست؟

machine check می‌تواند completeness و linkها را بررسی کند؛ کافی‌بودن slice و پذیرش نهایی به judgment انسانی نیاز دارد.

ارزیابی و انتقال

ارزیابی پنج لایه دارد: تعریف bounded، application روی Specification تازه، diagnosis یک decomposition معیوب، decision انسانی روی ترتیب/parallelization، و transfer به domain جدید.

برای PASS در سؤال‌های blocking باید:

• هر چهار مفهوم در artifact دیده شوند؛
• حداقل یک vertical slice واقعی criterion را ببندد؛
• کوچک‌ترین diff با smallest useful slice اشتباه نشود؛
• dependency order و rollback boundary دلیل‌دار باشند؛
• plan بدون context شفاهی قابل review باشد؛
• تصمیم انسانی Q4 علاوه بر verdict و rationale، ابهام/عدم‌قطعیت باقی‌مانده را ثبت کند؛ اگر موردی باقی نمانده، صریحاً NONE / بسته‌شده بنویسد؛
• اجرای AI به درس بعدی منتقل بماند.

Evidence نهایی این درس خود Vertical Slice Plan v1 + rationale + decision record است.

منابع فنی و وضعیت استاندارد

برای زمینهٔ requirements engineering، ISO/IEC/IEEE 29148:2018 همچنان Edition 2 منتشرشده است و ISO آن را در وضعیت «to be revised» نشان می‌دهد. Edition 3 در حال حاضر Draft International Standard و under development است و هنوز جایگزین نسخهٔ 2018 نشده است.

برای مفهوم slicing، گزارش Agile Alliance یک نمونهٔ عملی از تفاوت vertical و horizontal slicing و تحویل incrementهای کوچک و ارزشمند ارائه می‌کند. این منبع برای مفهوم‌سازی استفاده می‌شود؛ Vertical Slice Plan v1 یک artifact آموزشی این درس است و از هیچ استاندارد بیرونی به‌عنوان template اجباری کپی نشده است.