המדריך המלווה ל-SDD

מדריך מלווה · מוצר ופיתוח

Spec-Driven Development · פיתוח מונחה מפרט

איך מוצר ופיתוח עובדים יחד עם סוכני קוד: מה השיטה, מה כדאי ללמוד לפני שמתחילים, ואיך היא הופעלה בפועל בפרויקט הגמל להשקעה.

למסלול הלמידה

לכל פרק יש הקראה קולית באנגלית ובעברית, ותמליל · עודכן בספטמבר 2026

01תמצית

למה SDD, ולמה עכשיו

אנחנו מאמצים את Spec-Driven Development כגישת העבודה העיקרית בין מוצר לפיתוח. כלים אג׳נטיים כבר נמצאים בשימוש בכל שלב, ממצגות ואפיונים ועד דרישות, קוד ובדיקות. כדי לנהל עבודה משותפת ביעילות צריך תהליך עבודה מוגדר ומותאם, ובדיוק לזה SDD נועד. מטרה נוספת היא לקצר את זמן ה-delivery, מהרעיון ועד production.

המדריך כולל מסלול למידה קצר, ארבע עד שש שעות על פני יומיים, שבונה בסיס משותף לפני שמתחילים לעבוד בשיטה. המקורות נבחרו בכוונה: הנדסיים וביקורתיים, לא חומר שיווקי. אחריו מתוארת השיטה כפי שהופעלה בפועל בגמל להשקעה: מה יש בריפו, מי אחראי על כל קובץ, ואיך כל קובץ נראה.

למי המדריך לכל מי שעובד על פרויקט בשיטה: מוצר, הנדסה ופיתוח, ניתוח מערכות, QA ואבטחת מידע.

המטרה: שפה אחת משותפת למוצר, להנדסה ולסוכני הקוד.

תמליל ההקראה, פרק 1

02מצב ההטמעה

מה כבר פותח בשיטה, ומה עוד לא

ההטמעה מבוססת בעיקר על ניסוי וטעייה, ועדיין לא כל הפרויקטים עובדים כך. אלה הפרויקטים שכבר פותחו בשיטה, והפרויקט הבא בתור:

הושלםדיגיטל

פלואו הצטרפות לגמל להשקעה בדיגיטל

דרישה ברמה גבוהה, שהגיעה ממנהל המוצר של הדיגיטל, תורגמה ל-specs. המפתחים של הדיגיטל פיתחו לפיהם, גם front וגם back, עם Claude Code.

עם SDD3 שבועות
בתהליך הרגיל2.5 עד 3 חודשים
בשבועות. הערכת הצוות, לא מדידה מבוקרת.
הושלםתפעול

אוטומציה מבוססת AI לשיוך כספי הפקדות לקופות גמל

אוטומציה לעבודה תפעולית ידנית, שנבנתה עם צוות ה-AI. כל הדרישות והאפיונים הטכניים נכתבו כקבצי md ונשמרו בריפו, ומשם צוות הפיתוח מימש אותם.

2ספרינטיםעד סוף הפיתוח

בסיום נערך רטרו, ועלו ממנו לא מעט מסקנות.

בדרך

פרויקט החיתום הגדול

חיתום
תמליל ההקראה, פרק 2

03מסלול הלמידה

יומיים, ארבעה מקורות

יום 1 בונה שפה משותפת. יום 2 מראה איך היא נראית כשעובדים בפועל עם סוכן קוד, ומסתיים בתרגול על פיצ׳ר אמיתי.

יום 1 · שפה משותפתכ-40 דקות
  1. 1מאמר · Birgitta Böckelerשלושה כלים ושלוש רמות של SDD20 דק׳
  2. 2הרצאה · Sean Groveמי שכותב את המפרט קובע מה ייבנה20 דק׳
יום 2 · עם סוכן קוד3.5 עד 5 שעות
  1. 3קורס · DeepLearning.AI ו-JetBrainsSDD עם סוכני קוד, 15 שיעורים1.5 עד 2 שעות
  2. 4תרגול · GitHub Spec Kitחמש פקודות על פיצ׳ר אמיתי2 עד 3 שעות

