יישום ופרקטיקות בהטמעת אג'ייל בצוותי בדיקות

שמחה מירל, ר"צ במטריקס בדיקות ואוטומציה במנהל מקרקעי ישראל

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

מבוא

צוותי פיתוח בארגונים רבים בארץ ובעולם החלו לשלב שיטות פיתוח מתקדמות וזריזות התומכות באספקת תוצרי פיתוח רזות ומקצרות TTM, משלב הגדרת הדרישות ועד שלב הטמעת הדרישה בסביבת הייצור של הלקוחות. השינוי התפיסתי והמעבר לעבודה תוך שימוש במתודות זריזות כדוגמת: אג'ייל, סקראם, קנבן וכו' בעיקרו הינו שינוי תפיסה ארגונית המתחיל מרמת ההנהלה, דרך מנהלי הפרויקטים ועד אחרון העובדים במערכות המידע. שינוי זה מחייב את מובילי צוותי הבדיקות ליישר קו להכיר היטב את הנושא, להטמיע את השינוי בצורה הדרגתית ולבצע בקרות מתוכננות תוך בניית צוותים נכונה, שימוש במתודות, כלים, ניהול ובקרת התהליך עד למימוש והטמעה מוצלחת.
ניהול פרויקטים במתודולוגיית המסורתיות כדוגמת Waterfall שמה דגש על תהליכי אפיון דרישות כשלב מקדים לשלב הפיתוח. הבעיה המרכזית היא חוסר גמישות והעדר יכולת לבצע סטיות בתכנון ללא עלויות גבוהות. זמני פיתוח ארוכים המנותקים משינויים בדרישות משתמשי הקצה והתאמות נדרשות בחבילות הפיתוח כמענה לדרישות הרגולציה, שינויים טכנולוגים, עסקים וכו'.
מתודולוגיה זו, הפכה ללא משתלמת כלכלית ועסקית לארגונים והחל משנות ה-90 פינתה את מקומה למתודולוגיות זריזות המאופיינות בשלבי פיתוח קצרים ומהירים.
אימוץ מתודולוגיית האג'ייל מתאפיינת בחלוקת מוצר גדול ומורכב לקבוצות של חבילות עבודה המבוססות על פיצ'רים. שיתוף פעולה הדוק בין צוות הפיתוח ללקוחות, עבודה בספרינטים האורך בד"כ כשבועיים. צוות עבודה המורכב מ- Product Owner (מוביל עסקי ומנהל מטעם הלקוחות) שתפקידו לאפיין את ה-user story (בנק המשימות), מפתחים ובודק.
יתרונות השיטה היא יצירת ערך אמיתי ללקוח באמצעות קיצור משך זמן הפיתוח ומתן מענה לצרכים העסקיים המשתנים של הלקוח. ארגונים רבים בארץ ובעולם מיישמים את המתודות המהירות והזריזות כדוגמת חברות בענפי הפיננסים והבנקאות ומשרדי הממשלה השונים. למרות זאת50% , מהארגונים שהטמיעו אג'ייל לא מצליחים להתמיד לאורך זמן בתחזוק ההטמעה ובשימורה.
סקר חדש מעלה כי 94% מהנסקרים טענו שהם משתמשים באג'ייל אך 80% מהם לא הצליחו להטמיעו באופן מלא או שנמצאים בשלבים כאלה ואחרים של ההטמעה.

תנאים הכרחיים להטמעה בארגון

