In
God we trust; all others must bring data. W. Edwards Deming
חשיבותה של המדידה
בחברה מסוימת בה עבדתי הייתה בעיה: אחוז הפתיחה מחדש , ה-reopens, של באגים היה ממש גבוה.
אנשי הפיתוח נאלצו להתמודד עם מערכת מורכבת ביותר שכל דבר בה נוגע
בדבר אחר (אין הכוונה לקוד "ספאגטי", כלומר שהקוד היה גרוע, אלא שפשוט
זו הייתה טיבה של המערכת), וכל תיקון באג היה דורש לעצור ולחשוב במה זה יכול
לפגוע.
במקביל, בדיקת באג מתוקן דרשה את אותה מיומנות של הבנה במה שעלול
להיפגע. הבדיקה של התיקון עצמו היה הדבר הקל בד"כ. למעשה, הרבה פעמים הייתי
ממש יודע, אינטואיטיבית, מה יפגע בכל תיקון ותיקון.
בגלל הלחץ הרבה פעמים המפתחים לא חשבו על ההשלכות ומסיבה זו היו משהו
כמו 40 אחוז (אני לא טועה!) reopens. מה עושים? אפשר לחנך, להסביר וכד'. אולי זה טוב כשיש זמן וצד שני
שמוכן ללמוד, אבל אין אף פעם זמן. הפתרון הרבה יותר פשוט: סמנכ"ל הפיתוח
הודיע למפתחים שהם נמדדים מהיום לפי אחוז ה-reopens. אני מניח שזה גם היה קשור לבונוסים ותגמולים כאלה או אחרים.
מאותו הרגע חל מהפך. כשהמפתחים לא הבינו חלק כלשהו מהדיווח של הבאג
הם באו ושאלו. כשלא היו בטוחים בפתרון - הם התייעצו אתנו. היו מקרים שהם התווכחו
פה ושם על פתיחה מחדש של באג עם טיעוני בית דין מפולפלים (זה לא באמת קשור - זה רק
נראה כך), לפעמים הביאו תירוצים שונים ומשונים, אבל בסוף - שהגיע לא אחרי הרבה זמן
- אחוז ה-reopens ירד דרמתית.
זו דוגמא קלאסית לחשיבות של מדידה ומה עושים אתה. הייתה בעיה אמתית,
שגרמה לבזבוז זמן ותסכול לכל הצדדים, והיא נפתרה.
המטרה של המדידה היא לבדוק שהכל עובד כראוי ואם צריך להעלות את איכות
המוצר.
מדידות הן לא רק עניין אסתטי או נתוני טרויה מעניינות ככל שיהיו.
מדידות נועדו בסופו של דבר לשפר את ביצועי המערכת או להתריע על בעיות בזמן אמת.
חשוב לזכור זאת גם בקביעת המדדים וגם בהצגתם. תעשו לעצמכם טובה ואל תמדדו דברים
שאין להם משמעות בשבילכם. מצד שני מה שחשוב יש למדוד באופן קבוע לאורך חיי
המיזם.מהם KPIs?
לפי ווקי:
"מדדי ביצוע מרכזיים (באנגלית: Key
Performance Indicators, בקיצור: KPI) הם מדדים על פיהם אומד
הארגון את רמת ביצועיו. אלו יכולים להיות מדדים כלכליים ולא-כלכליים.
KPI משמש במודיעין עסקי להעריך את המצב הנוכחי של העסק ולקבוע דרכי
פעולה. מקובל לבחון באמצעותו פעילויות שקשה לכמת את מידת תרומתן לארגון כגון פיתוח
מנהיגות, מחויבות לארגון, רמת שביעות רצון וכדומה. המדדים אשר נקבעים כ-KPI, הם על פי רוב יעדים
אסטרטגיים של הארגון ולכן שונים מארגון לארגון ועוזרים לכמת את התקדמות
הארגון לעבר מטרותיו האסטרטגיות."
 |