הפס מראה את חלוקת הזמן בין ארבעת המקורות, לפי אמצע הטווח.

יום 1

שפה משותפת

כ-40 דקות
1מאמר20 דקות קריאה

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Birgitta Böckeler · אוקטובר 2025

לקריאת המאמר martinfowler.com

למה. ניתוח עצמאי ומצוטט של שלושה כלים, ונקודת פתיחה טובה לשפה משותפת.

על מה לשים לב · שלוש הרמות

spec-first

המפרט נכתב לפני הקוד.

כאן אנחנו
spec-anchored

המפרט נשאר ומתעדכן לאורך חיי הפיצ׳ר.

spec-as-source

המפרט הוא המקור, והקוד נגזר ממנו.

בסקירה שנעשתה ביוני על ריפו הגמל, העבודה מוקמה ב-spec-anchored: המפרטים נשארים חיים ומתעדכנים גם אחרי הבנייה.

  • כדאי לשים לב גם לביקורת שבמאמר: כמה markdown צריך לסקור, ומתי התהליך כבד מדי לבעיה קטנה.
2הרצאה20 דקות צפייה

The New Code

Sean Grove · OpenAI

לצפייה בהרצאה youtube.com

למה. ההרצאה ממסגרת את התפקיד של מנהל מוצר בעולם של סוכני קוד: מי שכותב את המפרט הוא זה שקובע מה ייבנה.

על מה לשים לב

  • הטענה שקוד הוא הקרנה חלקית של הכוונה, והמפרט הוא הדבר המלא.
  • הרעיון שמפרט הוא קודם כל כלי ליישור בין אנשים, ורק אחר כך הוראות לסוכן.
Whoever writes the spec … is now the programmer.Sean Grove, מתוך ההרצאה
יום 2

עם סוכן קוד

3.5 עד 5 שעות
3קורסDeepLearning.AI ו-JetBrains1.5 עד 2 שעות

Spec-Driven Development with Coding Agents

Paul Everitt · JetBrains

לקורס deeplearning.ai · 15 שיעורים

למה. כאן רואים איך הרעיונות של יום 1 נראים כשעובדים בפועל עם סוכן קוד.

על מה לשים לב, ובאיזה שיעור

  • איך נכתבת חוקה לפרויקט, ומה נכנס אליה. Creating the constitution
  • לולאת תכנון, מימוש ואימות, וכמה מהזמן הולך לאימות. Feature implementation Feature validation
  • הפרק על הטמעת SDD בקוד קיים. רוב העבודה אצלנו היא על מערכות קיימות, לא על פרויקטים חדשים. Legacy support
  • האריזה של ה-workflow ל-Skill שאפשר להשתמש בו שוב. Build your own workflow
4ריפו ותיעוד2 עד 3 שעות תרגול

GitHub Spec Kit

לריפו ב-GitHub לתיעוד github.com/github/spec-kit

למה. זה ה-toolkit של GitHub ל-SDD, והוא תומך ב-Claude Code ובסוכנים נוספים.

איך מתרגלים

  1. 1

    מתקינים לפי ה-README, ובוחרים ב-Claude Code כסוכן.

  2. 2

    בוחרים פיצ׳ר קטן ואמיתי, רצוי בריפו קיים.

  3. 3

    מריצים לפי הסדר את חמש הפקודות: constitution, specify, plan, tasks ו-implement.

  4. 4

    עוצרים אחרי כל שלב, ובודקים את הקובץ שנוצר לפני שממשיכים.

  5. 5

    בסוף מודדים כמה זמן הלך על יצירת הקוד, וכמה על בדיקה, אינטגרציה ו-review.

שלב 5 · המדידה

בסיום התרגול ממלאים כאן את שני הזמנים, ומקבלים את היחס ביניהם.

בגרסאות האחרונות הפקודות נקראות /speckit.constitution, /speckit.specify וכן הלאה, ויש גם שלבים אופציונליים כמו clarify ו-analyze.

תמליל ההקראה, פרק 3

04השיטה בפועל

איך עבדנו בגמל להשקעה

