בסיס עיקרי של תהליכי פיתוח מודרניים הוא פיתוח זריז . מתודולוגיית פיתוח זו מדגישה שימוש בסיפורי משתמש קטנים וגדולים ביסים כדי להגדיר מה המערכת עושה מנקודת מבט של משתמש, ולא טכנית. למשתמש אכפת אם מוצר הוא מהיר, קל לשימוש ופותר את הבעיה שלו. לא אכפת להם אם הוא עוקב אחר ארכיטקטורה בעלת שלוש שכבות, יש Mongo DB, או אם היא משתמשת ב- Rails או Asp.net.
Storyboard That המספק פלטפורמה אידיאלית ליצירת סיפורי משתמשים זריזים ולעורר שיחה בפורמט שהוא הרבה פחות ממיס מאשר קיר טקסט.
בהקשר של סיפורי משתמשים, "אפוס" הוא פשוט סיפור רחב מאוד שלימים יתפרק להרבה סיפורי משתמשים ספציפיים. החל מאפוס מיישר את כולם עם ראייה יחידה ברמה גבוהה. הסיפור האפי מעגן פרויקט מלמעלה למטה, ואם זה לא הגיוני לבנות אפוס, עבודה תומכת תהיה גם בזבוז מאמץ.
בסיפור זה ברור מאוד מה החזון לטווח הרחוק ואיך ההצלחה צריכה להראות. סיפור אפי טוב צריך לכלול:
במיוחד בעת תכנון תוכנה, חשוב שתהיה חזון טוב כיצד יראו המשתמשים. לא כל משתמש יתאים לחזון זה במדויק וייתכנו מספר קטגוריות של משתמשים, אך חזיונות נפרדים אלו זקוקים לניסוח. מחשבה על משתמשים הראשונים שמירה על הנדסת יתר וסיבוך יתר, מונעת ממוצר חדש שיהיה לו משהו לכל אחד ויהיה מועיל לאיש.
לאחר הקמת האפוס והגדרת המשתמשים, ניתן לבנות סיפורים קטנים יותר וספציפיים יותר על חוויות משתמש מסוימות. הסיפורים שלמטה מפרקים את המתואר לעיל לשני נרטיבים: לחפש הזמנה ולהזמין מחדש מוצר.
נרטיבים אלה אינם מכילים מידע טכני; למשתמשים לא אכפת כיצד יושגו התוצאות, כל עוד הוא מבצע את המשימות הרצויות. באופן דומה, ה- UX מתואר באופן כללי, כדי להימנע מחניקה של חידוש או אילוץ נתיב. באופן כללי, סיפורים צריכים להיות:
סיפורים אלה צריכים להזמין שיחה ושאלות, כגון:
סביר בהחלט ליצור סיפורים רבים; למעשה, יש לעודד זאת. חלק מהסיפורים הללו לעולם לא ישמשו, אך חשוב לראות את הדרך שהם קבעו. אוסף סיפורים זה ישטוף דרישות נוספות וישפיע על בדיקות.
הסיפורים צריכים לעורר וליידע דיונים על אופן בדיקת התוכנה ואילו כללי עסקים צריכים להיות מוגדרים במפורש. לדוגמה:
Storyboard That המספק כלי רב עוצמה ליצירת סיפורי משתמשים מעולים, אך הוא לא נועד לעמוד לבד כמסגרת לניהול פרויקטים. הנה כמה מהספרים האהובים עלינו בנושא.
בדקו את שאר מאמרי העסקים שלנו ומשאבים!
