כיצד לכתוב סיפורי משתמשים זריזים טובים

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

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

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


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

אנו יכולים לפרק את המבנה של סיפור משתמש כ:


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

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



כיצד לכתוב סיפורי משתמשים טובים

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

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

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


ו יכול להיות - הסיפור אמור לספק ערך כלשהו למשתמשים בו.

IS ניתן לעורר - על הצוות להיות מסוגל לאמוד את הסיפור.

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

ט estable - ודא שניתן לאמת ולבדוק את מה שמתפתח.


באיזה פורמט משתמשים כתיבת סיפורי משתמשים?

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

_כמו כן, אני רוצה כך ._

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

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


נרטיב

  • החלק הראשון של סיפור המשתמש הוא הנרטיב. 2-3 משפטים המשמשים לתיאור כוונת הסיפור. זה רק סיכום הכוונה.

שיחות

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

קריטריונים לקבלה

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

על מי לכתוב סיפורי משתמשים?

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


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

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

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

עד כמה סיפורי משתמשים צריכים להיות מפורטים?

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

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

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

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

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

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

טעויות נפוצות בעת כתיבת סיפורי משתמשים


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


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


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

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