כך הופעלה השיטה בפרויקט הגמל להשקעה, באפיק 1 שעסק בהצטרפות של לקוח חדש שאינו מזוהה. זו הגרסה המלאה, מלפני שהחוקה צומצמה, ומה שהשתנה מאז מופיע בסוף הפרק.

חלק א מתוך 2הרעיון, התהליך והמבנה

4.1הרעיון

המפרט הוא המוח, הסוכן הוא השריר

המוח

המפרט spec

מה בונים ולמה, באילו גבולות, ואיך נדע שזה עובד.

השריר

הסוכן agent

מממש לפי המפרט, בהקשר נקי לכל משימה, ובני אדם סוקרים כל diff.

בני האדם הם ארכיטקטים, לא מנהלי עבודה. הם מפקחים, מאמתים ומחליטים, ולא מכתיבים לסוכן שורה אחרי שורה.

4.2התהליך

שלושה שלבים: מה, איך, ובנייה

שלב 1 · מה בוניםShaping

מנהל המוצר מחדד את הדרישה ומדייק את התכולה, עד הסכמה על מה בתוך ה-scope ומה מחוצה לו.

שער
שלב 2 · איך בוניםPlanning

בונים את החוקה ומגדירים מי אחראי על מה, ואיך העבודה מתנהלת בין בעלי העניין.

שער
שלב 3 · בנייהExecution

לולאה של אפיון, מימוש ואימות, spec אחרי spec.

ציר הזמן: איך השלבים חופפים
רצף בין השלבים, ומקביליות בתוך שלב הבנייה. לא מתחילים Execution לפני ש-Planning נסגר, אבל מרגע שה-spec הראשון אופיין אפשר לממש אותו בזמן שהבאים עוד באפיון. הקו המקווקו מראה רגע אחד: spec 01 באימות, spec 02 במימוש ו-spec 03 באפיון. גוללים הצידה כדי לראות את כל הציר.

בכל מעבר בין שלבים יש סקירה ואישור אנושי, ורק אחריהם מתקדמים.

4.3מבנה הריפו

הכול במקום אחד, מקור אמת משותף

6מסמכי חוקה
17specs, אחד לכל user story
3מסמכים בכל spec
14חוזי שירות
עץ התיקיות, ומה יש בכל חלק
עץ התיקיות של ריפו הגמל
epic1-gemel-sdd/
├── CLAUDE.md 1
├── Constitution/ 2
│   ├── guardrails.md
│   ├── principles.md
│   ├── mission.md
│   ├── tech-stack.md
│   ├── contracts.md
│   ├── contracts/  14 חוזים ו-3 שלדים
│   └── roadmap.md
├── Specs/ 3
│   ├── 01-entry/
│   │   ├── specification.md
│   │   ├── implementation.md
│   │   └── validation.md
│   ├── 02-saver-details-otp/
│   ├── …
│   └── 17-animations/
├── STATUS.md 4
├── CHANGELOG.md 5
└── reference/ 6
  1. 1
    CLAUDE.md

    הוראות ההפעלה: איך עובדים בריפו, סדר הקדימות בין המסמכים, ואיך בונים implementation.

  2. 2
    Constitution/

    שישה מסמכי-על שכל השאר כפוף להם, ותיקיית חוזים עם קובץ לכל שירות.

  3. 3
    Specs/

    תיקייה לכל user story, עם שלושה מסמכים במבנה זהה.

  4. 4
    STATUS.md

    דשבורד מוכנות לבני אדם. שורת ה-Status שבכל spec היא המקור, והדשבורד רק מרכז אותה.

  5. 5
    CHANGELOG.md

    יומן חי של החלטות ושינויים, לצוות ולסוכנים שקוראים אותו.

  6. 6
    reference/

    חומרי רקע: מפת ה-flow, השוואות וסקירות.

4.4החוקה · Constitution

שישה מסמכי-על, ולכל אחד בעלים

המסמכים שכל שאר העבודה כפופה להם. בונים אותם ב-Planning, לפני שכותבים spec, ולכל אחד יש בעל תפקיד אחראי.

mission.mdמנהל המוצר

ההקשר העסקי: הבעיה, המטרות, הפרסונות, מה בתוך ה-scope ומה מחוצה לו, ומדדי ההצלחה.

