המעבר שלנו ל-JIRA: חוויות ולקחים מהשטח

המעבר שלנו ל-JIRA: חוויות ולקחים מהשטח
20 נוב 2019

מאת: עמיר ריקס

מה היא הפלטפורמה הטובה ביותר לניהול פרוייקטי המחקר והפיתוח שלנו? מה היא הגישה העדיפה לנו? Waterfall אוAgile? קיימנו דיונים רבים אודות הסוגיות הללו במשך מספר שבועות לקראת סוף שנת 2018. אנחנו לא טירונים במתודולוגיות הללו ופלטפורמת הקוד הפתוח RedMine שירתה אותנו היטב במהלך מספר שנים. אך משהו חייב היה להשתנות.

מה הציק לנו?

היינו חייבים להקדיש מאמצים רבים בתמיכה ובהתאמה של RedMine. TandemG צמחה באותה העת (וגם כיום) ומשמעות הדבר היא הצורך להתייחס לדרישות שונות. להלן רשימה קצרה של דרישות שעלתה במחשבותינו בעת ששקלנו לבצע שינוי:
גמישות – פלטפורמה שתאפשר לנו לנהל את הפרויקטים שלנו במתודולוגיית Agile (ללא איבוד חלופת ה-Waterfall)
עומס נמוך על מערכות ה-IT וה-DevOps – כלי מחקר ופיתוח יושבים היכן שהוא בתפר שבין DevOps לבין ה-IT. אנו, במחקר ופיתוח, שאפנו לתלות קטנה ככל האפשר בגורמי חוץ.
צ'ופרים ישירות מהקופסה – פלטפורמה שדורשת מאמץ מינימאלי כדי להתחיל לעבוד. ככל שהיא מכילה צ'ופרים רבים יותר ישירות מהקופסה, כך טוב יותר.
הגדרה קלה של קונפיגורציה – להיות מסוגלים להגדיר את תצורת תזרימי המערכת וההתנהגויות בתוכה ללא כל מאמץ.
תמיכה – ליהנות הן מתמיכה מקצועית והן מתמיכה של קהילת המשתמשים שיהיו מסוגלים ונענים להשיב לשאלות.
זירת מסחר – המיקוד שלנו הוא לא בפלטפורמה עצמה אלא בשימוש בה, כך ששאפנו לאפשרות להרחיב את יכולותיה.
ממשק מודרני – ממש הפתעה, אך מפתחי תוכנה אכן מעדיפים כלי אינטרנט מרהיבים.
בדקנו מספר חלופות אך לבסוף החלטנו להתעמק ב-JIRA. היה לנו ניסיון קודם עם JIRA וחשבנו שבמחיר שהיא מוצעת היא תספק את כל הדרישות שלעיל. אי לכך, התקנו אותה אצלנו בהתקנה מקומית והתחלנו בניסוי, שהתברר כמוצלח, כפי שבוודאי שיערתם.

כיצד יישמנו את התהליך?

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

זרימת עבודה?

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

 

 

 

 

 

 

 

תרשים מס' 1 – דיאגרמת זרימת עבודה ג'נרית המוצעת כברירת המחדל של JIRA

מצבים (Status)

ראשית, כל שינוי (transition) חייב להילקח בחשבון, ללא כפילויות. כתוצאה מכך החלטנו להסיר את הסטטוס "נפתח מחדש" ("Reopened") ולהחליפו בסטטוס "בבדיקה" (In Review""). לא מצאנו כל יתרון בסטטוס "נפתח מחדש".
שנית, כל נושא ("Issue") מכיל את הערות המשתמש ואת יומן הפעילות שמאפשר מעקב אחר ההיסטוריה, אם הצורך עולה. אך אנו רצינו את האפשרות לבחון כל נושא, בין אם על ידי חברה לצוות ובין אם על ידי מנהל, לפני שמסמנים אותו כ"פתור" ("Resolved").

מעברים (Transitions)

אתם רוצים להתמקד באופן מיוחד במעברים, ויש להימנע מיתירות. מעברים מאפשרים הצגת פונקציות לפני ואחרי והדבר שימושי ביותר כשרוצים להטמיע אוטומציה של דברים מסוימים במערכת. אפשר לעשות שימוש חוזר במעברים, היכן שהדבר אפשרי (דהיינו, חזרה למצב "פתוח" – "Open"). כל מעבר חייב שתהיה לו תעודת זהות (ID) שכן אחרת האוטומציה תיכשל. (אשאיר לדמיון של כל אחד את השאלה כיצד גילינו זאת…).
בדומה לקידוד, המשתמש רוצה להגדיר שמות בעלי משמעות, הן עבור מעברים והן עבור סטטוסים. השמות הללו מופיעים אחר כך בכל מחזור החיים של JIRA. נוסף לכך, שימוש חוזר בשמות ברירת המחדל של זרימת העבודה הוכיח את עצמו כמצמצם טעויות והוא אף הקל על חיפושים בגוגל.
אחרון אחרון חביב אך לא פחות חשוב, המשתמש מעוניין שהכלים שלו לבדיקת קוד ו/או לבקרת מקור ישתלבו גם הם ב-JIRA. עבורנו, יכולת זו, שמוצעת ישירות מהקופסה, היוותה שיקול מכריע!! אנחנו השתמשנו בתוכנת GitLab לבקרת קוד מקור וב-Gerrit לבדיקת קוד והצלחנו לשלב אותם בקלות ב-JIRA.
כדאי לבחון את האופן שבו זרימת העבודה משתלבת עם הכלים הללו. זה המקום שבו השינויים ב-ID והשימוש החוזר בהם יהפכו לשימושיים.

זרימת העבודה שלנו

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

 

 

 

 

 

 

תרשים מס' 2 – זרימת העבודה שהגדרנו לכמעט כל סוגי הנושאים

 

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

 

 

 

 

 

 

 

 

תרשים מס' 3 – זרימת העבודה שלנו עבור Epics

מה הוא הצעד הבא?

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

Share

Sharon

OPEN POSITIONS