אמות מידה לחומרת תקלות

[אבי ע]

אמות מידה לחומרת תקלות ../images/Emo39.gif

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

(את אמות המידה שלי פירטתי בפתיל קודם, כזכור)

 

[אבי ע]

ערן, סקרולוק, מישהו?

 

[erandd]

תגובה בקרוב

 

[ScrollLock]

טוב, אני מעדיף מינימליזם

כעיקרון, אני רואה את עצמי כמינימליסט ואני גם מחנך אחרים למינימליזם. אומרים ש- "סייג לחכמה - שתיקה" וכך גם אני גורס. לז*$#%& ת'שכל מה שפחות. ומכאן גם נגזרות אמות המידה שלי (שלנו) לחומרה של תקלות - 1. Critical - Data loss- הכי רציני - נגרם נזק ממשי ללקוח. פתיחת באג בחומרה כזו, כדאי שתהיה מלווה בשיחת טלפון והסברים ממש ממש טובים. 2. Urgent - לרוב מסמל תקלה שמונעת המשך עבודה על המערכת. 3. Medium - Required for next build - מסמל בקשה לתיקון מסויים עבור ה-Build הבא. יכול לסמל גם באג, אבל כזה שניתן בינתיים לחיות איתו. 4. Feature Request - עדיפות נמוכה (בקשה לתוספת/שינוי) 5. On - Hold - כל מה שלא גובשה דיעה סופית לגביו או באגים שלא ניתנים לשיחזור בצורה קונסיסטנטית. זה הכל - לא צריך ליצור הבדלה (כמו שמקובל בכל תוכנות ניהול הבאגים הגדולות) בין Priority ל- Severity. זה מה יש וזה מספיק. *לגבי הפורום - פורום מסוג כזה, שפונה לחתך אוכלוסיה כל כך קטן (אנשי QA\QC דוברי עברית), טבעו יהיה להישאר מצומצם מאוד.

 

[אבי ע]

נו טוף, לא כולם חכמים... ../images/Emo39.gif

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

 

[Rשף]

אצלינו המצב עגום

קיים רק ערך שנקרא Priority והשיקולים לבחירתו הם די ערטילאיים ונתונים בעיקר בידי ראשי הצוותים ללא הגדרה מוחלטת.

 

[עפר פרת]

למה לא לכנס את כולם ולהגדיר?

 

[Rשף]

כי מנהל הפיתוח מסתפק בזה

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

 

[xslf]

בגדול

אצלנו: * critical - קריסה / איבוד מידע * blocker - באג שחוסם אפשרות שימוש בפיצ'ר או בדיקה של אזור מסויים * major - פונקציונליות עיקרית נפגעה, או באג בעל visibilty גבוה * normal - רוב הבאגים נכנסים לכאן * minor - בעיקר באגים קוסמטיים

 

[erandd]

חשוב ודחוף

נתקלתי במודל שמדבר על 2 פרמטרים לקביעת חומרה של באג: דחיפות וחשיבות חשיבות נגזרת מכל הפרמטרים שציינתם דחיפות גם היא פרמטר שצריך להקבע עם אנשי המוצר לגבי הדחיפות של התיקון. לדוגמה מודול ש1% בלבד מהמשתמשים נכנס אליו שונה ממודול ש 90% נכנסים אליו ולכן המודול השני יהיה דחוף יותר מהמודול הראשון) בכל מקרה אפשר לאחד את שני הקריטריונים לקריטריון אחד ולקבוע שבאגים זהים בשני המודולים הנ"ל יקבלו דרגת חומרה שונה

 

[ScrollLock]

הכל עניין של השקפה...

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

 

[אבי ע]

דחוף וחשוב ../images/Emo39.gif

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

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

 

[erandd]

מודל משונן מחייב התנהגות משוננת

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

 

[אבי ע]

המממ... ../images/Emo39.gif

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

 

[אבי ע]

תודה לכם. סופסוף זה מתחיל... ../images/Emo39.gif

להיראות כמו פורום פעיל... עדיין מעט משתתפים, אבל מובחרים

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