roadmap.mdמנהל המוצר

מפת 17 ה-specs, גלי הבנייה, התלויות והחסמים, ושלד ההליכה (walking skeleton) לבנייה הראשונה.

guardrails.mdאבטחת מידע

כללי אבטחת מידע ופרטיות. יושב בראש החוקה, גובר על הכול, ונשמר כלשונו.

tech-stack.mdהנדסה

ארכיטקטורה, frameworks, סביבות, קטלוג השירותים ודרישות לא פונקציונליות.

בגמל: נשאר טיוטה שחיכתה לבעלים טכני.

contracts.mdמנתח מערכות

אינדקס של ממשקי השירות וקובץ לכל שירות: כתובת, request ו-response, authentication ושגיאות. נכתב מלוגים של production ומ-XSD.

principles.mdמוצר, בתיאום עם הנדסה

14 עקרונות שלא מתפשרים עליהם. למשל parity עם הפלואו הקיים, רק שירותים קיימים, ו-back office בלי שינוי.

בגמל: שני עקרונות הארכיטקטורה חיכו לאישור ההנדסה.

4.5סדר הקדימות

כששני מסמכים מתנגשים, הגבוה גובר

1גבולות אבטחהסמכות עליונהguardrails.mdאבטחת מידע
2עקרונות-עלאיך אנחנו תמיד מחליטיםprinciples.mdמוצר והנדסה
3כוונת המוצרמה ולמהmission.mdמנהל המוצר
4הקשר טכני וממשקיםאיך, מהצד הטכניtech-stack.md · contracts.mdהנדסה ומנתח מערכות
5התוכניתסדר וגלי בנייהroadmap.mdמנהל המוצר
6ה-specs הקונקרטייםהכי מפורטים, והכי משתניםSpecs/NN-*/לפי מסמך
  • כשמסמכים מתנגשים, הגבוה גובר. אפשר לשנות את הגבוה, אבל במכוון, ועם רשומה ב-CHANGELOG.
  • לפני ה-spec הראשון, כל בעל תפקיד כותב את החלק שלו בחוקה.
  • אבטחת מידע נכנסת ראשונה ומלמעלה, כך שהציות מובנה מהיום הראשון.
  • CLAUDE.md הוא מדריך ההפעלה. הוא קובע את התהליך, ובכל שאלה של תוכן מפנה לחוקה.

4.6תיקיית ה-spec

שלושה מסמכים, שלושה בעלים

כל user story היא תיקייה אחת, ובתוכה שלושה מסמכים במבנה זהה בכל 17 ה-specs: מה, איך, והוכחה.

מה ולמה

specification.md

בעלים: מנהל המוצר

  1. 0Overview
  2. 1הבעיה
  3. 2מה המשתמש רוצה
  4. 3User stories
  5. 4דרישות
  6. 5התנהגויות ומצבים
  7. 6מקרי קצה
  8. 7קריטריוני קבלה
  9. 8Flows
  10. 9UX
  11. 10שאלות פתוחות

מסכימים עליו לפני שבונים. מה שחסר מסומן TBD, להשלמת מנהל המוצר.

איך

implementation.md

בעלים: מנתח מערכות והנדסה

  1. 1Components
  2. 2APIs
  3. 3DB Schema
  4. 4Services
  5. 5Functions
  6. 6File structure
  7. 7Algorithms

נשאר כמעט ריק בכוונה, עד שהבעלים הטכני כותב אותו. לא ממציאים תכן טכני, ואת הממשקים מעתיקים מ-contracts.

הוכחה

validation.md

בעלים: מנהל המוצר ו-QA

  1. 1Test cases: תרחיש ותוצאה צפויה
  2. 2Manual tests
  3. 3Evals
  4. 4Performance tests
  5. 5Acceptance checklist

הבדיקות הפונקציונליות נגזרות מקריטריוני הקבלה. evals וביצועים אצל QA וההנדסה.

דוגמה: כך נראה specification.md בפועל
כך זה נראה בפועל. מתוך Specs/03-address/specification.md, בקיצור:
# 03 · Residential Address & Gender · Specification