1. מחויבות הנהלה ותמיכתו ביישום השינוי – מחייב שינוי במבנה בארגוני הקיים והוספת כוח אדם ייעודי לניהול והטמעת (גידול של 5% – 20% בכ"א).
2. אתגר – חשוב להבין שיישום אג'ייל בארגון הינו מהלך כלל ארגוני המחייב ביצוע שינויים במבנה הארגוני ובניית צוותים העובדים כיחידה עצמאית בארגון. חשוב ללמוד את השלכות השינוי והשפעה על המנהלים והעובדים כאחד ולנהל את תהליך השינוי בצורה הדרגתית תוך ליווי מקצועי מתאים.
3. ישום מותאם ללקוח – אסטרטגיית השינוי מחייבת הבנה מעמיקה של אופי החברה, מבנה ארגוני, צרכים ואילוצים הקיימים כדי לבצע התאמה מדויקת לצרכי החברה tailor made.
4. מדידה ובקרה – המטרה העיקרית של הארגון במעבר לאג'ייל הינו קיצור משך TTM ולכן בקרה יעילה מחייבת הגדרה מדויקת של שלבי פרויקט המדדים והעקיבים המאפשרים מדידת משך הזמן מקבלת הדרישות ועד ההטמעה ביצור.
5. שיפור מתמיד (continuous improvement) – שיפור מתמיד חייב להיות חלק מהטמעת השינוי בארגון. לא מדובר במהלך חד פעמי אלא בתרבות ארגונית מתפתחת המחייבת הטמעת השינוי ושמירתה לאורך זמן עד להפיכתה ל-DNA הארגוני.

טיפים לפני שיוצאים לדרך…

  • שלב יועץ מנוסה שיוביל וינהל את תהליך ההטמעה בארגון
  • למד והעמק ידע באמצעות איסוף חומרים מספרים ובלוגים מקצועים
  • החל בהטמעת התהליך בחבילות פיתוח קטנות תוך בקרה ושיפור מתמיד של התהליך

יצאנו לדרך … מתחילים – backlog, sprint, שחקנים ושאר ירקות

1. הגדרת מדדי הצלחה (CSF)

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

2. בניית צוותי עבודה

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

3. שילוב בודקים בשלבי פיתוח

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

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

 

4. אימוץ גישת "MAX – MIN"

משך ספרינט מוגדר בד"כ בין שבועיים לחודש ומחייב את מנהל הבדיקות לתכנן תכנית בדיקות ממוקדת ומדויקת ככל שניתן. התרחישים צריכים להיבנות במבנה של user story ולשקף את התהליכים העסקיים והתפעולים המבוצעים במהלך יום עבודה בארגון. כמות התרחישים ההכרחית תוגדר כ"הכמות המינימלית הנדרשת להשגת האיכות המקסימלית". מוצע לאמץ את שיטת הפארטו (20% עיקר / 80% תפל). דוגמה: 20% מהלקוחות מייצרים 80% ממחזור המכירות. יישום בבדיקות 20% מתרחישי הבדיקות יכסו 80% מהתהליכים העסקיים ולכן נדרש להתמקד בתרחישי הבדיקות הנכונים ולתעדף בצורה נכונה את ההרצות המתוכננות.


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

5. ניהול סיכונים

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

6. בקרה והפקת לקחים

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

מוצע לאמץ את שיטת הפארטו (20% עיקר / 80% טפל), אימוץ גישה זו, תסייע במיקוד בתרחישים העיקריים ותסייע להשגת איכות מקסימלית בזמן

פיתוח אוטמציה באג'יל

1. Continues integration

תרשים זה מסביר את השוני בין Continues אחד למשנהו
Continues Deployment – העברה לייצור בצורה אוטומטית מסיום הפיתוח ועד הייצור עצמו כולל כל תהליכי הבדיקות בדרך
• Continues delivery – משאיר את הבדיקה הידנית בשלב ה-UAT לפני המסירה לייצור
• Continues Integration – תהליך אוטומטי עד שלב סביבת ה-staging

2. מה זה Continues Testing ולמה זה קשור ל-Agile testing

המשמעות של Continues testing זה העברת תהליך הבדיקות מימין לשמאל, והמשכיות תהליך הבדיקות לאורך כל תהליך הפיתוח.
מדובר בשילוב תהליך הבדיקות בתהליך הפיתוח והגדרה של תהליך הבדיקות כחלק מתהליך הפיתוח, איך עושים את זה?

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

3. מבוסס מתודה BDD (נהוגה במטריקס)

השיטה משנה במקצת את תפיסת הבדיקות שלה הורגלנו, BDD = Behavior Driven Development, מדברת על בדיקת ההתנהגות של המערכת ולא פונקציונאליות ספציפית. מבוססת על דרישות המערכת ברמה העסקית. אימוץ השיטה מחייב הבנת הדרישות העסקיות ובדיקת התהליכים היא ברמה ההתנהגותית של המערכת.
שיטת ה-BDD היא תולדת השיטה TDD (Test Driven Development). השוני בין השיטות הוא ששיטת ה-TDD מתמקדת בפונקציונליות האטומית של המערכת, בשפת בדיקות יחידה. ה-TDD נכתבה למפתחים, היא מכוונת בדיקות יחידה (Unit Test) ומתעסקת בבדיקת האטומים של המערכת. ושיטת BDD מסתכלת רמה אחת למעלה ובודקת את הפונקציונליות העסקית (שוב ברמת הדרישות) של המערכת. חשוב לזכור שההתחלה היא כמעט אותו קונספט אך החשיבה והביצוע אחרים.

הייחודיות של ה-BDD
שיתוף הפעולה בין תחומי האנליטיקה עסקית/מפתחים/בודקים בכתיבת התסריטים הכרחית, כיוון שאיחוד הכוחות המעורבים ימנע סיכונים. שיתוף פעולה ברף נמוך, יגרום לבדיקת להיות בסיכון גבוה יותר.תסריטי הבדיקות נכתבים בד"כ בשיטת ה-GIVEN – WHEN – THEN בשפה שנקראת Gherkin, שפה זו יכולה להכיל את רוב תסריטי הבדיקות. כלי שנקרא Cucumber מבין את שפת ה-Gherkin, זהו כלי אוטומטי ולכן אחד מיתרונות שיטת ה-BDD זה כתיבת בדיקות אוטומטיות כבר בשלב החשיבה על המוצר.
מכיוון שהכתיבה בשיטת ה-BDD מתבצעת בזמן הפיתוח, נחשב השימוש בשיטה כחלק מתהליך
ה- .Continues Testing/Integration/Delivery/Deployment

TDD -Test Driven Development
על השוני בין השיטות דיברנו, בואו נבין את הדומה בין TDD ל-BDD.
כמו BDD גם בשיטת TDD איסוף המידע וכתיבת הבדיקות (ב-99% אוטומטיות) נעשה בשלב ההכנות, עוד לפני שנכתב קוד כלשהו, כלומר הרצת הבדיקות הראשונות אמורה ליפול מפני שהקוד מוכן.

כלי יישום ומחוונים

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

סיכום ומבט לעתיד

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


מעקב ובקרה חייב להתבצע ברמה היומית, חשוב לבצע פגישות עבודה יומיות, מעקב יומי אחרי התוצרים, זיהוי חריגות ומתן פתרונות לבעיות בזמן אמת ועוד.
נושאים נוספים שלא נדונו במסגרת מאמר זה וראוי להרחיבם במסגרת מאמרים עתידיים: מעבר ל- DevOps אתגרים בניהול תצורה, עבודה בענן ,big data ,ניהול ידע ועוד …

 

תודה מיוחדת לשרית כהן, CMO במטריקס DevOps, וליאור כץ, CTO מטריקס בדיקות ואוטומציה, שסייעו בכתיבת המאמר.

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

רוצים לשמוע עוד? דברו איתנו

מלאו פרטים ונחזור אליכם בהקדם