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

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

הנה מה שנכסה:

תחילת הדרך של אג'ייל

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

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

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

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

מהו אג'ייל?

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

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

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

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

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

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

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

נכנס לסיפור המשתמש.

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

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

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

מבנה של סיפור משתמש

כ [סוג המשתמש], כאשר אני [מבצע פעולה], [פלט צפוי]

בסיסי ביותר, זהו.

אתה משים דגש על המשתמש הסופי וה"ערך" שתספק.

בואו נעסוק בקלטים:

  • סוג המשתמש: אין חליפות אחידות ל"משתמש". יש "משתמשי מנהל", יש "משתמשים מחוברים", יש "משתמשים עם הרשאה X" או "משתמשים בתפקיד Y". זה מתייחס למי בדיוק מבצע את הפעולה

  • ביצוע פעולה: מה המשתמש עושה? לוחץ על כפתור "כניסה"? מוחק רשומה? מגיש טופס?

  • תוצאה צפויה: לאחר שהמשתמש ביצע את הפעולה, מה צריך לקרות? אם הוא לחץ על "כניסה" עם כתובת האימייל והסיסמה הנכונים, לאן צריך להוביל אותו? אם הוא לחץ על "כניסה" עם כתובת האימייל והסיסמה שגויים, מה צריך לקרות?

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

בואו נסתכל על דוגמאות לסיפורי משתמש עבור עמוד הכניסה.

אין דבר טוב יותר מדוגמאות.

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

מהן הה Permutations השונות שיכולות להתרחש בעמוד זה מנקודת המבט של המשתמש?

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

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

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

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

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

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

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

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

האם אתה יכול לראות כיצד כל אלה ממוקדים במשתמש?

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

איך ליצור סיפורי משתמש טובים

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

מודל INVEST:

  • Independent: יכול להתפתח בנפרד.

  • Negotiable: פתוח לדיון ושינוי.

  • Valuable: מספק ערך למשתמש.

  • Estimable: ניתן להערכה לפי מאמץ.

  • Small: מתאים בתוך ספרינט.

  • Testable: יש קריטריונים ברורים לקבלה.

בואו ניישם את מודל INVEST על אחד מדוגמאות סיפורי המשתמש מהנ"ל:

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

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

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

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

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

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

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

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

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

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

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

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

נראה שיצרנו סיפור משתמש טוב!

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

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

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

המיקוד בהיבטים טכניים

כפי שהדוגמאות שלי מראות למעלה, סיפור המשתמש הוא לא טכני.

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

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

התרכז במה שהמשתמש הולך לעשות, ומה שהמשתמש הולך לראות.

בואו נסתכל על דוגמה של סיפור ממוקד טכנולוגיה:

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

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

בואו נתקן את זה:

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

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

שיתוף פעולה עם צדדים

Agile הוא שיתוף פעולתי.

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

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

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

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

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

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

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

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

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

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

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

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

סיפורי משתמש מעורפלים

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

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

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

בואו נבדוק מחדש את סיפור המשתמש הבא:

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

יש שם מעורפלות.

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

אז כפי שאתה יכול לראות, פרטים חשובים.

סיפור המשתמש הזה הוא דוגמה פשוטה למדי ואני מצאתי הרבה שאלות לגביו.

בואו נתקן את הבעיה:

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

זה הסיר את השאלות סביב הפעולה של המשתמש אך לא פתר את הבעיה לגבי הודעת השגיאה הצפויה.

הכנס את קריטריוני הקבלה.

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

דברים כמו:

  • הודעת שגיאה: "כתובת דוא"ל או סיסמה לא חוקיים"

  • תיבת טקסט של כתובת דוא"ל וסיסמה מתאפסות לריק בעת רענון

  • משתמש אינו יכול לגשת לדפים שבהם דרושה התחברות

  • משתמש מוצג עם הצעה ל"השכחת סיסמה".

קריטריוני הקבלה מציינים מה צפוי מהיישום.

איך להתחיל עם סיפורי משתמשים

תתחיל קטן.

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

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

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

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

מסקנה

Agile היא שיתופית. Scrum היא שיתופית. יצירת סיפורי משתמש היא שיתופית. תזכור זאת.

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

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

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

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