יום שבת, 23 באוגוסט 2014

המעבר הראשוני לאג'ייל - הקשיים וכיצד ניתן להתכונן מראש

הכתוב מטה הוא מעיין סיכום של הפרק השלישי ("שינויים אירגוניים) בספר Agile Testing*

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

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




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



Agile Testing, Lisa Crispin, Janet Gregory,  Addison-Wesley 2009

יום שבת, 16 באוגוסט 2014

"למה הבדיקות לא מצאו את הבאג הזה בזמן?"

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

"למה הבדיקות לא מצאו את הבאג הזה בזמן?"

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

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

בפעם הבאה שמישהו שומע את השאלה הזו, כדאי שיקח את זכות הדיבור ויאמר את הדברים הבאים:

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


וכשמגיעים לחלק של הפקת הלקחים, גם לא שואלים "למה הבדיקות לא מצאו את הבאג הזה בזמן?", אלא את השאלות הבאות:

  • איך אפשר לוודא שהדבר ייצויין בפירוש בדרישות של המוצר?

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


  • איך אפשר לוודא שהדבר ייצויין בפירוש בדיזיין של הפיתוח?

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


  • איך אפשר לוודא שההתנהגות תבדק בפיתוח לפני המסירה לבדיקות?


  • האם כדאי וניתן בתהליך הפיתוח והבדיקות ליצור בדיקה משלימה שהיתה עשויה למצוא את הבעייה?


  • ו-כן, איך אפשר לוודא שבאג קריטי יתגלה מוקדם על-ידי הבדיקות?

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

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



יש לציין שבגישת ה"עליהום" יש חסרונות רבים:

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

רשומות פופולריות