> Owner: Product Manager · Status: partial · Screen(s): board 3
> Source: reference/flow-explanation-2026-06-18.md · PM narrative

## 4. Requirements
- City, street and house number are mandatory; apartment and zip are optional.
- City and street use the address service for autocomplete.

## 7. Acceptance criteria
- [ ] City and street accept only a value selected from the list.
- [ ] A complete screen advances to the amount step (04).

## 10. Open questions
- Address service is down: fall back to manual entry? (engineering)
תמליל ההקראה, חלק א · הרעיון, התהליך והמבנה

חלק ב מתוך 2העבודה והלקחים

4.7מי אחראי על מה

מי אחראי על כל קובץ

בעלים אחד או שניים לכל מסמך. אף אחד לא כותב בתחום של בעל תפקיד אחר, וכל החלטה מתקבלת אצל מי שאחראי עליה.

בעלויות על קבצי הריפו לפי תפקיד
קובץ מנהל המוצר מנתח מערכות הנדסה ופיתוח QA אבטחת מידע סוכן ה-AI
החוקה
guardrails.md קוראקוראקוראבעליםקורא
principles.md בעליםקוראמאשרקורא
mission.md בעליםקוראקוראקורא
tech-stack.md תורם טיוטהבעליםקורא
contracts.md בעליםמאשרקורא
roadmap.md בעליםקוראקורא
תיקיית ה-spec
specification.md בעליםקוראקוראקוראמנסח טיוטה
implementation.md בעליםבעליםמציע סעיפים
validation.md בעליםתורם בדיקות טכניותבעליםמנסח טיוטה
שורש הריפו
STATUS.md בעליםקוראקוראמסנכרן
CHANGELOG.md כותב רשומותכותב רשומותכותב רשומותכותב רשומותכותב רשומות

בחירת תפקיד מדגישה רק את התחום שלו.

4.8הלולאה

כך נראית העבודה על spec

חוזר לכל מפרט כל פעם בהקשר נקי סשן חדש /clear טוענים הקשר Constitution + spec הסוכן עובד draft · code סוקרים ומאשרים diff · commit 1 2 3 4
  1. 1

    סשן חדש. /clear

  2. 2

    טוענים הקשר. Constitution ו-spec

  3. 3

    הסוכן עובד. draft ו-code

  4. 4

    סוקרים ומאשרים. diff ו-commit

חוזר לכל מפרט, כל פעם בהקשר נקי.

  • הקשר נקי לכל spec.מתחילים כל spec בסשן חדש, וטוענים רק את החוקה ואת ה-spec הזה.
  • צעדים קטנים.קודם שלד הליכה דק מקצה לקצה, ואז גדילה אנכית. commit לעתים קרובות.
  • סוקרים כל diff.גם במסמכי md, לא רק בקוד.
  • משתמשים בחוזים.כש-spec נוגע בשירות, מעתיקים את הממשק מ-contracts ל-implementation, ולא מנחשים.

ובחזרה: מה שעולה בבנייה חוזר למפרט

ביקורת על הבנייה · 25.0616תיקונים, משלושה קבצי הערות
ה-spec היה נכון, והבנייה סטתה ממנוvalidation.mdנוספה בדיקה מפורשת
החלטה חדשה או שאלה שנסגרהspecification.mdה-spec עודכן
כלל שחל על כל המסכיםprinciples.mdנוספו עקרונות 13 ו-14
CHANGELOG.mdSTATUS.mdכל שינוי מתועד ומסונכרן
סבב הביקורת על הבנייה ב-25 ביוני. בחלק מהתיקונים ה-spec כבר היה נכון והבנייה סטתה ממנו, ולכן הם נרשמו כבדיקות ב-validation ולא כשינוי ב-spec. זה סימן בריא לשיטה: ה-spec נשאר מקור האמת.

4.9חסמים גלויים

כל אי-ודאות מסומנת, עם בעלים, לפני שורת קוד

ארבעת הסימונים שבהם משתמשים בתוך המסמכים:

מאושרנבדק מול מקור
טיוטה או הנחהכתוב, עם סעיפים שעוד צריך לאמת
placeholderעוד לא נכתב
חסוםשאלה פתוחה שעוצרת את ההתקדמות

