שלב 3

User Stories ו-Acceptance Criteria

רשימת משימות (Backlog) לא שווה הרבה אם המשימות עצמן עמומות. כשהפיתוח לא מבין מה צריך לעשות, מתחילות שאלות הפינג-פונג והעיכובים. בשיעור זה נלמד איך להשתמש ב-AI כדי לכתוב Acceptance Criteria ברורים וחד משמעיים בפורמט BDD.

01מתי משתמשים

לפני Sprint Planning או Backlog Refinement, כדי לוודא שכל ה-Tickets מוכנים לפיתוח
כשה-QA מבקש לדעת מהם מקרי הבדיקה (Test Cases) לפני פיתוח הפיצ'ר
במעבר מ-PRD שמאשר את ה'מה' לכרטיס ג'ירה שמאשר את ה'איך'

02דוגמה מעשית

ניקח משימה פשוטה כמו 'שחזור סיסמה'. במקום לכתוב 'על המשתמש לקבל אימייל שחזור', ה-AI ינסח: Given משתמש לא מחובר שלח בקשה; When הוא לוחץ על הלינק בתוך 24 שעות; Then הוא מופנה למסך בחירת סיסמה חדשה. בנוסף, נדרוש מה-AI לכסות Edge Cases כמו תפוגת תוקף הלינק.

03 פרומפט

deliveryבינוני

כותב Acceptance Criteria ל-Tickets

פירוט Ticket המכיל User Story מדויק ותרחישי הצלחה/כישלון בפורמט BDD

JiraBDDAcceptance CriteriaQA

פלט צפוי

טיקט מוכן להדבקה ישירה ב-Jira/Linear: כותרת קצרה ופונקציונלית, User Story בפורמט As a / I want / So that, Acceptance Criteria אטומיים בפורמט BDD מדויק (Given/When/Then) שכוללים לפחות שני Unhappy Paths, וסעיף Analytics עם ה-Events שצריך לשלוח בהצלחה ובכישלון. כל היקף לא ברור מסומן במקומו כ-[חסר: <מה חסר> - לבירור מול PM] במקום שה-AI ימציא אותו, ומחוץ לטיקט עצמו - תחת כותרת נפרדת 'מעבר לטיקט (לא להדביק בג'ירה)' - מופיע סעיף שמסביר לכל [חסר: ...] למה הוא נדרש ואיפה למצוא אותו.

טעויות נפוצות

להשאיר משימות עם AC של 'שזה יעבוד כמו באפיון' (מזמין באגים)
לא להגדיר מה קורה ב-Unhappy Paths (הזנת נתונים שגויים, שגיאות רשת)
ליצור משימות שיש להן תלויות (Dependencies) נסתרות מבלי לציין אותן בכרטיס

תרגול עצמי

בחר את אחד מסיפורי המשתמש שקיבלת מה-AI בשיעור הקודם. העתק אותו והזן אותו יחד עם הפרומפט החדש. בדוק את התוצאה: האם ה-AI כיסה את מקרה הקצה שבו מסד הנתונים למטה? אם לא, בקש ממנו להוסיף טיפול בשגיאת רשת.

תוצרים

User Story בפורמט התקני
Acceptance Criteria בשיטת BDD
הגדרות Tracking ו-Edge Cases מוכנים לפיתוח