אסלק הלסוי – מיפוי דוגמאות

מתוך קיוקפסט 2018-לונדון

תקציר

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

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

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

אחת הטכניקות הפופולריות בשנים האחרונות ( שפותחה ע"י מת' ויין שותפו לCUCUMBER) כדי להגיע להבנה משותפת של מרחב הבעיה: מיפוי דוגמאות. אסלק מדגים את השימוש בשיטה ביישומה על בסיס סיפור-משתמש במערכת ניהול מקומות שמורים בקרונות רכבת.

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

סיכום ההרצאה

חלק ראשון – תיאור הבעיה

רואים שתרחיש זה נכתב ע"י מישהו שנזכר ברגע האחרון בכל מיני דברים

על ידי מישהו שהוא בודק ידני

המון המון פרטים טכניים: טבלאות גדולות, אלמנטי תצוגה, מידע לא ברור ID/XML/JSON/CSS

מידע לא רציף ומבולבל, לא קוהרנטי

בודק התוכנה מגיב:

הבודק מבין שיש פה בעיית תקשורת כי ה-PM לא יבין את התרחיש אבל זה הדרך היחידה שלו לגרום לבדיקה לעבור.

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

הPM אומר: לא מכין מה אומר הגרקין הזה.

לסיכום:

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

חלק שני – ההבנה המשותפת והדרך להגיע אליה

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

בסוף, המטרה היא להגיע להבנה משותפת:

הבעיה העיקרית היא שיש הרבה מעברי מידע בין השותפים:

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

הפתרון הוא:

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

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

אך שוב ניתקל בבעיה:

בסופו של יום מקיימים שיחה של שלושת האמיגוס, אבל לא יודעים כ"כ איך להתחיל בשיחה

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

לשם כך קיימת הטכניקה של מיפוי דוגמאות או יש המכנים זאת discovery workshop

חלק שלישי- סדנת מיפוי דוגמאות

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

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

להלן תוצר הסדנה:

סיכום

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

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