חסום, לא סוגרים. spec עם שאלה חוסמת לא הופך לסופי עד שהשאלה נסגרת.

לא ממציאים את הלא ידוע. מה שלא ידוע מסומן TODO, עם בעל התפקיד שצריך לסגור אותו.

תמונת המצב של 17 ה-specs ב-30 ביוני
מצב המסמכים בכל spec ב-30 ביוני, ומי מחזיק את החסם הפתוח
specspecificationמהimplementationאיךvalidationהוכחהחסם פתוח אצל
כניסה לפלואו 01-entry
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
פרטי החוסך ואימות OTP 02-saver-details-otp
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		הנדסה
כתובת ומגדר 03-address
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
סכום מול תקרה 04-amount-ceiling
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
מסלולי השקעה 05-tracks
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
שאלון היכרות פיננסית 06-kyc-questionnaire
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
בעלי עסקים 07-kyc-business
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
בנק ותשלום 08-bank-and-payment
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
העלאת תעודה מזהה 09-id-upload
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
סיכום והצלחה 10-summary-success
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
שידור ל-back office 11-backend-emit
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד
טיוטה וליד 12-draft-and-lead
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		הנדסה
אנליטיקס ודוחות 13-analytics-bo
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		הנדסה
מסלול חסימה, AML 14-aml-redpath
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		מוצר
נגישות 15-accessibility
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		מוצר
הקלטת סשנים 16-glassbox
טיוטה מלאה
לא נכתב
בדיקות פונקציונליות בלבד		הנדסה
אנימציות 17-animations
חלקי
לא נכתב
לא נכתב		מוצר
תמונת המצב ב-30 ביוני, מתוך STATUS.md. עמודת ה-implementation נשארה ריקה לכל אורכה, כי צוות הפיתוח מימש ישירות מה-specification. ארבעה specs חיכו להחלטה של ההנדסה על מנגנון: OTP, ניהול session וטיוטות, אנליטיקס, ו-masking בהקלטות.

4.10מול Spec Kit

איפה אנחנו דומים, ואיפה שונים

המפה עוזרת לתרגם בין השיטות למי שמריץ את Spec Kit. היא מבוססת על הסקירה שנעשתה ביוני על ריפו הגמל.

ריפו הגמלהיחסSpec Kit
Constitution/עם סדר קדימות מפורש
מפורט יותר
constitution
specification.mdמה ולמה
תואם
specify
שאלות פתוחות וסימוני חסימהלא שלב נפרד, אבל מכוסה
מכוסה
clarifyאופציונלי
implementation.mdאיך
תואם
plan
אין שכבה כזופירוק מסודר למשימות קטנות
פער
tasks
בנייה עם Claude Code
תואם
implement
validation.mdמסמך נפרד, עם בעלים
מפורט יותר
בדיקותבדרך כלל בתוך tasks

הפער הבולט הוא שכבת ה-tasks, הגשר המסודר בין התכנון לקוד. מנגד, ה-validation אצלנו הוא מסמך נפרד, וסדר הקדימות בחוקה מחמיר יותר מהסטנדרט.

4.11מה למדנו

המציאות סטתה מהתוכנית, ומשם הלקחים

כך תוכנןכך קרה בפועל

מתחילים לכתוב specs אחרי שהחוקה שלמה.

כתיבת ה-specs התחילה עוד לפני שהחוקה הושלמה. הידע כבר היה קיים, ולא היה טעם לחכות.

כל חלקי החוקה נסגרים יחד.

קובץ ה-contracts הושלם באיחור, ושאר החוקה נסגר בלעדיו.

implementation נכתב לפני המימוש.

צוות הפיתוח מימש את ה-specification בלי קבצי implementation. קודם UI פונקציונלי, ורק אחר כך חיבור לשירותים.

פיתוח בתוך הסביבה הארגונית.

הפיתוח היה מול Figma ודרש חיבור MCP, שמצריך חשבון בתשלום מחוץ לארגון.

איפה זה עזר, ואיפה פחות · מתוך תחקיר עם אנשי הפיתוח

