כיצד לכתוב סיפורי משתמשים זריזים: 7 הנחיות

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

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

תחילת העבודה עם כתיבת סיפורי משתמשים זריזים

יש הרבה משאבים שיעזרו לבעלי מוצרים חדשים, אנליסטים עסקיים, אדוני סקרום ומובילים טכניים להבין את היסודות של כתיבת סיפורי משתמשים. כמה מקומות להתחיל לכלול מאמרים מ- Atlassian, FreeCodeCamp, Agile Modelling ודוגמאות 200 אלה של סיפור משתמש. אחת מהכתובות המלאות יותר היא בסיפור המשתמש הזריז ביותר של אלכסנדר קואן. ישנם ספרים על כתיבת סיפור, כולל מיפוי סיפור משתמש  מאת ג'ף פאטון ופיטר כלכלה וסיפורי משתמשים שהוחל על  ידי מייק קון. אתה יכול גם ללמוד קורסים על כתיבת סיפור מאת Udemy, Learning Tree, VersionOne ו- Lynda.

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

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

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

1. כתוב סיפורים לקהלים שישתמשו בהם

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

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

2. התחל עם המשתמש בראש

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

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

3. ענו מדוע הסיפור חשוב

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

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

4. הגדירו קריטריונים לקבלה ללא קביעת פתרון

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

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

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

5. השתמש בסיפורים כדי להגדיר מה ולמה; הגדר משימות כיצד ליישם

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

יש כמה סיבות שזה יכול לקרות.

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

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

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

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

6. תייג את הסיפורים שלך בכדי להניע ניתוחים ושיפור תרגול

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

הנה כמה דוגמאות:

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

7. הגדר תבניות סיפור זריזות ומדריכי סגנון

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

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

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

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

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