מכירים את זה שאתם מרגישים שמשהו לא עובד בתהליך? לדוגמא כאשר יש פערים שחוזרים על עצמם, או כשאנחנו לא מצליחים להתקדם ולהגיע למקום שרצינו, או כשאנחנו מרגישים שהתהליך עצמו אינו יעיל, אבל כך הוא מתנהל כבר שנים, ומי אנחנו שנשנה אותו דווקא עכשיו.
למעשה מדובר במצב שכיח במקומות עבודה רבים, אנחנו מיישמים שיטות עבודה סדורות, מבוססות אך גם שמרניות. אותן שיטות לא תמיד נותנות לנו מענה מספיק והן אינן בהכרח מותאמות לצרכים ולזמנים המשתנים, כך שלפעמים עלינו לצאת מהמסגרת ולחשוב באופן יצירתי על מנת להגיע לתוצאה הרצויה.
גם אני התמודדתי עם סיטואציה דומה במסגרת העבודה שלי.
אני מנהלת מוצר בחברה גלובאלית. המוצר הוא למעשה 'תבנית אתר', זו תבנית מעוצבת הכוללת סוגי דפים מסוגים שונים (כמו לובאים ודפי מאמר), ניווט עליון, פוטר (Footer) רכיבים, פיצ'רים (Features) ואף תוכן. ניתן לערוך את התוכן וכן להוסיף/להסיר רכיבים באמצעות מערכת ה- CMS (Content Management System), מדובר במערכת 'מאחורי הקלעים' (Back-end) שעליה יושבת התבנית. התבנית הזאת מוטמעת בכ-50 אתרי החברה, והעבודה שלי היא לדאוג לפיתוח המוצר ושיפורו.
תהליך הפיתוח מתחלק לשני שלבים עיקריים:
- שלב הכנת הדרישות לפיתוחים החדשים – זהו החלק שבאחריותי, במסגרתו אני עורכת את פרטי הדרישה: הגדרת מהות הפיתוח במילים שלי – מהו הצורך ובעקבות מה נוצר וכן מהו הפיתוח שישמש כפתרון לאותו צורך. בהמשך אפרט כיצד ניישם את הפיתוח במערכת הCMS, מהי התנהגות המצופה מאותו פיתוח (עשה ואל תעשה) וכן תרחישים אפשריים. בסיום, הדרישות מועברות לצוות המפתחים במחלקת IT.
- שלב הפיתוח - צוות המפתחים עובד על פיתוח הדרישות.
עם סיום השלב השני (וביצוע בדיקות תקינות), אנו עולים לאוויר עם גרסה חדשה של האתר הכוללת את הפיתוחים החדשים.
לכאורה התהליך נשמע פשוט וסדור, אלא שיחד עם חבריי לצוות, התחלנו להבחין בפערים בין מה שציפינו לקבל לבין מה שקיבלנו בפועל:
- חוסר תקשורת בין הצוות העיסקי לצוות הפיתוח בשלב יישום הדרישות לכדי פיתוח – הצוותים לא תקשרו מהשלב שלאחר הגשת הדרישות ועד העלייה לאוויר עם הפיתוחים החדשים. כך קרה ששאלות שעלו תוך כדי הפיתוח בנוגע לדרכי יישום הדרישה או קונפליקטים שהתגלו, לא שותפו ונפתרו פנימית, בהתאם לשיקול דעת המפתחים (שאינו תמיד זהה לשיקול הדעת שמניע את הצד העסקי).
- אי עמידה ביעדי פיתוח – לאור הפערים שהתגלו בפיתוחים החדשים לאחר העלייה לאוויר, היה עלינו ל'תקן' אותם באמצעות פיתוח נוסף (דבר שגרר עוד שעות פיתוח ומאמץ מכל הצדדים). במצב הזה 'נתקענו' עם פיתוחים שאי אפשר לעשות בהם שימוש וכן לא יכולנו להמשיך ולהתקדם לפיתוחים חדשים.
- ריבוי תקלות/באגים (Bugs) – על אף בדיקות התקינות שנעשו לפני העלייה לאוויר, לאחר העלייה לאוויר חווינו תקלות רבות, באופן חריג.
איפה טעינו? האם הדרישות לא היו ברורות? האם צוות הפיתוח אינו מספיק מנוסה? האם השקענו מספיק משאבים? ובעיקר - איך משפרים את התהליך???
חקרנו ומצאנו. למדנו שרבים וטובים כבר נתקלו בבעיה זו לפנינו, ואפילו בעולם התוכנה, וגיבשו תפיסה חדשה לפיתוח תוכנה: AGILE.
"פיתוח תוכנה זריז (Agile Software Development) היא גישה בהנדסת תוכנה המניחה שפיתוח תוכנה הוא ביסודו בעיה אמפירית, ולא ניתן לפתור אותה בשיטות המתבססות על חיזוי או תכנון. באנגלית, המונח Agile פירושו "זריז, קל רגליים, נע במהירות ובחן", ותרגומו לעברית הוא "זמיש" (הלחם של זריז וגמיש). הגישה קובעת שפיתוח תוכנה הוא פיתוח מוצר חדש ומתייחסת אליו כמשחק של שיתוף פעולה מוכוון־מטרה. הגישה הזריזה לפיתוח תוכנה מניחה שלא ניתן להגדיר במלואה תוכנה מסוימת קודם לפיתוחה בפועל, ומתמקדת במקום זאת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי הפיתוח".(ויקיפדיה)
בפיתוח לפי המודל האג’ילי, קיימים יחסי גומלין לאורך כל שלב בין צוות המפתחים ללקוח. הלקוח מספק פידבקים ויכול לשנות את הדרישות המקוריות של התוכנה (לדוגמא בהתאם לדרישות השוק או לפתרונות חלופיים). קבלת הפידבק הוא חלק הכרחי, מאחר והוא מאפשר פיתוח המותאם באופן אופטימלי ללקוח, בניגוד לתהליך המסורתי של אפיון מסודר שעל בסיסו נבנה הפתרון – גם אם דרישות השוק או הלקוח השתנו לאורך תקופת הפיתוח.
בהתאם למודל, יישמנו כלים ומתודולוגיות שעזרו לנו להתמודד עם הקשיים שלנו:
- ספרינט (Sprint) - סבב פיתוח מואץ הממוקד ביעדים ברורים ותחום לזמן קצר.
פרשנו את התהליך על פני שישה שבועות, בכל סבב ביצענו את הפעולות הבאות ולאחריהן העלייה לאוויר. אלו השלבים העיקרים:
- עריכת הדרישות
- תיעדוף הדרישות
- נעילת הספרינט
- פיתוח
- UAT (User acceptance testing) & QA – בדיקות תקינות
- עלייה לאוויר (+ בדיקות שפיות Sanity)
-
על צוות הפיתוח ועל הצוות העסקי לעבוד ביחד באופן יום יומי לאורך הפרויקט – אנו מקיימים ישיבות מרובות משתתפים לפני הגשת הדרישות. באותן פגישות אנו דנים יחד במהות הדרישות, בהתנהגויות הצפויות והבלתי צפויות, אנו מסכימים על הדרך הטובה ביותר ליישם את אותן דרישות לכדי פיתוח ומגשרים על פערים.
מה קיבלנו? צמצום פערי ידע בין הצוותים, תוצרים (פיתוחים) איכותיים, הבנה מעמיקה יותר של התהליך וכן של העשייה.
-
בדיקות תקינות (UAT & QA) – מדובר בבדיקות שנעשות לפני העלייה לאוויר.
בתחילת הדרך אותן בדיקות נעשו ע"י עובדים שונים (מי שיכל להתפנות לכך).
לאחר שעברנו ליישום הגישה האג'ילית, ייעדנו אדם אחד לתפקיד בודק מטעם הצד העסקי, וכן צוות של מספר אנשי QA שביצע בדיקות תקינות מצד צוות הפיתוח.
מה קיבלנו? צמצום פערי ידע, בדיקות תקינות יסודיות ותוצרים (פיתוחים) איכותיים יותר.
-
בדיקות שפיות (Sanity test) – מדובר בבדיקות שבוצעו על האתרים לאחר העלייה לאוויר, כדי לוודא את תקינות האתרים החיים.
בתחילת הדרך, כל בודק תיעד את הבדיקות שביצע בדף וורד (Word), דבר שהפך את תהליך הבדיקות לאיטי יותר. התקלות שנמצאו תועדו רק לאחר מכן ע"י מי שעבר על הרשומות וכן, מדי פעם היה עליו לחזור לאותו בודק לקבל הבהרות ולחזור שוב לתיעוד התקלות לאחר מכן.
לאחר שעברנו ליישום הגישה האג'ילית, התחלנו להשתמש בתוכנת Jira כדי לתעד את התקלות באופן מיידי (אונליין) ובמשותף- כל הבודקים נחשפו לכל התקלות ויכלו לשתף אחד את השני בממצאים שלהם.
מה קיבלנו? שיתוף ידע, חיסכון במשאבי עבודה, בדיקות שפיות איכותיות ויסודיות יותר.
כמובן שהיום אנחנו כבר מרגישים את השינוי בתפיסה ורואים את התוצאות החיוביות. מרגע שיישמנו את השיטה האג'ילית, אנחנו מחפשים איך אפשר להתייעל עוד יותר ולמקסם את הפוטנציאל של השיטה. אם בעבר תפסנו את המציאות ככזו ש"זה מה יש", היום אנחנו יודעים שלכל בעיה יש פתרון, או לכל הפחות דרך טובה יותר להתמודד עם הבעיה.