ציפיות סמכויות בסביבה אג'ילית | מור כורם

ציפיות, של מי?

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

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

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


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

 

אג'ייל מול פיתוח מסורתי

מה כל כך מיוחד במבנה הארגוני של ארגון המיישם גישה אג'ילית?

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

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

 

שינוי בדרישות התפקיד

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

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

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

 

שינוי התנהגותי

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

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

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

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

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

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

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

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

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

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

 

יצירת אחריות כלפי איכות

כיצד יוצרים אחריות כלפי איכות? הרי איכות זה התפקיד שלנו, לא?

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

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

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

 

קישור בין דרישות וחווית משתמש

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

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

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

 

יוזמה

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

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

 

מעורבות מוקדמת

הרבה נאמר בנושא מעורבות מוקדמת, אפילו ניתן לזה שם - "Shift Left". מעורבות מוקדמת אומרת תכנון בדיקות טרם תחילת כתיבת הקוד, אבל עוד הרבה מעבר. אנחנו מדברים על להתריע ולהציף סיכונים פנים-צוותיים שאינם קשורים ישירות לתכולת המערכת. למשל, עיכוב במועד תחילת פיתוח של משימה ספציפית יכול להוביל לכך שלא ישאר זמן מספיק לבדיקות. זהו סיכון הקשור ללו"ז של הצוות. זיהוי מוקדם מצידנו יכול למנוע את אי השלמת המשימה. אם נתריע מראש שנותרו 8 ימים לשחרור התכולה, נדרשים 5 ימי פיתוח ו 3 ימים בדיקות, לשם הדוגמה, אפשר יהיה לקבל החלטות מושכלות בזמן. ההחלטה יכולה להיות מגוון של צעדים ופתרונות, העיקר הוא שאנחנו דואגים להביא את הצוות לדיון בנושא במועד מוקדם שבו ניתן עדיין לשלוט על הבחירות ולא רק לפעול מתוך חוסר ברירה.

 

שיתוף, שיתוף, שיתוף

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

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

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

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

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

 

שאלות לטובת הכלל

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

 

בולטים:

 

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