ההבדלים בין סיפור משתמש למקרי שימוש User Story vs Use Case

האם סיפור משתמש (user story) זהה למקרה שימוש (Use Case) אנשים שואלים לעתים קרובות את השאלה הזו והמחלוקת אם צוות אג'ילי צריך לתרגל User Stories לעומת Use Cases קיימת בשטח כבר שנים. האם User Story וUse-Case הם אותו הדבר? אם לא, מה עדיף? באיזה מהם כדאי להשתמש? או האם אפשר להשתמש בשניהם?

הרבה אנשים מבלבלים בין מקרי שימוש (Use Cases) וסיפורי משתמש (User Stories) אבל למעשה מדובר במושגים שונים. מאמר זה דן בפירוט בשני המושגים ובהבדלים ביניהם.

סיפור משתמש לעומת מקרה שימוש

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

מהו מקרה שימוש?

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

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

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

• השחקן: זהו הגורם המקיים אינטראקציה עם המערכת (אדם, קבוצת אנשים או מערכת אחרת.) אלו יכולים להיקרא גם משתמשי המערכת.
• המטרה: זו התוצאה שלשמה תוכנן מקרה השימוש.
• המערכת: זה כולל את כל השלבים שבוצעו כדי להשיג את המטרה שנקבעה.

בנוסף, ניתן לכלול את המונחים הבאים:

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

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

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

תרחישי הצלחה עיקריים – מקרה שימוש בו שום דבר לא משתבש (בשפת הבודק: בדיקות חיוביות) נתיבים אלטרנטיביים – נתיבים אלו הם וריאציה על הנושא המרכזי

וכוללים מקרים חריגים שמשתבשים ברמת המערכת. (בשפת הבודק: בדיקות שליליות)

לדוגמא אם מקרה השימוש מתייחס ללקוח באתר קניות (E-Commerce) שמעוניין לשלם בכ"א ואלידי, עלינו לחשוב על בדיקות רבות שאינן ואלידיות כמו: תשלום בכ"א בסטטוס אבוד, גנוב, מעוקל וכ'ד).

 

מהו סיפור משתמש?

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

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

למשל: אם יש לנו לקוח שמעוניין להגיע מנקודה א' לנקודה ב' באמצעות תחבורה ציבורית וברצונו לקבל מידע זמין ומהימן לגבי שימוש יעיל בתחבורה ציבורית אפליקציית (MOOVIT) נתאר את סיפור המשתמש באופן הבא:

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

במילים טכניות, זהו תיאור של תכונה נדרשת במערכת מנקודת מבטו של משתמש הקצה, טכניקה שמאוד נפוצה בעולם האג'ילי. תיאור זה עוזר לצוות המוצר בזיהוי המשתמשים והדרישות שלהם. זה גם עוזר לפשט תהליכים מורכבים ולכן היתרון שלו משמעותי בפיתוח זריז וגמיש כאשר אפקט הזמן הוא קריטי וה- TIME TO THE MARKET הוא פקטור משמעותי.

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

חשוב שלסיפור משתמש יהיה מתווה ברור כדי לוודא שהדרישות מולאו במלואן,

ביצירת סיפור משתמש יש לבדוק את הפרטים הבאים:

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

 

נקודות דמיון:

סיפורי משתמש כוללים: משתמש (שחקן), מטרה וקריטריוני קבלה (acceptance criteria).

מקרי שימוש כוללים: משתמש קצה, זרימה של תהליך ותנאים מקדימים.

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

בסיפורי משתמש נחסכים פרטים טכניים חשובים שהיינו מפרטים במקרי שימוש בכדי לאפשר דיון בפגישות צוות תכופות (Scrum Meetings) המטרה היא לשמור על פידבק בתדירות גבוהה במקום לקבל מפרט דרישות מפורט מראש כמו במקרים של שימוש.

 

למה ליצור סיפור משתמש?

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

סיפורי משתמשים יכולים לעזור לייעל את הפרויקט

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

מביא את כולם לשיח משותף

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

הגדרה ברורה של המטרה

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

עוזר להגדיר את המוצר כולו

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

מעודד גישה ממוקדת משתמש

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

דוגמה לסיפור משתמש לעומת מקרה שימוש

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

דוגמה למקרה שימוש

שם מקרה שימוש: ביצוע הזמנת השכרת אופניים

שחקנים: שוכר (משתמש קצה)

מערכת נבדקת: מערכת חיוב (סליקה) אונליין

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

ייתכן שלמשתמש כבר יש חשבון בחברה עם פרטי חיוב.

אלטרנטיבה חלופית תהיה:

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

דוגמה לסיפור משתמש

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

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

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

מיקוד משתמש מול מיקוד טכני

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

כללי מול עומק

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

קצר מול מפורט

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

סיפורי משתמש מפותחים לפני מקרי השימוש

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

הדמיון של סיפור משתמש ומקרה שימוש

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

מתי להשתמש בסיפור משתמש לעומת מקרה שימוש?

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

חשוב לציין שמבחינת הבדיקות, הייעוד של הטכניקות הוא שונה. בעוד שסיפור משתמש מיועד לבדיקות ברמת המערכת (Test System), בדיקות שמבוצעות על ידי צוות הבודקים, הרי שמקרי שימוש מיועדים לשלב בדיקות הקבלה  (Acceptance Tests) שיופיעו ברמה גבוהה ומאוחרת יותר בשלבי הבדיקות.

מתי להשתמש במקרה שימוש לעומת סיפור משתמש?

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

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

לסיכום

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

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

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