כמו בכל חברה אחרת, גם ב-Easy LMS יש לנו תהליכים רבים. לדוגמה, איך אנחנו מטפלים בכרטיסי תמיכה או מפתחים תכונות חדשות. אנחנו משתמשים ב-Improvement Kata כדי לייעל את התהליכים שלנו. אחד הצעדים הראשונים הוא להגדיר את המצב הקיים. עם זאת, מתברר שלכל אחד יש את הדעה שלו לגבי המצב הקיים. EventStorming היא טכניקה שאנו משתמשים בה כדי להגדיר את התהליכים שלנו באופן חד-משמעי.
דמיינו שאתם עובדים חדשים שהצטרפו לחברה. אתם מוצבים לצד עובד מנוסה יותר ועוברים על כל תהליכי העבודה, שרובם אינם מתועדים. אתם יוצרים מודל מנטלי של התהליך על ידי שאלת שאלות וקריאת תיעוד. ככל שאתם צוברים ניסיון, כך אתם צריכים לשאול פחות שאלות ולקרוא פחות תיעוד. את רוב הדברים אתם תעשו באופן (חצי) אוטומטי.
תיעוד לא מעודכן של תהליך יוביל לשונות רבה יותר במודלים המנטליים של העובדים לגבי אותו תהליך.
ואז, אם תשווה את האופן שבו אתה מטפל בתהליך עם חבר צוות אחר, תבחין שאתה עושה כמה דברים בצורה שונה למדי. זה קורה בגלל שהמודלים המנטליים שלכם שונים.
כאשר אתם מייעלים תהליך באמצעות שיטת Improvement Kata, תיאור המצב הקיים עלול להיות מאתגר כאשר המודלים המנטליים שונים זה מזה באופן משמעותי. לו רק הייתה לנו דרך להפוך את המודלים המנטליים הללו לתיעוד.
איך הגענו ל-EventStorming
בתחילת 2020 השתתפתי בכנס Domain-Driven Design Europ כדי ללמוד יותר על דרכים טובות יותר למודל את התוכנה שלנו. סדנה אחת שרציתי להשתתף בה עסקה ב-EventStorming. קראתי על זה בעבר וחשבתי שזה יכול לעזור לנו להוציא את הידע הספציפי לתחום מהמוחות של המומחים שלנו בצורה שקל לשתף עם המפתחים. כלומר, נוכל לבנות תוכנה טובה יותר. התברר ש-EventStorming מאוד שימושי למודלים של תוכנה, אבל גם למודלים של תהליכים עסקיים!
למרבה הצער, המגפה פגעה. סגרנו את המשרד והתחלנו לעבוד מרחוק. EventStorming מתבסס על קבוצת מומחים שיושבים בחדר ועובדים על משטח משותף גדול. לא היה אפשר לארגן את זה יותר. למרבה המזל, אלברטו ברנדוליני, מייסד EventStorming, הבין זאת גם הוא וארגן סדנה אחרת כדי לפתור את הבעיה: Remote EventStorming. הצטרפתי אליה ולאחר מכן חיכיתי להזדמנות להתנסות ב-EventStorming.
מודלים של תהליך הפיתוח שלנו באמצעות EventStorming
בחודשים האחרונים שינינו רבות את תהליך הפיתוח שלנו. לעתים התהליך נכשל, והיה ברור שאף אחד כבר לא היה בעל תמונה מלאה של התהליך. זה היה תהליך מושלם לנסות עליו את EventStorming!
אני אומר לצוות שאני רוצה לנסות את EventStorming. אני בטוח שנוכל לקבל תמונה טובה של תהליך הפיתוח הנוכחי באמצעות שיטה זו. אני מזמין כמה מפתחים מעוניינים משני הצוותים ויוצר לוח משותף מרחוק באמצעות Miro. אנו פועלים לפי השלבים הבאים של EventStorming:
חקירה כאוטית: צור פתקיות לכל האירועים שאתה יכול לחשוב עליהם שקורים בתהליך.
אכוף את ציר הזמן: סדר את האירועים מהתחלת התהליך ועד סופו.
העשרת האירועים: הוסף מידע מטא לכל אירוע. הפקודה (הפעולה) שמפעילה את האירוע, הנתונים הדרושים, המערכת הפועלת והמדיניות הקובעת מה לעשות הלאה.
חקירה כאוטית
בהתחלה זה מרגיש קצת מוזר. אבל ברגע שהפתקאות הדביקות הראשונות מופיעות, הקצב באמת מתגבר וכולם נכנסים לעניין.
אנו מתחילים בכך שאנו נותנים לכל המשתתפים חלק מהלוח הלבן וצבע (אך לא כתום, נפרט על כך בהמשך). יש להם 25 דקות ליצור פתקיות דביקות לכל האירועים שהם יכולים לחשוב עליהם שיקרו במהלך התהליך. אירוע הוא משהו שקרה בעבר ואינו ניתן לשינוי. לכן יש לכתוב אותם בזמן עבר. לדוגמה: "מאגר קוד נוצר" או "קוד הוטמע בסביבת הייצור".
אני מעודד אותם "לרמות" ולהסתכל על האירועים שכתבו משתתפים אחרים, כי זה יכול לפתוח חלק חדש בתהליך שלא חשבתם עליו קודם. זה בסדר גמור להוסיף אירועים שיש גם למשתתפים אחרים.

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

העשרת האירועים במטא-נתונים
הסבר של שלב זה יובן טוב יותר באמצעות תמונה:

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

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