| Add caption |
אנחנו נתייחס ל-KPI של בדיקות.
אילו סוגי מדידות יש?
יש שתי סוגי מדידות.
מדידות שבאות להתריע בפני בעיות חשובות שאולי אנו לא מודעים לקיומן.
למשל אם רמת הבדיקות ירדה בצוותי האג'ייל לא תמיד אנו יודעים מזה, בעיקר אם הרמה
יורדת בהדרגתיות.
מצד שני יש גם בעיות שהן ידועות ברמת ההרגשה ולא מכומתות. לגבי המצב
הזה, מנהלים לא אוהבים "הרגשות" ולכן כדאי למדוד.
If
you can’t measure it, you can’t manage it. Peter Drucker
אילו מדידות חשובות?
רק המדידות שתוצאותיהן עשויות להסתיים בפעולה מתקנת. אם יש מדידה
ששינוי לכיוון כלשהו לא ידרוש פתרון, וותרו. אם אתם יודעים שמשהו עובד כראוי – אל
תמדדו. אם כולכם מסכימים שיש בעיה ואת הסיבה שלה גם צריך לחשוב אם צריך מדידה
מיוחדת (אלא אם המדידה תעזור בהערכת הפתרון).
לא בטוחים? הנה כמה נקודות למחשבה:
מהי המטרה של ה-KPI. לכן כדאי מראש לכמת את
התווך הרצוי ולוודא שיציאה ממנו תצטרך לגרור פעולות תיקון.
יש הגדרה ברורה ופשוטה (KISS).
מקורות המידע אמינים.
השם ברור ומתייחס למדידה.
למשל אם הזמנים שהצוות נותן הם סבירים וכל מה שתכננו בספרינט בוצע,
אין טעם לבקש מהפיתוח להכניס כל יום דיווח על מה הם עבדו.
איך מודדים?
לגבי איך שאנו מודדים - תדאגו שזה יהיה משהו שנוצר אוטומטית וקל
לעבור עליו. יהיה יעיל שנתונים חריגים יבלטו למשל בצבע שונה.
איך מציגים?
ויזואלית. בשעה שמציגים את הנתונים מומלץ להיות מוכן עם המידע הבא:
א. מדוע יש שינויים אל מול המצב שנקבע בתחילה או כל דבר חריג אחר.
למשל: הבנו שיש לבצע עוד בדיקות שלא היו מתוכננות.
ב. מה אנו מתכוונים לעשות בכדי להחזיר את המצב למצב טוב.
בלי תשובות אין טעם להציג את התמונה (אלא אם זה נקבע מראש כסיעור
מוחות).
סכנות
מלבד הברור שנפספס מדידה חשובה, יש סכנה לא פחות גרועה: הכל נראה טוב
ב-KPIs אבל לא בשטח. למשל היה
מוצר שעבדתי עליו, מצבו היה אנוש. אולם כשמדדו מספר באגים לעומת שורות קוד (מדידה
מקובלת) מצבו היה נראה נהדר. מדוע? כיוון שהוא היה כתוב כל-כך רע שהקוד היה בזבזני
וכל פעולה פשוטה נכתבה על גבי שורות רבות מעבר לדרוש.
אז צאו מהזחיחות ופתחו עיניים :)
תכיפות
תלוי בקלות אספת המידע וכמה הוא ברור. תלוי בחשיבות הנמדד ובכמה זמן
הוא עשוי להשתנות.
מדידות בעידן אג'ייל
אחד מהדברים החשובים שלמדנו מהאג'ייל זה שלא כדאי לבזבז זמן על דברים
מסוימים שלא מועילים או מועילים במעט. מישהי שאלה אותי לא מזמן איך מודדים באגים
אם לא פותחים באגים. לא הייתה לי תשובה בשלוף. נראה שאם יש חדש לבעיה ניתן למדוד
אותה גם כשאין פתיחת באגים בצורה פשוטה של טבלה שתכלול את מהות הבאג ומה רוצים
ללמוד (נניח קומפוננטה). אבל אם יש בעיה שאנו לא מודעים לה זה יהיה קשה יותר.
מצד שני הצוות מנהל את עצמו ואמור להיות מודע לבעיות, ולכן יש
רטרוספקטיב בסוף הספרינט.
דוגמאות למדידות:
לפני שאציג למטה כמה סוגי מדידות שנראות לי מעניינות, נסו לחשוב קודם
כל אם יש לכם הרגשה שמשהו לא בסדר במקום שאתם עובדים בו ואיך אפשר לכמת אותו.
אח"כ יהיה לכם אם הנתונים להבהיר שיש בעיה ולגייס תמיכה ופתרון.
יש לציין שיש עוד הרבה שלא ציינתי - הכל תלוי הקשר למקום בו אתם
נמצאים.
- המדידות שאני מתייחס אליהן הן של תהליכים ולא אנשים.
כללי
|
||
ה-KPI
|
איך
|
למה (או: מה יצא לי מזה)
|
כיסוי הדרישות מול תכנית הבדיקות
|
כמה דרישות מכוסות וכמה לא, כמה בדיקות יש לדרישה (1 - לא הגיוני,
גם 100 לא).
|
בא להראות שלא פספסנו דרישות. מצד שני זה עלול להיות מטעה, כיוון
שיכול להיות מספר סביר ביותר אך זה לא אומר שהבדיקות החשובות בפנים.
|
התקדמות הבדיקות
|
יכול להיות ב-burn down chart.
|
מסביר אם אנו עומדים בזמנים. בהחלט נתון עוזר, אבל רק כשלעצמו הוא
לא אומר הרבה.
כך גם נדע אם טעינו בהערכה ונוכל ללמוד להבא.
בנוסף, נדע מחיר ריאלי של עבודה.
טיפ: על כל תזוזה יש לכתוב הערה כי מרוב שהסביבה שלנו דינמית אפשר
לשכוח אח"כ מדוע עוכבנו.
|
כמה בדיקות עברו וכמה לא
|
מערכת
|
כדי לדעת אזורים פחות טובים, אבל אני מעדיף לראות באגים ולא את זה
כיוון שזה מורכב להבין מתוך "עבר / נכשל" מה זה אומר.
|
זמן אי-עבודה
|
רישום ידני
|
הרבה פעמים העבודה נעצרת בגלל חוסר תמיכה, מעבדות לא כשירות, חוסר
דרישות ועוד. יש לכמת ואח"כ להתחיל למצוא פתרונות מהקריטי לקל.
|
דיווחי
באגים
|
||
ה-KPI
|
איך
|
למה (או: מה יצא לי מזה)
|
גרף באגים פתוחים מול סגורים
|
שני קווים לאורך ציר הזמן
|
מדד ותיק אבל יעיל לפעמים. בא להראות את רמת המוכנות של הגרסה
לשחרור.
אמור להתחיל עם 0 סגורים והרבה פתוחים, הסגורים יעלו הפתוחים
יצטמצמו, עד ששני הקווים יפגשו, ולבסוף מעט פתוחים הרבה סגורים.
אפשר לציין בציר ה-X את
תאריכי קבלת ה-buildים כדי
לראות את השפעה שלהם מול קצב פתיחת הבאגים.
גם בודק את יעילות הבדיקות או ניהול גרסה: הרבה באגים שנפתחים בשלב
מתקדם: האם הייתה תכולה חדשה או הבודקים לא מצאו באגים משום מה בהתחלה?
|
מספר ה-reopens
|
אמור להיות במערכת
|
האם הפיתוח אכן תיקן את הבאג? האם תיאור הבאג היה מקצועי?
|
מספר הבאגים אל מול מספר דיווחי הבעיות מהשטח + באגים שהיו קיימים
בגרסאות קודמות
|
ע"י ציון מיוחד בדיווח הבאג עצמו
|
יעילות של בודקים.
|
כמות ה-rejected bugs
|
אמור להיות במערכת
|
אם אין הרבה, אין בעיה. אם יש כדאי להבין מה הסיבה.
- האם
חוסר הבנת הבודקים של המערכת? אולי כדאי לשפר את הידע הטכני והקשור לבדיקות
- אולי
הבאגים אינם מתוארים בצורה מקצועית?
- אולי
המפתחים כשלו כאן?
- שינוים
תכופים בדרישות?
- בעיות
שאינן משתחזרות? חשבו על לוגים טובים יותר למשל.
|
באגים פר פאזה של חיי מוצר.
|
למשל כמה באגים על דרישות, דוקומנטציה וכד'.
|
|
באגים לפי קומפוננטה או מרכיב לוגי כמו אפליקציה / שרת
|
רישום בדוח הבאג
|
אם יש מקום "מועד לפורענות" אולי כדאי להתעכב עליו יותר,
אולי רה-פאקטורינג בא בחשבון.
|
באגים לפי ההשפעה שלהם.
|
רישום בדוח הבאג
|
פונקציונלי, התקנה ועוד. עוד דרך להבין ממה המוצר סובל מנקודת ראות
גבוהה.
|
שינויי חומרה ודחיפות של באג
|
מערכת ניתור הבאגים אמורה לתת פתרון
|
האם הבודקים נוטים לדרמטיזציה של באגים או להמעטת ערך? אם הראשון,
האם זה כיוון שבאגים חשובים לא מקבלים דחיפות גבוהה ונותרים בבקלוג? או אי הבנה
של המערכת?
|
חומרה של באגים, דחיפות וכד'
|
מהמערכת
|
מצב הגרסה
|
אוטומציה
|
||
ה-KPI
|
איך
|
למה (או: מה יצא לי מזה)
|
כמה זמן לוקח לאוטומציה לרוץ מול בדיקות ידניות
|
רישום זמן של הקוד בתחילת וסוף ההרצה
|
יראה כמה זמן וכסף חסכנו
|
ROI במקרה של בדיקות ידניות מול
אוטומטיות
|
מעקב אחרי שעות הפיתוח ואח"כ לפי המדד הקודם
|
כמה זמן השקענו בפיתוח אוטומציה ותוך כמה זמן תחזור ההשקעה
|
כמות התחזוקה
|
מעקב אחרי שעות התחזוקה
|
גם כאן להבין כמה זה עולה לנו והאם זה יעיל
|
באגים שלא נבעו מהמוצר
|
האם יש הרבה רצות שנכשלו בגלל באג באוטומציה ולא במוצר
|
נבין אם יש בעיה ובזבוז של זמן
|
זמן אי-עבודה
|
מדידה של זמן שהאוטומציה לא רצה בגלל בעיה בתשתיות
|
נבין אם יש בעיה ובזבוז של זמן
|
כיסוי הבדיקות האוטומטיות מסך היקף הבדיקות
|
אם יש מסמכי בדיקות אפשר לסמן מה אוטומטי ואז לכמת את מה שנשאר
|
גם בשביל PR וגם
בשביל להבין כמה עשינו, כמה נשאר, האם הפרויקט הצליח וכד'.
|
כמה באגים האוטומציה חשפה והבדיקות הידניות לא
|
סימון בדיווח הבאג
|
למשל בדיקות רג'יסטרי שבודקים ידניים לא יבדקו כיוון שזה סיזיפי.
|
כמה באגים הבדיקות הידניות חשפו והאוטומציה לא
|
סימון בדיווח הבאג
|
האם האוטומציה יעילה
|
אין תגובות:
הוסף רשומת תגובה