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

מצאת באג שגורם למערכת לקרוס.

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

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

אתה מחכה…מחכה…מחכה…וזה לא קרה.

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

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

זה כיבה אותך לגמרי. נעשית מתוסכל ואתה לא בטוח מה קורה פה.

אם זה נשמע מוכר, אני איתך. הייתי שם, עשיתי את זה.

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

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

אוקיי, בוא נעשה את זה.

מה היא חומרה של באג?

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

איך יודעים עד כמה הבעיה חמורה?

זוכרים את ההגדרה של באג?

באג הוא "כל מה שמאיים על ערך המוצר" כמו שג'יימס באך מגדיר אותו.

אז עד כמה גרועה הבעיה שווה באופן דומה לעד כמה הבעיה מאיימת על ערך המוצר.

לדוגמא:

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

הבנתם את הרעיון.

הנה כמה חומרות באג ידועות:

  1. קריטית (Critical)– המערכת או האפליקציה קורסות ולא עובדות כלל. אין דרך לעקוף את זה. זה שואו סטופר (Showstopper) והמערכת לא שווה כלום אם הבעיה הזו לא תתוקן.
  2. משמעותית (Major)– אפליקציה משמעותית או רכיב משמעותי של המערכת לא עובדים כמצופה. יש דרך לעבוד על זה.
  3. מזערית (Minor)– תפקוד משני של רכיב במערכת לא עובד כמצופה.
  4. טריוויאלי/קוסמטי (Trivial/Cosmetic)– שגיאת כתיב, חוסר עקביות במראה ובהרגשה, שיפורים וכו'.

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

מהי עדיפות של באג?

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

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

מכל סיבה שהיא, תיקון כל הבאגים זו מטרה לא מציאותית…וזה מוביל אותי לשאלה הבאה:

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

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

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

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

כמו שאתה רואה, הגדרת העדיפות של הבאג היא מורכבת ובעיקרה החלטה עסקית.

הנה כמה דרגות עדיפות נפוצות של באגים:

  • דחוף (Urgent) – תקן מיד.
  • גבוה (High)– תקן בהקדם האפשרי.
  • נורמלי (Normal)– תקן בשחרור הבא.
  • נמוך (Low)– תקן כשיהיה זמן פנוי.

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

לחלק השני של המאמר:

ההבדלים בין חומרה (Severity) ועדיפות (Priority) של באג סוף סוף נחשפים (חלק 2)

דילוג לתוכן