Front · עבד היטב

המפרטים תורגמו כמעט ישירות למסכים

בניית ה-UI הייתה מהירה ומדויקת. כאן התרומה של השיטה הייתה הברורה ביותר.

Back · אתגר גדול יותר

דורש הקשר שהמודל לא מכיר לבד

החיבור ל-SOA ול-ESB, הקונבנציות הקבועות של הדיגיטל, המשמעות של כל שגיאה, ואפילו הרישום של הדיגיטל כצרכן ב-SOA.

SOAESBקונבנציות דיגיטל

פערים בשירותים שהוגדרו בחוקה הצריכו הרבה debugging. את ההקשר הזה אפשר וצריך ללמד את המודל, דרך Skills ייעודיים.

4.12מה השתנה מאז

מה השתנה בתבנית מאז הגמל

מהגמל ומפרויקט שיוך ההפקדות נבנו תבנית ריפו ו-Skill למנהלי המוצר. החוקה צומצמה לשלושה קבצים, והצד הטכני נשאר בידי ההנדסה.

מה קרה לכל קובץ, אחד אחד
הקובץבגמלבתבנית היום
mission.mdחוקהנשארההקשר העסקי, ועכשיו גם עקרונות התכולה.
roadmap.mdחוקהנשארועכשיו מרוכז בו גם סטטוס האפיון.
assumptions.mdלא היהחדשהמקום היחיד בריפו לערכים מחייבים: הנחות עסקיות וטכניות, וכללים רוחביים.
principles.mdחוקהפוצלעקרונות התכולה עברו ל-mission, הכללים הרוחביים ל-assumptions, ועקרונות הארכיטקטורה להנדסה.
tech-stack.mdחוקהפוצלקטלוג השירותים עבר ל-references. ה-frameworks, ה-persistence, ה-CI והסכמות אצל ההנדסה.
contracts.mdחוקהשל ההנדסהחוזים, ארכיטקטורה וסכמות, מחוץ לתבנית של מנהל המוצר.
guardrails.mdחוקהיצאכללי אבטחת המידע לא נכתבים בריפו. יש אליהם הפניה מתיקיית references.
specification.mdspecנשארבבעלות מנהל המוצר.
implementation.mdspecשל ההנדסההתבנית וה-Skill של מנהל המוצר לא נוגעים בו.
validation.mdspecנשארו-QA הבעלים. מנהל המוצר כותב רק בסעיף ההערות שלו.
STATUS.mdשורשיצאסטטוס האפיון ב-roadmap, ופיתוח ובדיקות ב-Jira.
תמליל ההקראה, חלק ב · העבודה והלקחים

05שאלות פתוחות

ארבע שאלות שעדיין פתוחות

עד היום השיטה נבנתה בעיקר מהצד של המוצר, והצד הטכני נשאר פתוח. אלה ארבע השאלות שעדיין פתוחות, וההכרעה בהן משותפת למוצר ולהנדסה.

implementation ו-tech-stack

מי כותב את ה"איך"?

בגמל שני הקבצים נשארו כמעט ריקים, וצוות הפיתוח מימש ישירות מה-specification. בתבנית החדשה הם מחוץ לתבנית של מנהל המוצר. איך ינוהל הצד הטכני, ומי אחראי עליו?

Skills לסוכן

הקשר ל-Back

SOA, ESB, הקונבנציות של הדיגיטל והמשמעות של כל שגיאה. אילו Skills צריך כדי שהסוכן יפסיק לנחש?

בקרה

Review ו-drift

איך עושים review למסמכי md כמו לקוד, ואיך שומרים שה-spec והקוד לא יתרחקו זה מזה?

בעקבות Spec Kit

שכבת ה-tasks

האם נדרשת שכבת tasks בין התכנון לקוד, ואיך היא מתחברת ל-Jira?

נתון לדיון

המדידה משלב 5 בתרגול Spec Kit: כמה זמן הלך על יצירת הקוד, וכמה על בדיקה, אינטגרציה ו-review. היחס הזה עוזר לבחון את ארבע השאלות.

תמליל ההקראה, פרק 5
פרק 1 · תמצית

0:00 0:00