מעקרונות קבוצת אג'ייל: לספק ללקוח בדיוק את מה שהוא צריך

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

מעקרונות קבוצת אג'ייל: פידבק מתמשך

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

מעקרונות קבוצת אג'ייל: אין תפקיד ספציפי של QA

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

מדוע הבדיקות והתמיכה צריכים להיות מאוחדים מבחינה ארגונית

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

1. בד"כ אנשי הבדיקות הם אלה שמכירים את המערכת כמערכת בצורה הטובה ביותר. ברגע שאנשי התמיכה נמצאים בתוך מחלקת הבדיקות, אפילו כצוות נפרד, יש להם אנשים זמינים בקלות (פיזית ומכאן גם חברתית) שהם בעלי הידע. יש את מי לשאול, יש עם מי להתייעץ.
2. אנשי הבדיקות תמיד מעודכנים בכל פיצ'ר חדש, בחסרונות שלו, ב-workarounds, בזמן העלייה שלו לפרודקשין וכד'. ברגע שהמנהל, שהוא גם המנהל של התמיכה, מארגן העברת ידע מסודרת בין הבודקים לתומכים, תהיה לתמיכה האינפורמציה האחרונה והמקיפה לגבי המערכת.
3. מצד שני, כשיש בעיה חדשה במערכת, התומכים הם הראשונים לדעת. תומך טוב יכול להבין שיש בעיה לפעמים לפני האנשים הטכניים, ולפעמים במקומם. למשל: אם שרת נפל, במערכת הבנוייה היטב אנשי הסיסטם יקבלו SMS ובתקוה, יטפלו בעניין מייד. אבל נניח שאיזשהו פיצ'ר הפסיק לעבוד (למשל בגלל עדכון תוכנה שאינו קשור למוצר, כמו Service pack חדש למע' ההפעלה). איש תמיכה טוב, אפילו ש"אצלו זה עובד", כבר יבין מהמייל השני שיש בעיה ויתחיל לעבוד עם הלקוחות בניתוח הבעיה.
4. התומכים הם צינור טוב למידע על ומהלקוח: מה מפריע לו, מה הוא לא מבין במערכת, לפעמים אילו רעיונות יש לו. למשל אם מקבלים מיילים חוזרים שמשתמש לא מבין איך עושים פעולה X, אז אפילו שלצוות הטכני זה נראה ברור מאיליו, כנראה שיש בעיה. פתרונה ירצה גם את הלקוח וגם את התמיכה בכך שמספר הפניות אליו יקטנו.

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