הגדרת סיפורי משתמשים ופיתוח זריז
בסיס עיקרי של תהליכי פיתוח מודרניים הוא פיתוח זריז . מתודולוגיית פיתוח זו מדגישה שימוש בסיפורי משתמש קטנים וגדולים ביסים כדי להגדיר מה המערכת עושה מנקודת מבט של משתמש, ולא טכנית. למשתמש אכפת אם מוצר הוא מהיר, קל לשימוש ופותר את הבעיה שלו. לא אכפת להם אם הוא עוקב אחר ארכיטקטורה בעלת שלוש שכבות, יש Mongo DB, או אם היא משתמשת ב- Rails או Asp.net.
סיפורי משתמש:
- קלים להבנה, וכל אחד יכול להשתתף
- עבוד באופן איטרטיבי; הם יכולים וצריכים לשנות או לתקן לעתים קרובות
- יישר מפתחים, משתמשים ומומחים עסקיים סביב יעדים וציפיות משותפים
- קל יותר לקרוא מאשר מסמכי דרישה של 400 עמודים
Storyboard That המספק פלטפורמה אידיאלית ליצירת סיפורי משתמשים זריזים ולעורר שיחה בפורמט שהוא הרבה פחות ממיס מאשר קיר טקסט.
אפוס
בהקשר של סיפורי משתמשים, "אפוס" הוא פשוט סיפור רחב מאוד שלימים יתפרק להרבה סיפורי משתמשים ספציפיים. החל מאפוס מיישר את כולם עם ראייה יחידה ברמה גבוהה. הסיפור האפי מעגן פרויקט מלמעלה למטה, ואם זה לא הגיוני לבנות אפוס, עבודה תומכת תהיה גם בזבוז מאמץ.
בסיפור זה ברור מאוד מה החזון לטווח הרחוק ואיך ההצלחה צריכה להראות. סיפור אפי טוב צריך לכלול:
- הגדרה או הקשר
- שחקנים או משתמשים
- מטרות ויעדים
- פעילויות ואירועים
הגדרת משתמשים
במיוחד בעת תכנון תוכנה, חשוב שתהיה חזון טוב כיצד יראו המשתמשים. לא כל משתמש יתאים לחזון זה במדויק וייתכנו מספר קטגוריות של משתמשים, אך חזיונות נפרדים אלו זקוקים לניסוח. מחשבה על משתמשים הראשונים שמירה על הנדסת יתר וסיבוך יתר, מונעת ממוצר חדש שיהיה לו משהו לכל אחד ויהיה מועיל לאיש.
יצירת סיפור
לאחר הקמת האפוס והגדרת המשתמשים, ניתן לבנות סיפורים קטנים יותר וספציפיים יותר על חוויות משתמש מסוימות. הסיפורים שלמטה מפרקים את המתואר לעיל לשני נרטיבים: לחפש הזמנה ולהזמין מחדש מוצר.
נרטיבים אלה אינם מכילים מידע טכני; למשתמשים לא אכפת כיצד יושגו התוצאות, כל עוד הוא מבצע את המשימות הרצויות. באופן דומה, ה- UX מתואר באופן כללי, כדי להימנע מחניקה של חידוש או אילוץ נתיב. באופן כללי, סיפורים צריכים להיות:
- קטן - פחות מ -10 יום עבודה
- ערך - לאחר השלמתם הם צריכים לספק משהו שמיש
- ניתן להעריך - תוכל ליצור אומדן של כדורי מרץ למאמץ רב
מחפש צו
שיחה ותכנון לבדיקה
סיפורים אלה צריכים להזמין שיחה ושאלות, כגון:
- האם אלה הסיפורים הנכונים שתואמים את האפוס שלנו?
- אילו סיפורים אחרים צריך ליצור?
- האם הסיפורים הללו תואמים את מה שאנחנו יודעים על המשתמשים שלנו?
סביר בהחלט ליצור סיפורים רבים; למעשה, יש לעודד זאת. חלק מהסיפורים הללו לעולם לא ישמשו, אך חשוב לראות את הדרך שהם קבעו. אוסף סיפורים זה ישטוף דרישות נוספות וישפיע על בדיקות.
הסיפורים צריכים לעורר וליידע דיונים על אופן בדיקת התוכנה ואילו כללי עסקים צריכים להיות מוגדרים במפורש. לדוגמה:
- כמה מהר צריך לבדוק?
- האם יש מגבלת זמן בהזמנות חוזרות?
- מה על המערכת לעשות אם זה ההזמנה השנייה? חמישי?
- אילו בדיקות ושאלות מעקב היו לך?
לקריאה נוספת
Storyboard That המספק כלי רב עוצמה ליצירת סיפורי משתמשים מעולים, אך הוא לא נועד לעמוד לבד כמסגרת לניהול פרויקטים. הנה כמה מהספרים האהובים עלינו בנושא.
תמחור
/חוֹדֶשׁ
מחויב מדי שנה
© 2021 - Clever Prototypes, LLC - כל הזכויות שמורות.
נוצרו למעלה מ- 15 מיליון לוחות סיפור
