הכתוב מטה הוא מעיין סיכום של הפרק השלישי ("שינויים אירגוניים) בספר Agile Testing*
הרבה מהצלחת המעבר לאג'ייל תלוי בתרבות האירגונית. גורם מעכב הוא למשל באם חלק מהאנשים הם בעלי ניסיון מר בעבודה באג'ייל. אם מתעלמים מהתרבות האירגונית המעבר עלול להיכשל.
יש לשים לב להלך הרוח של אנשים שעלולים לחשוש למשל מאיבוד עבודה. והחשש הוא רגש עצמתי. חשש אחר הוא החשש לאיבוד הכח למשל של הבודקים כחלק מקבוצת בדיקות:
- חשש שהם יאבדו את הזהות שלהם כבודקים.
- חשש שהדיווח למנהל שהוא מפתח (ואני שואל: למה חייב שיהיה מפתח?) יגרום להם להיות בעדיפות נמוכה מאשר לשאר המפתחים.
- חשש שאין להם הכישורים הנדרשים מבודקי אג'ייל.
- שבקבוצת האג'ייל הבנויה ממפתחים לא יהיה מי שייתן להם תמיכה.
- חשש שהם ומנהליהם ילכו לאיבוד בשיטת העבודה החדשה.
בכל ארגון יש להתייחס לפחדים אלה ואם צריך יש להביא מדריך מנוסה שיעזור בתהליך המעבר. יש להסביר שהפחד מהשינוי הוא טבעי.
בנוסף, לפי מתודולוגיית האג'ייל, אין אחראי איכות אחד, אלא כולם אחראי איכות, והבודק הוא גם אחראי איכות וגם בודק, כמו שהמפתח אחראי איכות ומפתח. קשה לעבור מתפקיד האחראי הבלעדי של הבדיקות לאחד מהאחראים.
למעשה האחריות של הבודק גדלה: בד"כ אין לו מנהל שהוא בודק תוכנה, ולכן התפקיד שלו גודל. יש יתרונות אבל גם חסרונות. על הבודק להיות מסוגל לשאול שאלות, להסביר דברים הקשורים לבדיקות לכאלה שאינם בודקים ולפעמים להגן על עמדותיו ועוד.
אם הארגון אוהב להשתפר באופן כלי הכניסה לאג'ייל תהיה קלה יותר.
בכדי להקל על הבודק כדאי שייכנס לצוות האג'ייל מתחילת הפרויקט ואם יש צורך להדריכו ע"י מדריך בדיקות אג'ייל מנוסה.
אחד השינויים הוא שבעבודת בדיקות מסורתית מצופה מהעובד שיעבוד עד לשעות מאוחרות בעת הוצאת גרסה ולעתים בסופי שבוע. באג'ייל הבודק נותן את המיטב לאורך הפיתוח ומבטל את ההתאמצות לקראת הסוף. בנוסף יש לקחת משימות ריאליות ללוחות הזמנים.
באג'ייל הלקוחות מוזמנים להשתתף בפיתוח, אם אפשר שנציג ישהה בסביבת הפיתוח. יש כאן יותר מן השותפות מאשר יחסי לקוח / מזמין העבודה. הבודק עובד צמוד ללקוח בכדי שיוכל לאפיין את ה-acceptance tests וידע מה חשוב ללקוח מבחינת איכות המוצר.
אם מתחילים בקבוצת אג'ייל אחת בארגון מסורתי, יש אתגרים המיוחדים למצב הזה. על כל הקבוצות, האג'ייל והמסורתיות, ללמוד להתגמש בכדי שיוכלו לעבוד האחת עם רעותה כשסדר העבודה שונה בתוכן, ולשתף מידע באופן תמידי. ואם אין דרכים מקובלות בכדי לקבל את מה שצריך, צריך להיות יצירתי.
על המנהלים להבין שצוות האג'ייל עובד בצורה שונה, ולתת לו את החופש הדרוש בכדי שיעבדו בצורה יצירתית. על צוות האג'ייל להגיע להסכמה על דרכי הפעולה שלהם. אפשר לנסות כיוונים שונים ולהמשיך עם אלו שנמצאו יעילים יותר.
בחברה גדולה מנהל הבדיקות יכול להיות מדריך שיכול לתת תמיכה ומידע לבודקים ויעזור להם לתקשר עם קבוצתם החדשה.
בזמן השינוי יש לקחת בחשבון תקופה מסוימת של כאוס. בכדי להימנע מזה, יש להסביר את השינוי בצורה מפורטת וליצור תיאום ציפיות.
יש צורך בזמן ובמשאבים בכדי לשפר את הקבוצה, תוך שימת לב שהאיכות של המוצר חשובה מהכמות ומהמהירות. יש צורך במוביל שידע לתקשר עם חלקים אחרים בחברה ותומכים כמו מנהל בדיקות. למעשה על כל ההנהלה להתגייס גם כשבתחילה היא תרגיש אולי איבוד שליטה בהעדר תהליכים פורמליים שהיו קודם. וכאן הקבוצה, לא מנהל, שמחליטה מתי מוצר הוא טוב מספיק.
בשל כך חשוב לעדכן את המנהלים בהתקדמות, להציג מצגות ברורות ולדבר ב"מנהלית" (כמו השפעה על ROI וכד') בכדי שהם ירגישו בשליטה.
מנהלים באג'ייל לא עסוקים בניהול מקרו אלא יותר בהסרת מכשולים מהקבוצה
המעבר עלול להיות ארוך ומתסכל. בשל הקשיים הנ"ל, מומלץ לחגוג פורמלית כל הישג.
בכדי להצליח יש להיות סבלני. לפעמים לקבל את דעת הרוב גם אם לא נכונה וכשזו נכשלת להציע שוב את נקודת המבט שלך. תבנה לך שם בהדרגה. פתח את עצמך ע"י הליכה לכנסים, קריאת ספרים וכד'. אל תסגל את נקודת המבט של "משטרת האיכות" אלא היה חלק מקבוצה שהאיכות חשובה לכולם. אם ניסית את כל זה ולא הלך, אולי כדאי שתחשוב על מקום אחר.
Agile Testing, Lisa Crispin, Janet Gregory, Addison-Wesley 2009
